Випуск і експлуатація

Виробничі інциденти: від першого сигналу до перевіреного відновлення

Сповіщення каже, що щось змінилося; воно ще не пояснює, кому саме зашкодило, що робити першою дією і чи вже повернулася послуга. У главі 61 ми навчилися…

Глава 62Заморожене українське видання

Сповіщення каже, що щось змінилося; воно ще не пояснює, кому саме зашкодило, що робити першою дією і чи вже повернулася послуга. У главі 61 ми навчилися пов’язувати метрики, журнали й траси з користувацьким досвідом. Тепер використаємо ці докази під тиском часу: домовимося про серйозність за впливом, організуємо роботу людей, зменшимо шкоду, перевіримо відновлення та передамо незакриті ризики.

Навчальний результат. Після цієї глави читач може оголосити й описати інцидент без передчасного висновку про причину; відрізнити встановлений факт від гіпотези; призначити координатора, технічного керівника, відповідального за комунікацію, хронологію та ризик; вибрати обмежену міру пом’якшення; перевірити користувацький результат, дані й черги після неї; а також визначити, що має залишитися у відкритих справах після закриття інциденту.

Межі тут навмисно практичні. Попередня глава описала сигнали, пороги й сповіщення; ця пояснює живу координацію після сигналу. Глава 63 розгляне заздалегідь підготовлені покрокові процедури, а глава 64 — повний розбір і навчання після інциденту. Приймання рішення про реліз, стратегії розгортання та відкат уже розглянуто в главах 59–60. Під час інциденту команда може скористатися відомим способом зупинити випуск або повернути безпечну поведінку, але не варто перетворювати цю главу на загальний посібник з розгортання.

Наведені нижче сценарії про бронювання, зовнішній інтерфейс та агента є вигаданими навчальними прикладами. Числа, назви систем і часові позначки в них вигадані й не є продуктовими межами чи універсальними порогами. Окремо розібрано реальний публічний звіт Amazon Web Services (AWS — хмарні сервіси Amazon) про подію в регіоні Північна Вірджинія у жовтні 2025 року; факти про неї приписані самому звіту AWS.

62.1. Інцидент — це стан роботи, а не назва винуватця

Виробничий інцидент — це незапланований стан послуги, який потребує скоординованої реакції, бо впливає або може невдовзі вплинути на людей, дані, фінансові операції, безпеку чи іншу важливу властивість продукту. Команда може оголосити інцидент до того, як знає причину. Наприклад, масові тайм-аути оформлення замовлення після випуску є достатньою підставою зібрати чергових; для цього не треба спершу довести, що винен останній commit.

Окрема помилка не завжди є інцидентом. Невдала спроба одного користувача може бути звичайною помилкою введення. Але низка однакових невдач, непідтверджений стан платежу або підозра на пошкодження даних потребують координації навіть тоді, коли загальна доступність головної сторінки не змінилася. І навпаки, гучний графік серверної помилки не завжди є тяжкою подією, якщо інші шляхи працюють, повтор безпечний, а користувачів не зачеплено.

Серйозність визначає масштаб і характер впливу, а не те, хто змінив код і наскільки складно пояснити збій. Оцінюйте щонайменше:

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

Для однієї організації «висока серйозність» може означати повну неможливість провести платіж; для іншої — неприпустиме відставання критичного потоку даних. Google Site Reliability Engineering (SRE — інженерія надійності послуг) також застерігає, що серйозність залежить від продукту та його користувачів, а не має одного набору порогів для всіх служб. Тому назви на кшталт «критичний», «значний» чи «обмежений» корисні лише тоді, коли команда наперед пов’язала їх із конкретним впливом, часом реакції та способом ескалації. Не вигадуйте загальноприйняте значення для «Sev 1»: «Sev» скорочує англійське severity («серйозність»), а номер задає локальну градацію. Google SRE: Product-focused reliability for SRE

Зручне початкове формулювання звучить так: «Ми бачимо [симптом] у [частині продукту] з [часу]; під впливом можуть бути [група або обсяг]; [важлива дія] зараз [стан]; причина поки невідома; наступну оцінку дамо о [час за координованим всесвітнім часом (Coordinated Universal Time, UTC)]». Воно дозволяє оголосити реакцію чесно, не підміняючи спостереження теорією.

62.2. Дайте роботі структуру, перш ніж людей стане більше

Під час невеликої події одна людина іноді здатна і досліджувати, і змінювати систему, і відповідати на запитання. Коли з’являються кілька каналів, залежностей або ризикових рішень, ця людина легко втрачає загальну картину. Практика SRE у Google та PagerDuty адаптує ідеї Incident Command System (системи командування інцидентами, ICS), щоб відокремити координацію від технічної роботи. Це корисний зразок, а не обов’язкова організаційна схема для кожної команди. Google SRE Workbook: Incident Response

Розподіліть ключові відповідальності між учасниками. Одна людина може поєднати кілька ролей, якщо це безпечно; один координатор має тримати цілісне рішення про пріоритети та наступні кроки. Для кожної зміни у виробничій системі призначайте одного виконавця: він відповідає за точну ціль, межу, послідовність кроків і звіт про результат. Фахівці можуть радити, а координатор погоджує ризик; для ризикової зміни окремий перевіряльник звіряє передумови й побічні ефекти, не виконуючи ту саму зміну.

