Etapa 5: responder e aprender

A forma como sua aplicação responde a eventos disruptivos influencia sua confiabilidade. Aprender com a experiência e como sua aplicação reagiu às interrupções no passado também é fundamental para melhorar sua confiabilidade. 

A etapa Responder e aprender se concentra nas práticas que você pode implementar para responder melhor a eventos disruptivos em suas aplicações. Também inclui práticas para ajudar você a extrair o máximo de aprendizado das experiências de suas equipes de operações e engenheiros.

Criação dos relatórios de análise de incidentes

Quando ocorre um incidente, a primeira ação é evitar mais danos aos clientes e à empresa o mais rápido possível. Depois que a aplicação for recuperada, a próxima etapa é entender o que aconteceu e identificar as etapas para evitar a recorrência. Essa análise pós-incidente geralmente é capturada como um relatório que documenta o conjunto de eventos que levaram à deficiência do aplicativo e os efeitos da interrupção na aplicação, nos clientes e nos negócios. Esses relatórios se tornam valiosos artefatos de aprendizado e devem ser amplamente compartilhados em toda a empresa.

Um bom relatório de análise de incidentes, como o documentado no processo Amazon Correction of Error (COE), segue um formato padronizado e tenta capturar, com o máximo de detalhes possível, as condições que levaram à deficiência da aplicação. O relatório detalha uma série de eventos com data e hora e captura dados quantitativos (geralmente métricas e capturas de tela de painéis de monitoramento) que descrevem o estado mensurável da aplicação ao longo do tempo. O relatório deve capturar os processos de pensamento dos operadores e engenheiros que agiram e as informações que os levaram às suas conclusões. O relatório também deve detalhar a performance de diferentes indicadores, por exemplo, quais alarmes foram acionados, se esses alarmes refletiram com precisão o estado da aplicação, o intervalo de tempo entre os eventos e os alarmes resultantes e o tempo para resolver o incidente. A linha do tempo também captura os runbooks ou as automações que foram iniciados e como eles ajudaram a aplicação a recuperar um estado útil. Esses elementos da linha do tempo ajudam sua equipe a entender a eficácia das respostas automatizadas e do operador, incluindo a agilidade com que resolveram o problema e a eficácia que demonstraram na mitigação da interrupção.

Essa descrição detalhada de um evento histórico é uma ferramenta educacional muito útil. As equipes devem armazenar esses relatórios em um repositório central que esteja disponível para toda a empresa, para que outras pessoas possam analisar os eventos e aprender com eles. Isso pode melhorar a intuição de suas equipes sobre o que pode dar errado na produção.

Um repositório de relatórios detalhados de incidentes também se torna uma fonte de material de treinamento para operadores. As equipes podem usar um relatório de incidentes para inspirar um dia de simulação ou dia de jogo ao vivo, em que elas recebem informações que reproduzem a sequência de eventos registrada no relatório. Os operadores podem percorrer o cenário com informações parciais da linha do tempo e descrever quais medidas eles tomariam. O moderador do dia de jogo pode então fornecer orientação sobre como a aplicação respondeu com base nas ações do operador. Isso desenvolve as habilidades de solução de problemas dos operadores, para que eles possam antecipar e solucionar problemas com mais facilidade.

Uma equipe centralizada responsável pela confiabilidade da aplicação deve manter esses relatórios em uma biblioteca centralizada que toda a organização possa acessar. Essa equipe também deve ser responsável por manter o modelo de relatório e treinar as equipes sobre como preencher o relatório de análise de incidentes. A equipe de confiabilidade deve revisar periodicamente os relatórios para detectar tendências em toda a empresa que possam ser abordadas por meio de bibliotecas de software, padrões de arquitetura ou alterações nos processos da equipe.

Realização das revisões operacionais

Conforme analisado na Etapa 4: operar, as análises operacionais são uma oportunidade para revisar lançamentos recentes de recursos, incidentes e métricas operacionais. A análise operacional também é uma oportunidade de compartilhar os aprendizados sobre incidentes e lançamentos de recursos com a comunidade mais ampla de engenharia da sua organização. Durante a análise operacional, as equipes analisam as implantações de recursos que foram revertidas, os incidentes que ocorreram e como eles foram tratados. Isso dá aos engenheiros de toda a organização a oportunidade de aprender com as experiências de outras pessoas e fazer perguntas.

Disponibilize suas análises operacionais para a comunidade de engenharia da sua empresa para que eles possam aprender mais sobre as aplicações de TI que executam os negócios e os tipos de problemas que podem encontrar. Eles aplicarão esse conhecimento à medida que projetam, implementam e implantam outras aplicações para a empresa.

Análise da performance do alarme

Os alarmes, conforme analisado na etapa de operação, podem resultar em alertas no painel, na criação de tíquetes, no envio de e-mails ou no acionamento dos operadores.  Uma aplicação terá vários alarmes configurados para monitorar diversos aspectos de sua operação. Com o tempo, a precisão e a eficácia desses alarmes devem ser revisadas para aumentar a precisão do alarme, reduzir os falsos positivos e consolidar alertas duplicados.

Precisão dos alarmes

Os alarmes devem ser tão específicos quanto possível para reduzir o tempo gasto interpretando ou diagnosticando a interrupção específica que causou o alarme. Quando um alarme é acionado em resposta a uma deficiência na aplicação, os operadores que recebem e respondem ao alarme devem primeiro interpretar as informações que o alarme transmite. As informações podem ser um código de erro simples que mapeia um curso de ação, como um procedimento de recuperação, ou podem incluir linhas de logs da aplicação que você precisa revisar para entender por que o alarme foi disparado. À medida que sua equipe aprende a operar uma aplicação com mais eficiência, ela deve refinar esses alarmes para torná-los o mais claros e concisos possível.

