ITIL для 50–500 человек. Что я выкидываю из учебника

Зачем ITIL на этом масштабе

Когда я готовился к ITIL Foundation в 2024-м, учебник предлагал 34 практики. В реальной работе на масштабе 50–500 человек я веду шесть. Остальное либо избыточно для масштаба, либо относится к продуктовым ИТ-компаниям и сервис-провайдерам, где сервис продают вовне.

У среднего бизнеса задача проще. Сделать так, чтобы инциденты не повторялись по кругу, а изменения не ломали то, что вчера работало. Плюс раз в месяц давать владельцу картину, по которой он принимает решения. Под это мне достаточно шести регламентов общим объёмом 14–18 страниц. Не «корпоративная архитектура управления услугами», а рабочий набор, который я отлаживал на разных компаниях за 18 лет практики.

Дальше разбираю каждую практику. Что внутри регламента, какие артефакты ведутся, какие метрики собираются. Без копирования учебника. С пометками «вот это я выкинул, потому что не работает».

Практика 1. Incident Management

Регламент на 2 страницы. Что такое инцидент (отличие от запроса на обслуживание и от изменения), классификация по приоритетам P1–P4, кто принимает на первой линии, SLA по реакции и восстановлению на каждый приоритет, правила эскалации, post-mortem на P1 в обязательном порядке.

Шкала приоритетов P1–P4

На приоритеты я тратил больше всего времени с инженерами, потому что от них зависят все SLA. Вот моя рабочая шкала на B2B-производстве 50–500 человек. P1 — производство стоит или почта не работает у всей компании. P2 — критическая система деградирует или недоступна для отдела. P3 — пользовательский запрос с реальной блокировкой работы. P4 — всё остальное.

Post-mortem на P1 в одну страницу, без обвинений

Post-mortem на P1 — короткий документ на одну страницу. Что случилось, последовательность действий, почему случилось (корневая причина, не симптом), какие действия предпринимаю, чтобы не повторилось. Без обвинений конкретных людей — культура blameless, иначе инженеры начнут скрывать инциденты.

Практика 2. Change Enablement (в ITIL v3 — Change Management)

Самая частая болевая точка у клиентов, к которым я прихожу. Инциденты обычно как-то ведутся, изменения — почти никогда. В результате каждое обновление 1С, каждый перезапуск виртуалки, каждый патч на сервере БД проводится по личному решению одного инженера. Половина крупных аварий за 18 лет моей практики — результат изменения, которое никто не согласовал.

Три типа изменения — Standard, Normal, Emergency

Регламент задаёт три типа изменения. Standard — заранее одобренные шаблоны (плановый перезапуск, обновление антивируса, смена пароля сервисного аккаунта). Normal — всё остальное, что планируется заранее и проходит через CAB. Emergency — срочные изменения для восстановления сервиса, согласуются по телефону с руководителем ИТ и оформляются задним числом в течение 24 часов.

RFC из 7 полей

RFC (request for change) — карточка из 7 полей. Что меняем, зачем, какой тип, риск-оценка, план отката, окно изменения, ответственный. Заполняется за 10 минут, читается за 2. Всё, что сложнее этих 7 полей, на масштабе среднего бизнеса избыточно.

Weekly CAB на 30 минут

Раз в неделю собираемся составом «руководитель ИТ + ключевые инженеры + ответственный за бизнес-приложения». 30 минут. На входе список normal-изменений на ближайшие 7 дней. По каждому RFC выносим решение. Одобрено, отложено, требует доработки. Emergency-изменения проходят отдельным треком и ретроспективно обсуждаются на ближайшем CAB.

Главная метрика — change success rate

Главная метрика практики — change success rate. Доля изменений, которые прошли без отката или последующего инцидента. На здоровой ИТ-функции цифра в районе 92–96%. Падение ниже 90% — сигнал, что либо CAB пропускает слабые RFC, либо инженеры обходят процесс через emergency.

Практика 3. Problem Management

Практика, которую я применяю только к повторяющимся инцидентам P1 и P2. Не как отдельный процесс с собственной командой и собственными артефактами, а как ветку Incident. Если за 90 дней один и тот же симптом повторился больше двух раз, заводится problem record, и его решает инженер с привязкой к корневой причине.

