Sobre

Sou o Cauê Braz. Comecei a programar aos catorze anos por causa de um jogo. Eu jogava Tibia, e em algum momento jogar não bastou. Eu queria meu próprio servidor, com as minhas regras, e os projetos de servidor aberto da época eram escritos em C e C++. Então aprendi C e C++ do jeito que um moleque aprende qualquer coisa que ele quer de verdade: mal, de madrugada, lendo fórum e código dos outros, quebrando tudo até rodar. Na primeira vez que um amigo entrou num mundo que eu mesmo tinha compilado, entendi o que eu queria fazer pelo resto da vida. Só ainda não tinha a palavra para isso.

Isso foi há mais de vinte anos. Nos últimos quinze eu sou pago para escrever software, e nos últimos dez trabalho na parte dele que decide se todo o resto se sustenta. Como a produção é arquitetada e como ela falha. Como o código sai de um pull request e chega rodando na frente dos usuários. Quem alcança o quê, e como saberíamos. Quanto a plataforma custa e o que isso compra. Hoje faço isso como Staff DevOps e Platform Engineer, do Brasil, para times que constroem produtos e sistemas de IA. O moleque que queria o próprio servidor virou alguém que cuida dos servidores para que outras pessoas construam os mundos delas em cima.

Antes de trabalhar principalmente com infraestrutura, passei anos construindo software. Isso muda o jeito como olho para uma plataforma. Sei o que é depender dela para colocar uma mudança em produção e sei o que é mantê-la funcionando depois.

O que me puxou para infraestrutura é a mesma coisa que me mantinha acordado aos catorze. Eu quero saber o que está acontecendo por baixo. E com os anos percebi uma coisa sobre o que acontece por baixo: sistemas falam. O incidente que volta todo trimestre. O passo manual que todo mundo conhece e ninguém tira. A credencial que mora num documento compartilhado porque o dia em que foi criada estava corrido. Eu não leio isso como falha. Leio como mensagem de um sistema que não achou outro jeito de ser ouvido e por isso se repete. Quando vejo uma, eu desacelero, fico no não saber um pouco mais do que é confortável, e pergunto o que a repetição está protegendo antes de tentar tirá-la. A maior parte do que sei sobre operar sistemas eu aprendi escutando desse jeito.

O que eu preciso dos sistemas que opero Link para o cabeçalho

Fico tranquilo quando consigo responder “como isso está configurado” abrindo um repositório. Fico inquieto quando a resposta mora na cabeça de alguém, e essa inquietação acabou sendo útil. Ela aponta a próxima coisa que precisa ser escrita. Então a infraestrutura que eu construo é código, passa por revisão como código, e o número por trás de uma decisão vem com fonte e data. Quando não vem, eu digo que é premissa na mesma frase.

Preciso que a proteção esteja resolvida antes do crescimento. Backup que já foi restaurado de verdade. Acesso que dá para auditar. Alguma folga para o dia em que a fatura do provedor dobrar. Depois disso me sinto livre para deixar as coisas mais rápidas ou mais baratas.

Preciso que um sistema caiba na cabeça de uma pessoa. Quando não consigo auditar de ponta a ponta, me pego confiando nele em vez de conhecê-lo. Confiança sem conhecimento é onde o próximo incidente já está esperando.

O que eu faço Link para o cabeçalho

A palavra “staff” no meu cargo fala de posição, não de patente. Meu trabalho atravessa times. Entro quando uma decisão deixa de caber em um único contexto e fico até que ela esteja clara o suficiente para ser contestada e colocada em prática sem depender de mim. Com o tempo passei a ver que, por trás dessas decisões, existe uma lista curta de perguntas que o sistema repete com palavras diferentes. Meu trabalho é ouvir qual delas está sendo feita.

Ele é confiável. Quando falha, falha de um jeito que a gente entende, numa escala que a gente consegue pagar, e volta sem alguém heroicamente acordado às três da manhã? Quero que a falha seja um comportamento desenhado, não uma surpresa. Um sistema sem modo de falha declarado tem um mesmo assim. Só ainda não contou.

Dá para ver. O sistema produz evidência do próprio comportamento, em logs, métricas e traces que uma pessoa lê como uma história só? Me sinto perdido dentro de um sistema que não consegue se descrever, e perdido é onde eu tomo minhas piores decisões. Observabilidade é como eu paro de adivinhar.

É seguro. Quem alcança o quê, como a gente sabe, e a gente perceberia se isso mudasse? Quero que o acesso seja o mínimo que a pessoa precisa, pelo tempo em que precisa, escrito num lugar onde uma terceira pessoa consiga conferir. Toda credencial que mora na memória de alguém é uma promessa que a organização fez sem perceber.

Quanto custa, e o que isso compra. Eu leio uma fatura como descrição de comportamento. Custo é onde a intenção encontra a realidade, e uma linha que cresce sem ninguém ter decidido é uma decisão que o sistema tomou sozinho. Cada unidade de gasto deveria ter dono e motivo, ou deveria sair.

Aguenta. Performance e escala são a mesma pergunta em duas distâncias. O sistema faz o trabalho no tempo que uma pessoa aceita esperar, e continua fazendo quando aparecem dez vezes mais pessoas? Prefiro achar o limite antes do tráfego e transformar o limite num número que a gente escolheu.

Dá para mudar. Quanto tempo entre uma ideia e essa ideia rodando em produção, e quanto medo tem nesse caminho? Eu meço entrega pela pouca coragem que ela exige. Um time com medo de fazer deploy ouviu alguma coisa sobre o próprio sistema. O medo é a mensagem.

E aí a versão mais nova de tudo isso, perguntada sobre IA. Qual modelo está sendo chamado, por quem, a que custo, com quais dados, e quem saberia se qualquer dessas respostas mudasse hoje à noite. Plataforma para IA é a velha disciplina com uma fatura mais rápida, e eu quero a governança no lugar antes que a fatura ensine.

Escrevo RFCs porque essas perguntas se respondem por escrito ou não se respondem. Um documento que um time consegue ler, contestar e adotar é a unidade real do meu trabalho. A infraestrutura que vem depois é consequência.

Como eu gosto de trabalhar com pessoas Link para o cabeçalho

Quando eu discordar de algo, vou dizer o que vi, onde, e o que isso causou. Não vou dizer o que você é. “O job na linha 42 falha com timeout porque o limite de ociosidade é 30 segundos” é algo em que podemos trabalhar juntos. “Isso está quebrado” não é. Tento dizer em voz alta a necessidade por trás da minha posição, e tento fazer pedidos que você possa recusar.

Parte do meu trabalho é deixar contexto suficiente para que outra pessoa consiga tomar a próxima decisão sem precisar me chamar.

Começo pela notícia ruim, e pelo número por trás dela. Quando eu suavizo, a outra pessoa escuta a suavização e perde a notícia, e nós dois perdemos um dia.

Eu erro com frequência. Quando você vir, me diga o que viu e o que aquilo produziu. Não vou defender uma posição depois que a evidência foi embora.

O que você vai encontrar aqui Link para o cabeçalho

Aqui eu compartilho o que aprendo fazendo o trabalho descrito acima. Coisas que deram errado e o que me ensinaram, decisões que eu repetiria e outras que não, e de vez em quando uma nota sobre uma ferramenta que mereceu o lugar. Escrevo para que alguém que encontre o mesmo problema mais tarde tenha um ponto de partida em vez de uma página em branco.

Se algo disso te ajudar, ou se você enxergar algo que eu deixei passar, vou gostar de saber.