Что такое управление проблемами и как перестать чинить одно и то же

Зачем управление проблемами

Управление проблемами по ITIL существует ради одного: находить и устранять причины сбоев, чтобы не чинить одно и то же снова и снова. Вернуть работу, когда она встала, — задача другой практикиПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4, управления инцидентами INCУправление инцидентами. Эта берётся за вторую половину: искать, из-за чего всё вставало, и убирать это «из-за».

Пять слов, без которых дальше не обойтись

ИнцидентИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами — незапланированное прерывание услугиУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation или снижение её качества. Работу с ним меряют временем: чем быстрее вернули, тем лучше.

ПроблемаПроблемаПричина одного или нескольких инцидентов.ITIL — причина одного или нескольких инцидентов, фактических или потенциальных. Работу с ней временем не меряют: закончена не тогда, когда «быстро закрыли», а когда причину устранили.

Известная ошибкаИзвестная ошибкаПроблема с установленной причиной, для которой есть обходное решение.ITIL — проблема, у которой причина установлена или найден способ снизить её влияние. Запись о ней позволяет закрывать такие же инциденты без нового расследования.

Обходное решениеОбходное решениеСпособ снизить или устранить последствия инцидента, когда полного решения ещё нет.ITIL 4, практическое руководство по управлению инцидентами — способ уменьшить или снять влияние сбоя, пока полное устранение недоступно. «Перезапустите сервис» — обходное решение; починить то, из-за чего он падает, — устранение.

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

Как это выглядит в жизни. Условный пример: в компании-разработчике 60 человек, её продукт — мобильное приложение и личный кабинет сети фитнес-клубов, где записываются на тренировки, платят за абонементы и получают уведомления.

У приложения есть дурная привычка. Пятого числа каждого месяца, в день списаний, оплата абонементов ложится: у одних посетителей не проходит продление, у других приложение отвечает «платёж не прошёл». Катя из поддержки принимает десяток обращений, поднимает Андрея, тот перезапускает платёжный сервис — к вечеру всё работает, инциденты закрыты.

Следующее пятое число повторяется до мелочей. И следующее. Каждый раз это «новый» сбой: берёт его тот, кто дежурит, закрывает перезапуском, а причину не ищет никто. За полгода — шесть волн одинаковых обращений и ни одной записи о причине.

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

Марина завела запись проблемы и связала с ней все шесть волн. Андрей нашёл причину за два дня, и она оказалась скучной: в день списаний задания на продление копятся в очереди быстрее, чем сервис успевает их разбирать, а в обычные дни очередь рассасывается сама. Устранение прошло обычным изменением в релизе, а в базу легла запись известной ошибки: по каким признакам узнать сбой и что делать первой линииПервая линияСпециалисты, принимающие обращения и решающие типовое по базе знаний.Разбор практики управления инцидентами на портале, пока исправления нет.

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

Цель практики ITIL формулирует так: сократить вероятность и влияние инцидентов, выявляя их фактические и потенциальные причины и управляя обходными решениями и известными ошибками 1. ГОСТ Р ИСО/МЭК 20000-1 — российский стандарт управления услугами — требует того же, но обязанностью: организация должна выявлять причины инцидентов, определять действия по их устранению и вести известные ошибки 4. COBIT 2019 говорит то же третьими словами: выявлять и классифицировать проблемы и их корневые причины, устранять в срок, чтобы инциденты не повторялись, и давать рекомендации по улучшению 5.

Практика управления проблемами всегда реактивна к самим проблемам: она не мешает им случиться в первый раз. Проактивность и реактивность описывают другое — как расследование относится к инцидентам: проактивное предотвращает первые инциденты, реактивное — повторные 1.

