paint-brush
Uma dúzia (ou mais) de aprendizados de 15 anos de gerenciamento de incidentes de softwarepor@arjunrao1987
1,435 leituras
1,435 leituras

Uma dúzia (ou mais) de aprendizados de 15 anos de gerenciamento de incidentes de software

por Arjun 9m2024/04/11
Read on Terminal Reader

Muito longo; Para ler

Tudo isso é tão SÉRIO! Dinheiro se perdendo! Clientes tendo uma experiência terrível! No entanto, no meio de tudo isso, descobri que é fundamental ter senso de humor. Não devemos esquecer que todos são humanos nesse processo e passam por diversos graus de estresse. Injetar doses de humor em momentos apropriados ajuda a aliviar parte dessa pressão.
featured image - Uma dúzia (ou mais) de aprendizados de 15 anos de gerenciamento de incidentes de software
Arjun  HackerNoon profile picture

Como engenheiro de software, lidar com incidentes é uma droga. Recebendo aquela página de plantão às 3 da manhã de um sábado? Pode ser assustador, sugador de almas e, no geral, um episódio repugnante. Se isso acontecer com frequência no seu local de trabalho, pode literalmente induzir o TEPT.


Infelizmente, isso é parte integrante do zeitgeist do software. Na verdade, estes são os fogos através dos quais a verdadeira engenharia é forjada. Esses incidentes ensinam como arquitetar sistemas robustos e, em muitos casos, como não fazê-lo.


Este artigo aborda dois aspectos de como lidar com incidentes de software:

  • 🛠️ As práticas que é preciso incutir em sua plataforma de software e equipes para prevenir e aprender com essas experiências.


  • 🧘 A atitude que é preciso ter é ser resiliente e sair dessas experiências não apenas ileso, mas com mais do que entrou.


Os tópicos que abordaremos são -

  1. Automatize seus sistemas o máximo que puder
  2. Acompanhamento de indicadores de liderança e de atraso
  3. Alertas “acionáveis” devem ser evidentes
  4. Estabeleça cadeias de chamadas e caminhos de escalonamento claros
  5. Capacite as linhas de frente para tomar grandes decisões
  6. Nem todos os incidentes são criados iguais
  7. Resolva primeiro, pergunte depois
  8. Certifique-se de que uma pessoa esteja no comando
  9. Comunique-se de forma clara e frequente
  10. Post-mortems inocentes são cruciais
  11. Acompanhamentos às autópsias são cruciais
  12. Os incidentes não são ruins, desde que o MTTD seja baixo
  13. O humor é o grande equalizador


Vamos mergulhar em alguns detalhes!

Automatize seus sistemas tanto quanto você puder

Você realmente deseja minimizar quantos incidentes você toma conhecimento por meio de seus clientes ou por meio de alguma discrepância contábil grave, dias ou semanas a partir do início do incidente. Embora “automação” seja uma palavra muito usada em engenharia, esta é uma daquelas áreas em que você realmente deseja encontrar o equilíbrio certo entre a relação sinal-ruído e garantir que você e sua equipe recebam alertas sem precisar de qualquer intervenção humana.


Se houver muitas coisas para escolher, vá de alto nível. Qual é a métrica de nível mais alto que você pode escolher? Aquele que, se os sistemas componentes não funcionarem conforme o esperado, se desviará da norma? Isso poderia ser o rastreamento da receita que flui através da plataforma (para uma plataforma de comércio eletrônico, financeira ou baseada em dólares) ou o número de usuários ativos atuais (para plataformas de mídia social).


Se você vir a cratera dos números ou cair um ou dois desvios padrão, alerte imediatamente a equipe de desenvolvimento. Concentrar os primeiros (ou mais importantes) alertas no pulso do negócio ou na experiência principal do usuário será uma ótima métrica a ser monitorada. À medida que você se torna mais sofisticado e entende melhor o sistema, você pode começar a se aprofundar na pilha do ponto de vista da observabilidade.
Foto de Markus Spiske no Unsplash

Acompanhamento de indicadores de liderança e atraso

Os indicadores avançados são de natureza preditiva e são susceptíveis de apontar para um problema prestes a acontecer, enquanto os indicadores atrasados são post-hoc e são representativos das consequências, uma vez que o problema está em bom andamento. Se você puder aproveitar os indicadores antecedentes (como, por exemplo, “Duração da sessão” começando a diminuir), além ou no lugar dos indicadores de atraso (como, por exemplo, “número de pedidos feitos em queda”), você provavelmente poderá evitar algo que é bastante catastrófico.

