Практики · Влияние на бизнес

Практики эксплуатации, которые видит бизнес: во что вкладываться в первую очередь

·12 минут чтения

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

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

  1. Четыре цели, ради которых платят за эксплуатацию
  2. Рейтинг практик по отдаче
  3. Почему первые три именно такие
  4. Что на самом деле оценивает клиент
  5. Порядок внедрения
  6. Чем измерять эффект
  7. Пять ловушек

1. Четыре цели, ради которых платят за эксплуатацию

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

Сохранить выручку, которая уже есть

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

Выглядеть надёжным для клиента

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

Получить допуск к рынку

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

Освободить время команды

Бизнес замечает эту цель последней, но от неё зависит, есть ли у компании силы на развитие. Команда, которая всё время тушит пожары, проекты делать не успевает.

2. Рейтинг практик по отдаче

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

№ПрактикаЧто даёт бизнесуЧто видит клиентС чего начать
1 Управление инцидентамиIncident Management Сокращает время простоя. Убирает паузы, которые часто длиннее самой починки: поиск ответственного, ожидание доступа, согласование решения Сбой заканчивается быстро; клиент получает понятный статус, а не тишину Разобрать пять самых долгих инцидентов по этапам: обнаружение, назначение, починка
2 Управление проблемамиProblem Management Сокращает число сбоев. По ITIL это практика, которая ищет и устраняет причины повторяющихся сбоев, а не отдельные случаи «У вас перестало ломаться одно и то же» - самый сильный сигнал доверия Завести карточку проблемы на три самых частых повторяющихся сбоя, с владельцем и сроком
3 Мониторинг и управление событиямиMonitoring and Event Management О сбое узнаёт система, а не клиент. Меняет саму точку, с которой начинается отсчёт простоя Компания сообщает о сбое первой. Это заметнее, чем разница в полчаса на восстановлении Посчитать долю инцидентов, о которых узнали от клиентов, и закрыть мониторингом самые частые
4 Управление изменениямиChange Enablement Закрывает крупнейший управляемый источник аварий: по данным Google, около 70% сбоев вызваны изменениями в работающей системе Обновления перестают быть лотереей; работы проходят в объявленное окно Ввести период наблюдения после обновлений и заранее записанное условие отката
5 Управление уровнем услугService Level Management Превращает работу службы в обещание, которое можно проверить. Без него разговор о качестве остаётся спором мнений Понятно, что обещано и выполняется ли; отчёт можно показать своему руководству Описать 3-5 ключевых услуг словами бизнеса и договориться по каждой о целевом уровне
6 Управление знаниями и база известных ошибокKnowledge Management; база известных ошибок - часть управления проблемами Снимает зависимость от «незаменимых» людей: известный сбой чинится по инструкции, а не по памяти одного инженера Скорость ответа не зависит от того, кто сегодня на смене Описать десять самых частых сбоев: признаки, обходное решение, статус постоянного
7 Управление мощностями и производительностьюCapacity and Performance Management Переводит часть аварий в плановые работы: место, память и пропускная способность заканчиваются предсказуемо Сервис не «тормозит в конце месяца»; пиковые периоды проходят ровно Взять три ресурса, которые растут к пределу, и посчитать дату, когда он наступит
8 Управление непрерывностью услугService Continuity Management Работает с редкими событиями, но именно они определяют худший сценарий года: потеря площадки, катастрофа Виден только в момент крупной аварии - зато тогда виден целиком Провести одно учение: восстановить ключевую базу из резервной копии и записать фактическое время
9 Управление поставщикамиSupplier Management Заметная часть простоя приходит извне: каналы, облака, платёжные шлюзы. Управлять этим можно только договором и процедурой Клиенту всё равно, чей это отказ. Он оценивает, как вы с ним справляетесь Собрать по каждому поставщику контакт, сроки и порядок эскалации - одна страница для дежурного
10 Управление конфигурациями и ИТ-активамиService Configuration Management, IT Asset Management Основа для связывания событий, анализа влияния и планирования. Сам по себе бизнесу почти не виден Не виден - проявляется через скорость остальных практик Не строить полный учёт. Описать зависимости только для ключевых услуг
11 Непрерывное улучшениеContinual Improvement Удерживает достигнутое: без регулярного пересмотра результаты остальных практик постепенно размываются Стабильность на длинном горизонте, а не событие Раз в квартал: один разбор данных, три решения, проверка через квартал
12 Управление запросами на обслуживаниеService Request Management Снимает с команды рутину - доступы, пароли, типовые просьбы - и освобождает время на инженерную работу Сильнее заметно сотрудникам, чем внешним клиентам Вынести в самообслуживание три самых массовых типовых запроса

Оговорка, без которой рейтинг легко прочитать неверно: это порядок отдачи на вложенное усилие, а не важности. Нижние строки не «неважные»: без учёта конфигураций не связать события, без непрерывного улучшения верхние строки со временем откатятся назад. Речь только о том, с чего начинать, когда ресурсов не хватает. А их не хватает почти всегда.