Главная трудность. Инцидент всегда срочнее проблемы: он горит сейчас, а расследование можно отложить на «потом» — и «потом» не наступает никогда. Отсюда два следствия, которые стоит принять до внедрения. Первое: проблемы временем не меряются. Расследование может занять месяц, и это не провал, если причину нашли; поставленный на него срок из соглашения об уровне услугСоглашение об уровне услугЗаписанная договорённость поставщика и заказчика: что услуга должна уметь, насколько надёжно работать и как это проверить.ITIL 4: практическое руководство Service Level Management и книга ITIL Foundation, 5.2.15.1; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.16, 3.2.20, 3.2.21, 7.5.4, 8.3.2–8.3.4; FitSM-0, FitSM-1 (PR2), FitSM-2 (PR2), шаблон и образец SLA из FitSM-4; MOF 4.0, глоссарий; itSMF, «Введение в ИТ Сервис-менеджмент», 2003; Ami Nahari, «Secrets of Service Level Management», TSO, 2013; Молоткова, Сахаров, «Качество услуг ИТ-аутсорсинга», 2008; «Аутсорсинг в стратегии современного бизнеса», 2019; альманах itSMF России, 2015; «Свободный ITIL» Елхимова; Брукс, «Метрики для управления ИТ-услугами» превращает расследование в формальность. Второе: практика не окупается быстро. Первые месяцы видны только затраты — люди разбираются вместо того, чтобы закрывать заявки. Отдача приходит позже и достаётся управлению инцидентами: обращений становится меньше, хвалят поддержку. Практика, у которой нет отдельного владельца и отдельной меры, в этот момент умирает тихо.

Когда практика работает

Три вопроса, ответы на которые видны по работе, а не по регламенту. К ним стоит возвращаться по ходу чтения: почти каждый следующий раздел объясняет, как добиться одного из них.

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

У первой линии есть чем закрыть инцидент, пока причина не устранена. Как проверить: обходное решение записано и доступно тому, кто принимает обращение, а не лежит в переписке. Обход «перезапустить сервис» полгода знали трое — это личное знание троих, а не результат практики.

Причины ищут не только после аварий. Как проверить: часть проблем заведена по итогам анализа накопленных данных, а не по факту громкого сбоя. Если все записи в журнале появились после крупных инцидентов, практика реактивна целиком, и потолок её — не допустить повторения того, что уже случилось.

Развёрнутая шкала — ниже, в разделе про зрелость.

Что входит и что рядом

Половина споров про управление проблемами — спор о границе с управлением инцидентами. Ниже она проведена явно, со ссылкой, куда идти за тем, что осталось снаружи 1 2.

Граница с инцидентами — не табличная формальность, и всем парам, которые путают с проблемой, ниже посвящён отдельный раздел. Здесь стоит удержать другое: инцидентное и проблемное управление работают в одном потоке и делят те же или пересекающиеся ресурсы, вплоть до людей и инструментов 1. Проводить границу надо не между отделами, а между задачами: «вернуть работу» и «убрать причину».

Что на входе и что на выходе

Предыдущий раздел отвечает на вопрос, где у практики граница. Этот — на другой: откуда в неё приходит работа и куда уходит результат.

Разница не словесная. Управление конфигурациями лежит рядом с проблемами — соседняя практика, только и всего. Но оно их ещё и питает: без состава услуги и связей между элементами причину ищут наугад. Соседство и питание — отношения разные. Соседа достаточно не трогать; без того, кто даёт данные, практику не запустить вовсе.

Списки ниже собраны по таблицам входов и выходов практического руководства 1. Каждая строка — не наше рассуждение, а то, что названо ключевым входом или выходом одного из четырёх процессов практики.

Что из этого следует. Управление проблемами не запускается изолированно, и видно это не из общих слов, а из списка: без записей об инцидентах нечего анализировать, без состава услуги некуда смотреть, без управления изменениями некому устранять найденную причину. Организация, у которой работает половина этого списка, получит журнал проблем, но не практику.

Обратное тоже верно и утешительнее: каждая связь — это то, чего у соседей уже можно попросить. Данные наблюдения, соглашения об уровне услуг и база знаний обычно есть задолго до того, как кто-то заводит управление проблемами.

Как это работает

Практика раскладывается на семь шагов. Порядок обязателен: каждый следующий имеет смысл только после предыдущего.

