Acompanhamento de incidentes

7 minutos

Os incidentes têm um ciclo de vida. Para responder com mais eficácia, você precisa ser capaz de acompanhar a evolução do incidente propriamente dito e a evolução da sua resposta a ele, desde o início desse ciclo de vida.

Avalie o que você sabe

Uma boa maneira de avaliar seu procedimento de acompanhamento de incidentes usando um incidente específico é fazer a si próprio uma série de perguntas:

Quando você soube a respeito do problema pela primeira vez? Se seu objetivo é reduzir o tempo necessário para a recuperação de incidentes, você precisa começar a capturar as informações desde o momento em que fica ciente dos problemas.
Como você descobriu sobre o problema? Seu sistema de monitoramento alertou você sobre o incidente? Você ouviu falar dele primeiro por reclamações de seus clientes, seja diretamente ou em mídia social?
Se você acabou de descobrir o problema: você foi o primeiro a saber? Se esse é o caso, quem você precisa notificar? Caso contrário, quem mais está ciente do problema?
Se outras pessoas estão cientes, o que (se houver algo) está sendo feito sobre ele? Todos estão supondo que há outra pessoa tentando solucioná-lo, ou alguém começou efetivamente a tomar medidas para solucioná-lo?
Quão grave o problema é? Talvez não tenhamos nenhuma noção da gravidade ou do impacto do problema e pode não haver nenhum lugar onde possamos descobrir o real nível de gravidade e quem ou o quê estão sendo afetados.

Essas questões podem ser difíceis de responder se nada estiver sendo acompanhado.

Padronizar onde as informações de incidente serão acompanhadas

Há muitos locais possíveis em que você pode manter e compartilhar sua lista de incidentes (ativos ou de outra forma) e todas as informações atuais sobre esses incidentes. A questão do local pode ser tão simples quanto uma área de arquivo compartilhada com documentos do Word e a de quem ou o quê são afetados tão complexa quanto softwares e serviços de acompanhamento de incidentes altamente especializados. Entre esses dois extremos, existem sistemas de criação de tíquetes e acompanhamento de trabalhos que você pode acionar para essa tarefa. O sistema que você escolher, na verdade, é menos importante do que o modo como você vai usá-lo. Independentemente de qual sistema você usar, todas as pessoas que possam ter qualquer conexão com os incidentes (engenheiros, suporte ao cliente, administração, relações públicas, departamento jurídico e assim por diante) precisam saber aonde ir para encontrar o sistema, como gerar um incidente e como acessar os dados quando for o caso. Uma forma de fazer o acompanhamento de incidentes que certamente resultará em falha é fazer com que as pessoas às quais ele dará suporte não saibam como chegar ao sistema ("qual é mesmo a URL para o nosso sistema?") quando precisarem.

Neste módulo, vamos usar a funcionalidade do item de trabalho do Azure DevOps para o nosso exemplo de sistema de acompanhamento.

Criar uma ponte de conversa

Para responder a algumas das perguntas na seção anterior — Avalie o que você sabe — e iniciar o processo de resposta a incidentes, você precisa ter uma forma de se comunicar com outras pessoas com relação ao incidente. Idealmente, teremos algum tipo de mídia eletrônica de "colaboração em equipe" para conversar, embora conexões por telefone também funcionem. Chamadas de conferência/conexões por telefone são menos desejáveis porque é mais difícil revisar a comunicação de incidentes retroativamente (daí a função de "Escrivão" mencionada anteriormente).

Seja qual for a mídia que escolher, você deve se certificar de criar um canal exclusivo, que seja rigorosamente limitado à discussão sobre esse incidente e nada mais. É importante manter discussões irrelevantes fora desse canal, pois você precisa ser capaz de localizar os dados e analisá-los posteriormente em sua revisão após o incidente.

Neste módulo, vamos usar o Microsoft Teams como nosso método de comunicação de incidentes.

Automatizar a inicialização do acompanhamento de incidentes

Vamos revisar aquilo que constatamos até agora. Temos:

Lista de pessoas a postos (e um rodízio definido para elas).
Uma função que possamos atribuir às pessoas trabalhando em um incidente.
Um local específico para declararmos o incidente e acompanhá-lo.
Um canal exclusivo para as pessoas trabalhando nesse incidente se comunicarem com relação a ele.

