Acompanhamento de incidentes
- 7 minutos
Incidentes têm um ciclo de vida. Para responder com mais eficiência, você precisa ser capaz de acompanhar a evolução do incidente em si e a evolução de sua resposta a ele, desde o início desse ciclo de vida.
Avaliar o que você sabe
Uma boa maneira de avaliar seu procedimento de acompanhamento de incidentes usando um incidente específico é fazer uma série de perguntas a si mesmo:
- Quando soube do problema pela primeira vez? Se sua meta for reduzir o tempo necessário para se recuperar de incidentes, você precisará começar a capturar informações a partir do momento em que estiver ciente dos problemas.
- Como você descobriu sobre o problema? Seu sistema de monitoramento alertou você sobre o incidente? Você ouviu pela primeira vez sobre isso de seus clientes reclamando, diretamente ou nas mídias sociais?
- Se você acabou de descobrir o problema, será que foi você a primeira pessoa a saber? Em caso afirmativo, quem você precisa notificar? Caso contrário, quem mais está ciente do problema?
- Se outros estão cientes, o que (se alguma coisa) está sendo feito sobre isso? Todos estão assumindo que outra pessoa está investigando, ou alguém começou a tomar medidas para resolvê-lo?
- Quão ruim é? Podemos não ter nenhuma noção de gravidade ou impacto, e não há lugar para descobrirmos o quão ruim o problema realmente é e quem é afetado.
Essas podem ser perguntas difíceis de responder se nada estiver sendo rastreado.
Padronizar onde as informações de incidentes serão rastreadas
Há muitos lugares possíveis que você pode manter e compartilhar sua lista de incidentes (ativos ou não) e todas as informações atuais sobre esses incidentes. Eles podem ser tão simples quanto uma área de arquivo compartilhado com documentos do Word e tão complexos quanto softwares e serviços altamente especializados de acompanhamento de incidentes. Entre esses dois extremos estão os sistemas de acompanhamento de trabalho e emissão de tíquetes que você pode colocar em operação para essa tarefa. Qual sistema você escolhe é, na verdade, menos importante do que como você o usa. Não importa qual sistema você use, todos que podem ter qualquer conexão com incidentes (engenheiros, suporte ao cliente, gerenciamento, relações públicas, jurídico e assim por diante) precisam saber para onde ir para encontrar o sistema, como gerar um incidente e como acessar os dados quando apropriado. Uma maneira certa de falhar com o rastreamento de incidentes é ter as pessoas que vão receber suporte sem saber como acessar o sistema ("qual era a URL do nosso sistema mesmo?") quando precisarem dele.
Neste módulo, usaremos a funcionalidade de item de trabalho do Azure DevOps para nosso sistema de acompanhamento de exemplo.
Criar uma ponte de conversa
Para responder algumas das perguntas na seção Avaliar o que você sabe e iniciar o processo de resposta a incidentes, você deve ter uma maneira de se comunicar com outras pessoas sobre o incidente. Idealmente, isso será algum tipo de meio eletrônico de "colaboração em equipe" para conversa, embora pontes telefônicas também funcionem. Chamadas de conferência ou pontes telefônicas são menos recomendadas, porque dificultam a revisão posterior da comunicação do incidente — por isso existe a função do "Escrivão", mencionada anteriormente.
Seja qual for o meio que você escolher, você deve ter certeza de esculpir um canal exclusivo que está estritamente limitado à discussão sobre este incidente e nada mais. É importante manter a discussão irrelevante fora deste canal, pois você precisa ser capaz de pegar os dados e analisá-los posteriormente em sua revisão pós-incidente.
Neste módulo, usaremos o Microsoft Teams como nosso método de comunicação de incidentes.
Automatizar o início do acompanhamento de incidentes
Então, vamos examinar as peças que reunimos até agora. Temos:
- Lista das pessoas de plantão (e uma rotação definida para elas).
- Função que podemos atribuir às pessoas que trabalham em um incidente.
- Local específico em que vamos declarar o incidente e acompanhá-lo.
- Canal exclusivo para as pessoas que trabalham nesse incidente se comunicarem sobre ele.
Você pode e deve automatizar a criação e o gerenciamento de todas essas coisas na medida do possível. Quando um problema urgente surge, você não quer ter que recordar todas as etapas necessárias para gerar um incidente, trazer as pessoas certas e rastreá-lo. Tudo o que você realmente deseja fazer é ser capaz de pressionar o botão "iniciar" para que o trabalho possa começar imediatamente a resolver o problema.
Usar Aplicativos Lógicos para automação sem código
Uma maneira de automatizar sua resposta inicial é usando aplicativos lógicos, que podem simplificar o trabalho de agendar, automatizar e orquestrar tarefas, processos de negócios e fluxos de trabalho.
Os Aplicativos Lógicos são um serviço de nuvem do Azure para criar soluções de integração. Ele usa conectores para criar fluxos de trabalho automatizados. Os gatilhos iniciam o Aplicativo Lógico quando um evento específico ocorre ou quando os dados atendem aos critérios especificados. As ações são as operações executadas no fluxo de trabalho do Aplicativo Lógico.
Para nosso exemplo, usaremos os seguintes conectores do Logic Apps para acompanhamento de incidentes.
- Azure Boards (uma parte do Azure DevOps), que você pode usar para criar e acompanhar problemas/incidentes.
- Armazenamento do Azure, onde você pode armazenar e recuperar informações sobre quem está de plantão para poder atribuir as pessoas adequadas para responder ao incidente. Em nosso exemplo, usaremos o Armazenamento de Tabelas do Azure porque ele oferece um repositório "chave-valor" muito simples que facilita o armazenamento de uma lista de engenheiros e seu status de chamada.
- Microsoft Teams, que você pode usar para criar um novo canal de incidente exclusivo para acompanhar as conversas de suas equipes de engenharia em tempo real à medida que eles se comunicam sobre incidentes específicos. Isso permite que você preserve as interações em relação à linha do tempo dos eventos posteriormente ao executar uma revisão pós-incidente.
Agora vamos unir tudo isso com um Aplicativo Lógico. Primeiro, dê uma olhada no aplicativo completo, conforme mostrado no Designer de Aplicativos Lógicos, em seguida, percorreremos ele passo a passo.
A primeira etapa é lidar com um gatilho, aquela solicitação HTTP que mencionamos. Uma solicitação HTTP POST é feita ao nosso aplicativo lógico que contém um conteúdo JSON com informações sobre o incidente que desejamos declarar. Analisamos essa carga útil e enviamos de volta uma confirmação de recebimento:
Usando essas informações, criamos um novo item de trabalho em nossa organização do Azure DevOps que representa esse incidente.
Em seguida, ele criará um novo canal do Teams para o incidente:
Depois que o canal é criado, o item de trabalho que criamos há um momento é atualizado com um link para o novo canal. Isso mantém todas as informações no mesmo lugar (o item de trabalho) e permite que as pessoas que o olham mais tarde saibam para onde ir se quiserem ingressar nesse canal.
Agora, é hora de trazer a pessoa de plantão para a cena. Executamos uma pesquisa no Armazenamento de Tabelas do Azure para o endereço de email do engenheiro listado como sendo de plantão. Isso retorna uma resposta JSON, que, em seguida, analisamos.
Como nossa consulta retornará uma lista, precisamos iterar sobre cada item dessa lista como a próxima etapa. Atribuimos o item de trabalho a cada pessoa (eles agora são "proprietários" do incidente).
Em seguida, como etapa final, enviamos uma mensagem para o canal do Teams com um ponteiro de retorno ao item de trabalho para pessoas que ingressarem no canal e quiserem saber onde as informações oficiais para esse incidente estão armazenadas.
Esse é apenas um exemplo de como podemos automatizar a configuração dos mecanismos de acompanhamento e comunicação de incidentes. Na próxima unidade, vamos nos aprofundar um pouco mais nos aspectos da comunicação em torno de um incidente.