'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Что такое ITIL
Библиотека появилась в британском государственном агентстве в конце восьмидесятых как попытка собрать удачные практики работы ИТ-служб. С тех пор она пережила несколько редакций; действующая — ITIL 4, вышедшая в 2019 году.
Главная идея простая. ИТ-подразделение оказывает услуги, у услуг есть потребители, а у потребителей — ожидания по доступности и срокам. Как только это записано, разговор о работе ИТ перестаёт быть спором о том, кто чем занят.
Ранние редакции описывали жёсткий набор процессов по стадиям жизненного цикла услуги. ITIL 4 от этого отошла: вместо обязательной последовательности там принципы и набор практик, из которых берут нужные. На практике компании начинают с трёх-четырёх и живут с ними годами.
Ключевое различие, на котором спотыкаются чаще всего, — между инцидентом и проблемой. Инцидент означает, что услуга не работает, и задача — вернуть её как можно быстрее, хоть обходным путём. Проблема — это причина инцидентов, и её разбирают отдельно, без спешки. Смешивание этих двух режимов даёт либо медленное восстановление, либо вечно повторяющиеся сбои.
Отдельная практика — контроль изменений. Значительная часть инцидентов рождается из собственных изменений, поэтому у них появляется порядок согласования, окно проведения и план отката.
В России есть сертифицируемый стандарт на систему управления ИТ-услугами — ГОСТ Р ИСО/МЭК 20000. Он требуется, когда этого просит заказчик; для внутренней пользы достаточно самих практик.
- К службе обращаются десятки раз в неделю, и обращения похожи друг на друга
- Пользователи не понимают, сколько ждать, и звонят напрямую знакомым исполнителям
- Одни и те же сбои повторяются, а причину никто не разбирает
- Часть аварий возникает после собственных изменений
- Служба из двух человек, обращений несколько в неделю: формализация съест больше, чем даст
- Работа проектная и штучная, повторяющихся обращений нет
- Цель — получить сертификат, а менять порядок работы никто не собирается
- Руководство не готово ограничивать поток изменений в продуктивную среду
Что появляется в работе
Документов немного, и каждый отвечает на свой вопрос: каталог — что мы даём, соглашение — за какой срок, база — как чинить, реестр изменений — что мы сами меняем.
Каталог услуг
Список того, что служба даёт потребителям, на их языке. «Доступ к системе учёта» вместо «настройки LDAP». Обычно десяток-полтора позиций.
Соглашение об уровне услуг
Обещание по времени реакции и восстановления для каждого типа обращения, часы поддержки, исключения. Согласуется с потребителем: спущенное сверху обещание не выполняется.
База типовых решений
Короткие инструкции по частым обращениям. Позволяет закрывать их первой линией и снижает нагрузку сильнее любой автоматизации.
Реестр изменений
Что меняем в продуктивной среде, кто согласовал, когда окно, как откатываем. Ведётся даже для мелких правок.
| СОБЫТИЕ | ЧАСТОТА И ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | ЧЕМ ЗАКАНЧИВАЕТСЯ |
|---|---|---|---|
| Разбор очереди | 10–15 мин ежедневно | линии поддержки | приоритеты на день, эскалации |
| Совет по изменениям | 30–60 мин еженедельно | владельцы систем и служба | согласованные изменения и окна |
| Разбор проблем | 1–2 ч раз в две недели | вторая линия и владельцы услуг | найденные причины повторяющихся сбоев |
| Обзор уровня услуг | 1 ч ежемесячно | служба и представители потребителей | решение о доработке обещаний или процесса |
С чего начать
Практик в библиотеке несколько десятков, и попытка внедрить их разом заканчивается регламентом, по которому никто не работает. Порядок ниже даёт результат за пару месяцев.
- 1Соберите обращения в одно местоЕдиная точка приёма вместо почты, чатов и звонков знакомым. Пока обращения приходят пятью путями, ни посчитать, ни распределить их невозможно.первая неделя
- 2Опишите каталог услугДесяток позиций на языке потребителя. Список того, что служба делает, написанный её собственными терминами, потребителю бесполезен.первый месяц
- 3Разделите инциденты и запросы«Не работает» и «дайте доступ» идут разными маршрутами с разными сроками. Смешение этих потоков — причина того, что срочное ждёт наравне с рутиной.первый месяц
- 4Договоритесь о срокахВремя реакции и восстановления по типам обращений, согласованное с потребителем. Начинайте с замера текущего положения, чтобы обещание было выполнимым.второй месяц
- 5Заведите разбор проблемРегулярная встреча по повторяющимся сбоям. Без неё служба вечно тушит одни и те же пожары и не имеет времени на причины.второй-третий месяц
- 6Введите контроль измененийСогласование, окно, план отката. Начните со значимых изменений в продуктивной среде, мелкие подключайте позже.третий месяц
Что считать
Где обычно ломается
Инциденты и проблемы ведут одинаково
Каталог написан на языке ИТ
Сроки взяли с потолка
Приоритет ставит тот, кто громче
Внедряют все практики сразу
Обходные каналы остаются
Темы про ITIL
Как собрать службу в Shtab
Заведите форму приёма обращений и разведите инциденты и запросы по разным доскам со своими статусами: у них разные сроки, и общая очередь всегда работает в пользу рутины.
- 01Форма приёма делает единую точку входа вместо почты, чатов и звонков.
- 02Контроль сроков реакции задаёт обещание по каждому типу обращений и считает долю уложившихся.
- 03Пользовательские поля хранят влияние и срочность, из которых считается приоритет.
- 04База типовых решений живёт страницами в том же проекте и открывается прямо из карточки.
- 05Автоматизации назначают исполнителя по типу обращения и уведомляют о приближении срока.
- 06Отдельный проект под изменения хранит согласование, окно проведения и план отката.
Частые вопросы
Ранние редакции описывали жёсткий набор процессов по стадиям жизненного цикла услуги, и внедрение выглядело как последовательное построение всех этапов. ITIL 4 заменила эту конструкцию принципами и набором практик, из которых берут нужные. Практически это означает, что начинать с трёх практик теперь не отступление от метода, а нормальный путь.