Кулінарна книга: навчання з аварійним вимикачем

Проведення безпечного навчання з аварійним вимикачем на непродакшн середовищі — увімкнення загальної зупинки, перевірка відмови через усі точки виконання.

Аварійний вимикач — це загальний шлюз заборони. Увімкнення його навмисно дешеве — рівень 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). Відсутній або не по порядку запис означає, що журнал має прогалину — розслідуйте перед тим, як довіряти йому при реальному інциденті.

Частота

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

Якщо ваша інфраструктура суттєво змінюється — нові точки виконання підключені, нові орендарі налаштовані, рушій політик замінений — проведіть позапланове навчання для покриття нової поверхні.

Пов’язане

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