Відповідальність	Що вона робить під час інциденту	Типове формулювання
Координатор реакції	Оголошує режим роботи, визначає потрібних людей, розставляє пріоритети, погоджує ризиковані кроки, стежить за часом і передає командування.	«Ми розслідуємо; до 14:20 не збільшуємо частку нового випуску».
Технічний керівник	Підтримує технічну модель, призначає окремі перевірки, пропонує міру пом’якшення та звіряє її результат за визначеним сигналом.	«Перевірте новий маршрут у регіоні B; не запускайте повторні списання».
Відповідальний за комунікацію	Готує зрозумілі й регулярні повідомлення підтримці, керівництву та, якщо потрібно, користувачам.	«Підтверджено лише затримки; стан платежів ще перевіряємо».
Ведучий хронології	Фіксує UTC-час, спостереження, гіпотези, рішення, їхніх власників та результат. Не переказує кожне повідомлення без розбору.	«14:11 UTC — вимкнули новий прапорець; частка помилок ще не змінилася».
Виконавець зміни	Виконує одну погоджену зміну в заданих межах і повідомляє, що фактично змінилося.	«14:13 UTC — нова ревізія більше не отримує трафік; контролер це підтвердив».
Власник ризику / незалежний перевіряльник	Перевіряє передумови й межі ризикової зміни, наявність умови зупинки та план перевірки побічних ефектів; не виконує ту саму зміну.	«Перед повтором упевнитися, що зовнішня система не прийняла попередній запит».

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

Поділ ролей не означає бюрократію. Він звільняє технічного фахівця від постійного перемикання між діагностикою й поясненням статусу, а координатору дає змогу помітити, що команда робить надто багато одночасних змін. У роботі з людьми корисно думати мовою Peopleware: які умови допомагають фахівцям зосереджуватися і приймати рішення разом? Продуктивність інцидентної команди — це здатність зменшити користувацьку шкоду й відновити довіру до сервісу, а не рейтинг окремих людей за кількістю повідомлень або комітів. DeMarco і Lister, Peopleware, 3-тє видання

62.3. Зробіть часовий запис придатним для рішення

Живий журнал інциденту потрібен не для красивого звіту. Він має відповісти новому учаснику на запитання: що знаємо, що припускаємо, що вже змінювали та що перевірятимемо далі. Усі часові позначки в записі узгоджуйте до єдиної шкали UTC і зберігайте номер випуску, конфігурації чи іншої ревізії там, де це має значення.

Мінімальний запис для кожного важливого повороту:

Час UTC	Клас запису	Зміст	Власник / джерело	Наступна перевірка
14:02	Спостережений факт	31 із 210 спроб підтвердження бронювання завершилися тайм-аутом за останні 5 хвилин; попередні 5 хвилин — 2 з 198.	Панель успішності оформлення	Перевірити розріз за ревізією й регіоном о 14:07
14:05	Факт із журналу	У невдалих трасах є повторна перевірка доступності після запису резерву; невідомо, чи повторний запит змінює цей самий запис.	Технічний керівник	Звірити контракт транзакції з власником бронювання
14:08	Гіпотеза	Нова перевірка стану могла збільшити час транзакції.	Інженер випуску	Порівняти стару й нову ревізію на однаковому шляху
14:10	Рішення	Зупинити поступове збільшення нового випуску, поки стан записів не підтверджено.	Координатор	Повторна оцінка о 14:15

Факт — те, що прямо видно в джерелі з указаним часом, вибіркою й межами. Гіпотеза — перевірюване пояснення, яке може бути хибним. «Помилка з’явилась після релізу, отже винен реліз» — не факт; це причинна гіпотеза. «На ревізії 4.8.2 частка тайм-аутів вища, ніж на 4.8.1, у тій самій функції та за той самий проміжок» — спостереження, якщо саме так сформовано запит і його вибірка. Позначайте, чи показник включає успішні операції, повторні спроби, затримані завдання та всі регіони; інакше сам відсоток можна витлумачити по-різному.

Час потрібен також для відновлення причинного порядку. Система моніторингу, клієнт, база та зовнішній провайдер можуть мати різні годинники й часові зони. Зберігайте час джерела й нормалізований час, якщо джерело має невідому похибку; не вдавайте, що всі події в одну секунду відбулися строго в послідовності журналу. Додайте посилання на графік, журнал або трасу, але не копіюйте до загального каналу приватний вміст чи секрети.

Хронологія має розрізняти дві події: «команду віддали» й «цільовий стан підтверджено». Якщо координатор попросив зупинити випуск о 14:10, а контролер показав нульову частку трафіку на новій ревізії о 14:13, це два рядки. Так само «скрипт повідомив про успіх» не доводить, що користувацький потік відновився.

62.4. Тріаж: спершу встановіть масштаб, потім вибирайте дію

