Incident management SRE
Last updated
Last updated
https://habr.com/ru/companies/otus/articles/722892/
IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM
Привет Хабр! Не так давно общался с SRE в нашей команде и он рассказал мне о базовых принципах процесса управления инцидентами, теперь я поделюсь этим с вами, быть может кому‑то поможет.
Управление инцидентами включает в себя мониторинг, анализ, планирование и выполнение. SRE работают с операционными группами, экспертами по техническим вопросам, разработчиками, инженерами DevOPs, владельцами приложений и другими.
При оценке инцидентов SRE обращают внимание на такие критерии, как импакт и частота повторения — для того, чтобы определить, какие инциденты требуют дальнейшего анализа.
Есть некоторые практики, которых придерживаются в нашей команде:
Прежде чем произойдет инцидент, сотрудничайте с другими, настроив уведомления о предупреждениях и информационные панели, чтобы во время события уведомлялись нужные люди и предпринимались правильные действия.
Во время инцидента SRE несут ответственность за решение инцидента; выполнение заявок на обслуживание; мониторинг каналов событий и журналов; и анализ информационных панелей, корреляций событий, данных о тикетах и тенденциях.
Необходимость меняться. После разрешения инцидента дополнительные действия приводят к управлению изменениями, управлению проблемами и обновлениям управления конфигурацией, чтобы снизить вероятность возникновения подобных инцидентов в будущем.
Автоматизация, связанная с проблемами, постоянно обновляется, чтобы предотвратить повторение инцидента или быстрее решить его, если все же он произойдет снова. Ниже приведена архитектура, которой мы пользуемся (больше как референс).
Инфраструктура всегда в мониторинге, что выявляет отклонения от нормального поведения, такие как уменьшение времени отклика, и оповещает ops об инцидентах.
Первые респондеры, которые всегда на связи, выявляют неисправный компонент и восстанавливают обслуживание как можно быстрее. Они делают это с помощью автоматизации и runbook (скрипт, который фиксит ту или иную проблему, если совсем уж просто), чтобы устранить зависимость и риски, связанные с ручным выполнением задач.
В то время как первые респондеры используют информационные панели, которые обеспечивают обзор приложения, они не смотрят на консоли в ожидании сигналов тревоги. Вместо этого они уведомляются о проблемах через алерты.
Эти алерты объединяются различными системами мониторинга, сопоставляются и дополняются соответствующей информацией, такой как имя приложения, затронутые пользователи и заинтересованные стороны, а также информация о соглашении об уровне обслуживания (SLA). Эти алерты являются и должны быть действенными, в идеале с четким описанием мер по смягчению последствий. Используя call‑rotation и списки on‑call, алерт отправляется правильному первому респонденту, который предпринимает необходимые действия.
Оповещения, которые не могут быть быстро определены для смягчения последствий, требуют дополнительного анализа. SME в нескольких доменах сотрудничают, чтобы изолировать инцидент и определить эффективный ответ.
Такие технологии, как ChatOps, помогают в этом сотрудничестве. Инструменты DevOps и управления услугами также интегрируются через бот‑агентов. Командир инцидента (да у нас есть и такие роли) координирует эти задачи и поддерживает прозрачную связь с пострадавшими заинтересованными сторонами.
Целью управления инцидентами является восстановление службы. Команда не тратит время на анализ основной причины проблемы. Этот анализ проводится на следующем этапе: управление проблемами.
Подходы к управлению инцидентами включают перезапуск микросервиса, настройку балансировщика нагрузки для игнорирования отказавшего инстанса или откат к предыдущей версии. Типичные принципы DevOps, такие как blue‑green deployment (CD), упрощают реализацию этих подходов.
Целью мониторинга инцидента является обнаружение простоев, сатурация производительности и т. д. Поскольку неэффективно просто заставлять наших сотрудников постоянно следить за консолями, следующим важным элементом является настройка алертов, чтобы нужный SME уведомлялся, когда что-то идет не так. В этих случаях тулчейн играет важную роль.
SRE часто должны сотрудничать с SME, чтобы изолировать проблему и определить стратегию смягчения последствий. Вместо того, чтобы полагаться на электронную почту и телефоны, SRE используют платформы уведомлений и совместной работы, из такой практики как ChatOps.
В дополнение к мониторингу и активному исследованию служб и API SRE также должны отслеживать файлы журналов служб. Этот мониторинг может помочь выявить проблемы до того, как они повлияют на службу. Это также может ускорить этап идентификации и разрешения инцидента.
По мере увеличения нагрузки и усложнения приложений, первые респондеры начинают получать слишком много предупреждений. Они получают оповещения, связанные с симптомами и причинами. Некоторые предупреждения могут не действовать. События могут не предоставлять достаточный контекст для быстрого реагирования, например соглашение об уровне обслуживания (SLA) или данные об импакте. На этом этапе должен быть “event management” в тулчейне. Управление событиями сопоставляет связанные события, удаляет” шум”, чтобы отображались только предупреждающие действия, и дополняет эти события дополнительным контекстом.
Усовершенствованная цепочка инструментов с управлением событиями будет выглядеть так, как показано здесь.
Чтобы быстро реагировать на проблемы, нужны runbook и средства автоматизации. Runbook могут вызываться автоматически либо для запуска диагностических команд, либо для устранения проблемы. Runbook также может запускаться вручную первым ответчиком и специалистом по разрешению инцидентов. Чтобы избежать ручного входа в систему и риска неправильного набора команд, автоматизированные и полуавтоматические runbook обеспечивают безопасное и согласованное выполнение.
По мере добавления новых инструментов SR-инженерам требуется обзор всего “ландшафта”. Эта видимость не заменяет существующие пользовательские интерфейсы продукта (UI), а вместо этого дополняет их и обеспечивает комбинированное представление среды на панелях управления для конкретных пользователей. В идеале в этих представлениях также отображается дополнительная информация, например действия по развертыванию или информация об уровне обслуживания.
Кроме того, информация об инцидентах постоянно отслеживается в инструментах оформления заявок, которые являются источником достоверной информации для расчета SLA. Предприятиям особенно необходимо вести журнал аудита для всех инцидентов. Отслеживаются начало и конец инцидента, а также любые важные обновления. Интеграция всей цепочки инструментов автоматизирует заполнение этого журнала действий.
Прозрачность — ключевой аспект завоевания и поддержания доверия пользователей вашего сервиса. Поскольку предприятия полагаются на доступность и качество услуг, они заинтересованы в получении информации о любых проблемах или инцидентах, влияющих на качество этих услуг. В дополнение к незапланированным отключениям любое плановое техническое обслуживание должно следовать той же парадигме. Руководящими принципами любого сообщения о сбоях являются точность, ясность и своевременное предоставление информации.
Можно использовать правило: “How? Who? When?”
How: Поставщики услуг информируют своих пользователей об инцидентах несколькими способами:
Веб-страница с информацией о статусе,
Информация о статусе через социальные сети, такие как Twitter,
Эмейл,
Программный API (веб-хук),
Инженерный блог компании.
Предоставить нужно информацию об инциденте в сочетании этих каналов. Не будем думать, что пользователи всегда знают, где искать.
Who: При составлении плана передачи информации о состоянии четко определите, кто отвечает за выполнение каждой задачи. Важно определить зоны ответственности, чтобы общение осуществлялось быстро и эффективно.
Типичной ролью, отвечающей за коммуникацию и координацию, является руководитель инцидента.
Этот человек олицетворяет культуру прозрачности, честности и подотчетности перед клиентами в качестве руководящих принципов.
Сосредоточив общение в одной роли, убедитесь, что общение последовательное и не конфликтное или, что еще хуже, противоречивое.
Для своевременного предоставления обновлений этот человек должен иметь возможность предоставлять обновления без трудоемкого процесса утверждения.
Использование готовых сценариев или шаблонов постов — хорошая стратегия для заблаговременного завершения проверки и утверждения.
When: Также важно определить, когда общаться. Как только произойдет сбой, подтвердите инцидент и сообщите об этом пользователям. Пользователи в любом случае узнают об инциденте, и если предоставленная поставщиком страница состояния отображает что “все хорошо”, люди будут чувствовать, что им лгут.
После подтверждения сбоя часто обновляйте статус.
Найдите баланс между регулярными и содержательными обновлениями. Как только статус изменится или появится значимая информация для обмена, отправьте обновление.
Следующее обновление может занять некоторое время, но пользователи хотят видеть, что команда все еще работает над инцидентом.
Рекомендуется обновлять информацию по истечении определенного времени, например, каждые 30 минут, даже если новая информация недоступна. Однако будьте осторожны, чтобы не показывать один и тот же ответ для нескольких итераций.
После восстановления службы опубликуйте уведомление об окончании сбоя.
Каким бы надежным ни был сервис, иногда возникают проблемы, которые могут повлиять на качество и доступность. Управление инцидентами — это процесс, посредством которого мы восстанавливаем поврежденный сервис. Работая вместе в команде, мы можем определить характеристики сервиса, чтобы как можно быстрее вернуть сервис в нужное русло.
Некоторые инциденты требуют дальнейшего анализа:
Когда проблемы возникают более одного раза (частота),
Когда сбой может затронуть многих пользователей (импакт),
Когда система не работает так, как задумано.
Каскадный сбой — это сбой, который со временем нарастает в результате положительной обратной связи. Когда одна часть всей системы выходит из строя, возрастает вероятность того, что другие части системы также откажут.Этот шаблон может создать эффект домино или каскада, который отключает все функции службы.
Снижение производительности: падение производительности относится к службам, которые не работают должным образом. Обнаружение и устранение ухудшения производительности может быть затруднено, но SRE несут ответственность за обнаружение и устранение проблем с ухудшением производительности.
Сбой функционала: Иногда команда создает необходимую функцию, и она не работает должным образом.
_Воздействие вышестоящих и нижестоящих зависимостей_Зачем учитывать восходящие и нисходящие зависимости при обработке инцидента?
Для вас важно учитывать восходящие и нисходящие зависимости, влияющие на микросервис, при обработке инцидента, поскольку они имеют решающее значение для разрешения инцидента в целом.
Примеры восходящих проблем включают в себя:
Проблема с сетью,
Проблема аутентификации.
Примеры нижестоящих проблем включают:
Проблема с облачным объектным хранилищем,
Проблема с блочным хранилищем,
Сбой в базе данных, на которую повлияла проблема микросервиса.
Зная, какие восходящие и нисходящие зависимости находятся в микросервисе, и как исправить любые проблемы с ними, вы приблизитесь к разрешению общего инцидента.
Один из методов, который SRE могут использовать для специального изучения зависимостей приложения — это распределенная трассировка. Его можно использовать для идентификации неудачной транзакции и отслеживания потока транзакции через приложение микрослужбы.
Распределенная трассировка — это метод, позволяющий регистрировать информацию в приложениях на основе микрослужб.
Уникальный идентификатор транзакции передается через цепочку вызовов каждой транзакции в распределенной топологии.
Одним из примеров транзакции является взаимодействие пользователя с веб-сайтом.
Уникальный идентификатор генерируется в точке входа транзакции.
Затем идентификатор передается каждой службе, используемой для завершения задания, и записывается как часть информации журнала служб.
Не менее важно включать временные метки в сообщения журнала вместе с идентификатором.
Идентификатор и отметка времени объединяются с действием, которое выполняет служба, и состоянием этого действия.
С помощью инструментов Runbook, интегрированных с уведомлениями о событиях, SRE могут определять автоматические процедуры, которые будут выполняться при возникновении определенного события. Рассмотрим, что происходит, когда система управления событиями получает событие, указывающее на сбой службы. Система может выполнять автоматизированные действия, определенные в runbook. Например, когда система получает событие сбоя службы, сценарий runbook предлагает сделать снимок системы. SRE могут автоматизировать следующие действия:
Использование системного имени хоста и учетных данных для входа на сервер,
Получение списка процессов, памяти, использования cpu, и другой информации,
Извлечение любых связанных журналов и сообщений трассировки.
Результаты действий могут быть немедленно отправлены первому ответчику, как только действие будет завершено. Выявление неполадок с помощью автоматизированных runbook — это низкий барьер, поскольку команды доступны только для чтения и обычно не наносят вреда системам. Со временем команда может писать сценарии для автоматического решения проблем без ручного вмешательства.
По мере взросления команды и приложения могут развиваться и runbook. Зрелость runbook включает следующие этапы:
Ad hoc: это начальное состояние характеризуется отдельными ручными действиями без документации или согласованности.
Repeatable: стандартные действия задокументированы и согласованы во всей организации. Эти действия по-прежнему выполняются вручную.
Defined: действия принудительно выполняются. Действия становятся доступными, поскольку сценарии и задачи предоставляются оператору в контексте инструментов управления.
Managed: система предлагает правильное действие для события. Используя базовые функции if/then, система автоматически запускает действия.
Optimized: на самом высоком уровне применяется аналитика, чтобы определить, когда и что автоматизировать.
Чтобы runbook был оптимальным, SRE должны управлять его содержимым и поддерживать его. Приложение может быть обновлено до версии, требующей других действий. Технологии и инфраструктура могут измениться, что приведет к изменениям в командах runbook. При выборе решения runbook рассмотрите возможность управления отзывами пользователей, управления библиотеками, контролем доступа, API, отчетами и аудитом.
User feedback: Когда инженеры используют runbook, собирайте их отзывы.
Вы можете задать им следующие вопросы:
Помог ли runbook решить проблему?
Как можно улучшить модуль runbook?
Library management: Некоторые решения Runbook предоставляют библиотеку «строительных блоков» Runbook, которые можно использовать для создания Runbook. В зависимости от инструмента библиотека может быть предоставлена поставщиком или представлять собой набор библиотек, предоставленных другими пользователями.
Например, Red Hat® Ansible поставляется с модулями для выполнения общих задач. Разработчик может использовать модуль для более быстрой разработки Runbook.
Access control: Для средних и крупных организаций решающее значение имеет управление пользователями и ресурсами. Конкретным пользователям или группам пользователей требуется доступ для работы с определенной группой ресурсов. Если необходим аудит, аудитору может потребоваться доступ только для чтения к большей группе ресурсов.
Другой формой управления доступом является имя пользователя и пароль для средства Runbook для выполнения действий с управляемыми ресурсами. Может потребоваться несколько уровней контроля доступа.
Например, чтобы прочитать состояние сервера, используйте обычные учетные данные для входа, но для изменения конфигурации сервера учетная запись должна иметь привилегии root. Runbook могут предоставить средства безопасного делегирования привилегированных команд администраторам.
API: В рамках интеграции Runbook система управления событиями может активировать Runbook. Runbook также можно запускать в результате действия инструмента на панели мониторинга топологии, как действие из системы ChatOps или как задачу в конвейере непрерывной доставки. Решение Runbook должно предоставлять набор API, чтобы другой компонент интеграции мог вызывать правильный Runbook с соответствующими полномочиями.
Report and audit: При рассмотрении решения Runbook обратите внимание на его возможности отчетности и аудита. Полезно знать, какие Runbook выполняются чаще всего или получают самые высокие оценки при решении проблем.. Вашей организации может потребоваться аудит Runbook в рамках деятельности по обеспечению соответствия требованиям.
Информация о выполнении модуля Runbook может быть передана группе SRE из отчета, чтобы расставить приоритеты в отношении необходимых работ по улучшению приложений или инфраструктуры.
В SRE подход к решению повторяющейся проблемы заключается в устранении ее источника. Runbook может быть хорошим краткосрочным тактическим решением, когда исправление требует дополнительного времени и усилий.
SRE может использовать отчет, созданный решением Runbook, и работать с приоритетным списком исправлений. По мере реализации большего количества исправлений требуется запускать меньше Runbook. Помните, что лучше предотвратить проблему до того, как она возникнет, чем решать ее после того, как она возникла. Однако иногда runbook является решением.
Организация может инвестировать в коммерческое программное обеспечение, которое команда SRE не может изменить напрямую, или SRE может использовать решение Runbook для автоматизации повторяющихся задач, выходящих за рамки управления инцидентами.
Устранение неполадок не зависит от удачи. Наша основная теория заключается в том, что SRE могут изучать и обучать эффективным стратегиям. Теория, лежащая в основе эффективного устранения неполадок, заключается в том, что этому можно научиться и чему можно научить.
Процесс устранения неполадок — это способность выдвигать гипотезы о причинах сбоя и тестировать решения.
Помните об этих важных моментах:
Не все неудачи одинаково вероятны — при прочих равных условиях наиболее вероятным решением может быть простое или очевидное решение.
Корреляция не является причинно-следственной связью.
Шаги в модели устранения неполадок:
Получаем сообщение о проблеме, что-то не так с системой.
Просмотрим телеметрию и логи, чтобы понять ее текущее состояние.
Определим некоторые возможные причины.
Активно «лечим» систему — то есть изменяем систему контролируемым образом и наблюдаем за результатами.
Повторно тестируем, пока не будет выявлена основная причина.
Примем меры для предотвращения повторения.
Напишите репорт о решении, задокументируем это.