Цвет шага: приём, учёт, работа с обращением техническая работа проверка, разбор, улучшение

Для повторяющихся типов проблем ITIL советует заводить модель проблемы — повторяемый способ ведения проблем одного типа 1. У компании из примера моделью становится сама запись «пятое число»: признаки, обход и план устранения уже описаны, и следующая такая проблема начнётся не с нуля.

Четыре места в этой цепочке стоит объяснить отдельно, потому что именно на них практика ломается чаще всего.

Обходное решение появляется раньше устранения, и это норма. Найденное обходное решение не закрывает проблему — запись остаётся открытой, а сам обход записывается в неё 2. Организация, где обход считается закрытием, получает предсказуемый результат: журнал проблем пуст, а инциденты повторяются с прежней частотой. Оговорка ITIL заслуживает отдельной строки: обходное решение, найденное при разборе проблемы, обычно не снижает вероятности инцидентов — оно помогает закрывать их быстрее и лучше, когда они случились 1. Предотвращающие обходные решения чаще находятся позже, на этапе контроля известных ошибок 1.

Устранение идёт только через изменение. Правка в рабочей среде, сделанная расследующим инженером «пока помню», — это неучтённое изменение со всеми его последствиями. ГОСТ ставит это требованием: решение проводят через принятый порядок управления изменениями 4. Практика CHNКонтроль изменений здесь не бюрократическое препятствие, а единственный способ не породить новый инцидент устранением старого.

Расследование не обязано находить одного виновника. В сложных системах у инцидента часто нет единственной причины: отказ рождается из маловероятных сочетаний маловероятных факторов, и останавливаться на первом найденном звене нельзя 1. Как именно ищут причину — пятью «почему», деревом отказов, по журналу изменений — разобрано отдельно, в статье про анализ корневых причин.

Закрытие проверяется, а не объявляется. Условия закрытия сформулированы жёстко: риск инцидентов, связанных с проблемой, снят или снижен до приемлемого уровня — либо проблема больше не влияет на организацию 1. При закрытии сверяют, что запись содержит полную историю событийСобытиеИзменение состояния, замеченное мониторингом.ITIL 4, и обновляют состояние известной ошибки 2. Если инциденты пошли снова, правило такое: при тех же условиях запись открывается заново, при других — заводится новая 2. Закрытые записи остаются в базе знаний: похожие проблемы имеют свойство возвращаться 1.

Жизненный цикл проблемы: состояния и переходы

Схема выше показывает работу — кто что делает и в каком порядке. Здесь показано другое: в каких состояниях бывает сама запись и что переводит её из одного в другое. Это разные вопросы, поэтому и рисуются они по-разному.

Проблема и что с ней путают

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

Проблема и инцидент. Инцидент — незапланированное прерывание услуги или снижение её качества. Проблема — причина или потенциальная причина одного или нескольких инцидентов 1; в ГОСТе теми же словами: причина одного или нескольких фактических или потенциальных инцидентов 4. Практический признак простой. Можете назвать причину — у вас уже не проблема, а известная ошибка. Восстанавливаете работу — вы в инциденте.

Проблема и известная ошибка. Это не два разных объекта, а два состояния одного. Известная ошибка — по ГОСТу проблема, коренная причина которой определена или у которой идентифицирован метод снижения или устранения последствий 4; ITIL 4 короче: проблема, которая разобрана, но не устранена 1. Заводить запись надо, как только понятно, в чём проявляется проблема, даже если причина ещё не найдена, — чтобы новые инциденты сразу опознавались и привязывались к записи 2. Кто ждёт установленной причины, теряет главную пользу реестра; кто заводит известную ошибку отдельным списком, получает два расходящихся реестра и ни одного полного.

Проблема и дефект. Не всякая причина инцидента — проблема в смысле этой практики. Рабочий регламент финансового ведомства штата Оклахома проводит границу так: дефект — это когда система работает ровно так, как её спроектировали, а спроектировали неудачно 2. Чинить нечего: сломанного нет, менять надо конструкцию. Разница видна по вопросу «что мы вернём»: в проблеме возвращают то, что раньше работало; в доработке делают то, чего не было. Доработка идёт запросом на изменение, а не записью проблемы.