Тріаж — це швидке впорядкування невизначених проблем за терміновістю та впливом, щоб команда спрямувала обмежену увагу туди, де зволікання найдорожче. Він не означає встановити кореневу причину за п’ять хвилин. Початкова послідовність часто така:

Оголосіть подію й назвіть координатора. Вкажіть симптом, час початку, потенційний вплив, канал координації й час наступного оновлення.
Перевірте, що саме переживає користувач. Візьміть показник важливої дії, сегментуйте за функцією, регіоном і ревізією. Не робіть висновку лише з доступності вебсервера.
Позначте ризик незворотного наслідку. Чи міг повтор запиту списати гроші двічі? Чи міг імпорт перезаписати правильний стан? Чи чекають люди на критичну відповідь?
Перевірте коротку хронологію змін. Новий випуск, конфігурація, ротація секрету, зміна постачальника або зростання навантаження — важливі кореляції, але не автоматичний доказ причини.
Оцініть, чи шкода росте. Подивіться на нові невдачі, довжину й вік черги, час оброблення, повтори, відставання реплік та часткову успішність.
Виберіть наступний крок, який можна перевірити й безпечно обмежити. Розділіть «зменшити вплив» і «знайти причину»; не чекайте повного пояснення, якщо є оборотний спосіб зупинити очевидне зростання шкоди.

Цілі рівня сервісу (Service Level Objective, SLO — цільовий рівень якості послуги) і показник рівня сервісу (Service Level Indicator, SLI — вимір фактичної якості) можуть допомогти зрозуміти відхилення від очікуваного досвіду, якщо продукт уже визначив їх для цієї дії. Але самі числа треба перекласти на наслідок: скільки заявок залишилося непідтвердженими; чи доступна альтернативна дія; чи збільшується строк затримки. Порогові значення однієї команди не стають стандартом для іншої.

За часткового збою сервіс може відповідати на частину запитів, приймати операції, але відкладати їх, або показувати застарілий стан. Такий збій складніший за повну недоступність, бо загальна середня може приховати малий, але важливий сегмент. Розгляньте розбиття за критерієм, що відповідає шляху дії: тип платежу, постачальник, зона, клієнтський сегмент, тип черги. Не додавайте необмежені персональні ідентифікатори в телеметричні мітки: конкретні операції краще шукати за контрольованим ідентифікатором у системі з належним доступом.

62.5. Пом’якшення шкоди — окреме рішення від пошуку причини

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

Перед зміною сформулюйте чотири речі:

ціль: що саме треба повернути чи захистити;
межа: які компоненти, дані, трафік або люди будуть зачеплені;
очікуваний сигнал: за якою ознакою побачимо поліпшення і коли;
умова зупинки або повернення: що робимо, якщо побічний ефект виявиться гіршим.

Якщо існує можливість, що зовнішній виклик до програмного інтерфейсу застосунку (Application Programming Interface, API) уже завершився, але відповідь загубилась, не трактуйте тайм-аут як «операція не відбулася». Спершу перевірте ідентифікатор операції або стан у системі-джерелі; повторюйте дію лише якщо контракт ідемпотентності чи інший контроль дублів це дозволяє. Ідемпотентна дія — операція, безпечне повторення якої не створює додаткового ефекту, якщо система гарантує цю властивість для потрібного ключа та періоду. AWS Builders’ Library пояснює, чому стабільний токен і чіткий контракт потрібні для безпечних повторів; сама наявність такого токена в запиті не гарантує правильності всієї операції. AWS Builders’ Library: Making retries safe with idempotent APIs

Під час деградації залежності необмежений повтор здатен збільшити її навантаження й погіршити ситуацію. Документація AWS рекомендує контролювати та обмежувати повторні виклики; у конкретній архітектурі можуть застосовуватись обмеження числа спроб, затримка зі збільшенням інтервалу, випадкове розсіювання часу повтору, ліміти конкуренції, черги та переривник запитів. Це інженерні механізми, а не магічний набір параметрів: перевірте, скільки рівнів повторюють виклик, чи є дедлайн, чи може провайдер виконати запит попри тайм-аут, і чи справді відомий стан результату. Налаштування однієї клієнтської бібліотеки не є універсальним правилом для всіх систем; бібліотеки та версії змінюються. AWS Well-Architected Framework: Control and limit retry calls

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

62.6. Діагностуйте з доказами, не з першою переконливою історією

Після обмеження шкоди шукайте пояснення, яке узгоджується з кількома незалежними сигналами і може бути спростоване. Відомості глави 61 тепер працюють разом:

метрики показують масштаб, розріз, тривалість і напрямок зміни;
журнали дають події конкретної операції та її стан переходу;
траси допомагають побачити, де витратився час і яка залежність повернула помилку;
версії й конфігурації показують, що змінювалося поруч у часі;
бізнес-перевірки відповідають, чи відбулася цільова дія, а не лише чи повернув сервер відповідь.

Для кожної гіпотези запитайте: який сигнал мав би змінитися, якщо вона правильна; що спростує її; який сегмент не охоплено; яка операція могла зафіксуватися попри тайм-аут; чи є відставання між основною копією й реплікою; чи накопичена черга потребуватиме окремого відновлення? Під час перевірки виберіть найбезпечніше порівняння — наприклад, стару й нову ревізію на однаковому маршруті та регіоні, а не загальну середню до й після різкого зростання трафіку.

