Язык управления инцидентами

Подтверждение инцидента

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

Действенное оповещение

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

Активный мониторинг

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

Анализ результатов принятых мер

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

Согласованное время обслуживания

Согласованное время обслуживания обычно измеряется в часах в год. В течение этого времени обеспечивается доступность сервиса. Договоренность о времени обслуживания нередко зафиксирована в SLA (соглашении об уровне обслуживания) между поставщиком и клиентом. Обычно для сервисов с высокой доступностью соглашение предписывает безотказную работу в течение 99,99 % времени. Так гарантируется, что простой будет длиться менее часа в год.

Оповещение

Сигнал тревоги или предупреждение. Оповещения срабатывают, когда средства мониторинга выявляют изменения, опасные действия или сбои в ИТ-среде.

Флуд оповещениями

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

Усталость от оповещений

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

Постоянно работающие сервисы

Сервис, от которого ждут непрерывной работы.

Ресурс/управление ресурсами

Ресурсы — это компоненты любой системы или сети, которые имеют ценность для бизнеса. Управление ресурсами представляет собой инвентаризацию этих компонентов. Она проводится сотрудником или командой с целью понять влияние обновления или удаления системы.

Аудит

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

Доступность

Ситуация, в которой продукт или система доступны и работают должным образом. Этот промежуток времени также называют временем безотказной работы системы.

Откат

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

Резервная копия

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

База

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

Эталон

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

Баг

Непредусмотренная проблема в ПО, коде, программах и т. д., которая может привести к аномальному поведению или сбою.

Анализ влияния на бизнес

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

Производительность

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

Изменение

Любые изменения в ИТ-сервисе, конфигурации, сети или процессе. Часто отслеживаются в рамках процесса, известного как управление изменениями.

История изменений

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

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

ИТ-процесс, предназначенный для изменения/обновления критически важных систем и служб с минимальным прерыванием работы. У одних команд этот процесс охватывает все аспекты изменений — от технических вопросов до нюансов, касающихся людей и других процессов. У других, согласно руководящим принципам ITIL 4, управление изменениями сосредоточено на управлении человеческими или культурными аспектами изменений. При этом другой процесс, известный как контроль изменений, посвящен оценке рисков, графикам и авторизации изменений.

ChatOps

Практика управления инцидентами с помощью чата и инструментов для совместной работы. Сотрудник компании Atlassian Шон Риган дает следующее определение ChatOps:

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

Закрытое состояние

Инцидент считается закрытым, когда были приняты все необходимые меры и устранена сама проблема.

Холодное резервирование (постепенное восстановление)

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

Холодный запуск

О холодном запуске можно говорить, когда для запуска невыполняемого приложения требуется больше времени, чем для запуска приложения, которое уже выполняется или было завершено недавно (еще «горячее»).

Ведущий специалист по взаимодействию с клиентами

Участник команды, отвечающий за коммуникацию во время инцидента.

Соответствие требованиям

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

Анализ воздействия отказа компонентов

Процесс определения влияния сбоя в работе компонента или конфигурации на сервис.

Параллелизм

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

Контрольные требования

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

Базовый сервис

Сервис, который выполняет центральную функцию для пользователей/клиентов.

Мера противодействия

Конкретная ответная мера, принятая для защиты системы или восстановления операций.

Сервис, предназначенный для клиентов

Сервисы, которые клиенты используют и с которыми они взаимодействуют.

Модель Cynefin

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

Дашбоард

Графическое представление информации о системах, оповещениях и инцидентах на одном экране. Предназначено для обобщения и систематизации сведений из различных инструментов вместе с контекстной информацией в понятном и четком формате.

Зависимость

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

Устаревание

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

Диагностика

Процесс и результат изучения инцидента и его основной причины.

Диагностические сообщения

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

Простой/отказ

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

Сверхсрочное изменение

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

Вспомогательный сервис

Сервис, необходимый для работы основного сервиса, но который не предлагается клиентам напрямую.

Среда тестирования*

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

Рабочая среда

Инфраструктура, в которой сервис предоставляется клиенту. Продукты поставляются в эту среду в целях эксплуатации. Иногда ее также называют средой эксплуатации.

Ошибка

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

Эскалация

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

Событие

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

Отчет по отклонениям

Отчет, создаваемый при превышении или недостижении пороговых значений для ключевых показателей эффективности (KPI).

Отказоустойчивость

Термином «отказоустойчивость» описывается способность сервиса продолжать работу даже в случае сбоя элемента конфигурации или отдельного компонента.

