Это распространённое и удобное допущение: если автоматизация выполнилась без сбоев, значит, цель достигнута. Оно почти никогда не проговаривается вслух, но лежит в основе того, как компании строят CI/CD, инфраструктурные пайплайны, реагирование на инциденты и теперь — операционных AI-агентов. И именно это допущение стоит разобрать подробно, потому что оно работает ровно до первого случая, когда работает не так.
Что на самом деле проверяет пайплайн
Возьмём типичный деплой: собрать приложение, прогнать тесты, собрать образ, задеплоить, подождать готовности, отметить успех. Если каждый шаг прошёл без ошибки, пайплайн становится зелёным. Но что это доказывает? По сути — только то, что заданная последовательность шагов выполнилась.
Это не то же самое, что «система пришла в нужное состояние». Деплой может технически завершиться успешно, но при этом развернётся не та версия образа, вместо трёх реплик поднимутся две, вырастет процент ошибок, окажется выключен нужный feature flag или регион окажется не тем, в котором развёртывание разрешено правилами компании. Исполнитель — будь то Kubernetes, Terraform-скрипт или произвольный контроллер — сделал свою работу. А операция в более широком смысле могла провалиться.
Это разрыв между успехом исполнения и соответствием результата намерению. Автоматизация отвечает на вопрос «шаги выполнились?». Обычно нужен ответ на другой вопрос: «система в итоге удовлетворяет условиям, которые мы задумывали?» Это разные вопросы, и путать их — не техническая мелочь, а системный источник ложного чувства безопасности.
Почему операционное знание оказывается разбросанным
Проблема усугубляется тем, что знание о том, каким должен быть правильный результат, редко живёт в одном месте. Оно расползается по раннбукам, тикетам, переписке в Slack, конфигурации CI/CD, файлам Terraform, дашбордам, правилам алертинга и памяти конкретных инженеров. Одна система знает, сколько реплик должно быть поднято. Другая — какой процент ошибок считается приемлемым. Третья описывает, когда требуется откат. Ни один из этих артефактов сам по себе не формулирует одновременно: вот что мы хотим сделать, вот ограничения, вот какие данные нам нужны для проверки, вот как мы решаем, что операция удалась.
Когда правила размазаны по десятку систем, исполнитель — скрипт, пайплайн, контроллер — фактически становится спецификацией по умолчанию. А если логика, которая выполняет действие, и логика, которая определяет успех, слиты в одном месте, проверка теряет смысл: вопрос «правильно ли сработала автоматизация» превращается в вопрос «сделала ли автоматизация то, что сама же считает правильным» — замкнутый круг без внешней точки опоры.
Команда — это не намерение
Разница становится нагляднее на уровне кода. Команда вида kubectl set image deployment/orders orders=registry.example.com/orders:2026.09.19 объясняет Kubernetes, как выполнить действие. Она ничего не говорит о том, почему это действие приемлемо. Реальное операционное намерение выглядит иначе: развернуть версию сервиса, при этом сохранить минимум три доступные реплики, не превысить порог ошибок и задержки, разворачивать только в разрешённом регионе, оставить возможность откатиться в течение получаса.
Команда и намерение связаны, но это не один и тот же артефакт. И тут кроется практическая выгода разделения: если цель операции описана отдельно от механизма её достижения, исполнителя можно заменить — перейти с Kubernetes на управляемую облачную платформу, на собственный оркестратор или на AI-агента — без того, чтобы заново придумывать, что вообще считалось успехом. Если же цель зашита прямо в код конкретного исполнителя, смена инструмента означает необходимость заново реконструировать смысл операции.
Что такое исполняемая операционная спецификация
Идея, которую разбирает первоисточник, формулируется просто: если система способна выполнить операцию автоматически, у нас должна быть возможность отдельно описать, что означает успешное выполнение — независимо от инструмента, который эту операцию выполняет. Такое описание — исполняемая операционная спецификация — включает как минимум цель, ограничения, которые должны выполняться, данные, которые нужно собрать в качестве доказательства, и правила, по которым эти данные сопоставляются с ограничениями.
Разница между тем, что делает исполнитель, наблюдаемостью и спецификацией удобно свести в одну таблицу:
| Слой | Что проверяет | На какой вопрос отвечает | Типичный ложный успех |
|---|---|---|---|
| Исполнитель (пайплайн, скрипт, агент) | Что шаги выполнены без ошибок | «Команды отработали?» | Код завершения 0, но система в неправильном состоянии |
| Наблюдаемость | Текущие метрики и события системы | «Что происходит прямо сейчас?» | Метрика видна, но нет условия, с которым её сравнить |
| Спецификация результата | Соответствие наблюдаемых данных заданным условиям | «Достигнута ли задуманная цель?» | Отсутствует — именно это спецификация должна закрывать |
Важная деталь: наблюдаемость и спецификация не заменяют друг друга, а работают в паре. Дашборд может показать, что процент ошибок равен 1,4%. Это наблюдение. Но приемлемо это число или нет — зависит от заранее заданного условия. Без ожидаемого порога метрика — просто число. Без метрики порог нельзя проверить. Нужны обе части.
Здесь стоит провести аккуратную границу с другим уже привычным понятием — SLO. Service Level Objective — это конкретный измеримый показатель надёжности или доступности, и его удобно использовать как пример ограничения внутри спецификации. Но SLO сам по себе не является полноценной спецификацией результата операции: он описывает один срез допустимого поведения системы во времени, а не весь набор условий, целей и доказательств, относящихся к конкретной операции. Путать одно с другим — соблазнительно, потому что оба понятия говорят о «допустимых значениях», но масштаб и назначение у них разные.
Как выглядит цепочка проверки
Если собрать всё вместе, получается последовательность, в которой намерение постепенно превращается в проверяемый факт:
flowchart TD A[Операционное намерение] --> B[Спецификация: цель и ограничения] B --> C[Исполнитель] C --> D[Свидетельства/evidence] D --> E[Оценка соответствия]
Ключевое звено здесь — то, что спецификация стоит между намерением и исполнителем, а не внутри него. Именно поэтому оценка на выходе может дать не бинарный «успех/провал», а содержательный ответ: три ограничения выполнены, одно нарушено, потому что доступных реплик оказалось две вместо трёх. Это гораздо более полезная информация, чем просто «операция провалилась», потому что она сразу указывает, что чинить.
Зачем это в CI/CD, инфраструктуре, инцидентах и агентах
Идея не привязана к одному классу задач. В CI/CD пайплайн и так описывает порядок шагов, но редко — условия, при которых релиз действительно можно считать состоявшимся: совпадение дайджеста артефакта с одобренной сборкой, сохранение минимального числа реплик, возможность откатиться. В инфраструктуре как коде уже есть желаемое состояние — этот принцип концептуально близок и хорошо знаком по GitOps, где система декларативно описывает целевое состояние и постоянно сверяется с ним. Но операционное намерение часто выходит за рамки конфигурации: лимиты стоимости, региональные ограничения, свежесть бэкапов — то, что живёт вне определения ресурса и нуждается в отдельной спецификации, объединяющей разные источники данных.
В реагировании на инциденты граница между «раннбук выполнился» и «инцидент решён» особенно ощутима: раннбук может предписывать перезапустить сервис, очистить кеш и увеличить число реплик, но настоящая цель — восстановить доступность оформления заказов без дублирования платежей и без потери состояния. Если перезапуск не восстановил эту доступность, раннбук технически выполнился, а операция — нет.
Наиболее остро вопрос встаёт с AI-агентами. Обычная автоматизация следует заранее заданной логике исполнения, поэтому её относительно легко проверять на уровне шагов. Агент же может выбирать путь исполнения динамически — иногда перезапустить сервис, иногда изменить ёмкость, иногда перенаправить трафик — и от инцидента к инциденту эта последовательность будет разной. Проверить агента, сравнивая с одним эталонным сценарием, becomes невозможно. Но проверить, достигнута ли заявленная цель при соблюдении заявленных ограничений — можно, если эта цель описана отдельно от того, какие именно действия агент выберет. Именно поэтому разделение намерения и механизма исполнения становится не архитектурной изящностью, а практической необходимостью по мере роста автономности систем.
Здесь важно не путать это разделение с иллюзией полного контроля. Возможность формально проверить результат — не то же самое, что гарантия безопасного поведения агента: спецификация задаёт условия проверки, но не заменяет ограничения доступа, аудит действий и организационные процедуры, которые определяют, что агенту разрешено делать в принципе.
Что этот подход не решает
Важно проговорить границы честно. Исполняемая спецификация не устраняет плохо сформулированные требования, неверные метрики, дыры в наблюдаемости или конфликтующие бизнес-цели. Она не гарантирует, что сама спецификация написана правильно — ошибочная или неполная спецификация может создавать ложную уверенность не хуже, чем её отсутствие. Устаревшая спецификация становится ещё одним источником расхождения с реальностью, если её не поддерживать в актуальном виде. И не любую операционную задачу можно корректно свести к набору простых порогов: часть операционного смысла — контекст, компромиссы, суждение человека — плохо поддаётся формализации, и попытка загнать их в жёсткие условия может обеднить исходную цель, а не прояснить её.
Наконец, стоит помнить, что сама по себе идея — это методологический каркас, а не готовый рецепт: как именно встраивать такие спецификации в конкретную организацию, с какими инструментами и процессами, — вопрос, требующий отдельной инженерной работы, которую первоисточник сознательно оставляет за рамками.
Итог
Автоматизация десятилетиями училась быть быстрее и надёжнее в исполнении. Но скорость исполнения не равна корректности результата. Пока критерий успеха живёт внутри исполнителя — будь то скрипт, пайплайн или агент, — проверка результата остаётся замкнутым кругом: система спрашивает саму себя, сделала ли она то, что сама считает правильным. Отделённая, независимо читаемая спецификация того, что должно получиться, разрывает этот круг — не потому, что гарантирует правильный исход, а потому, что делает разницу между «шаги выполнились» и «результат соответствует намерению» видимой и проверяемой. Именно эта видимость — и есть настоящая надёжность, которую стоит требовать от автоматизации, растущей быстрее, чем растёт наша способность объяснить, чего мы от неё хотим.