Залежності створюють часткові відмови: частина вузлів або операцій працює, інша частина затримується чи падає. Якщо завдання не встигає завершитись до строку оренди, система може призначити його знову; якщо перший працівник усе ще працює, з’являться паралельні спроби. Якщо клієнт не відрізняє тайм-аут від відмови, він може повторити створення замовлення. Якщо повторюють і бібліотека, і сервіс, і черга, множинність зростає по шарах. Отже, діагностуйте не тільки кінцеву залежність, а й місце, де рішення про повтор було прийнято.

Черга корисна як буфер, але вона не поглинає нескінченну роботу. Порівняйте швидкість надходження зі швидкістю обробки та вік найстарішого елемента. Зменшення довжини черги не завжди означає успіх: це може бути масове відхилення або видалення завдань. Якщо сервіс частково відновився, надто швидкий випуск відкладеної роботи здатен перевантажити його знову. Повторні завдання мають зберігати ідемпотентність, обмеження конкуренції та видимість помилок остаточної обробки. Висновок глави не в тому, що «чергу завжди треба осушити швидше», а в тому, що її вплив треба вимірювати окремо від доступності головного запиту.

Системний каскад виникає, коли деградація одного компонента підвищує навантаження на інші, ті затримуються, запускають повтори, а їхня черга чи ресурсні ліміти спричиняють нову деградацію. Тому операційний план має відповідати одразу на два запитання: який вхід тимчасово обмежити, щоб зупинити зростання черги; і за якою умовою можна відновлювати пропускну здатність поступово. Не маскуйте первинну помилку нескінченними повторними спробами. Розподілені системи мають неоднозначні результати, затримки та незалежні стани компонентів; як довідкову рамку для цих проблем можна читати Designing Data-Intensive Applications, 2-ге видання. Тут це рекомендована література, а не джерело конкретної процедури чи цитати з книжки. Martin Kleppmann і Chris Riccomini: Designing Data-Intensive Applications, 2nd edition

62.7. Відновлення — це стан користувача й даних, а не зелений сервіс

Після кожного пом’якшення перевірте кінцевий шлях, який бачили люди. Якщо інтерфейс став доступним, чи пройшла повна дія до підтвердження? Чи отримала людина правдивий стан і чи не потрібно її спонукати натиснути ще раз? Якщо фонове завдання знову береться в роботу, чи завершуються нові елементи, а старі — з відомим результатом?

Відновлення має принаймні чотири незалежні площини:

Площина	Що підтвердити
Нові операції	Успішність, затримка та помилки важливої користувацької дії повернулися до прийнятного для цього продукту стану.
Операції, що вже відбувалися	Немає подвійних списань, дубльованих записів, завислих переходів або невідомого результату без власника.
Відкладена робота	Черга, найстаріше завдання й відставання рухаються без повторного перевантаження; збої не приховано видаленням.
Дані й залежності	Репліки, індекси, кеші, зовнішній постачальник і контрольні підсумки узгоджені настільки, наскільки вимагає продукт.

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

«Відкат завершено» — це повідомлення про дію інженера, не про успіх користувача. Новий сервіс може перестати отримувати помилку від залежності, а сформована за попередні години черга залишиться. Аналогічно відновлена репліка може надолужити записи, але ще не відновити звіт, який люди бачили в кеші. Розділяйте стан інфраструктури, бізнес-операцію та дані. Якщо потрібен повторний імпорт чи компенсаційне виправлення, зафіксуйте окремий власник, часову межу, дозвіл на зміну й перевірку результату.

62.8. Підтримуйте спільну картину й повідомляйте без перебільшень

Google SRE описує три завдання управління інцидентом: координувати роботу, передавати інформацію й утримувати процес керованим. Практично це означає коротку регулярну комунікацію зі зрозумілою аудиторією. Технічний канал містить точні спостереження й план діагностики; внутрішня аудиторія отримує вплив, стан, обхідний шлях та час наступного повідомлення; зовнішнє повідомлення публікується уповноваженою людиною за правилами організації. Google SRE Workbook: Incident Response

Корисне оновлення має відповідати на чотири питання: що вже відомо; хто або що зазнає впливу; яку дію вжито чи перевіряють; коли буде наступне оновлення. Наприклад: «Від 14:02 UTC частина нових бронювань затримується після надсилання форми. Підтвердження вже створених бронювань ми перевіряємо окремо. Збільшення нового випуску зупинено; наступну інформацію надамо о 14:20 UTC. Поки що не надсилайте повторно заявку зі сторінки, де з’явилося повідомлення “перевіряємо результат”». Такий текст описує актуальне спостереження, а не обіцяє точний час повного відновлення без доказу.

Не пишіть «усі дані безпечні», якщо звірено лише частину запитів. Не називайте гіпотезу причиною. Не приховуйте частковий вплив за фразою «деякі користувачі», коли команда вже має обґрунтований сегмент або приблизний масштаб. Якщо масштаб невідомий, прямо скажіть це й коли його оцінять. Внутрішня комунікація теж має бути достовірною: координатору потрібні повідомлення про невдалу дію й побічний ефект, навіть якщо перше припущення виявилося помилковим.

