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

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

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

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

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

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

Подход к установлению сроков в управлении проблемами принципиально отличается от сроков в управлении инцидентами тем, что в управлении инцидентами используются строгие «инцидентские» временные нормативы, часто измеряемые часами или днями, поскольку цель инцидента - быстрое восстановление сервиса. В управлении проблемами сроки диагностики уже измеряются неделями (например, 1-2 недели в зависимости от уровня влияния), поскольку задача заключается в глубоком анализе и нахождении корневой причины, а не в быстром восстановлении работоспособности. При этом полная обработка проблемы (включая внедрение решения) не нормируется едиными сроками, так как зависит от множества факторов, включая сложность изменений и периодичность проявления проблемы.

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

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

Существуют четкие аналогии между управлением значительными инцидентами в ИТ и в службах экстренного реагирования, что подтверждается тем, что многие принципы ITIL заимствованы из практики экстренных служб. Как в лондонской системе экстренного реагирования (London Emergency Services Liason Panel), так и в ИТ, значительный инцидент определяется как ситуация, требующая специальных мероприятий с участием множества служб, затрагивающая большое число людей. В обоих случаях требуется: объявление инцидента значительным любым компетентным сотрудником, немедленное информирование руководства, назначение ответственного лица, мобилизация дополнительных ресурсов, обработка большого объема обращений и проведение анализа после разрешения кризиса. Эти аналогии подчеркивают универсальность принципов управления кризисными ситуациями независимо от отрасли.