В IT релиз в пятницу вечером - плохая идея. В OT это может быть не просто плохая идея, а остановленная линия, сорванная смена и брак в партии. Поэтому разговор про CI/CD в АСУ ТП почти всегда начинается с недоверия: “нам тут не стартап, у нас печь и насосы, а не кнопка в вебе”.
И это правильная реакция. Промышленный CI/CD работает только тогда, когда он не копирует IT-практики один в один, а учитывает технологический процесс, окна работ, MOC и реальную цену изменения.
Короткий ответ
CI/CD в OT - это конвейер для инженерных артефактов (PLC, SCADA, конфиги, скрипты), который делает изменения повторяемыми и проверяемыми до выхода в цех. Отличие от классического IT: больше предрелизных проверок, staged rollout, жёсткая привязка к окнам работ и обязательная связь с MOC. Цель не “релизить чаще”, а менять безопаснее и с контролируемым риском.
Что считается артефактом в промышленном CI/CD
В production-контуре это обычно:
•проекты ПЛК (исходники, библиотеки, параметры);
•SCADA-конфигурации, теги, экраны, alarm rules;
•сетевые и серверные конфиги OT-компонентов;
•скрипты интеграции (OPC UA, MQTT, ETL, отчётность);
•шаблоны документации ввода в эксплуатацию и backup-планы.
Если это влияет на процесс, это должно жить как версионируемый артефакт, а не “копия на рабочем столе главного инженера”.
Как адаптировать pipeline под OT
В IT CI/CD часто заканчивается автоматическим деплоем в прод. В OT такой подход рискован без дополнительных слоёв:
•проверка совместимости с версиями ПЛК/SCADA и библиотек вендора;
•тесты логики на стенде или цифровом макете;
•валидация сетевых/временных параметров;
•формальное одобрение через MOC;
•релиз только в согласованное технологическое окно.
По сути, pipeline в OT - это не “ускоритель релиза”, а “фильтр ошибок до цеха”.
Автоматизированные тесты: что реально автоматизировать
Не всё в АСУ ТП можно прогнать как unit test, но многое можно:
•статические проверки кода и шаблонов ПЛК;
•проверка именования тегов и соответствия стандартам проекта;
•smoke-тесты SCADA-конфигурации (битые ссылки, дубли, конфликтные теги);
•проверка аларм-логики на антишум и приоритеты;
•тесты интеграционных интерфейсов на тестовом брокере/шлюзе.
Главная ошибка - ждать “полной автоматизации”. Реалистичнее комбинировать авто-тесты и инженерный review.
Staged rollout для OT
Классический staged rollout в промышленности выглядит так:
1.стенд или пилотная ячейка;
2.одна линия в смене с минимальным риском;
3.расширение на остальные линии после стабильности;
4.фиксация результатов и lessons learned.
Если попытаться выкатывать сразу на все участки, любой скрытый дефект масштабируется вместе с релизом.
Feature flags для OT: где применимы
В АСУ ТП feature flags не всегда “кнопка в рантайме”. Чаще это:
•параметризуемые режимы логики, заранее заложенные в проект;
•включение нового алгоритма только для конкретного unit/линии;
•переключаемые пути интеграции (старый и новый коннектор параллельно).
Важно: флаг не должен обходить safety-логику и требования допуска. Для критичных функций изменения должны оставаться под формальным управлением.
Связь с MOC и окнами работ
Без MOC промышленный CI/CD превращается в “красивый Git без ответственности”. Нормальная схема:
•заявка на изменение с оценкой риска;
•привязка commit/релиза к номеру MOC;
•список затрагиваемых узлов и план отката;
•окно работ с подтверждением от эксплуатации;
•пост-релизный контроль и закрытие MOC по факту.
Это снимает вечный вопрос после инцидента: “кто и когда это поменял?”.
Пример pipeline: code -> build/compile -> test -> staging -> production release
Ниже рабочий шаблон для команды автоматизации:
1.Code
Инженер вносит изменения в проект ПЛК/SCADA и конфиги, создаёт merge request с описанием риска и ссылкой на MOC.
2.Build/Compile
CI-сервер собирает артефакты вендорскими toolchain-скриптами, фиксирует версии библиотек и хэши сборки.
3.Test
Автотесты проверяют стиль, адресацию, интеграционные контракты, а на стенде выполняются сценарные тесты критичных фаз.
4.Staging
Релиз идёт в тестовый контур или пилотный участок, где команда наблюдает стабильность в реальной смене.
5.Production Release
После approval и окна работ релиз выкатывается в прод с чек-листом отката, мониторингом первых часов и обязательной записью фактического результата в MOC.
Такой pipeline может быть медленнее “чистого IT”, но он предотвращает дорогие ошибки в процессе.
Типовые антипаттерны
Git есть, pipeline нет. Версии хранятся, но никто не проверяет, что они собираются и разворачиваются воспроизводимо.
Автодеплой в прод без окна работ. Быстро до первого инцидента.
Тесты только на бумаге. Чек-лист в Confluence без реального стенда не ловит регрессы.
Откат “как-нибудь”. План rollback пишут после аварии, а не до релиза.
Где уместен СТАБУР
В проектах на базе СТАБУР CI/CD логично продолжает практику версионирования и дисциплины изменений: инженерные артефакты проходят единый контур проверки, а релизы синхронизируются с технологическими окнами и MOC.
Заключение
Промышленный CI/CD - это не про гонку релизов, а про снижение операционного риска. Когда pipeline включает сборку, тесты, staged rollout и формальный MOC, команда меняет систему чаще и спокойнее. Без этого “DevOps в OT” остаётся презентацией, а не производственной практикой.
FAQ
Можно ли внедрить CI/CD без полного перехода на GitOps?
Да. Начните с версионирования и автоматической сборки, затем добавляйте тесты и staged rollout.
Нужен ли отдельный CI-сервер в OT-контуре?
Часто да, или сегрегированный агент в DMZ. Главное - контролируемый обмен артефактами и доступами.
Что важнее на старте: тесты или MOC?
MOC обязателен сразу, а тесты можно наращивать поэтапно. Но без тестов CI/CD быстро теряет ценность.
Как убедить эксплуатацию, что это не “игрушки IT”?
Покажите метрики: меньше аварийных откатов, меньше ручных ошибок, быстрее восстановление после изменений.
Где предел автоматизации в OT?
Там, где начинается safety-контур и регуляторные требования. Критичные решения всё равно требуют инженерного допуска.
Обсуждение