Когда не нужен отдельный problem manager

На масштабе 50–500 человек содержать отдельного problem-менеджера и отдельный поток работы непрактично. Те, кто занимаются инцидентами, в спокойные периоды разбирают проблемы. Итогом становится либо постоянное решение, либо временный обходной путь с пометкой «к проблеме возвращаемся при таких-то условиях».

Шаблон проблемного разбора

Шаблон проблемного разбора — расширенный post-mortem на 2–3 страницы. Пять «почему» по Toyota, схема причинно-следственных связей, конкретный ответственный за устранение, дата ревью. Этот документ живёт во внутренней базе знаний и читается на месячном ретро. По инструменту делаю оговорку. Confluence и Jira (Atlassian) с 2022 года в России не продаются, поэтому на новых проектах я веду базу знаний на том, что доступно on-prem — Kaiten, YouTrack, Yonote или wiki внутри корпоративного портала.

Практика 4. IT Asset Management

CMDB у меня не в Excel и не в чек-листе таск-трекера. В Excel невозможно вести историю изменений, в трекере теряется связь активов между собой. Я ставлю либо готовую CMDB с открытым кодом (Snipe-IT, GLPI, Ralph NG), либо в редких случаях самописное решение, если масштаб оправдывает разработку.

Когда оправдана самописная CMDB на интеграциях

Когда парк переваливает за несколько сотен единиц и разбросан по локациям, ручная инвентаризация в Excel перестаёт справляться. Тогда я строю CMDB с двумя интеграциями. С 1С — для учёта стоимости и амортизации, чтобы бухгалтерия и ИТ видели один и тот же актив. С DHCP-сервером — для автоматической регистрации новой техники, чтобы она не появлялась в сети мимо учёта. На парке такого размера это сокращает плановую инвентаризацию в разы и даёт историю по каждой единице от закупки до списания.

Что обязательно в CMDB на 50–500 человек

Минимум, который я требую от CMDB на 50–500 человек, такой. Серверы физические, серверы виртуальные, сетевое оборудование, рабочие станции, лицензии (особенно перепроверяемые ежегодно — Microsoft, 1С, антивирусы), внешние сервисы по подписке. Не нужно вести в CMDB каждую мышку и каждый патч-корд. Это перегруз, превращающий артефакт в свалку.

Зачем это в реальности

Ради чего CMDB вообще существует. При инциденте она показывает полный контекст актива. Где стоит, кто владелец, какие зависимости. При бюджетировании на год помогает понять парк железа и сроки замены. И отдельно ценна при лицензионном аудите. Когда вендор или регулятор спрашивает, сколько у вас пользователей 1С, по CMDB видно точное число, а не оценку на глаз. Разница между «412» и «850» в таком разговоре стоит реальных денег.

Практика 5. Service Level Management

SLA я делаю с бизнесом, а не внутри ИТ. Это ключевое отличие от того, как ITIL преподают на курсах. Учебник предполагает сложную пирамиду из SLA с заказчиком, OLA внутри ИТ-команды, UC с подрядчиками. На масштабе 50–500 человек эта пирамида разваливается под собственным весом.

Один документ вместо пирамиды SLA/OLA/UC

Я веду один документ на 3 страницы. Соглашение о качестве ИТ-сервисов между ИТ-функцией и бизнесом. Перечень критичных систем (обычно 5–8 штук), для каждой — целевая доступность в часах, окно регламентных работ, SLA на реакцию и восстановление, контакты ответственного со стороны ИТ, контакты ответственного со стороны бизнеса.

Цена ошибки между 99,5% и 99,95%

Документ обновляется раз в год вместе с бюджетом. Если бизнес хочет 99,95% доступности 1С (4,4 часа простоя в год), это стоит других денег, чем 99,5% (43,8 часа). Цифры обсуждаются на этапе планирования бюджета. После подписания SLA становится основанием для приоритизации инцидентов и для обоснования закупок резервного оборудования.

Метрика практики — доля выполненных месяцев

