2. serviços em produção
Sendo a maior parte escrito
em Clojure e rodando em
Kubernetes.
engenheiros mensagens produzidas/dia
Em mais de 30 squads, indo
de produto à plataforma.
Usamos Kafka para todas as
comunicações assíncronas.
clientes
Em produtos como cartão,
Rewards e NuConta.
8. Post-mortem
“Processo de documentar um incidente, com seu
impacto, ações tomadas para mitigar ou resolver,
sua causa e action items que previnam que
aconteça novamente.”
Site Reliability Engineering (O'Reilly)
9. Blameless
Não se tem um único culpado
em um incidente, se um erro
humano aconteceu a culpa é
do tooling, dos processos,
entre outras coisas.
11. Timeline
Tão importante quanto saber
o que aconteceu é saber em
que ordem aconteceu. Todas
as pessoas envolvidas podem
contribuir com isso, assim no
final você sabe exatamente o
que foi feito para resolver o
incidente.
13. Root causes
Com a timeline é muito mais
fácil descobrir qual foi o
evento que causou todo o
incidente (causas raízes) e
assim descobrir como evitar
que aconteça novamente.
14. Root causes
Woods' Theorem:
As the complexity of a system increases, the
accuracy of any single agent's own model of that
system decreases rapidly.
15. Aprendizados
Quando conduzindo um
post-mortem nosso objetivo é
aprender, então esse deve ser
o nosso foco. Como por
exemplo, saber o que
funcionou e não funcionou
durante a resposta ao
incidente.
16. Prevenção
Tendo tudo isso que já
comentamos, é hora de
descobrir o que precisamos
fazer para evitar que o
incidente aconteça de novo.
17. Action items
O resultado de um
post-mortem são action items
que vão corrigir ou mitigar a
causa raiz, é importante que
cada um deles tenha um
"dono".
18. Compartilhe!
É importante que todas as
pessoas, em especial as da
engenharia, tenham acesso
aos post-mortems
pregressos. Assim como
qualquer conhecimento, é
preciso disseminar o que se
aprende com os incidentes.
19. E por fim,
celebre!
O incidente foi doloroso,
preocupante mas trouxe
muitos aprendizados e coisas
para melhorar, depois de tudo
feito comemore por isso.
20. Recap
Não existe um único culpado, seja uma pessoa ou um único evento
Escreva a timeline com a ajuda de quem participou e LOGO
Documente todos os aprendizados e compartilhe!
Comemore a oportunidade de tornar seu sistema mais anti-frágil
24. Por que esse incidente?
Incidente global que atingiu muitas empresas e desenvolvedores
A stack de monitoramento da Cloudflare é parecida com a do Nubank
Post-mortem público e detalhado
6 ANOS sem um outage global
26. Root causes
"Although the regular expression itself is of interest to many people
(and is discussed more below), the real story of how the Cloudflare
service went down for 27 minutes IS MUCH MORE COMPLEX THAN
A REGULAR EXPRESSION WENT BAD. We’ve taken the time to write
out THE SERIES OF EVENTS that lead to the outage and kept us
from responding quickly."
27. Root causes
A protection that would have helped prevent excessive CPU use by a
regular expression was removed by mistake during a refactoring of
the WAF weeks prior—a refactoring that was part of making the WAF
use less CPU.
The SOP allowed a non-emergency rule change to go globally into
production without a staged rollout.
The rollback plan required running the complete WAF
build twice taking too long.
SREs had lost access to some systems because their credentials
had been timed out for security reasons.