Você não pode prever todas as possíveis interrupções em uma aplicação, então sempre haverá alarmes gerais que exigem que um operador analise e diagnostique. Sua equipe deve trabalhar para reduzir o número de alarmes gerais a fim de melhorar os tempos de resposta e diminuir o tempo médio de reparo (MTTR). O ideal é que haja uma relação de um para um entre um alarme e uma resposta automatizada ou executada por humanos.  

Falsos positivos

Os alarmes que não exigem nenhuma ação dos operadores, mas produzem alertas como e-mails, acionamentos ou tíquetes, serão ignorados pelos operadores ao longo do tempo.  Periodicamente, ou como parte de uma análise de incidentes, revise os alarmes para identificar aqueles que geralmente são ignorados ou que não exigem nenhuma ação dos operadores (falsos positivos).  Você deve trabalhar para remover o alarme ou melhorá-lo para que ele emita um alerta acionável aos operadores.

Falsos negativos

Durante um incidente, os alarmes configurados para alertar durante o incidente podem falhar, talvez devido a um evento que afete a aplicação de forma inesperada.  Como parte de uma análise de incidentes, você deve revisar os alarmes que deveriam ter sido acionados, mas não foram. Você deve trabalhar para melhorar esses alarmes para que eles reflitam melhor as condições que podem surgir de um evento. Como alternativa, talvez seja necessário criar alarmes adicionais mapeados para a mesma interrupção, mas que sejam gerados por um sintoma diferente da interrupção.

Alertas duplicados

Uma interrupção que comprometa o funcionamento da aplicação provavelmente causará vários sintomas e resultará em vários alarmes.  Periodicamente, ou como parte de uma análise de incidentes, você deve revisar os alarmes e alertas emitidos.  Se os operadores receberam alertas duplicados, crie alarmes agregados para consolidá-los em uma única mensagem de alerta.

Realização das revisões de métricas

Sua equipe deve coletar métricas operacionais sobre sua aplicação, como o número de incidentes por gravidade por mês, o tempo para detectar o incidente, o tempo para identificar a causa, o tempo para remediar e o número de tíquetes criados, alertas enviados e acionamentos. Analise essas métricas pelo menos uma vez por mês para entender a carga da equipe operacional, a relação sinal/ruído com a qual ela lida (por exemplo, alertas informativos versus alertas acionáveis) e se a equipe está melhorando sua capacidade de operar as aplicações sob seu controle. Use essa análise para entender as tendências nos aspectos mensuráveis da equipe de operações. Solicite ideias da equipe sobre como melhorar essas métricas.  

Fornecimento de treinamento e capacitação

É difícil capturar uma descrição detalhada de uma aplicação e de seu ambiente que provocou um incidente ou comportamento inesperado. Além disso, modelar a resiliência da sua aplicação para antecipar esses cenários nem sempre é simples. Sua organização deve investir em materiais de treinamento e capacitação para que seus desenvolvedores e equipes operacionais participem de atividades como modelagem de resiliência, análise de incidentes, dias de jogo e experimentos de engenharia do caos. Isso aprimorará a precisão dos relatórios gerados por suas equipes e o conhecimento que elas registram. As equipes também estarão mais bem preparadas para antecipar falhas sem depender de um grupo menor e mais experiente de engenheiros, que fornecem seus insights por meio de revisões programadas.

Criação de uma base de conhecimento sobre incidentes

Um relatório de incidentes é um resultado padrão de uma análise de incidentes. Você deve usar o mesmo relatório ou um semelhante para documentar cenários em que detectou um comportamento anômalo da aplicação, mesmo que esta não tenha sido danificada. Use a mesma estrutura de relatórios padronizada para registrar o resultado de experimentos de caos e dias de jogo. O relatório representa um snapshot da aplicação e de seu ambiente que levou a um incidente ou a um comportamento inesperado. Você deve armazenar esses relatórios padronizados em um repositório central para que todos os engenheiros da empresa possam acessar.  

As equipes de operações e os desenvolvedores podem então pesquisar essa base de conhecimento para entender o que interrompeu as aplicações no passado, quais tipos de cenários poderiam ter causado interrupções e o que evitou a deficiência das aplicações. Essa base de conhecimento se torna um acelerador para aprimorar as habilidades de suas equipes operacionais e de seus desenvolvedores e permite que eles compartilhem seus conhecimentos e experiências. Além disso, você pode usar os relatórios como material de treinamento ou cenários para dias de jogo ou experimentos de caos para melhorar a intuição e a capacidade da equipe operacional de solucionar interrupções.

Implementação da resiliência em profundidade

Conforme analisado anteriormente, uma organização avançada implementará várias respostas a um alarme. Não há garantia de que uma resposta será eficaz, portanto, ao agrupar as respostas em camadas, uma aplicação estará mais bem equipada para falhar de forma controlada. Recomendamos que você implemente pelo menos duas respostas para cada indicador para garantir que uma resposta individual não se torne um único ponto de falha que possa levar a um cenário de DR.  Essas camadas devem ser criadas em ordem serial, para que uma resposta sucessiva seja executada somente se a resposta anterior for ineficaz. Você não deve executar várias respostas em camadas para um único alarme. Em vez disso, use um alarme que indique se uma resposta não teve êxito e, em caso afirmativo, inicie a próxima resposta em camadas.