Alertas “acionáveis” devem ser evidentes

Seus alertas devem ser evidentes para que fique claro quais os próximos passos a serem tomados quando eles forem disparados. Seja para verificar a gravidade do problema, solucionar o incidente ou remediar o problema, deve haver detalhes suficientes associados ao alerta. Você deseja garantir que não seja necessária muita discussão inicial para determinar o que fazer com o alerta.


Você pode inserir esses detalhes no conteúdo do próprio alerta ou, se for bastante detalhado, pode vincular a um(s) runbook(s) que a equipe mantém para esses tipos de problemas.

Estabeleça cadeias de chamadas e caminhos de escalonamento claros

Ter uma descrição clara do que acontece quando um alerta é disparado, incluindo para quem ele é encaminhado com base em itens como propriedade do serviço, reconhecimento de fuso horário, etc., é fundamental para garantir uma resposta rápida. Além dessa primeira linha de defesa imediata, também é igualmente crítico garantir que haja clareza sobre como e para quem a resposta ao incidente pode escalar o incidente.


Muitas vezes, se o problema for complexo ou de escopo muito maior do que uma pessoa pode lidar, pode ser necessário atrair mais pessoas seniores (ou várias pessoas na equipe), bem como partes interessadas multifuncionais. Tornar tudo isso facilmente acessível por meio de ferramentas (como PagerDuty, OpsGenie) ou documentação cristalina (livros, páginas wiki, READMEs de repositório) pode ser a diferença entre um incidente catastrófico ou um hambúrguer sem nada.
Exemplo de cadeia de chamadas

Capacite a linha de frente para tomar grandes decisões

Embora você precise de caminhos de escalonamento claros, você não quer que essa seja a resposta padrão. Você deve capacitar os socorristas para que possam tomar medidas reais para conter o sangramento ou tomar decisões imediatas para remediação, sem a necessidade de consultar a gerência sênior. Isto é bom tanto para a empresa em termos de limitar as consequências, como também para os funcionários que recebem uma grande responsabilidade e confiança para tomar grandes decisões. Reduza a burocracia e aumente a agência dos indivíduos.

Nem todos os incidentes são criados iguais

Junto com coisas como cadeias de chamadas e caminhos de escalonamento, outra garantia importante é uma escala de prioridade de incidentes. Normalmente, esta é uma referência rápida para o socorrista ou o comandante do incidente. Isso os ajuda a identificar rapidamente qual é a gravidade do incidente e rotulá-lo como tal, pois pode justificar diferentes graus de respostas.


A diferenciação entre incidentes críticos (como interrupções do sistema ou corrupção de dados financeiros) e problemas menores (como falhas na paleta de cores) é essencial para que os socorristas evitem alarmes falsos. Também garante que a resposta da equipe permaneça eficaz e focada.
Exemplo de matriz de priorização (Fonte)

Resolva primeiro, pergunte depois

Sem dúvida, uma das coisas mais importantes a fazer é resolver o incidente o mais rápido possível. Você não quer perder tempo filosofando por que algo aconteceu ou como poderia ter sido evitado enquanto o incidente está em andamento. Você pode reservar isso para a autópsia. No momento, concentre-se implacavelmente em resolver o incidente e faça as perguntas difíceis mais tarde.

Certifique-se de que uma pessoa esteja no comando

Às vezes, os incidentes podem ficar muito grandes. Eles abrangem muitos serviços, abrangem vários domínios de negócios ou são simplesmente realmente impactantes em termos de receita ou reputação. É nesse momento que é absolutamente crucial que haja uma pessoa designada para “guardar o trânsito” durante todo o incidente. Na Place Exchange, instituímos “Comandantes de Incidentes”, que são um pequeno grupo de pessoas treinadas em resposta a incidentes complexos.


A razão pela qual é tão importante ter esse tipo de função é porque, quando há várias partes envolvidas, alguém precisa direcionar o tráfego. Muitas vezes, os engenheiros começam a investigar a complexidade do problema ou a tentar entender como resolvê-lo.


O papel do Comandante do Incidente é manter o foco do grupo na resolução rápida do incidente. Eles garantem que todos tenham uma tendência para agir e, embora as investigações paralelas possam ser importantes, garantir o impulso futuro é ainda mais importante. São também responsáveis por garantir que existe uma comunicação clara e constante com as partes interessadas e parceiros internos e externos.


