The Delivery Hero Reliability Manifesto (tradução)

Como cada ponto é profundamente marcante, não consegui fazer um resumo simples, então vou apenas listar alguns dos que mais me impactaram.

• Não viole o Manifesto; em vez disso, discuta mudanças nas regras para evoluir o próprio Manifesto.
• Todos os serviços devem ser documentados em diagramas de arquitetura, incluindo suas dependências, e a arquitetura deve passar por revisão.
• Quem produz dados também deve documentar os dados que produz.
• Até deploys feitos na sexta-feira devem funcionar de forma estável.
• Implemente lógica de defesa para cenários de falha (timeout, retry, circuit breaker, fallback, throttling, idempotência etc.).
• Crie dashboards para monitorar o estado dos serviços (requisições por minuto, taxa de erro, tempo de resposta do servidor, métricas de negócio).
• Documente em runbooks como analisar e reproduzir problemas, e conecte isso aos alertas para minimizar o tempo de recuperação.
• Quando surgir um problema, arregace as mangas e ajude a resolvê-lo.
• Vamos interpretar toda conversa por texto sempre partindo da premissa de que há uma intenção de boa-fé.
• Para refletir ações relacionadas à segurança no desempenho das equipes, crie e publique uma tabela de pontuação de segurança por time.
• À medida que o número de pedidos no sistema aumenta, o custo por pedido deve cair. Seria bom reduzir esse custo em 10% por trimestre.
• Monitore lead time (do início do desenvolvimento até o deploy em produção), frequência de deploy, tempo de recuperação e a taxa de erro durante o período de recuperação.

Há ainda muito mais conteúdo, e enquanto eu lia, também fiquei pensando em quantas pessoas contribuíram para construir algo assim... É um texto que realmente desperta um sentimento de admiração.