Проблема и риск. Риск — то, что может случиться. Проблема — то, что уже проявилось инцидентами. Практика RSKУправление рисками работает с первым, эта — со вторым. Смешение даёт журнал проблем, наполовину состоящий из опасений.

Классификация и приоритет

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

Приоритет складывается из двух осей и одной поправки.

Влияние — сколько людей и функций затронуто. Шкала из трёх ступеней 2. Низкое — один-два человека: услуга деградировала, но держится в пределах соглашения. Среднее — несколько человек на одной площадке: услуга вышла за пределы соглашения. Высокое — все пользователи услуги: затронуто несколько подразделений либо услуга недоступна снаружи.

Серьёзность — насколько человек ограничен в работе. Три ступени: низкая — не может выполнять часть обязанностей; средняя — не может выполнять критичные по времени функции; высокая — услуга или её значимая часть недоступна 2.

Поправка на частоту — то, чем приоритет проблемы отличается от приоритета инцидента: обязательно учитывается частота и суммарное влияние порождённых инцидентов 2. Проблема, дающая по одному мелкому инциденту в день, может стоить дороже той, что один раз дала крупный.

Именно поправка на частоту связывает практику с деньгами. Пример из того же регламента показывает, зачем нужны обе шкалы: сбой у одного человека, который считает зарплату, останавливает одного пользователя — а без ведомости остаются все, кому она нужна 2.

Сама по себе оценка влияния и срочности — ещё не приоритет. ITIL проводит здесь полезную границу: расстановка приоритетов нужна только при конфликте ресурсов, а проблемы планируются в одном бэклоге вместе с остальными задачами 1. В компании из примера бэклог один: «починить пятое число» встаёт в него рядом с задачами от заказчика и соревнуется за Андрея, а не живёт в отдельном журнале, который никто не открывает.

Реактивная и проактивная работа

Практика делится на две половины, и в большинстве организаций живёт только первая. Реактивная предотвращает повторные инциденты, проактивная — первые 1.

Реактивная начинается после того, как инциденты случились. Поводов завести запись несколько: много похожих инцидентов; большой процент инцидентов, решённых дольше целевого времени; крупный инцидент; доступность услуги ниже цели 1. И заводит её тот, кто заметил первым: поддержка заподозрила неустановленную причину, техническая группа при разборе обнаружила за инцидентом проблему, наблюдение выявило неисправность, которая ещё не дала сбоя 2.

Проактивная начинается с анализа накопленных данных ради поиска причин, которые ещё не проявились 1 2. Это работа с данными, а не с обращениями, и в этом её организационная сложность: у неё нет входящего события, которое заставит кого-то ею заняться. Реактивную работу приносит служба поддержки; проактивную не приносит никто.

Отсюда практический вывод, стоящий дороже любого регламента: проактивная работа существует только тогда, когда для неё выделено время в расписании и назван ответственный. Попытки завести её как «делайте, когда будет свободная минута» кончаются одинаково: свободной минуты не бывает. Простейший способ начать — раз в месяц задать накопленному один вопрос: какие обращения повторялись чаще всего и что их объединяет. Инструмента и бюджета для этого не нужно; Катина таблица из истории — ровно эта работа, сделанная руками. Первые записи проактивных проблем появляются уже через месяц.

Известные ошибки и обходные решения

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

Что в нём лежит. Запись содержит признаки, по которым ошибку узнают, перечень инцидентов, которые она порождает, и ссылку на обходное решение, если оно найдено 2. Признаки важнее причины: первая линия ищет по симптому, а не по корневой причине.

Когда заводится. Как только диагностика продвинулась достаточно, чтобы понимать, в чём дело, — даже если причина ещё не установлена 2. Ждать полной ясности значит терять недели, в течение которых те же инциденты разбираются с нуля каждым, кто их получил.

