DevOps

DevOps в ITSM-контексте рассматривают как культурный и управленческий подход, который помогает организации быстрее и предсказуемее доставлять ценность через ИТ-услуги и продукты, сокращая разрывы между разработкой, эксплуатацией и командами поддержки. Центральная идея — улучшать поток создания ценности от замысла и изменения до развёртывания, работы в эксплуатации и получения обратной связи. Практически DevOps поддерживает согласование целей, прозрачность работы, совместную ответственность за результат, высокую степень автоматизации (сборка, тестирование, развёртывание, мониторинг), а также дисциплину бережливого производства для устранения потерь и очередей. Измерение и отчётность используются для управления производительностью и качеством: метрики стабильности, скорости поставки, качества, времени восстановления. DevOps хорошо сочетается с управлением изменениями, управлением релизами, управлением развёртыванием и постоянным совершенствованием, помогая сделать эти практики более «потоковыми». Вне охвата DevOps находятся формальные требования к управлению услугами как таковому, например определение уровней услуги и SLA, а также все вопросы стратегии, портфеля и финансов, если они не связаны напрямую с улучшением потока создания ценности.

DevOps часто ошибочно сводят к набору инструментов или к «непрерывному развёртыванию». Инструменты и непрерывная интеграция важны, но термин в определении подчёркивает именно организационную культуру: без совместной ответственности, доверия и общего языка автоматизация лишь ускорит выпуск дефектов. Ещё одна типичная путаница — DevOps как замена управлению изменениями. На практике DevOps не отменяет контроль: он помогает сделать управление изменениями более эффективным через модели изменения, автоматизированные проверки, управление рисками и встроенную валидацию. Также DevOps не равен Agile: Agile помогает управлять созданием продукта, а DevOps — обеспечить устойчивое и повторяемое предоставление и поддержка в рабочей среде, включая мониторинг, реагирование на инциденты и улучшение ремонтопригодности. Распространённая ошибка внедрения — создание «DevOps-команды» как отдельного силоса; это снижает скорость организации и ухудшает сервисные отношения между командами. Наконец, CALMS нередко трактуют формально, ограничиваясь «Measurement» в виде дашборда, но без замыкания цикла обратной связи и реального постоянного совершенствования по результатам измерений.