Анализ дерева неисправностей

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

Поддержка первого уровня

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

Зафиксировать

Действие или способ ремонта.

Основной ресурс

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

График с учетом часовых поясов

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

Компьютерно-техническая экспертиза

Научное, основанное на фактических данных, исследование компьютерной системы с целью выявления причины инцидента.

Работоспособный

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

Постепенное восстановление

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

Горячее резервирование

«Горячее» резервирование — это способ восстановления, при котором дублирующиеся ресурсы эксплуатируются одновременно с основными, чтобы ИТ-сервис оставался работоспособным в случае сбоя. Когда активная система выходит из строя, система из «горячего» резерва уже запущена и готова заменить отказавший компонент без каких-либо действий со стороны команды и без простоя. Другое название: немедленное восстановление.

Исправление

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

Последствия

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

Недейственное оповещение

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

Инцидент

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

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

То, как команды реагируют на инцидент. Как правило, порядок реагирования предопределен. Правила, роли и рекомендации определяются до возникновения инцидента.

Управление инцидентами

Процесс реагирования на незапланированное событие или перерыв в обслуживании с целью возобновить предоставление этой услуги. Данный процесс реализуется командами DevOps и группами по эксплуатации ИТ.

Руководитель команды реагирования на инцидент

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

Жизненный цикл инцидента

Период существования инцидента от его возникновения и обнаружения до его разрешения.

Метрики для операций ввода-вывода

Набор метрик, по которым можно оценить операции ввода-вывода. Обычно в этой категории используют такие метрики, как IOWait (время, в течение которого ЦП ожидает запрос ввода-вывода) и IOPS (количество запросов ввода-вывода в секунду).

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

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

Запись об инциденте

Запись, содержащая информацию о том или ином инциденте и перечень использованных процессов.

Лицо, реагирующее на инцидент

Лица и (или) команды, ответственные за расследование и разрешение инцидента.

Заинтересованные стороны/наблюдатели (в ходе инцидента)

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

Среднесрочное восстановление

Этот тип восстановления, также известный как «горячее» резервирование, обычно занимает от 24 до 72 часов. Нередко на восстановление уходит много времени из-за восстановления данных и (или) конфигурации аппаратного и программного обеспечения.

Библиотека инфраструктуры информационных технологий (ITIL)

Задокументированный набор общепринятых рекомендаций для ИТ-услуг.

Управление услугами информационных технологий (ITSM)

Все аспекты процессов и процедур, необходимых для оказания ИТ-услуг клиентам. Сюда входят все аспекты жизненного цикла обслуживания — от проектирования до поставки и управления инцидентами.

Метод Кепнера-Трего (Kepner Tregoe)

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

Ключевые показатели эффективности (KPI)

Показатели успешности систем или продуктов. KPI определяют заранее и регулярно отслеживают. В случае отклонения KPI от ожидаемых пороговых значений часто создаются оповещения. Например, если средняя наработка на отказ (MTBF) начинает сокращаться, можно создать оповещение, чтобы ваша команда могла выявить и изучить проблему.

Известная ошибка

Ранее существовавшая проблема, для которой уже придумано обходное решение.

Задержка

Задержка, наблюдаемая в процессе передачи данных.

Журналы

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

Легкость сопровождения

Показатель того, насколько легко можно внедрить изменения в сервис или функцию.

Обходное решение в ручном режиме

Решение, реализованное вручную (а не автоматически).

Средняя наработка на отказ (MTBF)

Среднее время работы технологического продукта между сбоями, поддающимися исправлению. Другое название: среднее время между инцидентами сервиса (MTBSI).

Среднее время подтверждения (MTTA)

Среднее время с момента создания оповещения до начала работы над решением проблемы.

Средняя наработка до отказа (MTTF)

Среднее время работы технологического продукта между сбоями, не поддающимися исправлению.

Среднее время исправления (MTTR)

Среднее время, необходимое для ремонта системы (обычно технической или механической). Это время включает в себя как время ремонта, так и любое время тестирования.

Среднее время восстановления (MTTR)

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

Среднее время разрешения (MTTR)

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

Среднее время реагирования (MTTR)

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

Модель/моделирование

Представление фактической системы, сервиса, приложения и т. д.

Мониторинг

Повторяющийся процесс для проверки функционирования сервиса или процесса.

Обычное изменение

Несрочное изменение, для которого не предусмотрен утвержденный процесс.

Расписание дежурства

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