Você pode e deve automatizar a criação e o gerenciamento de todos esses elementos na medida do possível. Quando surge um problema urgente, você não deseja ter que se lembrar de todas as etapas necessárias para gerar um incidente, reunir as pessoas certas e acompanhá-lo. Tudo o que você realmente quer fazer é apertar o botão "começar" para que o trabalho de resolução do problema possa começar imediatamente.

Usar os Aplicativos Lógicos para automação sem código

Uma forma de automatizar sua resposta inicial é usando Aplicativos Lógicos, que podem simplificar o trabalho de agendamento, automatização e orquestração de tarefas, processos da empresa e fluxos de trabalho.

Os Aplicativos Lógicos são um serviço de nuvem do Azure para a criação de soluções de integração. Ele usa conectores para criar fluxos de trabalho automatizados. Os gatilhos irão iniciar o Aplicativo Lógico quando ocorrer um evento específico ou os dados cumprirem os critérios especificados. As ações são as operações executadas no fluxo de trabalho do Aplicativo Lógico.

Para o nosso exemplo, usaremos os seguintes conectores de Aplicativo Lógico para acompanhamento de incidentes:

O Azure Boards (uma parte do Azure DevOps), que você pode usar para criar e acompanhar problemas/incidentes.
O Armazenamento do Azure, onde você pode armazenar e recuperar informações sobre quem está a postos para que você possa alocar as pessoas adequadas para responder ao incidente. No nosso exemplo, usaremos o Armazenamento de Tabelas do Azure porque oferece um repositório de "chave-valor" muito simples, que facilita o armazenamento de uma lista de engenheiros e seu status de disponibilidade.
O Microsoft Teams, que você pode usar para criar um novo canal de incidentes exclusivo para acompanhar as conversas de suas equipes de engenharia em tempo real, à medida que se comunicam sobre incidentes específicos. Isso permitirá que você preserve as interações com relação à linha do tempo de eventos mais tarde, quando executar uma revisão pós-incidente.

Agora, vamos unir tudo isso com um Aplicativo Lógico. Primeiro, examine o aplicativo completo, conforme mostrado no designer de Aplicativos Lógicos; a seguir, vamos analisá-lo passo a passo.

Screenshot of a zoomed out view of a logic app as displayed in the Logic Apps Designer.

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 esse conteúdo e enviamos uma confirmação de que o recebemos:

Screenshot of the HTTP and Response block in Logic App Designer view of the Logic App.

Usando essas informações, criamos um item de trabalho em nossa organização do Azure DevOps que representa esse incidente.

Screenshot of the Create a work item block in Logic App Designer view of the Logic App.

Em seguida, o aplicativo vai criar um novo canal do Teams para o incidente:

Screenshot of the Create a channel block in Logic App Designer view of the Logic App.

Após o canal ter sido criado, o item de trabalho que criamos há alguns minutos será atualizado com um link para o novo canal. Isso mantém todas as informações no mesmo local (o item de trabalho) e permite que as pessoas examinem isso posteriormente para saberem para onde ir se desejam ingressar nesse canal.

Screenshot of the Update work item block in Logic App Designer view of the Logic App.

Agora, chegou a hora de colocar em cena a pessoa que está de plantão. Pesquisamos no Armazenamento de Tabelas do Azure o endereço de email do engenheiro listado como estando a postos. Isso retorna uma resposta JSON que analisamos a seguir.

Screenshot of the Get entities block in Logic App Designer view of the Logic App.

Como nossa consulta retorna uma lista, na próxima etapa vamos precisar iterar em cada item. Atribuímos o item de trabalho a cada pessoa (agora eles são "proprietários" do incidente).

Screenshot of the Foreach block in Logic App Designer view of the Logic App.

Em seguida, como uma etapa final, enviamos uma mensagem para o canal do Teams com um ponteiro retornando para o item de trabalho as pessoas que ingressarem no canal e quiserem saber onde as informações oficiais desse incidente estão armazenadas.

Screenshot of the Post a message as the Flow bot channel block in Logic App Designer view of the Logic App.

Esse é apenas um exemplo de como podemos automatizar a configuração dos mecanismos para acompanhamento e comunicação de incidentes. Na próxima unidade, vamos nos aprofundar em aspectos da comunicação relativa a um incidente.