CAB (Change Advisory Board) - это комитет по изменениям, ответственный за информирование и governance в части проведения масштабных, сложных и многосвязных изменений в гетерогенной, территориально распределенной инфраструктуре. Основная функция CAB заключается в управлении и надзоре над выполнением изменений и проектов там, где в регулярных работах участвуют множество подрядчиков и развит аутсорсинг. В компаниях с использованием ресурсов различных юридических лиц, например, в рамках холдингов, CAB помогает обеспечить стабильность в сложном окружении через планирование, контроль и оценку изменений.

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

CMDB (Configuration Management Database) - это база данных управления конфигурациями, предназначенная для структурированного хранения информации об ИТ-инфраструктуре компании. В ней собирается информация о взаимосвязанных компонентах ИТ-инфраструктуры, их настройках и связях между ними. Поскольку запомнить всю эту информацию невозможно из-за ее объема и сложности, организации используют CMDB для управляемого и структурированного хранения конфигурационных данных, что позволяет эффективно управлять ИТ-услугами.

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

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

Этапы расширенного жизненного цикла инцидента включают: 1) момент возникновения инцидента — момент, когда пользователь ощутил снижение качества сервиса; 2) обнаружение — промежуток времени от возникновения до информирования поставщика ИТ-услуг; 3) диагностика — поиск причины инцидента; 4) исправление — проведение работ по устранению сбоя или замене компонента; 5) восстановление — завершение ремонтных работ в инфраструктуре; 6) возобновление — период от окончания восстановления до полного возврата пользователя к нормальной работе. Каждый из этапов имеет определённую продолжительность, и анализ затраченного времени на них позволяет оптимизировать процессы управления доступностью ИТ-услуг.

Конфигурационная единица (Configuration Item, CI) – это любой компонент или элемент, который необходимо управлять для обеспечения успешного предоставления ИТ-услуг. CI может представлять собой аппаратное обеспечение, программное обеспечение, документацию, сетевые устройства или даже персонал и места расположения. Каждая конфигурационная единица имеет свой набор атрибутов, необходимых для идентификации и управления, а также может быть связана с другими CI через определённые отношения. Правильная идентификация и управление конфигурационными единицами является основой эффективного управления конфигурациями и позволяет отслеживать их состояние, изменения и влияние на ИТ-услуги.

Availability (Availability) представляет собой показатель, определяющий, насколько система, компонент или услуга могут быть использованы в заданное время. В технической надежности, согласно ГОСТ 27.002-89 (ГОСТ Р 53480-2009), этот термин переводится как «готовность». В ITIL и ISO/IEC 20000 он трактуется как «доступность». Разница кроется в контексте применения: «готовность» акцентирует внимание на технической способности системы функционировать, тогда как «доступность» в ИТ-управлении связана с предоставлением услуги пользователю. Термины отражают разные аспекты одной метрики и требуют уточнения в документах для избежания неоднозначности.

Инцидент — это незапланированное прерывание или снижение качества услуги. В ITIL 4 определение звучит как «ан unplanned interruption to a service or reduction in the quality of a service». При этом важно отметить, что практика управления инцидентами не ограничивается только тем качеством услуги, которое воспринимают пользователи. Она также включает в себя восстановление нормальной работы услуг и ресурсов, даже когда их сбой или отклонение не видны потребителям услуг. Нормальная работа может быть определена в технических спецификациях услуг или конфигурационных единиц.

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