Исправление
Разделение жизненного цикла реагирования на инциденты на пять этапов, как вы видели в этом модуле, помогает понять процесс, но этапы не всегда так отличаются, как они отображаются на схеме. В частности, граница между фазами реагирования и исправления часто размывается. Это особенно верно, если действия, предназначенные для устранения или улучшения ситуации, имеют противоположный эффект. В этом случае реагирование и исправление, как правило, перекрываются или переключаются между этими двумя процессами.
В этом уроке вы узнаете больше об исправлении и шагах, составляющих этот этап, а также некоторые полезные советы и инструменты. Важно отметить: вы не должны принимать меры, описанные здесь, как предписательный контрольный список.
Если у вас действительно имеется на руках контрольный список для исправления, это часто индикатор того, что пришло время внедрить автоматизацию. Когда вы можете описать именно то, что нужно сделать, и в каком порядке устранить проблему, это идеальное время для обучения этих шагов компьютеру, чтобы система может сделать это для вас.
С чего начать
Вы узнали о важности сокращения времени, необходимого для реагирования на инцидент. Теперь давайте рассмотрим несколько вещей, которые могут помочь ускорить процесс исправления или устранить проблему.
Разные члены команды могут иметь разные ментальные модели того, как работают процессы, и различные идеи о том, каким должен быть первый шаг. Сначала можно просмотреть журналы, а другой может сначала запустить запросы и просмотреть метрики. Нет единого правильного пути к успеху.
Тем не менее, это помогает предоставить людям контекст и руководство о том, где они должны идти и что они должны смотреть.
Как и кому эскалировать
Важный вопрос, на который нужно ответить при определении вашей исходной точки для исправления: когда вы застряли, к кому можно обратиться за эскалацией проблемы? Вы должны попытаться распределить больше обязанностей по дежурству на команду в целом, а не только на операции или обеспечение надежности сайта. Это должна быть ответственность всех членов команды, чтобы системы были установлены и запущены для удовлетворения ваших целей надежности.
Какие ресурсы полезны для первых респондентов?
Далее следует определить те вещи, которые могут использовать первые ответчики, чтобы начать процесс. Это может включать соответствующие метрики, журналы, запросы и т. д. Если это возможно, их следует указать в книге Azure или руководстве по устранению неполадок. Мы поговорим о них всего за один момент.
Также полезно предоставить простые ссылки на ресурсы (часто в руководстве по устранению неполадок). Если ваша цель состоит в том, чтобы реагировать и устранять проблему как можно быстрее, помогая людям находить ответы на вопросы без необходимости искать нужный документ или URL-адрес ускорит процесс.
Информирование заинтересованных сторон
Вы можете стать настолько сосредоточены на устранении проблемы, что вы можете забыть, что есть много людей, которые не участвуют непосредственно в ответ на инцидент, но кто хочет и должен знать, что происходит.
Важно взаимодействовать с другими внутренними командами и следить за тем, что происходит при возникновении инцидента. Если вы не предоставляете им регулярные обновления, они, скорее всего, будут запрашивать отчет о статусе. Они имеют право на эту информацию, но вам нужен лучший способ сделать их осведомленным о проблеме и о том, что делается об этом.
Вам нужно чётко обозначить признание команд внутри компании. Будьте ясны в представлении того, о чем вы знаете и что делается, и установите ожидания относительно того, когда они получат от вас ответ.
Формула взаимодействия с заинтересованными лицами проста:
- Это то, что мы знаем.
- Это то, что мы делаем.
- Мы вернемся к вам через X промежуток времени.
Это поможет предотвратить ситуацию, когда заинтересованные лица будут приходить к вам и отвлекать вас, пока вы пытаетесь решить проблемы.
Одним из способов распространения этой информации является использование легко редактируемой веб-страницы состояния, например той, которую мы упомянули в последнем уроке. Во многих случаях может потребоваться отдельная, более подробная страница состояния для внутренних заинтересованных лиц и внешний для клиентов. Предыдущая формула работает в обоих случаях.
Использование рабочих книг Azure Monitor и руководств по устранению неполадок
Azure имеет две тесно связанные функции, которые могут быть чрезвычайно полезными для команды на этапе исправления: Azure Monitor Workbooks и Application Insights Troubleshooting Guides. Для этого модуля они взаимозаменяемы, включая один и тот же пользовательский интерфейс. Рабочие тетради Azure Monitor можно найти на портале Azure в разделе Azure Monitor. Вы найдете руководства по устранению неполадок Azure Insights на портале Azure при выборе экземпляра Application Insights.
Можно рассматривать рабочие книги и руководства по устранению неполадок как "живые документы", которые можно создавать с помощью интерфейса создания страниц. При создании нового элемента, вы можете добавить на страницу:
- Произвольный текст, например маркированный список элементов, которые нужно сделать, или другие полезные сведения для кого-то, кто знакомится со страницей.
- Ссылки на другие системы, например ссылки на другие панели мониторинга или документацию
- Запросы языка запросов Kusto (KQL)
Это последний элемент, который делает документ "динамическим". В предыдущем модуле в этой схеме обучения мы изучили язык запросов KQL, встроенный в Log Analytics и другие части Azure Monitor. Используя этот язык, можно написать собственные запросы для возврата и отображения диагностических сведений из нашего приложения и инфраструктуры Azure. Когда запрос KQL вставляется в книгу или руководство по устранению неполадок, текущие результаты этого запроса отображаются в режиме реального времени для читателей документа. Это означает, что руководство по устранению неполадок может сказать не только "Обязательно проверить частоту ошибок на веб-сервере", но и показать текущий график для этой частоты ошибок прямо рядом с инструкциями. Она может иметь ссылку, например, "вот документация по перезапуску веб-сервера", которая переносит первого ответчика непосредственно к нужной документации.
Azure также предоставляет некоторые существующие шаблоны, помогающие приступить к разработке собственных документов. Ниже приведен снимок экрана некоторых готовых шаблонов, которые вы можете предложить:
Существует расширенный редактор для рабочих книг и руководств по устранению неполадок, который позволяет получить доступ к JSON или шаблону Azure Resource Manager и вставить представление этого документа. Это означает, что вы можете отслеживать и распространять эти документы, используя выбранную вами систему управления версиями. Он также позволяет автоматизировать настройку рабочих книг или руководств по устранению неполадок, что полезно при развертывании другой инфраструктуры. Создание набора пользовательских документов по устранению неполадок для новой службы на этапе её развёртывания становится лёгким с помощью этой лучшей практики.
Другие полезные советы и инструменты
В этом модуле вы узнали о различных средствах и сочетаниях клавиш, которые можно использовать для повышения эффективности и уменьшения времени реагирования на инциденты. Как мы заключим этот последний урок, мы сделаем краткий обзор некоторых инструментов и методов, которые полезны для диагностики проблем в ваших системах.
- Вы можете использовать ссылку "Панель мониторинга приложений" в Application Insights для автоматического создания панели мониторинга с большинством ключевых элементов, необходимых в качестве отправной точки. Обратите внимание, что это не включает здоровье служб Azure. Это необходимо закрепить на панели мониторинга, чтобы проверить, связана ли проблема с системами или самой облачной службой.
- Вы можете использовать Карту приложений в Application Insights, чтобы точно определить, что происходит и выявить причины проблем. Чтобы найти причину ошибки (например, неправильно сформированный URL-адрес), можно следовать следуйте указаниям.
- Log Analytics можно использовать для запроса любой части системы.
Все предыдущие средства являются бесценными в устранении проблем.