Introdução

A Hierarquia de Confiabilidade de Dickerson oferece um mapa para navegar pelos desafios de confiabilidade; o que precisa ser abordado e em que ordem. Como outras hierarquias desse tipo, é importante que o nível em que você está seja sólido antes de subir na pirâmide.

Da base para cima, os sete níveis são:

1. Monitorização: Não se pode melhorar aquilo que não se vê.
2. Resposta a Incidentes: Processos fiáveis e repetíveis para reagir quando são acionados alertas.
3. Revisão Pós-Incidente: Aprender com os incidentes que ocorrem (foco deste módulo).
4. Testes e Lançamento: Detectar regressões antes que cheguem à produção.
5. Planeamento de Capacidade: Garantir que o sistema tem os recursos necessários para satisfazer a procura.
6. Desenvolvimento: Escrever software fiável.
7. Produto: Construir a coisa certa para os utilizadores.

Este módulo aborda o nível aproximadamente no meio da pirâmide. Depois de abordares a tua monitorização e resposta a incidentes (talvez com a ajuda de outros módulos Learn neste percurso de aprendizagem), tens agora a oportunidade de te focar em princípios e práticas que te podem ajudar a melhorar a tua prática operacional.

A hierarquia é adaptada do livro Hierarchy of Reliability Needs, de Mikey Dickerson.

Neste módulo, vamos focar-nos em revisões pós-incidente que podem ajudá-lo a aprender com falhas, resultando numa maior fiabilidade.

Depois de concluir este módulo, você irá:

• Descubra a importância de aprender com os incidentes.
• Compreender os aspetos de sistemas complexos que tornam importante aprender com o fracasso.
• Saiba quando e como realizar uma revisão pós-incidente.
• Compreender o propósito e os objetivos de uma revisão pós-incidente.
• Aprenda os componentes que fazem parte de uma boa revisão pós-incidente.
• Explore as ferramentas do Azure que podem ajudar a iniciar as revisões pós-incidente.
• Esteja atento às armadilhas comuns a evitar.
• Identifique práticas úteis para realizar uma melhor revisão.

Uma história introdutória

Para contextualizar este módulo, aqui está uma história verdadeira (ou metade dela, na verdade; chegamos à segunda parte mais à frente neste módulo):

Durante a Segunda Guerra Mundial, a aeronave B-17 "Flying Fortress" esteve envolvida em uma série de acidentes. Não sabemos todos os detalhes desses acidentes e não sabemos exatamente quantos foram. Era tempo de guerra, e muitos dos detalhes eram secretos e continuam a ser. O que sabemos é que houve um número significativo de incidentes semelhantes envolvendo muitas aeronaves individuais. As versões históricas tendem a focar-se em aeronaves danificadas em vez de ferimentos graves, mas o registo de guerra é incompleto.

Em cada caso, o que acontecia era o seguinte: um B-17 chegava para aterrar, aterrava com sucesso, e depois, seja na pista ou ao taxiar de volta ao hangar, algo estranho acontecia. Algo grave aconteceria. O B-17 estaria no chão e, de repente, o trem de aterragem retraía-se, e o avião desabava sobre a pista.

Em cada caso, os investigadores procuravam evidências de falha mecânica ou elétrica e, em cada caso, não conseguiam encontrar nenhuma. Então, o que eles concluíram foi que este era um caso de erro do piloto, que os pilotos tinham retraído por engano o trem de pouso.

Aqui estão duas informações adicionais: os investigadores estavam certos ao afirmar que não ocorreram falhas mecânicas ou elétricas. Os acidentes continuaram acontecendo.

Esta informação pode levá-lo a ficar insatisfeito com a conclusão inicial alcançada sobre estes acidentes, talvez deixá-lo a pensar se esta é a história toda. Neste módulo, vamos propor que algo está faltando nesta conclusão e nas investigações que levaram a ela.