Чем отличается от базы знаний. Реестр известных ошибок отвечает на вопрос «это уже известно, и вот что делать сейчас», база знаний KNWУправление знаниями — на вопрос «как вообще выполняется эта работа». Держать их в одном инструменте нормально; смысл записей разный: известная ошибка живёт до устранения причины, знание живёт постоянно.

Что портит реестр. Чаще всего — записи без признаков: причина описана, а узнать её по симптому нельзя. Следом — обходные решения, устаревшие после устранения причины и никем не удалённые: первая линия применяет их к новым инцидентам и делает хуже. Реже, но тяжелее всего — доступ: реестр, лежащий в инструменте расследующей группы, до первой линии не доходит и пользы не приносит.

Три исхода у разобранной проблемы

Установить причину — не значит закрыть запись. ITIL допускает три подхода к ослаблению проблемы, и они различаются тем, что происходит с записью 1.

Полное устранение. Ошибку чинят как следует. Запись закрывается; путь рекомендован для всего, что под полным контролем организации, и особенно для собственного ПО.

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

Решения для инцидентов. Причину не устраняют вовсе: дорогой фикс мелкой проблемы не окупается. Запись остаётся открытой, а известная ошибка пересматривается периодически — инциденты повторяются, но закрываются быстро.

Что из этого следует. Второй и третий путь — это признанный технический долг: полный список переделок, накопленных из-за выбора обходных решений вместо системных, которые заняли бы дольше 1. Известные ошибки — часть этого долга, и убирать их положено, где это разумно практически 1. Реестр, который ведут честно, показывает организации цену каждого «потом починим».

Кто участвует

Иерархия ролей по ITIL скромнее, чем кажется. Отдельный менеджер проблем встречается в организациях со сложной бюрократией и большим числом проблем; часть рутиныРутинаРучная повторяющаяся работа без долговременной ценности, которая растёт вместе с сервисом и поддаётся автоматизации.Google. Site Reliability Engineering, глава о вытеснении рутины в них делегируют координатору проблем; для крупных проблем собирают временные команды 1. А в продуктовых компаниях отдельные роли не вводят вовсе: практика встроена в ежедневную работу команд разработки 1 — как в компании из примера.

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

А ошибка в чужом продукте для этой практики — обычное дело, и разрешимость зависит не только от инженеров: от архитектуры решения, гибкости поставщика, того, насколько важны для него отношения с вами, и от условий договора 1.

Регулярные встречи

У практики есть ритм, и своды его описывают. При внедрении он пропадает первым: регламент пишут, календарь не пишет никто.

Регулярных ритуалов три 1.

Пересмотр открытых проблем. Команда возвращается к тем, по которым решения пока нет: изменились ли обстоятельства, не появилось ли постоянное решение, не пора ли менять подход к снижению влияния. Периодичность не назначена: её задаёт подход, согласованный по каждой проблеме, или то, что показывает наблюдение.

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

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

Четвёртая встреча приходит со стороны инцидентов. Менеджер инцидентов вместе с владельцами услуг разбирает выбранные случаи — крупные, не решённые в срок или все за период 8. Для управления проблемами это главный поставщик поводов, и попасть на этот разбор важнее, чем завести свой.

Пятое — не встреча, а требование. ГОСТ обязывает в заранее назначенные сроки разбирать, результативно ли устраняются проблемы, и показывать это в отчётности 4. Интервал организация назначает сама, но наличие интервала проверяется.

В компании из примера весь ритм умещается в одну строку календаря: раз в месяц получасовой разбор открытых проблем и известных ошибок. Дешевле, чем суббота с тетрадкой.

Что должно быть в записи проблемы

Состав записи — не бюрократия, а условие того, что через полгода запись можно прочитать. Ниже перечень из процессного документа, дополненный тем, что показывает практика 2.

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

По ходу расследования. Ход диагностики записывается тогда, когда он идёт, а не восстанавливается по памяти при закрытии. Это то же требование, что и в управлении инцидентами, и нарушается оно так же часто.

Обходное решение — отдельным полем. Не в переписке, не в комментарии, а там, откуда его берёт первая линия 2.

