Por que aprender com incidentes?

Quando um incidente ocorre, sua primeira reação provavelmente não é: "Hurray, uma oportunidade de aprendizado!" Sua prioridade imediata é descobrir o que deu errado e corrigi-lo o mais rápido possível, para reduzir o impacto sobre seus clientes e usuários finais, como deveria ser. Este é o processo de resposta a incidentes que discutimos em outro módulo neste roteiro de aprendizagem.

No entanto, depois que o incidente for resolvido, é importante acompanhar e se beneficiar da experiência. Se não tomarmos tempo para aprender com o incidente, então ele permanece apenas uma perda de tempo, dinheiro, reputação e assim por diante; mas se esse incidente pode ser uma fonte de informação (da maneira que nenhuma outra fonte pode) podemos realmente derivar algum benefício dele.

A revisão pós-incidente faz parte da fase de análise do ciclo de vida de resposta a incidentes. Nem todas as revisões pós-incidente são iguais. Há diferentes maneiras de abordar o processo e o foco excessivo em determinados aspectos do problema ou enquadrar questões da maneira errada pode reduzir o valor da revisão.

Nesta unidade, você começará a pensar não apenas no porquê, mas também em como aprender melhor com incidentes. Expandiremos o "como" nas unidades subsequentes.

Falha de sistemas complexos

Você deve "aprender a aprender" com as falhas, não porque seus sistemas possam falhar, mas porque é uma certeza que seus sistemas falharão.

No mundo moderno, a maioria dos sistemas com os quais trabalhamos hoje , especialmente em um ambiente de nuvem, são complexos. Elas são compostas por muitas partes de interconexão que precisam trabalhar juntas, e o comportamento geral do sistema vem da interação dessas partes tanto quanto das próprias partes individuais.

Confiabilidade é o fio condutor ao longo deste caminho de aprendizagem, mas sistemas complexos nunca são completamente confiáveis. Esses sistemas se comportam de maneiras interessantes e contraintuitivas. Eles são compostos por muitas partes, e muitas vezes o comportamento do sistema vem das interações entre essas partes, tanto quanto das próprias partes.

Para uma discussão mais aprofundada deste tópico, um bom recurso é o artigo intitulado How Complex Systems Fail by Dr. Richard I. Cook. Ele é anestesista e pesquisador que passou décadas trabalhando em segurança em sistemas complexos, especificamente na segurança do paciente no sistema de saúde. Neste artigo, ele explica o que é comum a sistemas complexos em todos os campos, desde serviços de saúde até operações de software.

Alguns de seus principais pontos são particularmente relevantes para a análise de incidentes e o processo de revisão pós-incidente:

• Sistemas complexos contêm misturas variáveis de falhas latentes. É impossível que seus sistemas sejam executados sem que várias falhas estejam presentes. As falhas mudam constantemente devido à mudança da tecnologia, da organização do trabalho e dos esforços para erradicar o fracasso. Seu sistema nunca está funcionando perfeitamente.
• Sistemas complexos são executados no modo degradado. Sistemas complexos estão sempre em execução como sistemas "defeituosos". Eles continuam "trabalhando" nesse estado porque contêm muitas redundâncias, e as pessoas podem mantê-las funcionando apesar da presença de muitas falhas. As operações do sistema são dinâmicas, com componentes falhando continuamente e sendo substituídos.
• A catástrofe está sempre ao virar da esquina. A complexidade desses sistemas significa que as principais falhas do sistema são, a longo prazo, inevitáveis. Sistemas complexos sempre possuem o potencial de falha catastrófica e isso pode acontecer a qualquer momento. É impossível eliminar esse potencial porque faz parte da natureza inerente do sistema.

Prevenção e resposta

Em seus esforços para alcançar o nível desejado de confiabilidade para seus sistemas e serviços, você faz todo o possível para evitar que incidentes ocorram. No entanto, devido à complexidade desses sistemas, conforme explicado anteriormente, a prevenção nem sempre é possível.

Por causa dessa realização, temos que adotar uma abordagem de duas pontas para o fracasso: prevenção e, quando isso não for possível, preparação para responder de forma rápida e eficaz.

A prevenção e a resposta estão interligadas. Você pode ter experimentado isso quando sua organização implantou uma parte sofisticada da automação que funcionou na maior parte do tempo. Era ótimo que funcionasse a maior parte do tempo, mas quando isso acontecia, provavelmente falhava de forma espetacular e ficava mais difícil para os operadores entenderem o problema.

Os sistemas em que você trabalha são compostos por mais do que a tecnologia. Na verdade, você não trabalha "em" ou "com" um sistema; você trabalha no sistema. Você faz parte do sistema. Sistemas complexos incluem componentes técnicos (hardware, software) e componentes humanos (pessoas e suas personalidades, treinamento e conhecimento). Nossos sistemas são sistemas que incluem humanos, e como os humanos respondem quando as coisas dão errado é tão importante quanto impedir que as coisas deem errado em primeiro lugar.

Linguagem

A linguagem é importante. Você aprenderá neste módulo que seremos muito específicos sobre quais termos usamos e quais não usamos intencionalmente.

As palavras que usamos afetam como pensamos sobre o que aconteceu em um incidente, e podem mudar drasticamente o que e o quanto aprendemos. Essa descoberta vem de pesquisas em indústrias críticas à segurança, como aviação, medicina, busca e resgate, combate a incêndios e muito mais.

Coletivamente, esse campo de pesquisa tornou-se conhecido como RE ( Engenharia de Resiliência ).

Temos muito a aprender sobre a Engenharia de Resiliência no setor de tecnologia. Mais adiante neste módulo, compartilharemos algumas coisas realmente úteis que aprendemos com a literatura RE, incluindo quatro das armadilhas mais comuns em que as pessoas se enquadram ao tentar aprender com o fracasso; mas primeiro, precisamos definir alguns termos.