- Mesmo na era da codificação agêntica, a demanda por engenheiros de software tende a aumentar; o ponto central está na capacidade de operar serviços, e não de escrever código
- Escrever código sempre foi a parte fácil; o realmente difícil é operar sistemas com estabilidade por longos períodos
- Assim como nos casos de no-code e planilhas, até não especialistas podem criar ferramentas, mas o peso da manutenção e da operação no fim exige engenharia profissional
- Usuários não compram software, e sim serviços; um bom software deve funcionar de forma invisível
- Excelência operacional (operational excellence), como uptime, taxa de falhas, velocidade de recuperação e atualizações de segurança, é o núcleo da competitividade no futuro
- Como função que atende a todas essas exigências, o SRE está se tornando o centro da engenharia de software
SRE deve se tornar a função mais contratada
- Quando o código fica barato, quem vence é a excelência operacional
- Qualquer um consegue fazer uma demo greenfield, mas para operar um serviço com estabilidade é preciso capacidade de engenharia
- "Todo mundo quer criar demos greenfield, mas ninguém quer operar serviços"
- Engenharia de software não é programação pura e simples, e sim gerenciar sistemas que mudam ao longo do tempo
A lição da era do no-code e das planilhas
- Joe, do time de contabilidade, reduziu de 10 horas para 1 hora por semana uma tarefa repetitiva usando ferramentas no-code e macros de planilha
- No começo, os resultados foram claros, mas com o tempo a complexidade cresceu rapidamente
- Mudanças no ambiente de negócios, alterações nas regras contábeis e o acúmulo de problemas com fuso horário e horário de verão
- A cada semana apareciam novos edge cases, exigindo ajustes e correções contínuos
- No fim, Joe passou a ficar preso ao sistema que ele mesmo criou
- Mesmo nas férias, precisava se preocupar com o sistema, e era difícil passar a operação para outra pessoa
- Executar o código e conferir os resultados por si só virou fonte de ansiedade e tensão
A doença do computador (The Computer Disease)
- Conceito batizado por Feynman: o problema dos computadores é que eles fazem você querer mexer neles o tempo todo
- Automatizar em si é divertido, mas existe a armadilha de automatizar até áreas desnecessárias e aumentar a complexidade
- O verdadeiro peso está na operação do serviço
- Mantê-lo funcionando com estabilidade
- Escalá-lo em ambientes de grande porte sem problemas
- Gerenciá-lo continuamente ao longo de anos
- Na entrega de serviços, estabilidade, confiabilidade e continuidade são fundamentais
Por que a excelência operacional é o futuro
- As pessoas não compram software; elas contratam um serviço que resolve um problema
- Ninguém se importa com o funcionamento interno do iCloud; espera apenas que as fotos estejam sempre sincronizadas automaticamente entre dispositivos
- Não importa como Word, Notion ou gDocs foram feitos; o essencial é a experiência de escrever e compartilhar ideias
- Mais importante que a arquitetura da rede de pagamentos é o resultado de conseguir pagar, sem problemas, um matcha latte de 7 dólares
- Um bom software é invisível (funciona de forma natural, sem chamar atenção para si)
Os desafios de engenharia realmente difíceis
- Os primeiros 90% para criar uma demo funcional são fáceis; os 190% restantes são os que realmente importam
- Perguntas que precisam ser respondidas do ponto de vista operacional:
- Qual é o uptime
- Qual é a taxa de ocorrência de falhas
- Em caso de incidente, quão rápido é o tempo de recuperação
- Os problemas são detectados antes de o usuário perceber
- É possível gerenciar as dependências upstream
- Quando há problema com fornecedor, ele é detectado antes das reclamações dos usuários
- Quanto tempo leva para incorporar ideias sugeridas pelos usuários
- Há mecanismos para impedir que engenheiros quebrem os sistemas uns dos outros
- Existe um sistema que permita aos engenheiros seguir avançando sem que o app vire uma massa confusa
- É possível lidar com software numa escala que não cabe na cabeça de uma única pessoa
- Se um grande problema acontece enquanto o engenheiro dorme em um fuso horário com 12 horas de diferença, ele é resolvido antes de o usuário desistir
- É possível se recuperar de falhas internas e de falhas upstream, ou dados importantes se perdem
- As atualizações de segurança estão sendo aplicadas continuamente
- Os dados dos usuários não sofrem vazamento
- Dá para confiar
- Dá para depender disso
- Existe evidência que sustente essa confiança
- É possível assinar uma garantia juridicamente vinculante de que o software funcionará quando necessário
- Esses são os verdadeiros desafios difíceis da engenharia, e escrever código é a parte fácil
8 comentários
A reação nos comentários kkkkkk realmente parece uma versão podada, mantendo só o que era necessário do conteúdo original~ gostei da leitura
Resultado da análise por IA: bip bip bi bi biiic... 95% de probabilidade de ser um blog de IA.
kkkk 90 190 kkkk
kkkkkkkkkkkk
Do que você está falando?
Acho que teria sido melhor se viesse junto uma explicação do que é SRE.