Исправление

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

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

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

С чего начать

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

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

Тем не менее, это помогает предоставить людям контекст и руководство о том, где они должны идти и что они должны смотреть.

Как и кому эскалировать

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

Какие ресурсы полезны для первых респондентов?

Далее следует определить те вещи, которые могут использовать первые ответчики, чтобы начать процесс. Это может включать соответствующие метрики, журналы, запросы и т. д. Они должны быть предоставлены в рабочей тетради Azure Monitor, если это возможно. Мы поговорим о них всего за один момент.

Также полезно предоставить простые ссылки на ресурсы (часто в книге). Если ваша цель состоит в том, чтобы реагировать и устранять проблему как можно быстрее, помогая людям находить ответы на вопросы без необходимости искать нужный документ или URL-адрес ускорит процесс.

Информирование заинтересованных сторон

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

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

Вам нужно чётко обозначить признание команд внутри компании. Будьте ясны в представлении того, о чем вы знаете и что делается, и установите ожидания относительно того, когда они получат от вас ответ.

Формула взаимодействия с заинтересованными лицами проста:

• Это то, что мы знаем.
• Это то, что мы делаем.
• Мы вернемся к вам через X промежуток времени.

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

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

Использование рабочих книг Azure Monitor

Azure Monitor Рабочие книги являются чрезвычайно полезными для команды на этапе исправления проблем. Рабочие тетради Azure Monitor можно найти в Azure Monitor на портале Azure.

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

• Произвольный текст, например маркированный список элементов, которые нужно сделать, или другие полезные сведения для кого-то, кто знакомится со страницей.
• Ссылки на другие системы, например ссылки на другие панели мониторинга или документацию
• Запросы языка запросов Kusto (KQL)

Это последний элемент, который делает документ "динамическим". В предыдущем модуле в этой схеме обучения мы изучили язык запросов KQL, встроенный в Log Analytics и другие части Azure Monitor. Используя этот язык, мы можем написать собственные запросы для возврата и отображения диагностических сведений из нашего приложения и инфраструктуры Azure. При вставке запроса KQL в книгу текущие результаты этого запроса отображаются в реальном времени для читателей документа. Это означает, что книга может сказать не только "Не забудьте проверить частоту ошибок на веб-сервере", но и показать текущий график для этой частоты ошибок прямо рядом с инструкциями. Она может иметь ссылку, например, "вот документация по перезапуску веб-сервера", которая переносит первого ответчика непосредственно к нужной документации.

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

Существует функция Advanced editor для рабочих книг, которая позволяет просматривать содержимое книг в виде JSON и экспортировать его в виде шаблона Azure Resource Manager (ARM). Это означает, что вы можете отслеживать и распространять эти документы, используя выбранную вами систему управления версиями. Кроме того, он позволяет автоматизировать подготовку документов, что полезно при развертывании другой инфраструктуры. Если вы предпочитаете Bicep, вы можете включить ресурс рабочей книги в развертывание Bicep за пределами редактора. Создание набора пользовательских книг для использования с новой службой в момент предоставления этой службы становится легким с помощью этой лучшей практики.

Другие полезные советы и инструменты

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

• Вы можете использовать ссылку "Панель мониторинга приложений" в Application Insights в качестве настраиваемой отправной точки для работоспособности и производительности приложений. Проверьте Работоспособность служб Azure отдельно, чтобы определить, связана ли проблема с системами или службой Azure.
• Карту приложений в Application Insights можно использовать для трассировки зависимостей, точечных точек сбоя и сузить место возникновения проблемы. После этих связей вы можете найти вероятный источник ошибки, например неправильный URL-адрес.
• Вы можете использовать Log Analytics для запроса данных телеметрии и журналов, собираемых конвейером мониторинга по всей системе.

Все предыдущие средства являются бесценными в устранении проблем.