Передачу чергування зробіть явною: хто від кого приймає роль координатора, який поточний стан, які рішення вже прийняті, що не можна повторювати, що перевірять наступним і о котрій годині. Новий координатор підтверджує прийняття ролі, перш ніж попередній виходить. Це зменшує ймовірність, що два фахівці окремо віддадуть суперечливі накази або критична гіпотеза загубиться між змінами.

Погляд Accelerate корисний як рамка спільної здатності команди безпечно доставляти зміни й відновлювати роботу. Цю главу не слід перетворювати на таблицю індивідуальних винуватців або рейтингів під час інциденту. Окремі метрики можуть допомогти команді оцінити, де застрягає її шлях доставки або реакції, але інцидентний канал не є оцінкою продуктивності конкретного працівника. Книжку наведено як подальше читання про організаційні результати й поліпшення команди, а не як джерело універсального протоколу реагування. Forsgren, Humble і Kim: Accelerate

62.9. Агент може зібрати докази, але повноваження належать середовищу

Агент корисний для підготовки хронології, зведення журналів, сегментації помилок і формулювання кількох перевірюваних гіпотез. У висновку він має чітко відділяти спостережені факти від інтерпретації, вказувати джерело, часову межу та прогалину. Наприклад: «У 18 вибраних трасах після ревізії 4.8.2 збільшився час очікування сервісу підтвердження; вибірка охоплює регіон A, а не всі регіони. Це узгоджується з гіпотезою про затримку залежності, але не встановлює причину. Наступна безпечна перевірка — зіставити трасу до релізу на тому самому маршруті».

Для такого розслідування достатньо доступу лише для читання до телеметрії, стану операцій і журналу аудиту. Доступ до запису в production за замовчуванням агенту не потрібен: якщо зміна справді необхідна, її точна ціль, середовище та наслідки мають бути показані названому відповідальному до виконання. Політика, яка може самостійно дозволити інструменту «безпечний» виклик, не тотожна людському погодженню. Тому для високоризикової дії вимагайте явного підтвердження уповноваженої людини; без доступного каналу підтвердження дію не виконуйте.

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

Поведінка залежить від продукту та його конфігурації. Документація OpenAI Agents SDK (Software Development Kit — комплект для розробки програмного забезпечення) описує переривання запуску для затвердження чутливої дії та відновлення того самого стану запуску після рішення. Вона радить розміщати перевірку поруч із засобом, що створює побічний ефект. Це інструкція для конкретного SDK та застосунку, а не гарантія про кожен агент OpenAI, Codex або будь-яке середовище. OpenAI: Guardrails and human review

Документація Anthropic про Managed Agents позначає ці правила як бета-можливість конкретної платформи. Вона розрізняє автоматичний дозвіл, очікування підтвердження та серверну оцінку; власні інструменти, які виконує застосунок, керуються самим застосунком, а не цими політиками. Отже, назва режиму дозволів в одному продукті не доводить наявність аналогічного бар’єра в іншому. Перевіряйте саме конфігурацію середовища, в якому працює агент, і місце виконання інструмента. Anthropic: Managed Agents permission policies

Якщо виклик інструмента повернув тайм-аут або агент перервався після запису, результат може бути невідомим. Не повторюйте побічну дію навмання. Спочатку з’ясуйте стан за ідентифікатором операції, журналом аудиту чи джерелом істини. Потім вирішіть, чи завершився попередній виклик, чи безпечний повтор за визначеним ключем і контрактом. Проблеми доставки відповіді та виконання команди — не одне й те саме: втрачена відповідь не скасовує вже створений платіж або запуск процесу. Такий принцип стосується і людського виконавця після втрати з’єднання.

62.10. Розбір 1 — після випуску не підтверджуються бронювання

Вигадана навчальна ситуація. Онлайн-сервіс бронювання випустив ревізію 4.8.2 о 14:00 UTC. До цього клієнтський екран показував завершення успішно у 98% спроб. Через кілька хвилин черговий отримав сигнал про 15% тайм-аутів підтвердження за п’ять хвилин. Точні числа в цьому сценарії умовні; вони не задають поріг для реального продукту.

Координатор о 14:06 оголошує інцидент та просить зупинити розширення випуску. Технічна людина перевіряє метрику завершення повного шляху, журнал станів бронювання та траси повільних запитів. Вони бачать, що помилка зосереджена в новій ревізії, але поки не знають, чи кожен тайм-аут означає, що бронювання не створилося. Власник даних перевіряє журнал підтверджених і очікуючих записів, не запускаючи повторного створення замовлень.

Команда спершу не надсилає користувачам інструкцію натиснути «бронювати» знову: через невідомий стан це могло створити дубль. Підтримка отримує короткий сценарій відповіді: повідомити, що стан заявки перевіряють, попросити не надсилати дубль і записати контрольний ідентифікатор звернення. Координатор фіксує у хронології, що ревізію зупинено, але не називає її доведеною причиною.

