Отслеживание инцидентов

Инциденты имеют жизненный цикл. Чтобы реагировать наиболее эффективно, необходимо иметь возможность отслеживать эволюцию самого инцидента и эволюцию вашего ответа на него с самого начала этого жизненного цикла.

Оценка того, что вы знаете

Хороший способ оценить процедуру отслеживания инцидентов с помощью конкретного инцидента — задать себе ряд вопросов:

• Когда вы впервые узнали о проблеме? Если ваша цель заключается в сокращении времени, необходимого для восстановления от инцидентов, необходимо начать сбор информации с момента, когда вы узнаете о проблемах.
• Как вы узнали о проблеме? Оповещает ли ваша система мониторинга об инциденте? Вы впервые услышали об этом от клиентов, которые жаловались лично или в социальных сетях?
• Узнав о проблеме, вы являетесь первым, кто об этом узнал? Если да, кто вам нужно уведомить? Если нет, кто еще знает о проблеме?
• Если другие знают, то что предпринимается по этому поводу? Предполагает ли каждый, что кто-то другой занимается этим, или уже кто-то начал принимать меры для решения этой проблемы?
• Насколько это плохо? У нас может не быть никакого представления о серьезности или последствиях, и нет возможности узнать, насколько серьезна на самом деле проблема и кто пострадал.

Это могут быть трудные вопросы, чтобы ответить, если ничего не отслеживается.

Установите стандарты для отслеживания информации об инцидентах

Существует множество возможных мест, где можно хранить и где можно поделиться списком инцидентов (активных или неактивных) и всей текущей информацией об этих инцидентах. Это может быть столь же просто, как общая файловая область с документами Word, и столь же сложно, как высокоспециализированное программное обеспечение и службы для отслеживания инцидентов. Между этими двумя крайностями находятся системы обработки заявок и отслеживания работы, которые можно использовать для этой задачи. Какая система, которую вы выбираете, на самом деле менее важна, чем ее использование. Независимо от того, какая система используется, все, кто может иметь любое подключение ко всем инцидентам (инженеры, специалисты по поддержке клиентов, управлению, связям с общественностью, юридическими и т. д.), должны знать, куда идти, чтобы найти систему, как вызвать инцидент и как получить доступ к данным при необходимости. Один из способов допустить провал при отслеживании инцидентов заключается в том, чтобы люди, которых он поддерживает, не знали, как получить доступ к системе ("какой у нашей системы был URL-адрес?"), когда им это нужно.

В этом модуле мы используем функциональные возможности рабочих элементов Azure DevOps для нашей примера системы отслеживания.

Создание мостика для общения

Чтобы ответить на некоторые вопросы в предыдущем разделе "Оцените, что вы знаете" и начать процесс реагирования на инциденты, необходимо иметь способ общаться с другими о данном инциденте. В идеале это будет какая-то "командное сотрудничество" электронная платформа для общения, хотя телефонные конференции также работают. Конференц-связи и телефонные мосты менее предпочтительны, потому что сложнее ретроспективно восстановить ход общения во время инцидента, поэтому ранее упоминалась роль "Секретаря".

Независимо от того, какое средство вы выбираете, вы должны быть уверены, что создаете уникальный канал, строго ограниченный для обсуждения этого инцидента и исключительно для этого. Важно избегать неуместных обсуждений в этом канале, потому что вам нужно иметь возможность собирать данные и анализировать их позже в ходе проверки после инцидента.

В этом модуле мы будем использовать Microsoft Teams в качестве метода связи с инцидентами.

Автоматизация запуска отслеживания инцидентов

Итак, давайте рассмотрим части, которые мы собрали до сих пор. У нас есть:

• Список дежурных (и график, определенный для них).
• Роль, которую мы можем назначить людям, работающим над инцидентом.
• В конкретном месте мы объявим инцидент и будем отслеживать его.
• Уникальный канал для людей, работающих над этим инцидентом, чтобы сообщить об этом.

Вы можете и должны автоматизировать создание и управление всеми этими вещами до максимально возможной степени. При возникновении срочной проблемы вам не хотелось бы вспоминать все шаги, необходимые для подачи инцидента, вовлечения подходящих специалистов и отслеживания процесса. Все, что вы действительно хотите сделать, заключается в том, чтобы иметь возможность нажать кнопку "старт", чтобы работа могла немедленно начать решать проблему.

Использование Logic Apps для автоматизации без кода

Одним из способов автоматизации первоначального ответа является использование Logic Apps, которое может упростить задание планирования, автоматизации и оркестрации задач, бизнес-процессов и рабочих процессов.

Logic Apps — это Azure облачная служба для создания решений интеграции. Он использует соединители для создания автоматизированных рабочих процессов. Триггеры запускают Logic App, когда выполняется определенное событие или когда данные соответствуют указанным критериям. Действия — это операции, которые затем выполняются в рабочем процессе приложения логики.

В нашем примере мы будем использовать следующие коннекторы Logic App для отслеживания инцидентов:

• Azure DevOps, который можно использовать для создания и отслеживания рабочих элементов инцидентов в Azure Boards.
• Azure Table Storage, где можно хранить и извлекать информацию о том, кто звонит, чтобы вы могли уведомить соответствующих людей, чтобы реагировать на инцидент. В нашем примере мы будем использовать его в качестве простого хранилища ключей и атрибутов без схемы для данных дежурных списков.
• Microsoft Teams, который можно использовать для создания нового уникального канала инцидентов для отслеживания бесед команд инженеров в режиме реального времени при обмене данными о конкретных инцидентах. Это позволяет сохранить взаимодействие в соответствии с временной последовательностью событий при проведении проверки после инцидента.

Теперь давайте связываем это все вместе с приложением логики. Сначала ознакомьтесь с полным приложением, как показано в конструкторе Logic Apps, а затем рассмотрим его пошагово.

Первым шагом является обработка триггера — упомянутого HTTP-запроса. HTTP POST-запрос выполняется в нашем логическом приложении, которое содержит JSON-содержимое с информацией об инциденте, который мы хотим зарегистрировать. Мы анализируем полученные данные и отправляем обратно подтверждение о получении.

Используя эти сведения, мы создадим новый рабочий элемент в нашей Azure DevOps организации, представляющей этот инцидент.

Затем он создаст новый канал Teams для инцидента:

После создания канала рабочий элемент, который мы создали момент назад, обновляется со ссылкой на новый канал. Это хранит всю информацию в одном месте (рабочий элемент) и позволяет людям, глядя на него позже, знать, куда идти, если они хотят присоединиться к этому каналу.

Теперь пришло время вовлечь дежурного в ситуацию. Мы запрашиваем в Azure Table Storage запись реестра, определяющую текущего дежурного инженера. Возвращается ответ JSON, который затем анализируется.

Так как наш запрос может возвращать список, необходимо выполнить итерацию каждого соответствующего элемента в качестве следующего шага. В рабочем процессе используйте эти данные для идентификации владельца первичного инцидента и любых резервных копий. Основной ответчик может быть назначен рабочему элементу Azure DevOps, а дополнительные ответчики могут быть отслежены с помощью связанных задач, комментариев или уведомлений.

Затем, в качестве заключительного шага, мы отправляем сообщение в канал Teams с указателем на рабочий элемент для тех, кто присоединяется к каналу и хочет знать, где хранится достоверная информация по этому инциденту.

Это лишь один пример того, как можно автоматизировать настройку механизмов отслеживания инцидентов и обмена данными. В следующем уроке мы немного углубимся в аспекты взаимодействия вокруг инцидента.