При закрытии. Проверка, что запись содержит полную историю событий; если нет — запись дополняется, а не закрывается 2. Обновление состояния связанной известной ошибки. Закрытие связанных инцидентов, которые ещё открыты.

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

Чем автоматизируется

Инструмент здесь закрепляет тот порядок, который есть, и не создаёт того, которого нет. Проверить готовность просто: если у вас нет ответа на вопрос «кто владеет проблемой», система этого ответа не даст.

Что от инструмента действительно нужно, в порядке важности:

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

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

Доступ первой линии к обходным решениям. Поиск по признакам, а не по номеру записи.

Выгрузка для анализа. Проактивная половина практики — это работа с накопленными данными. Если данные нельзя выгрузить и посмотреть срезами, проактивной работы не будет независимо от намерений.

Чего от инструмента ждать не стоит: он не назначит владельца, не выделит время на расследование и не помешает закрыть проблему обходным решением. Все три — организационные решения, и принимаются они до покупки.

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

Как измерять

Метрика не стоит сама по себе. Сначала определим, что должно быть, чтобы практика работала, и только потом — чем это проверяется. Такие условия называют факторами успеха. У управления проблемами их два 1.

Выявлять проблемы и понимать их влияние на услуги. Организация должна знать ошибки в своих продуктах: они порождают инциденты и бьют по качеству. Проверяется тремя величинами — сколько проблем выявлено за период и с каким влиянием; сколько инцидентов пришло без связи с известной ошибкой; сколько инцидентов потребовали срочного расследования причины 1. Вторая и третья растут, когда практика опаздывает: причину начинают искать в момент аварии, а не до неё.

Оптимизировать устранение проблем и снижение их влияния. Устранить все причины не удаётся почти никогда, но выявление без устранения почти ничего не стоит. Здесь меряется обратная сторона — сколько инцидентов предотвращено устранением причины; сколько решено средствами, найденными при расследовании; сколько известных ошибок остаётся открытыми 1. Подход к снижению влияния положено взвешивать по стоимости, риску и качеству услуги: «устранять всё» правильным ответом здесь не считается.

Дальше идёт то, чего в ITIL нет, а в процессных документах есть: рабочая разбивка показателей по трём группам. Первая говорит о нагрузке, вторая о работе процесса, третья о результате. Хвалиться принято первой, а отвечать надо третьей.

Две цифры из средней группы встречаются в отчётах реже всего, а говорят больше остальных: число отклонённых решений показывает, насколько качественно расследуют, а число проблем, порождённых изменениями, — насколько честно работает CHNКонтроль изменений. Готовой формулы для третьей группы не даёт ни один источник, и это честно: результат считается по вашим данным.

Отдельная мера, которую стоит завести всем: доля инцидентов, привязанных к проблемам. Она отвечает на вопрос, ведётся ли связь вообще. Ноль означает, что практика живёт отдельно от управления инцидентами, и остальные показатели тогда не считаются.

У показателя должно быть два числа, а не одно. Целевое — куда идём, и опасное — при каком значении пора вмешиваться. Брукс задаёт обе границы у каждой своей метрики 7, и для доли непривязанных инцидентов это цель 25% при тревоге в 40%. Мера та же, что и абзацем выше, только с обратной стороны: три четверти инцидентов должны выходить на какую-то проблему. Рядом ещё три пары. Открытых проблем одновременно — 25 при тревоге в 40. Не решённых в срок — 2 при тревоге в 5. Среднее время закрытия — 3 при тревоге в 5, и единица тут намеренно не названа: часы, дни или минуты выбирает организация, а держать надо соотношение.

Числа эти к вам не переезжают. Брукс приводит их образцами для настройки под свою модель работы; переносится привычка держать у метрики обе границы, а не одну.

Среднее время закрытия умеет обманывать. Когда закрывают проблему, висевшую полгода, среднее подскакивает — и выглядит это как ухудшение ровно в тот момент, когда случилось лучшее за полгода. Брукс советует считать среднее без того, что не удавалось решить дольше месяца 7, а долгие случаи разбирать отдельно и поштучно.

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

