Resolver não é aprender
Um serviço falha, a equipa arranja-o, todos respiram e voltam ao que estavam a fazer. Três meses depois, a mesma falha, noutro serviço, com outra pessoa de prevenção que não sabia o que aconteceu da primeira vez.
Resolver um incidente é necessário. Mas se no fim do incidente a plataforma estiver exatamente igual a antes, o único que se ganhou foi tempo.
O ciclo completo
- Recuperar o serviço, com o procedimento desenhado para isso (vimo-lo ao desenhar para falhar).
- Analisar sem procurar culpados. A pergunta não é quem se enganou, mas o que permitiu que o erro chegasse a produção.
- Encontrar a causa de raiz, que quase nunca é a óbvia. «Alguém carregou uma configuração errada» é o sintoma; «nada verificava essa configuração antes de a implementar» é a causa.
- Transformá-la em algo permanente.
O que conta como «permanente»
Não conta «ter mais cuidado». Conta algo que continue a funcionar quando todos se tiverem esquecido do incidente:
- Um teste que teria detetado a falha.
- Uma validação automática na construção, como as do artigo sobre que falhe a construção.
- Uma regra na norma da organização, com a sua verificação.
- Um registo de decisão se a falha revelou que uma decisão de desenho já não se sustenta.
Medi-lo
Uma plataforma que aprende nota-se em dois números: os incidentes repetidos descem e cada vez mais falhas param na construção em vez de chegarem a produção.
Muitas dessas regras e validações são hoje aplicadas por assistentes de IA que trabalham dentro da plataforma. Como se governa isso é o último bloco da série.
Como o aplicamos: Engenharia de Plataforma.