Rastreamento de incidentes

Os incidentes têm um ciclo de vida. Para responder de forma mais eficaz, você precisa ser capaz de acompanhar a evolução do incidente em si, e a evolução da sua resposta a ele, desde o início desse ciclo de vida.

Avalie o que sabe

Uma boa maneira de avaliar seu procedimento de rastreamento de incidentes usando um incidente específico é fazer a si mesmo uma série de perguntas:

• Quando teve conhecimento do problema? Se o seu objetivo é reduzir o tempo necessário para se recuperar de incidentes, você precisa começar a capturar informações a partir do momento em que toma conhecimento dos problemas.
• Como teve conhecimento do problema? O seu sistema de monitorização alertou-o sobre o incidente? Você ouviu falar sobre isso pela primeira vez de seus clientes reclamando, diretamente ou nas redes sociais?
• Se você está apenas descobrindo o problema, você é o primeiro a saber? Em caso afirmativo, quem deve notificar? Em caso negativo, quem mais tem conhecimento do problema?
• Se os outros estão cientes, o que (se alguma coisa) está sendo feito a respeito? Todo mundo está assumindo que alguém está investigando isso, ou alguém começou a tomar medidas para resolvê-lo?
• Quão ruim é? Podemos não ter qualquer noção de gravidade ou impacto, e não há lugar para descobrirmos o quão ruim o problema realmente é e quem é afetado.

Estas podem ser perguntas difíceis de responder se nada estiver a ser registado.

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. Estes podem ser tão simples como uma área de ficheiros partilhada com documentos Word e tão complexos como software e serviços altamente especializados de rastreamento de incidentes. Entre esses dois extremos estão os sistemas de emissão de bilhetes e rastreamento de trabalho que pode utilizar para esta tarefa. O sistema que escolher é, na verdade, menos importante do que a forma como o utiliza. Não importa qual sistema você usa, todos que possam ter alguma conexão com incidentes (engenheiros, suporte ao cliente, gerenciamento, relações públicas, jurídico e assim por diante) precisam saber onde encontrar o sistema, como levantar um incidente e como acessar os dados quando apropriado. Uma forma certa de falhar no rastreio de incidentes é quando as pessoas que o sistema apoia não sabem como aceder ao sistema ("qual era mesmo o URL do nosso sistema?") quando precisam.

Neste módulo, utilizamos a funcionalidade de itens de trabalho do Azure DevOps para o nosso sistema de rastreamento de exemplos.

Criar uma ponte de conversação

Para responder a algumas das perguntas da seção Avaliar o que você sabe anterior e iniciar o processo de resposta a incidentes, você deve ter uma maneira de se comunicar com outras pessoas sobre o incidente. Idealmente, este será algum tipo de meio eletrônico de "colaboração em equipe" para conversação, embora as pontes telefônicas também funcionem. Teleconferências/pontes telefônicas são menos preferidas, porque é mais difícil revisar retroativamente a comunicação do incidente (daí o papel "Scribe" mencionado anteriormente).

Seja qual for o meio escolhido, você deve ter certeza de criar um canal exclusivo que seja estritamente limitado à discussão sobre esse incidente e nada mais. É importante manter discussões irrelevantes fora desse canal, porque você precisa ser capaz de pegar os dados e analisá-los posteriormente em sua revisão pós-incidente.

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

Automatize o lançamento do rastreamento de incidentes

Então, vamos rever as peças que reunimos até agora. Temos um:

• Lista das pessoas de plantão (e um rodízio definido para elas).
• Função que podemos atribuir às pessoas que trabalham em um incidente.
• O local específico onde vamos reportar o incidente e monitorizá-lo.
• Canal único 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 máxima extensão possível. Quando um problema urgente surge, você não quer ter que lembrar todas as etapas necessárias para levantar um incidente, trazer as pessoas certas e rastreá-lo. Tudo o que realmente queres 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 agendamento, automação e orquestração de tarefas, processos de negócios e fluxos de trabalho.

Logic Apps é um serviço cloud do Azure para construir soluções de integração. Ele usa conectores para criar fluxos de trabalho automatizados. Acionadores iniciam a Aplicação Lógica quando ocorre um evento específico ou quando os dados satisfazem os critérios especificados. Ações são as operações que são executadas no fluxo de trabalho da Aplicação Lógica.

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

• Azure DevOps, que pode usar para criar e acompanhar itens de trabalho relacionados a incidentes no Azure Boards.
• Armazenamento de Tabelas do Azure, onde pode armazenar e recuperar informações sobre quem está de plantão para notificar as pessoas certas para responder ao incidente. No nosso exemplo, vamos usá-lo como um simples armazenamento de chaves/atributos sem esquema para dados de plantel de chamada.
• Microsoft Teams, que pode usar para criar um novo canal de incidentes único para acompanhar as conversas das suas equipas de engenharia em tempo real enquanto comunicam sobre incidentes específicos. Isso permite que você preserve as interações em relação à linha do tempo dos eventos mais tarde 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 Logic Apps Designer, depois vamos percorrê-lo passo a passo.

O primeiro passo é lidar com um gatilho, aquela solicitação HTTP que mencionamos. Uma solicitação HTTP POST é feita ao nosso aplicativo lógico que contém uma carga JSON com informações sobre o incidente que desejamos declarar. Analisamos essa carga útil e enviamos de volta uma confirmação que recebemos:

Com esta informação, criamos um novo item de trabalho na nossa organização Azure DevOps representando este incidente.

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

Uma vez que o canal é criado, o item de trabalho que criamos um momento atrás é 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 olham para ela mais tarde saibam para onde ir se quiserem participar desse canal.

Agora, é hora de trazer a pessoa de plantão para a cena. Consultamos o Armazenamento de Tabelas do Azure para a entrada de lista que identifica o engenheiro de chamada atual. Isso retorna uma resposta JSON, que analisamos.

Como a nossa consulta pode devolver uma lista, precisamos iterar sobre cada item correspondente como próximo passo. Num fluxo de trabalho de produção, use esses dados para identificar o proprietário principal do incidente e quaisquer backups. O respondedor principal pode ser atribuído ao item de trabalho do Azure DevOps, enquanto respondedores adicionais podem ser acompanhados através de tarefas ligadas, comentários ou notificações.

Em seguida, como etapa final, enviamos uma mensagem para o canal do Teams com uma ligação de retorno para o item de trabalho, para as pessoas que entram no canal e querem saber onde as informações oficiais sobre esse incidente estão armazenadas.

Esse é apenas um exemplo de como podemos automatizar a configuração dos mecanismos de rastreamento e comunicação de incidentes. Na próxima unidade, vamos nos aprofundar um pouco mais nos aspetos da comunicação em torno de um incidente.