Метрика практики простая. Доля месяцев в году, когда SLA по каждой критичной системе выполнен. Если SLA нарушен — короткая отметка в месячном отчёте владельцу: «доступность 1С 99,3% при цели 99,5%, причины — два P1 по корневой инфраструктуре, план снижения риска в RFC такой-то».

Практика 6. Continual Improvement

Месячный ретро на 60 минут с владельцем. Со мной как руководителем ИТ или vCIO садятся владелец и финансовый директор по желанию. Повестка одна и та же из месяца в месяц. Что улучшаем в этом месяце.

Структура 60-минутного ретро

Структура ретро такая. 10 минут на прошлый месяц (что было сделано, что не сделано, почему), 20 минут на проблемы и инциденты P1 (что выявили, какие закономерности повторяются, какие изменения предлагаю), 20 минут на план следующего месяца (3–5 пунктов с конкретными результатами и датами), 10 минут на риски и вопросы. Протокол ведётся в общей базе знаний или в облачном документе и уходит владельцу в течение суток после встречи.

Почему этот час даёт основной эффект

Этот ретро — самая дешёвая практика из шести и самая ценная. За 60 минут в месяц владелец получает картину ИТ, а я получаю мандат на изменения и приоритеты. Заодно инженеры видят, что их работа замечена. У клиентов, которые игнорируют эту практику, через 3–6 месяцев начинается медленный отрыв ИТ от бизнес-приоритетов. Обычно я замечаю это по нарастанию P3-тикетов с пометкой «не критично, но мешает».

Что я не делаю

Десять практик из канона, которые не применяю

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

Остальные практики из 34 либо вообще не релевантны для непродуктового бизнеса (Service Validation and Testing, Software Development and Management, Business Analysis), либо схлопываются внутрь Incident Management. Service Desk, Service Request Management и Monitoring and Event Management я веду не отдельными процессами, а частями той же первой линии и того же потока инцидентов.

Какой эффект это даёт

Точные цифры одной компании я приводить не буду. Это были бы либо чужие данные под NDA, либо красивая выдумка. Дам то, что честно. Порядок величин, который я обычно вижу на проектах масштаба 50–500 человек за первый год, когда эти шесть практик ставятся с нуля на функции, где раньше не было регламентов.

Типичные ориентиры за первый год

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

Про сертификацию

Foundation как общий словарь

ITIL Foundation я сдал в 2024 году. По делу — полезный сертификат как общий словарь. Когда я разговариваю с другим ИТ-руководителем или с консультантом, и мы оба знаем, что такое CAB, что такое RFC, что такое P1, мы не тратим первый час встречи на согласование терминологии.

Practitioner и специализации я пропустил

Дальше учебная программа уходит в Practitioner и в специализации (Create, Deliver and Support; Drive Stakeholder Value; High Velocity IT; Direct, Plan and Improve). На масштабе среднего бизнеса всё это избыточно. Я Practitioner не сдавал и не планирую, потому что в моём контексте дополнительная глубина ITIL не превращается в практическую ценность.

Что читал вместо Practitioner

Чем я заменил Practitioner. Книги по системному мышлению Питера Сенге («Пятая дисциплина»), по DevOps от Джина Кима (Phoenix Project, Unicorn Project), про роль архитектора между инженерной и бизнес-частью — Грегор Хохпе, The Software Architect Elevator, плюс практические материалы по управлению инцидентами от Google SRE. Эта подборка лучше отвечает на вопрос «как улучшить ИТ-функцию среднего бизнеса», чем дополнительные ITIL-сертификаты.

Зачем читал

Если у вас есть учебник ITIL и нет рабочих регламентов, запишитесь на 30-минутный установочный звонок через форму контакта. За один аудит-проект я отдам шесть регламентов общим объёмом 14–18 страниц, по которым ваш ИТ-отдел сможет работать. Без толстого тома.

Если вы только думаете про аудит, посмотрите запись про карту ИТ-зрелости за 4 недели. Шесть практик ITIL — это домен «Процессы» в этой карте, один из девяти. Без остальных восьми доменов ITIL зависает в воздухе. Про разницу между vCIO и штатным CIO читайте в сравнении моделей. Про реальный инцидент, который иллюстрирует пользу практики Change Enablement, смотрите RCA про apt purge dovecot-sieve.