Problem Management.
Что? Зачем? И почему?
 
Incident Management - восстанавливает сервис. 
Problem Management - убирает причину, по которой он сломался.
 
Если инцидент - это симптом, то проблема - это источник боли. 
 
Что такое проблема?
Проблема - это неизвестная корневая причина одного или нескольких инцидентов.
 
Примеры:
▪️ У 15 клиентов за день упал один и тот же сервис.
▪️ Сервер каждый понедельник в 9:00 замедляется на 30 минут.
▪️ После каждого обновления падает интеграция с биллингом.
 
Инцидент - это «не могу войти». 
Проблема - это «почему у 200 пользователей каждый четверг в 14:00 падает авторизация».
 
Что такое Problem Management?
Это процесс поиска и устранения корневых причин инцидентов.
 
Не чтобы закрыть тикет.  А чтобы больше не открывать такие тикеты.
Цель - не реагировать. Цель - предотвратить.
 
Основные цели Problem Management
 
1️⃣ Найти корневую причину 
   Не «починили» - а поняли, почему сломалось.
 
2️⃣ Предотвратить повторение
   Устранить не симптом, а источник. 
   Чтобы инцидент больше не возникал.
 
3️⃣ Создать долгосрочное решение
   Не временный обходной путь, а постоянное исправление - в коде, в архитектуре, в процессе.
 
5️⃣ Связать инциденты в паттерны*
   Увидеть, что 10 разных инцидентов — на самом деле одна проблема.
 
5️⃣ Передать знания команде
   Зафиксировать решение в базе знаний. 
   Чтобы следующий инженер не изобретал велосипед.
 
Когда запускается Problem Management?
Проблема может начаться:
▪️ после серии повторяющихся инцидентов,
▪️ после Major Incident (там всегда есть корень),
▪️ по инициативе инженера: «Я вижу закономерность»,
▪️ из аналитики: «Сервис падает каждый раз после бэкапа».
 
Главное - не ждать. Если инцидент повторяется - пора искать проблему.
 
Как работает процесс?
 
1️⃣ Выявление проблемы
  ▪️ Анализ инцидентов. 
  ▪️ Выявление паттернов. 
  ▪️ Сигнал: «Никогда такого не было. И вот опять».
 
2️⃣ Корневой анализ (RCA)
   ▪️ Не «что упало», а «почему упало». 
   ▪️ Методы: 5 Why, Fishbone, Timeline Analysis. 
   ▪️ Важно: искать системную причину, а не виноватого.
 
3️⃣ Поиск постоянного решения
   ▪️ Это не обходное решение. 
   ▪️ Это изменение: в коде, архитектуре, процессе, документации.
 
5️⃣ Реализация через Change Management 
   ▪️ Никаких «сделал и забыл». 
   ▪️ Решение внедряется официально, с тестированием и апрувами.
 
5️⃣ Закрытие и артефакт 
   ▪️ Клиент доволен? 
   ▪️ Инциденты прекратились? 
   ▪️ Значит, проблема решена. 
   ▪️ И артефакт (документ, статья, чек-лист) — сохранён для команды.
 
Кто участвует?
 
▪️ Problem Manager - не техник, а аналитик. 
  Он видит систему, а не только симптомы.
▪️ L2/L3, SRE, DevOps, разработка - те, кто может глубоко копать.
▪️ Incident Manager - передаёт контекст: что, где, сколько раз.
▪️ Knowledge Manager - фиксирует решение, чтобы оно не потерялось.
 
 Зачем это измерять?
Потому что:
▪️ Сколько проблем выявлено и закрыто? 
  Если ноль — значит, вы не смотрите.
▪️ Среднее время на решение проблемы
  Не торопитесь. Главное — качество анализа.
▪️ Снижение количества инцидентов после решения
  Это и есть доказательство эффективности.
▪️ Доля инцидентов, связанных с известными проблемами 
  Если высокая - у вас есть «дыра», которую давно пора закрыть.
 
Типичные ошибки
▪️ Не начинают вовремя
  Ждут, пока станет «очень плохо».
 ▪️ Смешивают с Incident Management. 
  Инженер пытается «починить и разобраться» одновременно. 
  Не получается.
 ▪️ Не фиксируют артефакты. 
  Решение «в голове» - это не решение. 
  Это риск.
 ▪️ Не передают в Change Management. 
  «Поправили вручную» - и снова ждут, пока упадёт.
 
Итог
Incident Management - это пожарная команда 
Problem Management - это инженер, который проверяет проводку.
Хороший процесс - это когда пожаров становится всё меньше.

#ProblemManagement #ITIL #TechSupport