- Incident Management — «тушит пожар». Восстанавливает сервис как можно быстрее. Работает с симптомом. - Problem Management — «ищет причину пожара». Делает так, чтобы он не повторился. Работает с корневой причиной. - Risk Management — «предотвращает пожар до того, как он начался». Оценивает вероятность и последствия. Работает с будущим. Одно — про «сейчас». Другое — про «почему». Третье — про «что, если». В чём разница — на примере. Ситуация: у пользователей по адресу Х не грузятся PDF. Incident Management: — зарегистрировали — приоритизировали — восстановили работу (перезагрузили сервер) — закрыли инцидент — сервис работает Problem Management: — заметили: «это пятый инцидент за месяц по тому же адресу» — провели RCA — нашли корневую причину: «потеря пакетов на конкретном узле» — заменили кабель — проблема устранена навсегда Risk Management: — задали вопрос: «А где ещё такие узлы? Где старые кабели? Где риск потери пакетов?» — оценили вероятность и последствия — разработали мероприятия: «заменить кабели во всех узлах с риском», «обучить администраторов» — предотвратили десятки будущих инцидентов Incident — устранил один симптом. Problem — устранил одну проблему. Risk — предотвратил десятки проблем. А теперь — главное. Эти три направления работают эффективно только в связке. И только если их ведёт один центр ответ-ти. Почему — один? Первое. Он видит весь цикл. Риск → инцидент → проблема → устранение → новый риск. Если эти этапы разбросаны по разным людям — никто не видит целого. Каждый закрывает свой участок. А — система — накапливает проблемы. Второе. Он видит паттерны. Один и тот же инцидент — симптом. Пять таких инцидентов — паттерн. Пять паттернов — системный риск. Если инциденты — в одном отделе, проблемы — в другом, риски — в третьем — паттерн не увидит никто. Третье. Он имеет базу первоисточников. База знаний, реестр инцидентов, реестр проблем, реестр рисков, данные мониторинга, заявки пользователей, данные о сбоях, данные о нагрузках, данные о состоянии физических сетей на местах. Без этой базы — анализ невозможен. А анализ — основа всех трёх практик. Четвёртое. Разорванные — они не работают. · Без Incident — бизнес лежит, пока ищут причину. · Без Problem — одни и те же инциденты повторяются годами. · Без Risk — каждая проблема — «неожиданность», хотя её можно было предвидеть. Только вместе — они дают устойчивую систему. Где это должно быть: не только в техподдержке. Первое. Эксплуатация информационных систем. Это — классика. Инциденты, проблемы, риски. Без связки — система деградирует. Второе. Клиентский сервис. Обращения клиентов — инциденты. Повторные обращения — проблема. Потеря клиентов — риск. Если клиентский сервис не видит всей цепочки — он «отвечает», не «решает». Третье. Процессы. Любой процесс — можно смотреть через эти три призмы. Сбой — инцидент. Повторяющийся сбой — проблема. Сценарии сбоя — риск. Без связки — процесс «работает», пока не сломается. Четвёртое. Проекты. Проектные команды часто не видят рисков — потому что не смотрят в будущее. А проблемы — повторяются из проекта в проект. Пятое. Управление изменениями. Каждое изменение — риск. Каждый сбой — инцидент. Каждый повтор — проблема. Связка — обязательна. Шестое. Безопасность. Уязвимость — риск. Атака — инцидент. Повторная атака — проблема. Без связки — безопасность не работает. Седьмое. Финансы и операции. Финансовый сбой — инцидент. Повторяющийся сбой — проблема. Сценарии — риск. Связка — основа устойчивости. Что это даёт. Первое. Система — не «тушит пожары», а — «предотвращает их». Второе. Решения — не «на уровне симптома», а — «на уровне корня». Третье. Риски — под контролем. Не «неожиданность». Четвёртое. Ресурсы — не «распыляются». А — «концентрируются на главном». Пятое. Устойчивость. Система — работает. Всегда. Итог. Incident Management — «сейчас». Problem Management — «почему». Risk Management — «что, если». Три практики. Один цикл. Одна база. Один центр. Разорванные — не работают. Соединённые — создают устойчивую систему. И это — не про техподдержку. Это — про любое управление. #управление #ITIL #RCA #риски #экспертизаборисовской