Dicas e práticas recomendadas da resposta a incidentes

1. Tenha sempre um kit de ferramentas para incidentes

O kit para os respondentes de incidentes contém todas as informações importantes que as equipes precisam acessar com o menor atraso. Embora seja mais provável que seja um documento digital, ter um ponto de partida centralizado para os respondentes de incidente é uma grande ajuda.

Ele pode incluir uma variedade de coisas:

• Planos de resposta a incidentes
• Listas de contatos
• Cronogramas de plantão
• Escalation Policy
• Links para ferramentas de conferência
• Códigos de acesso
• Documentos de políticas
• Documentação técnica e runbooks

2. Não fuja dos runbooks

Os runbooks oferecem orientações sobre quais etapas tomar em um determinado cenário. Eles são muito importantes para equipes que trabalham em revezamentos de plantão quando um especialista em sistemas não está disponível de imediato. Um conjunto bem mantido de runbooks permite que as equipes respondam com mais rapidez e criem uma base de conhecimento compartilhada de práticas de resposta a incidentes.

3. Adote o caos, promova a estabilidade

A engenharia de caos é a prática de experimentar sistemas injetando falhas com intenção para entender como os sistemas podem ser criados para serem mais robustos. Um exemplo é o Chaos Monkey. Desenvolvido pela Netflix, o Chaos Monkey é uma ferramenta que testa a resiliência da rede, derrubando os sistemas de produção.

4. Pense fora dos NOCs

Pelo histórico, os Network Operations Centers (NOCs) atuaram como o hub de monitoramento e alertas para sistemas de TI de grande escala. As ferramentas modernas de gerenciamento de incidentes permitem que esse processo seja bastante simplificado. Ao automatizar fluxos de trabalho de entrega de alertas com base em tipos de alerta definidos, cronogramas de equipe e políticas de escalonamento, o potencial de erro humano e/ou atrasos pode ser evitado.

5. Agregue, não agrave

Nada é pior do que receber uma enxurrada contínua de alertas de várias ferramentas de monitoramento. Ao centralizar o fluxo de alertas por meio de uma única ferramenta, as equipes podem filtrar melhor o ruído para que possam se concentrar com rapidez em assuntos que precisam de atenção.

6. Fique ligado: conhecimento é poder

Um alerta básico indica que algo está errado, mas nem sempre indica o item, ocasionando atrasos desnecessários, pois as equipes devem investigar e determinar a causa. Ao combinar alertas com as informações técnicas do motivo por ter sido acionado, o processo de reparação pode começar mais rápido.

7. Tenha alertas para os alertas

A frase em latim "quis custodiet ipsos custodes" ("Quem vigia os vigilantes?") identifica um problema universal. As ferramentas de monitoramento que as equipes de TI e desenvolvedores empregam são tão vulneráveis a incidentes e ao tempo de inatividade quanto os sistemas que eles são projetados para proteger. Os processos holísticos de alerta garantem que tanto os sistemas quanto as ferramentas que os monitoram sejam verificados com continuidade quanto à integridade.

8. Pare o sangramento

O médico de triagem sabe que ele pode causar danos maiores se ficar sobrecarregado na tentativa de resolver todas as situações à medida que chegam. O foco dele está em ações de curto prazo que estabilizam o paciente o suficiente para a transferência para cuidados mais específicos. Nas áreas da tecnologia, as ações de contenção se concentram em soluções temporárias (isolando uma rede, regredindo um build, reiniciando servidores, etc.) que, no mínimo, limitem o escopo do incidente ou, em uma situação mais ideal, façam os sistemas ficarem on-line do novo.

9. Não faça sozinho

A cultura de heróis nas equipes de TI e DevOps é uma filosofia em estado terminal. Já não é comum ser o engenheiro solitário que trabalha sem fim até tarde da noite e aos finais de semana, porque eles são os únicos que podem fazer os sistemas funcionarem de novo. Em vez disso, as equipes trabalham como equipes. A cadeia é tão forte quanto o elo mais fraco, trabalha para nutrir toda a equipe e não apenas um funcionário solitário.

10. Seja transparente

Se os usuários se depararem com uma interrupção de serviço, é comum que o incidente se torne público em curto prazo. Para ficar à frente, as equipes devem ter um plano de comunicação de incidentes implementado. O objetivo é criar confiança com os clientes reconhecendo ao público que uma interrupção está ocorrendo e assegurando que as medidas para resolver o caso estão sendo tomadas. Ferramentas como o Statuspage são ótimas para divulgar essas informações.

11. Aprenda com as falhas

Na grande maioria das vezes, as equipes de TI e DevOps vão dizer que eles só reservam um tempo para analisar "interrupções graves". Embora este seja um bom começo, muitas vezes incidentes menores que podem ter um impacto persistente são negligenciados. Talvez não seja necessário um relatório demorado para todos os incidentes, mas uma análise retrospectiva é sempre útil.

12. Encontre a causa raiz (não há nenhuma causa raiz!)

Ou existe? Ao analisar um incidente, é raro que uma única causa "raiz" identificável possa ser nomeada. Muitas vezes, os sistemas são muito complexos e interdependentes para definir uma única causa raiz de um incidente. Mesmo que a causa raiz pareça aparente (por exemplo, um erro de pressionamento de tecla que trava um aplicativo), em geral, há motivos para entender quais fatores externos podem ter levado o aplicativo a falhar (ou a não impedir a falha). Procure várias causas raízes para ter uma compreensão mais profunda dos incidentes.

13. Sem culpados

O objetivo de cada análise retrospectiva de incidentes é entender o que deu errado e o que pode ser feito para evitar incidentes semelhantes no futuro. É importante ressaltar que esse processo não deve ser usado para atribuir culpa. A razão é que as equipes que se concentram no "quem" e não no "quê", permitem que as emoções afastem a análise de entender o que aconteceu de fato.

Mais uma observação

Em ambientes modernos de gerenciamento de incidentes, a mudança é a única constante. Ou seja, os sistemas vão ser sempre enfatizados de maneiras novas e diferentes. As equipes que entendem essa mensagem também entendem que não é uma questão de se, mas quando os sistemas vão falhar. Tomar medidas para se preparar para essas falhas deve ser reconhecido como um elemento essencial do sucesso contínuo e integrado ao DNA das equipes de engenharia.