Не всякий полезный показатель годится в сводный отчёт. Пять категорий инцидентов, по которым за период было больше всего обращений, Брукс называет информативной внутренней метрикой и прямо оговаривает: в консолидированные показатели она не идёт 7. Команде она подсказывает, куда копать дальше, а в отчёте наверх превращается в повод для выводов, которых из неё не следует: верхние категории тем и велики, что они массовые, а не потому, что там хуже всего.

У решения проблемы есть цена, и её тоже меряют. У метрики «затраты на решение проблемы» целевое значение задано не числом, а условием: решение должно окупаться; опасное — когда затраты перевалили за выгоду 7. Само же решение, тратить ли деньги на устранение причины, принимается не здесь, а в CHNКонтроль изменений: управление проблемами показывает цену вопроса, а разрешает расход другая практика.

ITIL предлагает и сводный показатель продуктивности практики, но за формулой отсылает к отдельному руководству по измерению и отчётности и сразу оговаривает: единственно верного набора показателей нет, он строится от стратегии услуг и целей организации 1. Оговорка стоит того, чтобы её повторить, — она снимает соблазн взять чужой набор целиком.

Про отчётность из процессных документов: отчёты по стадиям делаются ежемесячно с квартальными сводками, а разбор открытых проблем высшего приоритета — еженедельно 2. Ежедневная отчётность по проблемам смысла не имеет: за день в этой практике не происходит ничего, что стоило бы отдельного взгляда.

Зрелость управления проблемами

✕

Компания из примера — на нижней ступени лестницы — уровне «Повторяемый»: записи о проблемах заводятся, но только после громких сбоев, и закрывает их тот, кто дежурил. Шаг выше — уровень «Определённый»: у практики есть владелец и ритм. В примере это значит: Марина назначена владельцем, разбор открытых проблем стоит в календаре раз в месяц, а записи заводятся не только по «горящему» пятому числу.

Где ломается чаще всего

Семь мест, в которых практика разваливается. Порядок — по частоте, с которой это встречается.

Проблемы заводит и расследует тот же человек, что закрывает инциденты. Инциденты всегда срочнее. Расследование откладывается на «после», и «после» не наступает. Лечится не уговорами, а выделенным временем в расписании. В истории выше эта беда прожила полгода и была прервана таблицей Кати.

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

Связь с инцидентами не ведётся. Записи есть, привязки нет. Никакой показатель результата не считается, и через полгода практика не может показать ни одной цифры в свою пользу — со всеми последствиями при обсуждении бюджета.

Реестр известных ошибок не доходит до первой линии. Знание есть, применить его некому. Проверяется одним вопросом к оператору: где вы смотрите, известна ли уже эта ошибка.

Практика реактивна целиком. Все записи заведены после громких сбоев. Потолок такой практики — не допустить повторения того, что уже случилось; всё, что ещё не случилось, вне поля зрения.

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

Крупные проблемы не разбираются. Разбор после крупного сбоя либо не проводится, либо заканчивается протоколом. Выводы не доходят ни до изменений в системах, ни до правил наблюдения. Разбор, после которого не появилось ни одной записи в IMPПостоянное улучшение, проведён впустую.

Как менялись стандарты

Практика старше большинства сводов, и её описание заметно менялось трижды.

Вторая редакция ITIL развела управление инцидентами и управление проблемами как разные области ответственности и ввела рекомендацию о явной границе между ними: если служба поддержки не может решить инцидент, он передаётся в управление проблемами 3. Терминология того времени отличается: в процессных документах эпохи встречается «известная проблема» там, где сейчас говорят «известная ошибка», а сама практика описывается как надстройка над разбором инцидентов 3. Читая документы тех лет, эту разницу стоит держать в голове.

Третья редакция закрепила разделение реактивной и проактивной работы и вывела реестр известных ошибок в самостоятельный объект со своим жизненным циклом. Регламент финансового ведомства штата Оклахома, написанный в 2011 году, следует уже этой логике 2: там есть и деление на две половины, и отдельный реестр, и правило о владении 2.