О 14:14 перевірка показує, що нова ревізія додає синхронну перевірку зовнішнього розкладу після створення тимчасового резерву. У частині трас перевірка затягується; транзакція ще не підтверджує бронювання, але тимчасовий резерв уже існує. Команда відкотила лише нову поведінку, яка додає перевірку після резерву, залишивши код запису й безпекову перевірку без змін. Це обмежена гіпотеза про корисну міру пом’якшення, а не доказ остаточної причини.

Після зміни технічний керівник перевіряє нові бронювання на старому шляху, а власник даних окремо звіряє тимчасові резерви з підтвердженнями. Протягом вигаданих 15 хвилин команда встановлює, що нові заявки знову підтверджуються, незавершені резерви відомі, дубльованих активних бронювань не виявлено у перевіреному наборі, а кілька заявок потребують ручного узгодження. Користувачам повідомляють лише перевірені результати та час наступного оновлення.

Чому це рішення підходить тут. Команда пом’якшила вплив, не повторювала невизначену операцію та окремо перевірила нові й уже розпочаті заявки. Лише після відновлення маршруту вона може спокійно порівнювати трасування та код. Якщо би тайм-аути виникали також у старій ревізії або в усіх маршрутах одночасно, зміна клієнтського випуску могла б не допомогти; тоді наступним кроком стало б дослідження залежності розкладу чи бази. Результати ручного узгодження, підтримки та запобігання повтору переходять у відкриті дії, а не зникають разом із зеленим графіком.

62.11. Розбір 2 — повільний постачальник перетворив затримку на шторм повторів

Вигадана навчальна ситуація. Сервіс звітності отримує профілі клієнтів через зовнішній API. Постачальник повільно відповідає; з першої спроби клієнт чекає 8 секунд, а споживач черги має власний 10-секундний дедлайн. Бібліотека повторює виклик двічі, фоновий працівник повторює завдання ще раз, а планувальник через прострочений термін призначає його знову. Усі числа і послідовність вигадані.

О 09:20 UTC інцидент оголошують не через один графік зовнішньої затримки, а через три ознаки: завершено лише 61% нових звітів у межах продуктового очікування, найстаріше завдання в черзі стає старішим, а один і той самий ключ звіту має кілька активних спроб. Координатор призначає відповідального за зовнішню комунікацію, технічний керівник відокремлює клієнтські запити від повторного імпорту, а власник ризику перевіряє, чи запит постачальнику не створює платну операцію при повторі.

Першою мірою стає тимчасове обмеження швидкості нових звітів до третини звичайного потоку — суто вигадана межа цього прикладу. Правила повтору команда поки не змінює. Вона залишає читання вже отриманих даних, позначає стан нових звітів як «затримано», не говорить користувачам «дані недійсні» без доказу й надає час наступного оновлення. За п’ять хвилин приплив нових елементів у чергу спадає, але вік найстарішого завдання далі зростає; обмеження зменшило тиск, а не усунуло причину.

Після початкового обмеження технічний керівник переглядає журнали повторів. Вони показують, що один ключ звіту може одночасно запускатися клієнтською бібліотекою, фоновим працівником і планувальником; постачальник іноді завершує повільний запит уже після клієнтського тайм-ауту. Отже, проблема не лише в повільній відповіді: кілька локальних рівнів трактують невідомий результат як дозвіл створити ще одну спробу. О 09:32 UTC керівник зміни змінює один чинник — вимикає тільки повторне призначення планувальником після тайм-ауту. Лімітований повтор клієнтської бібліотеки не змінює. Після п’яти хвилин запис показує, що середня кількість одночасних спроб на той самий ключ знизилася з трьох до приблизно однієї, а приплив у чергу стабілізувався; завершення звітів усе ще повільне, тож команді немає підстав оголошувати відновлення.

Команда не подовжує загальний час очікування й не додає ключ дедуплікації під час живого інциденту: такі зміни вплинули б на ресурси й семантику повтору, а їхні наслідки ще не перевірено. Натомість перед будь-якою повторною дією вона перевіряє стан у постачальника за ідентифікатором запиту. Коли зовнішня система стабілізується, працівники відновлюють обробку черги малими порціями. Подовження дедлайну, наскрізний ключ ідемпотентності та додаткова метрика активних спроб стають окремими післяінцидентними змінами з власниками.

Черга не спорожнюється «в повну швидкість»: після підтвердження стабільності постачальника споживання відновлюють малими порціями, контролюючи час найстарішого елемента, конкуренцію та частку успішних звітів. Через затримку постачальника кілька елементів потребують остаточної повторної обробки; один звіт не можна безпечно повторити до підтвердження зовнішнього стану. Користувачі бачать повідомлення «обробка триває» з актуальним часом, а не фіктивний статус готовності.

Чому це рішення підходить тут. Команда відокремила початкове обмеження навантаження від зміни політики повтору, зачекала на спостережуваний результат після другої дії та відклала додаткові зміни до перевірки. Тому хронологія дає обмежену, але корисну інформацію про те, що зменшило дублювання; повільне завершення звітів усе ще потребує окремого пояснення. Якщо виклик постачальника є чистим читанням, підходить інша політика повтору, ніж для платних або незворотних операцій. Для останніх потрібні статусна перевірка й контракт ідемпотентності; збільшення backoff (затримки перед повтором) саме собою не робить повтор безпечним.

