Управление инцидентами SRE: обзор, методы и инструменты

В мире инженера по надежности объекта (SRE) сбой — это не только возможное событие, это событие также ожидаемо. Системы, веб-приложения, серверы, устройства и т. д. в какой-то момент уязвимы к проблемам с производительностью и неожиданным сбоям. Это неизбежный факт.

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

Однако, как мы все знаем, проблемы могут ускользнуть из виду. Цель состоит в том, чтобы не допустить, чтобы эти инциденты переросли в крупномасштабные каскадные отключения. Команды SRE и DevOps могут использовать эти инциденты, чтобы лучше создавать и улучшать свои системы и сервисы.

Что такое инцидент?

Прежде чем мы углубимся в эту тему, мы должны сначала обсудить, что такое инцидент. Где грань между тем, что требует немедленных действий, и тем, что можно расследовать позже? Если бы каждая проблема была классифицирована как срочная, никто бы не нашел решения. В контексте ИТ (информационных технологий) инцидент — это просто событие или проблема, которая нарушает нормальную работу или качество обслуживания.

Это может не приводить к ошибке, но если этого не остановить, проблема может оказать серьезное влияние на ваши услуги и операции. И обычно они происходят в 2 часа ночи, когда вы блаженно спите и просыпаетесь от звука телефона. Мы, конечно, шутим, но когда это происходит так рано, понимаешь, что что-то нехорошо. Ничего хорошего в 2 часа ночи не происходит, особенно когда речь идет об IT-индустрии.

Что такое управление инцидентами?

Теперь, когда мы поговорили о том, что такое инцидент, управление инцидентами — это процесс, с помощью которого команды разрешают эти события и возвращают системы и службы к нормальной работе. Следует также отметить, что управление инцидентами — это лишь один элемент более широкой концепции, известной как Управление ИТ-услугами или ITSM.

ITSM определяет, как команды проектируют, создают и предоставляют свои услуги. Это гораздо больше, чем просто ИТ-поддержка. ITSM — это политики, процессы и структуры, лежащие в основе жизненного цикла ИТ-услуг. ITSM — это одна из практик Библиотеки инфраструктуры информационных технологий (ITIL).

ITIL предоставляет основу и рекомендации для создания решений ITSM. Возможно, вы уже знакомы с другими фреймворками, такими как: Структура бизнес-процессов (eTOM), Цели управления информационными и смежными технологиями (COBIT), FitSM, ISO/IEC 20000 и Microsoft Operations Framework (MOF).

Структура управления ИТ-услугами (ITSM)

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

Каталог услуг

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

Служба поддержки

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

Управление проблемами

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

Управление изменениями

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

Управление активами

Вы не можете виртуализировать все… пока. Для работы программных сервисов по-прежнему требуются физические устройства и оборудование. Компаниям необходимо отслеживать, управлять и постоянно обновлять эти устройства, чтобы обеспечить бесперебойную работу их услуг. Управление активами также известно как управление ИТ-активами или ITAM.

Управление знаниями, политикой и процедурами

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

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

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

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

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

Выявление инцидентов

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

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

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

Ошибка на сайте

Регистрация инцидентов

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

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

Категоризация инцидентов

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

Приоритизация инцидентов

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

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

Реагирование на инциденты, разрешение и закрытие

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

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

Анализ

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

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

- Краткое изложение и хронология инцидента.

- Анализ первопричины и источника инцидента.

- Действия, предпринятые для разрешения инцидента, и какие из них были эффективными или неэффективными.

- Предотвращение будущих инцидентов, а также обнаружение дополнительной информации.

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

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

Управление инцидентами SRE: инструменты и услуги

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

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

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

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

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

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

Если ваша организация использует Office 365, вы, вероятно, уже знакомы с Microsoft Teams. Microsoft Teams — это приложение для общения в реальном времени, которое предлагает такие функции, как онлайн-обмен сообщениями, видеочат и обмен документами.

Эпилог

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

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

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

Компания Mainton - разработка и тестирование программного обеспечения под заказ, DevOps и SRE, SEO и реклама в интернете с 2004 года.

ПЕНТЕСТ БЕЗОПАСНОСТЬ ВЗЛОМАЛИ? МОНИТОРИНГ ВАКАНСИИ