Четвёртая редакция переписала практику как деятельность, а не как процесс с жёсткой последовательностью шагов, и сместила акцент на управление обходными решениями и известными ошибками наравне с устранением причин 1. Формулировка цели стала шире: не «устранить причины», а «сократить вероятность и влияние инцидентов».

ISO/IEC 20000-1 в редакции 2018 года (у нас — ГОСТ Р ИСО/МЭК 20000-1—2021) требований к устройству процесса не предъявляет. Он задаёт результат: причины выявляются, действия определяются, известные ошибки ведутся, решения доводятся до изменений 4. Для того, кто готовится к сертификации, это удобнее ITIL: проверяется не соответствие описанию, а наличие работающего механизма.

COBIT 2019 держит практику в цели DSS03, по-русски — управление проблемами, и раскладывает её на пять шагов: выявить и классифицировать, расследовать и установить причину, завести известные ошибки, устранить и закрыть, вести проактивную работу 5. Там же назван и результат, которого ждут: рост доступности, соблюдение уровня услуг, снижение затрат и числа операционных проблем.

Отдельно стоит посмотреть, как за те же годы менялись документы одной организации. То самое ведомство штата, чей процессный регламент 2011 года описан выше, сегодня называется иначе и держит по этой практике собственный стандарт на две страницы 6. Устройства процесса в нём нет вовсе. Есть определения, требование вести записи о проблемах в системе и единый почтовый адрес для тех, у кого доступа к системе нет. Есть обязанность документировать расследования и доводить их результаты до подведомственных организаций. И есть ссылка на статьи закона штата, которыми стандарт введён.

Движение то же, что и у ISO/IEC 20000: от описания порядка к требованию результата. Развёрнутый регламент с ролями и матрицами превратился в короткий нормативный текст, а описание того, как именно работать, ушло в систему и в рабочие инструкции. Для читателя, который собирает свои документы, это подсказка о том, что писать в регламенте, а что оставить настройке инструмента.

Где описано

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

Что обязательно по стандарту

ITIL описывает, как эту практику обычно устраивают. ГОСТ — что в ней обязано быть. Разница практическая: по ITIL вас никто не проверит, по стандарту проверят.

Пункт 8.6.3 «Управление проблемами» короткий, и в нём нет ни одного «следует» — только «должен» 4:

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

Чего стандарт не требует — и это важнее списка. Ни ролей, ни менеджера проблем, ни линий поддержки, ни сроков, ни формы записи, ни отдельного инструмента. Всё перечисленное организация выбирает сама, и на аудите этого не спросят.

Одна оговорка про перевод. В пункте стоит «расширены, если необходимо»; в исходном тексте стандарта — escalated, то есть эскалированы. Формулировку ГОСТа мы приводим как есть, потому что цитируем действующий документ, но читать её надо как эскалациюЭскалацияПередача инцидента тем, у кого больше компетенции, либо уведомление руководителя об угрозе срока.Разбор практики управления инцидентами на портале.

Проекты внедрения

Каждый разобранный проект открывается своей страницей: что болело, что сделали, что получилось и отдельно — что не получилось. Остальные проекты по этой практике — в каталоге проектов.

Материалы по теме

Что почитать дальше

Начинать стоит с INCУправление инцидентами: управление проблемами без работающего управления инцидентами нечем кормить — не будет ни повторяющихся обращений, по которым видна проблема, ни данных для анализа.

Следом — CHNКонтроль изменений: устранение причины идёт только через изменение, и практика, в которой изменения не контролируются, будет порождать новые проблемы быстрее, чем закрывать старые.

Третьим — KNWУправление знаниями: реестр известных ошибок и база знаний живут рядом, и решать, что где лежит, лучше до того, как оба списка наполнятся.

Для проактивной половины пригодится REPИзмерение и отчётность: она вся построена на анализе накопленных данных, и без нормальных срезов делать её нечем.