Установіть безпечні межі самовідновлення
ЗавершеноАвтоматизуйте відомі дії відновлення з явними повноваженнями, перевіркою та умовами зупинки. Відокремлюйте відновлення під час виконання від зміни програмного забезпечення.
Видавець TaigaЯк ми пишемо
Перевірте своє розумінняКонтролер двічі перезапустив процес-обробник. Черга продовжує зростати, а база даних недосяжна. Що має зробити політика?Виконайте вправу
Чого ви навчитеся
- Відрізняти самовідновлення від постійного виправлення програмного забезпечення.
- Визначати обмежену політику відновлення та незалежні перевірки успіху.
- Розпізнавати, коли автоматизація має зупинитися й ескалувати проблему.
Відновлюйте відомий стан
Самовідновлення автоматично виявляє визначену відмову та намагається виконати дозволену дію відновлення. Приклади — перезапуск процесу, що зупинився, або заміна несправного екземпляра. Дія має відповідати відмові та моделі стану сервісу.
Kubernetes може замінювати несправні екземпляри навантаження та узгоджувати фактичний стан із задекларованим. Це не виправляє помилкової логіки застосунку або кожного збою сховища. Відновлення інфраструктури та правильність програмного забезпечення потребують різних перевірок. Самовідновлення Kubernetes.
Визначте ціль до механізму. Відновлення експорту означає, що дозволена робота правильно завершується. Запущений контейнер — лише одна передумова.
Розділіть три види змін
| Зміна | Приклад | Потрібне рішення |
|---|---|---|
| Відновлення під час виконання | Замінити один несправний процес-обробник без стану | Це може дозволяти попередньо схвалена політика відновлення |
| Виправлення програмного забезпечення | Виправити витік пам’яті, що зупиняє процес-обробник | Перегляд, тести, засоби контролю випуску та перевірка в продуктивному середовищі |
| Зміна політики | Збільшити дозволену частоту перезапусків або обсяг доступу | Явне схвалення відповідального за політику |
Агент може запропонувати виправлення після відновлення. Ця пропозиція — нова зміна програмного забезпечення. Вона не має успадковувати необмежених повноважень від контролера відновлення.
Контролер також не має змінювати власних критеріїв успіху, коли перевірка не проходить. Інакше система може повідомляти про поліпшення, не поліпшуючи сервісу.
Напишіть політику відновлення до її ввімкнення
Наведена політика вигадана. Її числа ілюструють проєктні рішення; це не рекомендовані типові значення.
| Поле політики | Вигадане правило процесу-обробника експорту |
|---|---|
| Умова запуску | Сигнал активності процесу-обробника відсутній 90 секунд і в черзі є робота |
| Передумови | Інший процес-обробник справний; перевірки залежностей успішні; немає підозри на компрометацію чи порушення цілісності |
| Дозволена дія | Замінити один процес-обробник, використовуючи поточний схвалений артефакт |
| Захист стану | Задачі використовують стійке сховище та перевірений ключ ідемпотентності |
| Ліміт | Щонайбільше дві заміни за 15 хвилин; ніколи не більше однієї одночасно |
| Пауза | Чекати п’ять хвилин після заміни до наступної спроби |
| Успіх | Синтетична задача правильно завершується, а уражена черга починає зменшуватися |
| Зупинка й ескалація | Будь-яка передумова не виконується, досягнуто ліміту або успіх неможливо перевірити |
Використовуйте ідентичність із мінімальними привілеями. Записуйте версію політики, докази умови запуску, дію, ресурс і результат. Надайте незалежний спосіб вимкнути контролер. Визначте відповідальну людину, яка отримує ескалацію.
Перевіряйте шляхи відмов так само, як успішне відновлення
Повторна спроба може повторити побічну дію. Процес-обробник може зберегти файл і зупинитися до підтвердження задачі. Перевірте ідемпотентність до дозволу нового виконання. Дивіться приклад відмови cloud native.
Повторні спроби також можуть посилювати перевантаження залежності. Використовуйте обмежені спроби, тайм-аути та належне збільшення затримки. Уникайте синхронізованих повторів у всьому наборі процесів. AWS пояснює, чому збільшення затримки та її випадкова варіація допомагають зменшувати це посилення. Рекомендації щодо повторних спроб.
Перевірте вигадану політику на трьох випадках. Один зупинений процес-обробник має відновитися. Збій бази даних має запобігати повторним замінам. Невизначене порушення цілісності має зупинити автоматизацію та запросити рішення щодо реагування.
Також перевірте відсутню телеметрію. Відсутність сигналу активності може означати несправний процес-обробник або несправний шлях збирання даних. Контролеру потрібні достатні для дії докази, а не впевненість у поясненні ШІ.
Вимірюйте, чи допомагає політика
Записуйте перевірені відновлення, невдалі спроби, ескалації, дубльовану роботу та тривалість впливу на користувачів. Порівнюйте їх із попереднім способом експлуатації за подібних умов.
Зберігайте базовий дефект як інженерну роботу. Повторювані перезапуски процесу з витоком пам’яті можуть зменшувати негайний вплив, поки витік триває. Продовжіть із самовдосконалення, щоб пов’язати спостереження з довготривалим виправленням.
Виконайте вправу
Спроєктуйте політику відновлення для вигаданого процесу-обробника експорту з цього уроку. Визначте умову запуску, виключення, дозволену дію, ліміт повторів, паузу, перевірку успіху та відповідального за ескалацію. Перевірте її на збої бази даних і невідомому порушенні цілісності даних.
Завантажити робочий аркуш (Markdown)Зняття цієї позначки видаляє весь прогрес, збережений у цьому браузері.
Прогрес залишається в цьому браузері. Без облікового запису та відстеження.
Джерела та додаткові матеріали
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