62.12. Розбір 3 — агент пропонує видалити «завислі» рядки

Вигадана навчальна ситуація. Агент прочитав журнали черги внутрішнього каталогу та побачив сім записів у стані processing понад 40 хвилин. Він рекомендує видалити ці рядки командою мовою структурованих запитів (Structured Query Language, SQL), а потім повторно запустити синхронізацію. Це лише приклад: назви таблиць, кількість і вік вигадані.

Інженер-черговий не виконує команду і не просить агента повторити її з іншими правами. Координатор просить провести читальну перевірку: які ідентифікатори завдань; коли вони перейшли в processing; який власник; які спроби й помилки видно; чи є відповідні об’єкти в зовнішньому сховищі; чи оновився lease (тимчасове право працівника обробляти завдання); чи з’явилися записи про завершення після тайм-ауту інструмента. Агент може підготувати запит на читання та пояснити його умови, але не має права видалення.

Хронологія показує, що шість записів дійсно неактивні й мають відповідний журнал завершеної обробки, але сьомий усе ще виконується у повільному зовнішньому процесі. Якби його видалили, зовнішня операція завершилася б без локального запису; повторне завдання могло б продублювати дію. Власник системи даних визначає підтримувану процедуру примирення стану: зберегти первинний запис, відновити статус підтверджених елементів і відкласти сьомий до перевірки результату постачальника. Якщо для ручного виправлення потрібен запис у базу, відповідальна людина розглядає точну зміну, резервний план і вивід контрольного запиту; агент її не виконує сам.

Окрема перевірка повертає тайм-аут після того, як агент надіслав запит на зміну стану тестового завдання. Команда не запускає той самий виклик повторно: спершу читає журнал аудиту й знаходить ідентифікатор операції, після чого встановлює, що тестове завдання вже оновлене. У продакшені перевірка виконувалася б за окремими повноваженнями та правилами доступу; сам факт, що другий виклик можна сформувати, не означає, що його безпечно повторити.

Чому це рішення підходить тут. Статус processing описує локальне спостереження, а не доводить, що запис зайвий. Читання джерела істини та зовнішнього ефекту передує виправленню; для кожної зміни відомі власник, точна ціль і перевірка. Якщо система надає офіційний механізм повторного захоплення застарілої оренди, його можна розглянути з власником даних і чіткою передумовою. Безпечніше не намагатися вручну «очистити» все, що довго не змінювалося.

62.13. Реальний розбір — DynamoDB відновився раніше за залежні потоки AWS

У звіті AWS про подію 19–20 жовтня 2025 року описано кілька пов’язаних, але окремих періодів впливу в регіоні us-east-1. AWS повідомляє, що проблема почалася з гонки стану в автоматизації керування записами системи доменних імен (Domain Name System, DNS), яка призвела до порожнього DNS-запису регіональної адреси DynamoDB і зупинила автоматичне виправлення. Часові позначки звіту наведено за тихоокеанським літнім часом (Pacific Daylight Time, PDT); далі залишено час саме так, як його публікує AWS. За повідомленням AWS, інженери визначили стан DNS як джерело основного збою о 00:38 PDT 20 жовтня; записи було відновлено о 02:25, а репліки глобальних таблиць наздогналися до 02:32. Через кешування DNS клієнтське підключення відновлювалося до 02:40. AWS: Summary of the Amazon DynamoDB Service Disruption

Проте відновлення DNS не означало, що всі залежні шляхи знову працюють. AWS пише, що в системі керування фізичними вузлами Amazon Elastic Compute Cloud (EC2) переривалися перевірки стану, після чого тимчасові оренди (leases) вузлів почали спливати. Коли DynamoDB знову стала доступна, відновлення оренд створило велику чергу; через чергу й повтори компоненти не встигали просуватися. AWS зазначає, що о 04:14 інженери обмежили вхідну роботу й вибірково перезапустили частину керувальних вузлів, що допомогло відновити просування оренд. До 05:28 оренди було відновлено й нові запуски EC2 почали проходити, хоча обмеження запитів і відкладене поширення мережевої конфігурації ще впливали на відновлення. Повністю систему EC2 відновили о 13:50 PDT. AWS: Summary of the Amazon DynamoDB Service Disruption

У звіті також описано вплив на інші залежні потоки, включно з обробкою повідомлень і затриманими чергами. Це важлива межа поняття «сервіс відновлено»: DNS-адреса відповідає, але оренди, черги, мережеве поширення, ліміти й операції, що накопичилися за час збою, живуть у власних підсистемах. Навіть якщо первинний компонент знову доступний, ці стани треба перевірити окремо та відновлювати з темпом, який не запускає новий каскад. AWS: Summary of the Amazon DynamoDB Service Disruption