Os comandantes de incidentes normalmente iniciam uma linha síncrona de comunicação de voz, como uma reunião do Slack ou uma reunião do Google Meet. Isso garante que as pessoas cruciais para a resolução do incidente estejam em contato constante. É incrível como essa pequena coisa é eficaz em comparação com apenas permitir que as pessoas resolvam as coisas de forma assíncrona usando o chat.


Os comandantes de incidentes também são responsáveis por garantir que haja uma delegação clara para as tarefas que precisam ser realizadas e por garantir que haja responsabilidade pela obtenção de respostas ou resultados para essas tarefas.


Como se costuma dizer, se você pedir para 2 pessoas alimentarem um cavalo, o cavalo morre. Um comandante do incidente evita que isso aconteça e, em última análise, é responsável pela rápida resolução do incidente.

Comunique-se de forma clara e frequente

Muitas vezes, as pessoas perdoarão seu aplicativo ou software favorito se forem mantidas informadas sobre como a equipe está trabalhando duro para resolver o incidente. Tentar manter as coisas escondidas porque você sente que não tem controle completo sobre o incidente ou porque você e sua equipe se sentem envergonhados com isso não são motivos para impedir que a comunicação flua para fora.


Certifique-se de que a comunicação seja concisa, frequente e transparente tanto para os seus parceiros internos como externos, pois isso ajudará a construir boa vontade.
Fonte

Post-mortems inocentes são cruciais

Post mortems ou retrospectivas pós-incidentes são importantes para construir uma cultura de aprendizagem e devem ser absolutamente isentas de culpa. Seja crítico do processo e não da pessoa. Ninguém é mais duro consigo mesmo do que a(s) pessoa(s) que pode(m) ter causado isso, e você não ganha nada flagelando-as em público. Na verdade, todas as pesquisas sugerem que você realmente perde ao fazer isso. O pessoal da Etsy fala muito melhor sobre isso, então leia https://www.etsy.com/codeascraft/blameless-postmortems se quiser saber mais.
Fonte

Acompanhamentos às autópsias são cruciais

Embora a realização de autópsias por si só seja importante para criar consciência e os ciclos de feedback para aprender com estes incidentes, os itens de ação que são discutidos para evitar que estes aconteçam no futuro são talvez mais importantes. Caso o grupo tenha identificado um conjunto de lacunas ou vulnerabilidades no sistema, é super importante que haja foco e atenção para resolvê-las em tempo hábil para evitar que o mesmo problema aconteça novamente.


É difícil evitar que incidentes aconteçam e essa geralmente é uma conversa difícil com sua empresa e seus clientes. Mas se o mesmo incidente acontecer repetidamente, agora isso será muito mais difícil de defender e indicará um grave problema de saúde e habilidade da equipe.

Os incidentes não são ruins, desde que o MTTD seja baixo

Todo mundo entende. Até os empresários entendem. Construir software é DIFÍCIL e, em um mundo onde todo o nosso software tem centenas de milhares de dependências, onde as falhas podem quebrar, é impossível prever. A merda vai bater no ventilador e está tudo bem. Não podemos evitar que incidentes aconteçam. No entanto, o que realmente ajuda é garantir que o MTTD dos seus incidentes seja realmente baixo.


O tempo médio de detecção (MTTD) é um indicador chave de desempenho (KPI) que mede o tempo médio que uma organização leva para identificar um incidente ou ameaça à segurança. É difícil generalizar, dado o domínio do negócio, a gravidade do impacto, etc., mas se você conseguir reduzir seu MTTD para segundos ou minutos, provavelmente conseguirá reduzir significativamente o impacto de um incidente em vez de dizer isso. foi de horas a dias (e muito menos semanas ou meses, o que infelizmente é perfeitamente possível).
Exemplo de gráfico MTTD/MTTR (fonte)

O humor alivia a dor do momento

Tudo isso é tão SÉRIO! Dinheiro se perdendo! Clientes tendo uma experiência terrível! No entanto, no meio de tudo isso, descobri que é fundamental ter senso de humor. Não devemos esquecer que todos são humanos nesse processo e passam por diversos graus de estresse. Injetar doses de humor em momentos apropriados ajuda a aliviar parte dessa pressão.


Isso cria um senso de camaradagem que faz com que a equipe sinta que estão juntos, em vez de em uma ilha no inferno.


Isso é um embrulho. Obrigado por ler!


⭐ Se você gosta desse tipo de conteúdo, não deixe de me seguir ou se inscrever em https://a1engineering.substack.com/subscribe ! ⭐


Foto de destaque de Julien L no Unsplash