Head of DevOps, SRE & Security (DevSecOps)
Group CTO de 145 pessoas em seis países, e ainda com a mão na massa. Infraestrutura de pagamentos para um banco central, uma plataforma de agentes de IA em três nuvens, dez A100 em bare metal e duas certificações aprovadas em auditoria.
- 99,999%no Bakong, o sistema de pagamentos do Banco Nacional do Camboja
- 0 achadosna auditoria de manutenção da ISO 27001; SOC 2 Type II aprovado duas vezes
- 145 pessoasem seis países, com reporte ao CEO
Trajetória
O que eu já conduzi
Oito áreas, um mesmo padrão de evidência
Liderança
145 pessoas · 6 paísesGroup CTO · Head of DevOps, SRE & Security
Liderança
145 pessoas · 6 países- Toda a organização se reportava a mim, com escritórios no Japão, Rússia, Suíça, Montenegro, Tailândia e Dubai. Eu me reportava ao CEO.
- Montei primeiro a organização técnica: 37 subordinados diretos no pico, sendo 12 de DevOps, 6 de segurança e 19 de QA.
- Na Everworker: projeto do zero, sem ferramentas, processos nem equipe. Construí um time de segurança com 4 pessoas.
Pagamentos e CBDC
99,999%Bakong · pilotos de CBDC
Pagamentos e CBDC
99,999%- Confiabilidade e segurança do Bakong, o sistema de pagamentos do Banco Nacional do Camboja, escrito em Java sobre Hyperledger Iroha.
- Mais de US$ 150 bilhões liquidados em 2024, cerca de 330% do PIB do Camboja, e 1,3 bilhão de pagamentos em 2025, conforme divulgado pelo NBC.
- Pilotos de CBDC em todo o grupo. Contribuí para o prêmio “CBDC Partner of the Year”, da Central Banking, em 2020.
Plataforma e IA
300+ apps · 99% IaCAWS · Azure · GCP · bare metal
Plataforma e IA
300+ apps · 99% IaC- Uma plataforma de agentes de IA em três nuvens, entregue como SaaS e autohospedada nas contas dos próprios clientes.
- Listagem no AWS Marketplace com Helm charts para três nuvens, entregue sozinho depois de me dizerem que seriam necessários parceiros pagos. AWS Marketplace
- 10 × NVIDIA A100 em bare metal no Moro Hub, em Dubai (Tier III), depois que uma única instância de GPU esquecida queimou milhares de dólares em dois dias.
- Mais de 300 aplicações, mais de 700 repositórios, 6 organizações no GitHub. Tempo de build 40% menor, custo mais de 30% menor.
Confiabilidade
MTTR −60%Prática de SRE criada do zero
Confiabilidade
MTTR −60%- SRE embarcado em mais de 20 times stream-aligned em 4 regiões: SLIs, SLOs, orçamentos de erro, comando de incidentes, revisões sem culpados.
- SLA de 99% para 99,99%. Backup e DR automatizados para 5 sistemas críticos, com as restaurações realmente executadas.
- Um on-call em que dá para viver: escala diária, um backup em cada turno, um runbook e uma métrica para cada alerta.
Segurança e conformidade
0 achados em auditoria de manutençãoISO 27001 · SOC 2 Type II · NIST CSF
Segurança e conformidade
0 achados em auditoria de manutenção- ISO/IEC 27001:2022: 5 não conformidades menores da auditoria inicial encerradas e primeiro ano de manutenção aprovado com zero achados. Trust Center
- SOC 2 Type II aprovado por dois anos seguidos, com escopo ampliado para Privacidade e Disponibilidade. Conduzi o programa NIST CSF por demanda de clientes.
- SDLC seguro para mais de 100 desenvolvedores: modelos de ameaças STRIDE e VAST, pontuação CVSS e EPSS, Security Champions. Janelas de exposição 70% menores.
- Pentest independente: 12 achados (1 alto, 6 médios, 5 baixos) triados; os principais viraram checks de regressão de DAST, então continuam sob teste.
Produtos
2 produtos · 2 × 12 pessoassob minha responsabilidade de ponta a ponta
Produtos
2 produtos · 2 × 12 pessoas- Um sistema de pagamentos para ilhas do Caribe, com time próprio de 12 pessoas.
- Um sistema de pontos de fidelidade para um grande ecossistema, com time próprio de 12 pessoas.
Web3
mesmos gates dos pagamentosPolkadot · Klaytn · SORA
Web3
mesmos gates dos pagamentos- Grants da Web3 Foundation, desenvolvimento no ecossistema Polkadot, Klaytn e o ecossistema SORA, sobre os mesmos pipelines e gates de segurança dos sistemas de pagamento.
- Palestrante no Next-Generation Payments 2023 e em conferências de fintech em Bangkok.
Revisões de incidentes
Vindos de resposta a incidentes, auditorias e trabalho em plataformas de clientes. Cada um terminou em um controle, não em um patch.
Exfiltração de código-fonte e tentativa de extorsão
87.000 eventos analisados
- Detecção
Atividade anômala em repositórios.
- Investigação
Perícia forense em uma exportação de auditoria com 87.000 eventos. O alcance da credencial foi testado de novo, não presumido.
- Correção
Contenção e redefinição da credencial, depois acessos de toda a organização reconstruídos como Pulumi IaC para que concessões manuais não possam voltar.
Uma rotação de credencial que o monitoramento não conseguia ver
0 dados perdidos · corrigido no mesmo dia
- Detecção
Em uma plataforma de cliente, o banco de dados gerenciado rotacionou a senha mestre conforme o agendado e a aplicação perdeu a conexão com o banco durante a noite. Nenhum alerta disparou.
- Investigação
A aplicação lia a senha uma única vez, no deploy. Uma revisão do alerting mostrou que cada regra era cega à sua maneira: o processo continuava de pé, os limites de erro ficavam acima do que esse tráfego consegue atingir mesmo numa falha total, e o alerta do pool culpava queries lentas.
- Correção
No mesmo dia: a aplicação passou para um papel de menor privilégio com uma senha que o time controla, e agora o deploy falha se essa credencial não conseguir fazer login. Novos alertas para pool vazio, endpoint de health, piso de conexões e backup ausente. Nenhum dado foi perdido.
Webhooks falhando em uma a cada quatro requisições
corrigido no upstream para todos os usuários
- Detecção
Em uma plataforma de cliente, erros 500 em webhooks, assinaturas divergentes e erros de CSRF atingiram cerca de um quarto das requisições POST depois que uma imagem upstream mudou por baixo da release fixada.
- Investigação
Corpos chunked chegavam vazios à aplicação: ela lê o corpo por Content-Length, e uma requisição chunked não tem esse cabeçalho. Os 500 não eram registrados em lugar nenhum, porque o logging padrão do framework os engolia com debug desligado.
- Correção
O buffering de requisições virou o padrão na ferramenta de deploy open source, a aplicação remonta os chunks na camada WSGI, os webhooks nunca respondem 5xx e os erros vão para logs estruturados.
Connection refused, 14 segundos por vez
0 de 7.254 probes falharam
- Detecção
Usuários finais de uma plataforma de cliente relataram conexões recusadas na porta 443. O autoscaler da nuvem tinha removido o proxy de borda 37 vezes naquele dia, contra 0 a 8 por dia antes.
- Investigação
O proxy drenava por 10 segundos; o load balancer precisava de cerca de 24 para tirar o nó. Reproduzi com um probe a cada meio segundo: uma janela de 14 segundos em que cerca de metade das novas conexões falhava.
- Correção
Drenar por mais tempo que o health check, proxies espalhados à força entre hosts, e as duas configurações adicionadas à ferramenta open source. 0 falhas em 7.254 probes ao longo de vários rollouts.
Um processo de release com uma etapa que dava para pular
deploys agora são tudo ou nada
- Detecção
Em uma plataforma de cliente, a produção rodou de 20 a 30 minutos sem o processador de tarefas em segundo plano, enquanto o uptime continuava verde: o worker não tinha sido implantado, então não havia o que alarmar.
- Investigação
O release dependia de dois passos manuais separados, web e depois worker, e nada verificava se os dois tinham rodado. Foram descartadas as verificações pré-merge e o admission control: o git estava correto, e o worker nunca foi enviado.
- Correção
Serviços divididos agora são implantados como um único workflow ordenado, que fica vermelho a menos que as duas metades tenham sucesso, e o deploy isolado do worker foi removido. Alertas de paridade continuam como rede de segurança.
Alertas em que ninguém confiava
89% falsos → 0
- Detecção
232 disparos de alarme do CloudTrail em 14 dias, cerca de 89% de falsos positivos.
- Correção
8 detectores além da baseline CIS, com exclusões por detector: disparos diários de um dígito, zero falso positivo na primeira janela e um runbook para cada alerta.
O vigia que parou de vigiar
execuções travadas se liberam sozinhas
- Detecção
O dead-man's switch de um cliente tinha parado em silêncio: por 4,5 dias, toda execução agendada terminou cancelada.
- Investigação
Uma execução que a plataforma de CI deixou na fila segurou o concurrency group para sempre. Timeouts não valem antes de um job começar, então cada execução seguinte esperava e depois era cancelada. Repetiu em menos de um dia.
- Correção
Workflows agendados curtos agora cancelam a execução em andamento, e uma execução presa é substituída pela seguinte em vez de bloqueá-la.
Uma conta 52% maior com 4% de CPU
11 nós fixos → 5-9 sob demanda
- Detecção
Revisão de custos em uma plataforma de cliente: a previsão subiu 52% em um mês, com 18 nós rodando a cerca de 4% de CPU.
- Investigação
O disruption budget padrão da ferramenta de deploy deixava serviços de réplica única com zero remoções permitidas, então o autoscaler nunca conseguia drenar um nó. Cada novo white-label prendia mais um.
- Correção
Um budget que permite uma remoção, aplicado em 13 repositórios. A produção foi de 11 nós fixos para 5-9 sob demanda, e o staging de 7 para 3. A troca do padrão no upstream foi segurada: muita mudança acumulada para uma produção de pagamentos.
Um ISMS que declarava ferramentas que a empresa não tinha
29 políticas verificadas
- Detecção
29 políticas herdadas, redigidas por IA, que citavam MDM, EDR e serviços de diretório que não existiam.
- Correção
Verificação de cada ferramenta e função citada tornada obrigatória antes da aprovação. A IA redige, a evidência decide.