Цей кейс підтверджує конкретне міркування: виявити й усунути первинний збій — це не те саме, що відновити кожного споживача його залежностей. Це висновок із послідовності, яку наводить AWS, а не твердження, що будь-який інцидент має таку структуру. У власній системі перевіряйте окремо кореневий сервіс, його споживачів, черги, повтори, репліки, нові й уже наявні операції. Не приписуйте AWS число постраждалих клієнтів чи незалежно підтверджену тривалість: джерелом наведених тут фактів є власний публічний звіт компанії.

62.14. Закриття інциденту й передача наступної роботи

Координатор може закрити активний режим реакції, коли команда підтвердила достатню стабільність користувацького шляху за перевірками §62.7, основний ризик більше не зростає, а незавершені операції та побічні ефекти мають власників. Закриття не означає, що кожне виправлення вже поставлено у код або що причина вичерпно пояснена. Воно означає, що для кожної відомої залишкової роботи є явне рішення: виконати зараз, передати в окрему справу, прийняти ризик визначеним власником або відкласти з обґрунтуванням.

Перед завершенням узгодьте такі пункти:

яка зміна або дія пом’якшила поточний вплив і коли її результат перевірено;
що саме бачать користувачі тепер, включно з відомими обмеженнями;
чи є непідтверджені, дубльовані, застряглі або відкладені транзакції;
який залишок у чергах та чи безпечно відновлювати звичайне навантаження;
які часові графіки чи підсистеми ще не повернулися до норми;
хто володіє кожною відкладеною дією, коли вона буде перевірена та яка умова її завершення;
кому потрібне завершальне повідомлення і який канал залишається відкритим для підтримки.

Залиште стислий підсумок для людей, які не були на дзвінку: початковий вплив; важливі часові позначки; що пом’якшило ситуацію; що ще невідомо; стан даних і черги; відкриті рішення. Повний аналіз причин та системних поліпшень належить главі 64. Цей підсумок лише зберігає матеріал, який інакше загубився б після завершення чергування. Розподіліть подальшу роботу між командами або власниками системи, а не між іменами, яким приписано провину.

Короткий підсумок

Інцидент оголошують за впливом і потребою в координації, навіть коли причина ще невідома. Одна людина тримає спільні пріоритети; технічна діагностика, комунікація, хронологія й власник ризику мають визначених відповідальних, хоча в невеликій команді ролі можна поєднати. Кожне твердження відокремлює спостереження від гіпотези та має час і джерело. Спершу обмежують зростання шкоди, потім перевіряють пояснення за метриками, журналами, трасами й ревізіями. Тайм-аут не доводить, що операція не відбулася; повтор безпечний лише за зрозумілою семантикою. Повернення сервісу не доводить, що користувацькі операції, дані, черги й залежності узгоджені. Агент може підготувати докази й запропонувати перевірку, але право на побічну зміну та підтвердження її результату залишаються за визначеним власником і правилами конкретного середовища.

Джерела та подальше читання

Онлайн-джерела перевірено 24 вересня 2026 року; звіт AWS і документацію OpenAI та Anthropic повторно звірено 10 жовтня 2026 року. Звіт AWS описує позицію постачальника щодо власної події; наведені факти подано з цією атрибуцією. Поведінка SDK, інструментів і платформ може змінюватися, залежить від версії та конфігурації; перед використанням звірте актуальну документацію свого середовища.

Google SRE Workbook, Incident Response — приклад структури координації, ролей, робочого запису та раннього оголошення; модель Google/PagerDuty подано як адаптований зразок, не обов’язкову схему для всіх команд.
Google SRE, Managing Incidents — розподіл відповідальності, живий запис стану та передача ролі.
Google SRE, Effective Troubleshooting — перевірка гіпотез, систематична діагностика та обережність із передчасним висновком.
Google SRE, Product-focused reliability for SRE — залежність критеріїв надійності й серйозності від продуктового впливу.
AWS, Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region — офіційний звіт про часові інтервали та залежні наслідки події 19–20.10.2025; перевірено 10.10.2026.
AWS Well-Architected Framework, Control and limit retry calls — рекомендації контролювати повтори; конкретні механізми залежать від клієнта й системи.
AWS Builders’ Library, Making retries safe with idempotent APIs — дизайн повторів і контракт ідемпотентності для API.
OpenAI, Guardrails and human review — затвердження в конкретному Agents SDK, переривання та розміщення перевірки на межі побічного ефекту; перевірено 10.10.2026.
Anthropic, Managed Agents permission policies — конкретна бета-модель політик інструментів Anthropic; налаштування власних інструментів залишається на стороні застосунку; перевірено 10.10.2026.
Tom DeMarco і Tim Lister, Peopleware, 3-тє видання, Addison-Wesley, 2013 — людські умови розробки та командної роботи; використано як концептуальну лінзу, не як протокол реагування.
Nicole Forsgren, Jez Humble і Gene Kim, Accelerate, IT Revolution, 2018 — організаційні спроможності та результати доставки; наведено для подальшого читання, без приписування книзі конкретної схеми інцидентних ролей.
Martin Kleppmann і Chris Riccomini, Designing Data-Intensive Applications, 2nd edition — подальше читання про розподілені системи й їхні межі; книжку не використано як доказ конкретного твердження цієї глави.