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

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

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

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

Принцип "Упрощайте" (Keep it simple), описанный в ITIL Practitioner Guidance 2016 года, был расширен в ITIL 4 до формулировки "Простота и практичность" (Keep it simple and practical). Это изменение отражает важность не только простоты решения, но и его практической применимости. В ITIL 4 подчеркивается, что слишком сложные решения затрудняют внедрение и эксплуатацию, однако простота ради простоты тоже не имеет смысла, если решение не решает поставленные задачи. Таким образом, акцент смещен с простого упрощения на поиск оптимального баланса между простотой и практической пользой.

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

В тексте приведен пример с копанием канавы: владелец процесса определяет задачу ('Надо выкопать канаву вооон от того забора до завтрашнего обеда'), а менеджер процесса отвечает за её выполнение — покупает лопаты, следит за работой копателей и контролирует сроки. Этот пример помогает понять разницу между стратегическим управлением (владелец) и оперативным выполнением (менеджер).

Матрично-иерархическая структура в классификаторе изменений применяется следующим образом: Сначала устанавливается иерархия категорий изменений: - На верхнем уровне разделяются стандартные и нестандартные изменения - Далее по критериям риска, типа объекта (ИТ-инфраструктура, информационные системы, сети) - Иерархия продолжается до уровня конкретных типов или групп систем Затем формируется матрица параметров для каждой категории: - Для каждой группы систем или направлений определяются свои наборы параметров - Параметры включают: ответственных за координацию, уполномоченных на согласование, обязательные результаты этапов - Набор опциональных этапов для конкретной группы систем Особенность применения такой структуры: - Для ИТ-инфраструктуры может быть определен общий типовой порядок с опциональными этапами для работ в боевой среде - Для информационных систем — мастер-порядок с обязательным приёмочным тестированием - Для разных групп информационных систем (например, критически важных) — дополнительные этапы оценки влияния Как пример конкретной реализации: - Категория «Стандартные изменения для серверной инфраструктуры»: * Общие этапы: запрос, техническое согласование, выполнение, подтверждение * Параметры: ответственный координатор — администратор соответствующего направления, срок выполнения — не более 2 часов * Специфика: не требуется приёмочное тестирование, так как работы выполняются в режиме реального времени - Категория «Изменения для критически важных информационных систем»: * Общие этапы: запрос, анализ влияния, утверждение комитета, планирование, тестирование, выполнение, подтверждение * Параметры: ответственный координатор — старший сотрудник, срок планирования — минимум 5 рабочих дней * Специфика: обязательное приёмочное тестирование в выделенной среде Этот подход позволяет значительно сократить количество уникальных моделей, оставаясь при этом достаточно гибким для учета специфики различных систем и направлений.

После устранения major-инцидента необходимо: оперативно оповестить ИТ-специалистов, чтобы они могли завершить обработку всех связанных обращений и проверить восстановление ИТ-услуг; уведомить конечных пользователей о восстановлении сервисов; провести мини-расследование (major incident review) с формированием отчета, направленного на предотвращение повторения инцидента; оценить действия по обработке инцидента и при необходимости зарегистрировать проблему, известную ошибку или новые мероприятия по улучшению ИТ-услуг (например, в рамках service improvement plan или реестра CSI).

Метрика First Time Resolution (FTR) в разрезе рабочих групп рассчитывается по формуле: FTR = (Nj - Sj) / Nj. Здесь Nj — количество обращений (инцидентов), обработанных j-той группой и закрытых без рекламаций (Cj), плюс количество возвратов на доработку в эту группу (Sj). Sj — это количество объектов, возвращенных на доработку в j-тую группу. Расчёт производится за период, когда завершена процедура проверки решения инцидента, а не фактическое решение задачи. Важно учитывать возвраты индивидуально по каждой группе, так как одно обращение может быть переназначено в другую группу или возвращено несколько раз в разные группы.