Рецепт: учения аварийного выключателя

Проведение безопасных учений аварийного выключателя на непродакшен-окружении — включение остановки, проверка отказов по всем точкам исполнения.

Аварийный выключатель — это шлюз запрета на уровне всего окружения. Включение намеренно дёшево — уровень admin, без кворума — потому что остановка, которая ждёт консенсуса, — это не остановка. Повторное включение намеренно дорого: двойной контроль, без экстренного обхода. Вы не хотите обнаружить пробел в любом направлении в 03:00.

Учения на непродакшен-тенанте — единственный безопасный способ доказать, что шлюз остановки отклоняет каждую точку исполнения, что ожидающие согласования отменяются атомарно и что повторное включение действительно требует двух различных людей. Проведите их до того, как они понадобятся.

Предварительные требования

Непродакшен-тенант. Учения включают реальную остановку на уровне всего окружения. Проводите их на staging или dev, никогда на продакшене.
Минимум три человека. (1) Включающий уровня admin; (2) два различных согласующих повторное включение (editor или выше), удовлетворяющих минимуму двойного контроля critical; (3) незаинтересованный пост-ревизор (editor или выше), который закрывает принудительную пост-ревизию. Пост-ревизор может совпадать с согласующим, если он не является включающим.
Список управляемых точек исполнения для тестирования — deploy apply, orchestration fire, voice open, model execution, budget spend, плюс любые пользовательские поверхности, которые вы подключили.

Шаг 1: Включите аварийный выключатель

Включающий активирует аварийный выключатель с обязательной строкой причины:

# API-вызов — подставьте свой хост, порт и заголовок авторизации.
curl -X POST https://<host>/v1/kill-switch/engage \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "scheduled quarterly drill"}'

Включение намеренно дёшево: уровень admin, причина, без кворума согласования, без повышения, без экстренного обхода. Запись остановки становится единственным источником истины. Каждый управляемый шлюз исполнения обращается к ней в реальном времени при каждом действии и завершается отказом при ошибке чтения.

В той же транзакции, что и включение, каждое ожидающее согласование исполнения отменяется — намерение, существовавшее до остановки, не может превратиться в грант в момент возвращения окружения. Запишите временную метку; вы проверите журнал позже.

Шаг 2: Проверьте отказы

С включённым аварийным выключателем попытайтесь выполнить каждое управляемое действие, подключённое к вашему окружению. Каждое должно вернуть отказ.

Точки исполнения для тестирования:

Точка	Что попытаться	Ожидаемый результат
Deploy	`POST /v1/deploy/apply` с валидным планом	Отказано
Orchestration	`POST /v1/orchestration/fire`	Отказано
Voice	`POST /v1/voice/open`	Отказано
Model execution	Любой инференс или вызов модели через управляемый путь	Отказано
Budget spend	Любое действие расхода через бюджетные шлюзы	Отказано

Протестируйте каждую точку, подключённую к вашему окружению. Если у вас есть пользовательские поверхности исполнения, подключённые через ядро управления, включите и их.

Также проверьте, что должно продолжать работать:

Остановка останавливает агентное окружение, но не контроли, которые им управляют. Действия управления остаются доступными:

Чтение карты доступа — GET /v1/access-map должен возвращать нормально.
Просмотр аудиторского журнала — GET /v1/audit/export должен возвращать журнал, включая событие включения, которое вы только что создали.
Список согласований — очередь согласований доступна для чтения; ранее ожидавшие согласования должны отображаться как отменённые.

Если какая-либо точка исполнения возвращает что-то отличное от отказа, или если какое-либо действие управления заблокировано, остановите учения и расследуйте. У аварийного выключателя есть пробел.

Шаг 3: Повторно включите окружение

Повторное включение никогда не является односторонним. Требуется новое согласование с двойным контролем на уровне critical: два различных человека, структурно перепроверенных при включении. Намеренно нет пути экстренного обхода для повторного включения — «окружение остаётся остановленным» является безопасным состоянием.

Включающий (или любой admin) запрашивает повторное включение:

curl -X POST https://<host>/v1/kill-switch/re-enable \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "drill complete, restoring estate"}'

Это создаёт запрос на согласование уровня critical. Два согласующих — каждый отдельный человек, ни один не использующий системный токен — должны каждый согласовать через POST /v1/approvals/<request-id>/decide с {"decision": "approve"}. Минимум двойного контроля обеспечивается на стороне сервера: защита от дублирования решающих не позволяет одному человеку засчитаться дважды, а системный токен отклоняется (нет человеческой гарантии). Даже если уровень политики понижен, структурный минимум сохраняется — действие critical не может пройти с одним согласующим. Как только оба согласования получены, окружение включается.

Шаг 4: Проверьте восстановление

Повторите каждую попытку исполнения из шага 2. Каждая теперь должна завершиться успешно (разрешено или маршрутизировано в обычный процесс согласования). Если какая-либо точка остаётся отклонённой после повторного включения, повторное включение не распространилось полностью — расследуйте перед подписанием результатов учений.

Шаг 5: Закройте пост-ревизию

Принудительная пост-ревизия незаинтересованным человеком структурно требуется перед следующим включением аварийного выключателя. Ревизор должен быть кем-то, кто не был включающим:

curl -X POST https://<host>/v1/kill-switch/post-review \
  -H "Authorization: Bearer <reviewer-token>" \
  -H "Content-Type: application/json" \
  -d '{"notes": "drill verified: all seams denied, re-enable required dual-control, restoration confirmed"}'

Пока эта ревизия не закрыта, последующее включение аварийного выключателя заблокировано. Это по замыслу — нельзя накапливать включения, чтобы избежать контроля.

Что проверить в журнале

После учений экспортируйте аудиторский журнал и проверьте полный след:

olivares audit export --format json --since <drill-start-timestamp>

Журнал должен содержать по порядку:

Событие включения — admin, причина (“scheduled quarterly drill”), временная метка и уровень гарантии включающей сессии.
Отмены согласований — каждое ожидавшее согласование, отменённое в той же транзакции, что и включение.
События отказов — по одному на каждую попытку исполнения, которая была отклонена во время остановки.
Запрос на повторное включение — запрос на согласование уровня critical.
Два решения согласования — по одному на каждого согласующего, каждое указывающее отдельную человеческую идентичность.
Событие повторного включения — окружение восстановлено.
Событие пост-ревизии — незаинтересованный ревизор, их заметки, временная метка закрытия.

Каждая запись несёт поля целостности цепочки (seq, prev_hash, hash, sig). Отсутствующая или не по порядку запись означает, что в журнале есть пробел — расследуйте, прежде чем доверять ему в реальном инциденте.

Периодичность

Проводите учения ежеквартально. Аварийный выключатель — последняя линия обороны; если у него есть пробел, вы хотите найти его в запланированном окне, а не во время инцидента. Добавьте учения в ваш операционный календарь наряду с другими упражнениями непрерывности (восстановление из бэкапа, переключение на резерв, активация экстренного обхода).

Если ваше окружение существенно изменилось — подключены новые точки исполнения, настроены новые тенанты, заменён движок политик — проведите внеплановые учения для покрытия новой поверхности.

Связанные материалы

Управление — модель авторизации, уровни риска и дизайн аварийного выключателя.
Аварийный выключатель — шлюз запрета на уровне всего окружения в терминах продукта.
Управление и согласование — рабочий процесс согласования и механика двойного контроля.