ITIL и ITSM для DevOps – знать корни важнее, чем помнить все команды наизусть Собственно на написание статьи сподвигло общение с HR рекрутером и ее вопрос что можно спросить у devops любого уровня для понимания его знаний. Короткий ответ, знание принципов ИТИЛ, и длинная версия ниже. Все естественно IMHO с удовольствием обсужу в комментариях.

Рецепт успешного DevOps-инженера не в знании сотни CLI-трюков и  умении цитировать по памяти tldp.org, а в понимании, откуда взялся весь этот процессный балаган. ITIL (Information Technology Infrastructure Library) и ITSM (IT Service Management) стали прародителями современных практик DevOps – так что игнорировать их историю всё равно что пытаться строить дом с крыши потому Ондулин вот он под рукой а остальное потом как-нибудь.

Чуть-чуть истории

Когда в 1980-х годах правительство Великобритании столкнулось с хаосом в ИТ-услугах, они решили систематизировать всё: завести процессы для инцидентов, управления изменениями, релизов, доступности и прочего добра. Получилась библиотека рекомендаций — ITIL. На этой основе вырос ITSM, призванный связать нужды бизнеса и ИТ-операций: определить, кто за что отвечает, как быстро реагировать на заявку от пользователя и как контролировать уровень сервиса.

DevOps взял эти практики и «раскача­л»: объединил разработку и эксплуатацию так, чтобы частые релизы и автоматизация шли рука об руку с качественным сервис-менеджментом. Если не знать, зачем вообще нужен процесс управления изменениями или катастрофами, риск упустить фазу проверки и вбить в прод релиз с «Докер-легаси» и «кривым» ansible. А потом любить мозги коллегам и гореть седалищем в три ночи, когда всё «упало и горит».

Важно понимать методологию: зачем согласовывать изменения, кто подписывает план отката и почему в ITSM-букваре водится термин “Service Level Agreement”. Без этого вы будете слепо тыкать командами в терминале и удивляться, почему спринт превращается в бесконечный ад. В противовес этому, общее видение архитектуры сервиса, его жизненного цикла и непрерывного улучшения – сильнее любого «git reset --hard».

Да, есть кучи горячих комбинаций CLI-приёмов и шаблонов Terraform. Руку набиваешь – кайф. Но куда приятнее делать это, зная, почему ты автоматизируешь конкретный этап процесса и как твои действия вписываются в общее движение от идеи фичи до счастливого пользователя. Со стороны DevOps-специалиста это похоже на знакомство с готовкой, надо знать как готовить каждый компонент, как его выбирать, разделывать подготавливать, чтобы на выходе получить вителло тонато, а не рыбомясное изделие.

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

Помня о корнях ITIL и методологии ITSM, вы урежете хвост бесконечных ад-хуков и невротичных попыток «запомнить всё». Зато на практике вы будете уверенно скользить по CI/CD-пайплайну, а не бороться с флагами и фатальными ошибками. И самый главный бонус: у вас всегда будет аргумент «я так предусмотрительно прописал процесс» — что звучит куда лучше, чем «ну, я так уже делал, мне сказали сделать так». Т.е. даже на уровне джуна, старайтесь смотреть на то что делаете с точки зрения что вы как пользователь хотели бы получить и как devops что нужно для этого сделать, и не стесняйтесь коллегам подсовывать выдержки из ITIL, как оказалось многие уже забыли/не знали/считаю неактуальным эти библиотеки.