Відкат чи термінове виправлення під час інциденту

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

Дві серверні вежі з перерваним шляхом і безперервним маршрутом відновлення.

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

Перевірте межі змін

Порівняйте початок проблеми з випусками, конфігурацією, міграціями й провайдерами. Чи стара версія читає та записує нинішні дані? Руйнівна міграція або незворотна зовнішня дія може заблокувати просте повернення. Зберігайте докази, одночасно обмежуючи поточну шкоду.

Порівняйте способи відновлення

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

Дійте узгоджено

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

Приклад і доказ приймання

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

Часті запитання

Чи відкат завжди швидший?

Ні. Сумісність і дані можуть зробити його повільним або небезпечним.

Чи можна відкотити міграцію?

Лише правильним перевіреним шляхом для поточних даних.

Коли доречний hotfix?

За вузької доведеної причини та нижчого ризику, ніж альтернативи.

Чи кілька команд можуть діяти?

Так, за координації, що запобігає суперечливим змінам.

Коли завершити інцидент?

Після перевірки сервісу й даних та призначення залишкової роботи.

Від задуму до реалістичного обсягу робіт

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

Переглянути склад послуги →