Центр управления операциями

Фактическое место, в котором осуществляется мониторинг ИТ-услуг.

Ведущий специалист по операциям

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

Конечный результат

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

Анализ «потери/выгода»

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

Пассивный мониторинг

Отслеживание работоспособности сервиса в автоматическом режиме (в отличие от активного или ручного мониторинга).

Период работоспособности

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

Снижение производительности

Показатель того, насколько снизилась производительность системы из-за события или инцидента.

Плановые простои

Период времени, в течение которого доступ к ИТ-службе намеренно прекращен в целях технического обслуживания или обновления.

Сборник сценариев

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

Разбор инцидента/анализ по итогам реагирования на инцидент/анализ результатов реагирования на инцидент

Анализ инцидента после его разрешения. Разбор проводится с целью улучшить процессы реагирования, предотвратить будущие инциденты и понять причину последнего инцидента.

Priority

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

Запись о проблеме

Запись о проблеме — это документ, в котором описаны все аспекты проблемы, от выявления до устранения.

Ожидаемый перебой в обслуживании

Документ, в котором описано, как будущее техническое обслуживание или тестирование повлияют на согласованные уровни обслуживания.

Контроль качества

Процесс тестирования, обеспечивающий соответствие стандартам во всем, что связано с ИТ, от новых функций до практических руководств.

Система управления качеством

Существующая платформа или системы, предназначенные для контроля качества.

Реактивный мониторинг

Мониторинг, который осуществляется в ответ на событие или инцидент.

Восстановление

Процесс восстановления базовой работоспособности и технического состояния сервиса.

Целевая точка восстановления

Максимальный объем данных, которые могут быть потеряны во время восстановления.

Целевой срок восстановления

Максимальная продолжительность перерыва в обслуживании.

Выпускайте релизы

Изменение, развернутое для пользователей.

управление релизами

Планирование, проектирование, тестирование, определение сроков, устранение неполадок и развертывание изменений.

Отказоустойчивость

Способность системы продолжать работать при отказе и быстро восстанавливаться в случае инцидента.

Время реакции

Время с момента создания оповещения до принятия первых мер командой.

Оценка рисков

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

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

Работа с угрозами путем их выявления и контроля.

Основная причина

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

Перечни процедур

В перечнях процедур приведены подробные описания процедур для управления инцидентами. Ими, как правило, пользуется системный администратор или команда по управлению сетевыми операциями (NOC). Перечни процедур могут существовать в цифровом или печатном виде.

Область действия

Масштабы проблемы, решения, проекта, возможности и т. д.

Поддержка второго уровня

Люди с дополнительными возможностями (время, опыт, знания, ресурсы) для решения проблем, которые могут быть не по силам сотрудникам, первыми реагирующим на инцидент.

Изменение сервиса

Обновления, исправления, устаревание или другие изменения, внесенные в сервис.

Техподдержка:

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

Анализ отказов сервиса

Анализ отказов сервиса — это процесс изучения перебоя в обслуживании для определения его причины.

Соглашение об уровне обслуживания (SLA)

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

Диаграмма для отслеживания выполнения соглашений об уровне обслуживания (SLAM-диаграмма)

Документ, в котором содержатся данные о целевых уровнях обслуживания и отслеживается их достижение.

Целевые уровни обслуживания (SLO)

Соглашение в рамках SLA о конкретном показателе, например о времени безотказной работы.

Уровни опасности

Показатель масштаба воздействия инцидента на сервис. Как правило, команды используют систему с 3–5 уровнями опасности, в которой уровень 1 соответствует самой высокой степени опасности, а уровень 3–5 присваивают менее серьезной проблеме, которая не требует срочных мер.

Единая точка отказа

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

Спецификация

Официальный перечень требований к конфигурации, связанной с ИТ.

Инженер по техническому обеспечению надежности сайта (SRE)

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

Стандартные изменения

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

Резерв

Неактивные ресурсы, доступные для поддержки управления инцидентами.

Состояние

Текущее состояние сервиса.

Statuspage

Специальное решение для информирования о текущем состоянии сервиса, в котором регулярно обновляется статус инцидентов.

Профильный специалист

Лицо, обладающее знаниями по конкретной проблеме, сервису и т. д.

Технический стек

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

Сопряженные метрики

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

Пороговое значение

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

График

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

Анализ динамики

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

Обходной путь

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

Нагрузка

Ресурсы — как человеческие, так и машинные — необходимые для предоставления ИТ-услуг.