3. Почему первые три именно такие

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

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

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

4. Что на самом деле оценивает клиент

Служба эксплуатации мерит себя доступностью и временем восстановления. Клиент мерит другим, и разница между этими списками объясняет ситуацию «показатели зелёные, а клиент недоволен». Ниже - что, по нашему опыту, клиенты называют сами, и практика, которая за это отвечает.

Что важно клиентуПочему именно этоКакая практика отвечает
Предсказуемость важнее скорости Клиент планирует свою работу. Сбой на два часа с понятным сроком переносится легче, чем сбой на сорок минут в полной неизвестности Управление уровнем услуг, сообщения о ходе работ
Узнать от вас, а не заметить самому Если клиент обнаружил сбой первым, доверие страдает сильнее, чем от самой длительности Мониторинг и управление событиями
Чтобы не повторялось Одну крупную аварию воспринимают как невезение. Третий одинаковый сбой за месяц - как свойство поставщика Управление проблемами, база известных ошибок
Один вход и один ответственный Пересказывать проблему третьему человеку раздражает сильнее всего, каким бы ни был итог. В ITIL это называется единой точкой обращения Управление инцидентами, служба поддержки
Работы - в объявленное окно Недоступность, о которой не предупредили, для клиента ничем не отличается от аварии Управление изменениями, календарь работ
Реальный срок вместо оптимистичного Сорванный срок обходится дороже, чем сразу названный длинный. После второго раза клиент не верит ни одному сроку Управление инцидентами, дисциплина сообщений

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

5. Порядок внедрения

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

  1. Навести порядок в записи. Один журнал инцидентов, обязательные поля: время начала и конца, объект, исход. Без этого нечем мерить эффект остальных шагов, и через полгода спор о результате будет спором мнений.
  2. Очистить оповещения и починить эскалацию. Кто узнаёт, за сколько, кто следующий по таймеру. Видимый результат - за недели.
  3. Ввести период наблюдения после изменений и условие отката. Самый дешёвый шаг с самой быстрой отдачей: не нужны ни новые системы, ни новые люди.
  4. Запустить управление проблемами на трёх самых частых сбоях. Не на всех - именно на трёх. Практика, начатая широко, обычно глохнет в первый же квартал.
  5. Описать ключевые услуги и договориться о целевых уровнях. Теперь есть чем подтверждать обещания: журнал ведётся, эскалация работает, повторов меньше.
  6. Дальше - по данным. Мощности, непрерывность, поставщики, учёт конфигураций подключаются в том порядке, который подсказывает разбор ваших собственных инцидентов, а не общий список.

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

6. Чем измерять эффект

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

  • Доля повторных инцидентов: сколько процентов сбоев повторяют уже встречавшийся. Прямая оценка управления проблемами.
  • Доля неудачных изменений: сколько обновлений потребовали срочного вмешательства - отката или срочного исправления. Это один из показателей DORA, общепринятого набора метрик выпуска изменений. Оценка управления изменениями.
  • Доля сбоев, обнаруженных раньше клиента: главный показатель мониторинга и одновременно то, что клиент чувствует напрямую.
  • Время до начала работ против времени починки: две части одного отрезка. В DevOps первую часть мерят средним временем подтверждения (MTTA), всё целиком - средним временем восстановления (MTTR). Разрыв показывает, куда вкладываться: в порядок передачи или в квалификацию.
  • Концентрация простоя: какая доля систем даёт основную часть потерянного времени. Показывает, где вообще есть смысл прилагать усилия.
  • Доля времени команды на аварийную и рутинную работу: считается не по журналу, а по учёту времени. Ориентир Google SRE - держать её ниже 50%. Именно этот показатель объясняет бизнесу, почему не двигаются проекты.

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

7. Пять ловушек

  • Внедрять практику целиком по книге. ITIL - набор рекомендаций, а не обязательная программа. Работающий минимум почти всегда меньше описанного, и начинать надо с него.
  • Мерить команду числом закрытых заявок. Показатель растёт быстро и не значит ничего: он поощряет дробить задачи и закрывать их по формальному признаку вместо работы с причинами.
  • Ставить целью время закрытия. Инциденты начинают закрывать раньше, чем всё восстановлено, а потом открывают новые на то же самое. Данные портятся, а с ними и возможность что-либо анализировать.
  • Считать практику внедрённой, когда написан регламент. Признак внедрения - изменившееся поведение дежурного в три часа ночи, а не подписанный документ.
  • Строить всё сразу. Три практики, доведённые до конца, дают больше, чем двенадцать начатых. Это частая ошибка сильных команд: у них хватает сил начать всё.

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

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

Обсудить план на квартал с инженером-эксплуатационником - .