ITSM на практике: запускаем Change Management с CAB и RFC-формой в JIRA

Примерно раз в квартал у любого ИТ-аутсорсера случается неприятный разговор с клиентом: «У нас вчера упал сервис - кто и что менял?». Ответить обычно нечего: кто-то обновил драйвер, кто-то поправил конфиг «на минуту», кто-то перезапустил службу «для профилактики». Всё это без заявок, без согласования, без записи. Вот и результат.

Примерно с таким положением дел мы столкнулись у одного из клиентов в начале года. Инфраструктура средняя по размеру - около 80 серверов, несколько площадок, смешанная команда: наши инженеры плюс их внутренний IT-специалист. Инциденты случались нередко, и примерно в половине случаев причиной оказывалось чьё-то несогласованное изменение. Клиент хотел порядка. Мы решили запустить Change Management по ITIL v3 - не в полную силу корпоративной бюрократии, но достаточно, чтобы зафиксировать хаос.

Зачем вообще ITIL v3 2011 Edition

ITIL не новость: библиотека выходит с конца 1980-х. Но 2011 Edition, вышедший в прошлом году, навёл в документации порядок - убрал противоречия между книгами, уточнил роли и процедуры. Управление изменениями там описано достаточно конкретно, чтобы взять за основу без дополнительных консультаций на 40 часов.

Ключевые элементы, которые мы взяли из ITIL v3 для этого проекта:

• RFC (Request for Change) - формальная заявка на изменение с описанием, планом отката и оценкой риска.
• CAB (Change Advisory Board) - совещание, на котором заявки рассматриваются и одобряются.
• Emergency Change - процедура для срочных изменений, которые нельзя ждать до следующего CAB.

Всё остальное из ITIL - конфигурационные единицы, CMDB, CSI - пока отложили. Начинать лучше с одного процесса, а не пытаться внедрить всё сразу.

Инструмент: JIRA Service Desk

На рынке есть несколько специализированных ITSM-систем. Naumen Service Desk популярен у крупных российских заказчиков, HP Service Manager - в банках и телекоме. Мы выбрали JIRA Service Desk по простой причине: у клиента уже стоит JIRA для задач разработки, лицензия покрывает Service Desk, а команда умеет работать в интерфейсе Atlassian.

Настройка заняла меньше дня. Создали отдельный проект типа «Service Desk», сделали форму RFC с обязательными полями:

• Описание изменения - что именно меняется и почему.
• Затронутые системы - список серверов или сервисов.
• Риск - три уровня: низкий, средний, высокий.
• План отката - что делать, если что-то пойдёт не так.
• Дата и время - когда планируется работа.

Workflow для RFC получился линейный: Draft -> Submitted -> Approved / Rejected -> Implemented -> Closed. Для Emergency Change - укороченный: Submitted -> Approved (устно, закрепляем постфактум) -> Implemented -> Closed.

CAB раз в неделю: как это выглядит на практике

CAB мы запустили в формате часового созвона каждый вторник в 10:00. Участники: наш ведущий инженер, IT-директор клиента, иногда - представитель бизнеса, если изменение касается критичного сервиса.

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

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

Что с Emergency Change

Договорились сразу: Emergency Change - это не способ обойти CAB, а исключение для реальных инцидентов, когда изменение нужно прямо сейчас. Критерий простой: активный инцидент с влиянием на бизнес. Плановые работы, которые просто забыли подать вовремя, не считаются.

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

Промежуточный результат

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

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

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

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