В мире инженера по надежности сайта (SRE)отказ является не только вариантом, но и ожидаемым. Системы, веб-приложения, серверы, устройства и т. Д. Все подвержены проблемам с производительностью и неожиданным отключениям в какой-то момент. Это неизбежный факт. Эти неожиданные неудачи могут привести к огромным потерям доходов, доверия клиентов и, в зависимости от отрасли, возможно, штрафам. К счастью, управление инцидентами SRE является одной из основных практик, используемых для ограничения сбоев, вызванных неожиданными проблемами. В другой статье мы говорили о проектировании хаоса и о том, как команды SRE активно ищут и тестируют неудачи, чтобы предотвратить худшее. Однако, как мы все знаем, проблемы могут проскользнуть через трещины. Цель состоит в том, чтобы эти инциденты не превратились в крупномасштабные каскадные сбои. Команды SРЕ и DevOps могут использовать эти инциденты для более эффективного построения и улучшения своих систем и служб.
Что такое инцидент?
Прежде чем мы углубимся в эту тему, сначала мы должны обсудить, что такое инцидент. Где проводится грань между чем-то, что требует немедленных действий, и тем, что может быть исследовано позже? Если бы каждый вопрос был классифицирован как срочный, никто бы не получил никакого решения. В контексте ИТ (информационных технологий) инцидент — это просто событие или проблема, которая нарушает нормальную работу или качество обслуживания. Это не привело к сбою, но если его не остановить, может оказать большее влияние на ваши службы и операции. И они обычно происходят в 2:00 ночи, когда вы блаженно спите и буждаетесь от звука выключенного телефона. Мы, конечно, шутим, но вы знаете, что что-то плохо, если это произойдет рано утром. Ничего хорошего в 2:00 .m., особенно когда речь идет об ИТ-индустрии.
Что такое управление инцидентами?
Теперь, когда мы поговорили о том, что такое инцидент, управление инцидентами — это процесс, с помощью которого команды решают эти события и возвращают системы и службы в нормальное состояние. Следует также отметить, что управление инцидентами является лишь одним из элементов более широкой концепции, известной как управление ИТ-услугами или ITSM. ITSM определяет, как команды проектируют, создают и предоставляют свои услуги. Это гораздо больше, чем просто ИТ-поддержка. ITSM — это политики, процессы и структура, лежащие в основе жизненного цикла ИТ-услуг. ITSM является одной из практик Библиотеки инфраструктуры информационных технологий, или ITIL.
ITIL предоставляет основу и руководящие принципы для создания ITSM-решений. Возможно, вы уже знакомы с другими платформами, такими как Business Process Framework (eTOM), Control Objectives for Information and Related Technologies (COBIT), FitSM, ISO/IEC 20000 и Microsoft Operations Framework (MOF).
Структура управления ИТ-услугами (ITSM)
Если мы отступим назад и просто немного сосредоточимся на элементах в структуре ITSM, есть шесть других компонентов, которые составляют «колесо» ITSM вместе с управлением инцидентами. Пока мы не будем вдаваться в подробности об этом, но важно понять, как все эти кусочки сочетаются вместе с управлением инцидентами.
Каталог услуг
Каталог ИТ-услуг обычно представляет собой базу данных или ресурс, который организация создает для предоставления пользователям информации об их операционных услугах и предложениях. Эти каталоги услуг предоставляют полезную информацию о текущих и планируемых услугах, а также о ценах, процессе закупок, точках контакта и других результатах.
Служба поддержки
Службу поддержки можно рассматривать как точку контакта между поставщиком услуг и пользователями, такими как внутренние сотрудники, заинтересованные стороны или клиенты. Это центральный «хаб», куда пользователи идут, чтобы получить помощь и обслуживание. По определению ITIL, служба поддержки может принимать форму разрешения инцидентов или запросов на обслуживание, но в любом случае основной целью службы поддержки является предоставление быстрого и эффективного обслуживания.
Управление проблемами
Когда мы говорим об управлении инцидентами, команда SRE может быстро разрешить инцидент, но основная проблема все еще может существовать и сохраняться еще некоторое время. Управление проблемами — это процесс, с помощью которого коренные причины инцидентов постоянно устраняются, что повышает долгосрочную производительность и будущие развертывания служб.
Управление изменениями
В любом типе изменений, идет ли речь о развертывании новых услуг или личных изменениях, всегда есть элемент риска. Управление изменениями — это процесс определения того, как изменения повлияют на развертывание службы, и/или рассмотрения их влияния на сам бизнес. Управление изменениями также иногда группируется с управлением выпусками.
Управление активами
Вы не можете виртуализировать все… ещё. Программные службы по-прежнему требуют физических устройств и оборудования для их функционирования. И организациям необходимо отслеживать, управлять и постоянно обновлять эти устройства, чтобы обеспечить бесперебойную работу их услуг. Управление активами также называется управлением ИТ-активами или ITAM.
Управление знаниями, политикой и процедурами
Целью управления знаниями является сокращение избыточности с точки зрения сбора, анализа и обмена информацией в организации. Это помогает повысить эффективность и гарантирует, что информация является последовательной, актуальной и доступной.
Жизненный цикл управления инцидентами: процесс и этапы
Реакция организации на инцидент, независимо от того, говорим ли мы о простоях, нарушениях безопасности или кибератаки, или даже о длительной задержке и повторяющихся ошибках, имеет решающее значение для дальнейшего успеха бизнеса и доверия со стороны клиента или конечного пользователя. SРЕ должны управлять сложными распределенными системами. Хотя преимущества этих систем заключаются в том, что они более надежны, масштабируемы и отказоустойчивы, это также делает их чрезвычайно сложными, что может привести к увеличению времени устранения, поскольку проблемы сложнее обнаружить и точно определить. Лучшие команды управления инцидентами SRE придерживаются строгого процесса управления инцидентами и их устранения. Хотя фактические шаги и процессы могут варьироваться в зависимости от организации, большинство из них следуют одному и тому же основному пути. Давайте рассмотрим процесс и шаги управления инцидентами SRE.
1. Идентификация инцидентов
Вы не можете исправить проблемы, о которых вы не знаете. Идентификация инцидентов начинается с той или иной формы механизма мониторинга или оповещения. Мы говорили о мониторинге распределенных систем в другой статье и о том, как это относится к командам SRE. Знание того, когда и где происходит ошибка, время простоя или задержка приложения, является критическим фактором в ограничении воздействия на пользователей и клиентов. Тем не менее, в некоторых случаях инцидент становится известным через запрос в службу поддержки, телефонный звонок или даже социальные сети, что никогда не является хорошей новостью, когда проблемы публикуются публично для всеобщего обозревшего.
2. Протоколирование инцидентов
Каким бы ни был метод обнаружения, после того, как инцидент был идентифицирован, он должен быть зарегистрирован. Ведение журнала инцидентов служит нескольким целям. Он обеспечивает наличие официального протокола, который был представлен, и для последующего рассмотрения тенденций инцидентов. Если один и тот же или похожий инцидент возникает неоднократно, это может свидетельствовать о более сложной проблеме, которую необходимо решить. При регистрации инцидента также включается соответствующая информация, такая как метка времени, описание инцидента и кто обнаружил проблему. Чем более подробная информация, тем лучше.
3. Категоризация инцидентов
Далее следует классификация инцидента на основе таких факторов, как серьезность, срочность или функциональная область воздействия. Подобно регистрации инцидента, больше информации, которая предоставляется, может помочь позже при определении правильной команды или человека для назначения ответа на инцидент.
4. Приоритизация инцидентов
В зависимости от того, как инцидент был классифицирован, следующим шагом является установка уровня приоритета. Опять же, некоторые из этих шагов происходят в одно и то же время, поэтому в некоторых случаях они могут быть выполнены в одно и то же время. Организации обычно используют простую шкалу низкого, среднего или высокого уровня, однако некоторые инциденты могут автоматически попадать в определенные категории в зависимости от того, что затронуто. Например, если инцидент связан с отключением, это автоматически становится приоритетным.
5. Реагирование, разрешение и закрытие инцидентов
Последний шаг заключается в том, чтобы, наконец, отреагировать и разрешить инцидент, чтобы положить конец. Этот последний шаг больше похож на искусство, чем на науку. Здесь нет простой кнопки. Он может занять несколько циклов и пытается подтвердить, что инцидент окончательно разрешен. Каждая попытка может принести больше информации и дополнительных теорий относительно того, почему инцидент может происходить. Это также может привести к выявлению дополнительных возможностей, где могут присутствовать слабые места. После того, как инцидент был рассмотрен, пришло время закрыть запрос и ответить первоначальному пользователю, который сообщил об инциденте.
Вскрытие
После реагирования на инцидент, как правило, рекомендуется просмотреть детали инцидента в полном объеме. Это называется патологоанатомическая патологоанатомическая. Определение того, какие инциденты требуют вскрытия, обычно решается командой или организацией, однако причины остаются прежними. Вскрытие помогает определить области, которые можно улучшить, выявить слепые зоны производительности и усовершенствовать процесс реагирования на инциденты. Вскрытие должно обобщать все аспекты инцидента и включать следующие элементы:
- Резюме высокого уровня и график инцидента.
- Анализ первопричин и источника инцидента.
- Действия, предпринятые для разрешения инцидента, и какие из них были эффективными или неэффективными.
- Предотвращение инцидентов в будущем вместе с дополнительной информацией, которая была обнаружена.
Патологоанатомия является одним из основных правил культуры SRE. На самом деле, они называют это безупречным вскрытием. Идея этой концепции заключается в том, что все в команде действовали с лучшими намерениями, и никто не виноват в инциденте. Основное внимание уделяется определению того, почему это произошло и как улучшить производительность системы в будущем. Ошибки являются естественной частью отрасли, поэтому вместо того, чтобы обвинять отдельных лиц, основное внимание уделяется созданию более надежной, устойчивой системы, чтобы проблемы никогда не повторялися.
Заключение: Управление инцидентами SRE – обзор, методы и инструменты
Управление инцидентами SRE имеет решающее значение для поддержания работоооборота систем, приложений, сайтов и служб. Секунды имеют значение, особенно когда речь идет о пользовательском опыте. В больших распределенных системах самая маленькая проблема может вызвать каскадные проблемы. Упреждающая настройка правильных оповещений и уведомлений может быть разницей при возникновении проблем и обеспечении ограниченного воздействия на пользователей. Для получения дополнительной информации о том, как платформа Dotcom-Monitor интегрируется с этими инструментами управления инцидентами, посетите нашу базу знаний.
Попробуйте Dotcom-Monitor бесплатно и получите доступ ко всем решениям, интеграциям и функциям платформы.
