Reflexões rápidas sobre os Comos Infinitos – Codificação, Escalada e Comentários
Pensamentos rápidos da leitura de The Infinite Hows
Se você está tentando estabelecer uma cultura post-mortem saudável em sua empresa, então você deve se apoiar em uma estrutura estabelecida. Os Cinco Porquês, apesar da tentativa de derrubar os Comos Infinitos, mantêm-se com doses saudáveis de cultura inocente e abertura à complexidade do mundo real.
Um colega de trabalho recomendou recentemente The Infinite Hows como uma alternativa superior aos Cinco Porquês. O Comos Infinitos afirma que os Cinco Porquês apresentam falhas de duas maneiras principais:
- Os Cinco Porquês, incorretamente, sugerem que existe uma única cadeia lógica de causa e efeito que eventualmente atinge uma causa raiz. Esta é uma simplificação grosseira da realidade, que não pode ser expressa como uma única cadeia lógica. A ideia de uma única cadeia lógica satisfaz o desejo da mente humana de uma resposta direta a uma pergunta difícil. Mas encobre omissões e ramificações lógicas inexploradas.
- Os Cinco Porquês nos levam ao caminho da culpa humana em vez da análise do sistema. Esta culpa humana, em vez de nos ajudar a aprender com os nossos erros, injeta medo e atrito na resposta a incidentes.
Ambos são pontos importantes, mas não parecem intrínsecos à questão do porquê versus como. Se internalizarmos que o “Porquê” de uma pergunta é uma relação um-para-muitos e que devemos culpar as pessoas e não os sistemas, então o Porquê parece ser uma boa pergunta a fazer.
Em todos os meus trabalhos de software, as empresas empregaram uma análise post-mortem inocente que corresponde aproximadamente aos Cinco Porquês, sem problemas. Talvez a diferença venha do facto de os Comos Infinitos terem sido escritos em 2014 e as minhas primeiras exposições post-mortem terem ocorrido em 2015. Em 2015, a indústria poderá ter amadurecido para uma cultura post-mortem mais eficiente (por exemplo, sem culpa).
Por outro lado, o primeiro ponto sobre a falácia de uma cadeia lógica única parece mais saliente. Certamente já experimentei incidentes com múltiplas cadeias de problemas. Já vi incidentes graves o suficiente para que os engenheiros fossem divididos em grupos diferentes para explorar diferentes mitigações. Por exemplo, um grupo pode explorar se uma reversão de um determinado serviço pode mitigar o incidente, enquanto o segundo grupo pode explorar se alguma combinação de alterações de sinalizadores de recursos pode mitigar. Agora existem dois ramos de eventos. Cada ramo terá sua própria subsequência de etapas, com as quais provavelmente poderemos aprender algo.
Suponha que o incidente possa ser mitigado por uma reversão, mas o segundo grupo tem muitos problemas para determinar se houve um determinado sinalizador de culpado. Mesmo que a reversão resolva o incidente, a investigação abandonada do sinalizador de recurso não deve desaparecer. Toda a tangente do sinalizador de recurso não é mais relevante para a causa raiz, mas a dor de encontrar um sinalizador culpado provavelmente surgirá em um incidente futuro.
E além de esquecer os ramos inexplorados, os Comos Infinitos menciona o problema muito real da omissão. Os engenheiros muitas vezes excluem certas partes da história porque se sentem adjacentes à culpa ou desconfortáveis em compartilhar. Alguns exemplos:
- Um oncall pode demorar muito para responder a uma página
- Um engenheiro pode enviar uma mensagem a um especialista no assunto em vez de bipá-lo, por medo de incomodar o especialista
- Os engenheiros podem gastar muito tempo tentando resolver um incidente por meio de uma sequência de mensagens em vez de criar uma chamada de vídeo
Todas essas são questões de processo que podem ser exploradas para melhorias. Todo mundo tem seu aplicativo de pager configurado para substituir o Não perturbe? A empresa tem uma política escrita sobre quando enviar mensagens para outras pessoas ou quando criar uma videochamada? Ao criar políticas para estas situações, podemos eliminar a sobrecarga mental da tomada de decisão e substituir o medo do julgamento dessa decisão pelo acompanhamento do processo.
Em última análise, culpar as pessoas em vez dos sistemas é contraproducente para melhorar a segurança da engenharia, e a omissão de “sub-ramos” de incidentes renuncia a alguns benefícios de aprendizagem. No entanto, nenhum deles parece particularmente digno de inventar uma abordagem inteiramente nova.
Talvez a melhor abordagem seja uma estrutura de análise de incidentes que acomode causas raízes múltiplas e ponderadas e ramificações lógicas. Esta árvore de eventos ponderados e casuais reconheceria múltiplas causas contribuintes, revelaria um ou dois motivadores “primários” para foco e preservaria sub-ramos para melhorias futuras. Isto ajudaria a articular a ideia de que muitas causas podem contribuir para um único efeito, sem abandonar a ideia de uma causa raiz primária. A certa altura, temos que escolher um conjunto limitado de causas e cortar a profundidade da árvore lógica.
Se você está procurando uma boa estrutura de análise de incidentes, pode confiar nos confiáveis Cinco Porquês ou nos Infinitos Comos, mais matizados e reflexivos.
