Поставите безбедне границе за самостални опоравак
ЗавршеноАутоматизујте познате радње опоравка са јасним овлашћењима, провером и условима заустављања. Раздвојите опоравак током рада од промене софтвера.
Објављује TaigaКако пишемо
Проверите разумевањеКонтролер је два пута поново покренуо worker. Ред наставља да расте, а база није доступна. Шта политика треба да уради?Урадите вежбу
Шта ћете научити
- Разликујте самостални опоравак од трајне исправке софтвера.
- Дефинишите ограничену политику опоравка и независне провере успеха.
- Препознајте када аутоматизација мора да стане и ескалира проблем.
Опоравите познато стање
Самостални опоравак, односно self-healing, аутоматски открива дефинисан отказ и покушава овлашћену радњу опоравка. Примери могу да буду поновно покретање отказалог процеса или замена неисправне инстанце. Радња мора да одговара отказу и моделу стања сервиса.
Kubernetes може да замени отказале инстанце радног система и усагласи декларисано стање. То не исправља неисправну логику апликације нити сваки отказ складишта. За опоравак инфраструктуре и исправност софтвера потребне су различите провере. Kubernetes самостални опоравак.
Дефинишите циљ пре механизма. Опоравак извоза значи да се прихватљиви послови исправно завршавају. Активан контејнер је само један предуслов.
Раздвојите три врсте промена
| Промена | Пример | Потребна одлука |
|---|---|---|
| Опоравак током рада | Заменити један отказали worker без стања | Унапред одобрена политика опоравка може то да овласти |
| Исправка софтвера | Исправити цурење меморије које зауставља worker | Преглед, тестови, контроле објављивања и провера у продукцији |
| Промена политике | Повећати дозвољену учесталост поновног покретања или обухват приступа | Изричито одобрење особе одговорне за политику |
Агент може да предложи исправку после опоравка. Тај предлог је нова промена софтвера. Не сме да наследи неограничено овлашћење од контролера опоравка.
Контролер такође не сме да мења сопствене критеријуме успеха када провера не успе. У супротном, систем може да пријави побољшање без побољшања сервиса.
Напишите политику опоравка пре него што је активирате
Следећа политика је измишљена. Њени бројеви илуструју изборе дизајна; нису препоручене подразумеване вредности.
| Поље политике | Правило за измишљени worker извоза |
|---|---|
| Услов покретања | Сигнал активности worker-а изостаје 90 секунди, а у реду постоји посао |
| Предуслови | Други worker је исправан; провере зависности пролазе; нема сумње на компромитацију или проблем интегритета |
| Дозвољена радња | Заменити један worker тренутно одобреним артефактом |
| Заштита стања | Послови користе трајно складиште и проверен кључ идемпотентности |
| Ограничење | Највише две замене у 15 минута; никада више од једне истовремено |
| Пауза | Сачекати пет минута после замене пре новог покушаја |
| Успех | Синтетички посао се исправно заврши и погођени ред почиње да се празни |
| Заустављање и ескалација | Било који предуслов није испуњен, ограничење је достигнуто или успех не може да се провери |
Користите идентитет са најмањим потребним привилегијама. Бележите верзију политике, доказе за покретање, радњу, ресурс и резултат. Обезбедите независан начин искључивања контролера. Одредите особу која прима ескалацију.
Тестирајте путање отказа, као и успешан опоравак
Поновни покушај може да понови споредни ефекат. Worker може да сачува датотеку и стане пре потврде посла. Проверите идемпотентност пре дозвољавања новог извршавања. Погледајте cloud native пример отказа.
Поновни покушаји могу и да додатно оптерете већ преоптерећену зависност. Користите ограничен број покушаја, временска ограничења и одговарајуће повећавање паузе. Избегавајте синхронизоване поновне покушаје свих инстанци. AWS објашњава зашто backoff и jitter помажу да се смањи ово појачање оптерећења. Смернице за поновне покушаје.
Тестирајте измишљену политику у три случаја. Један заустављен worker треба да се опорави. Прекид рада базе треба да спречи поновљене замене. Неизвестан проблем интегритета треба да заустави аутоматизацију и затражи одлуку о одговору.
Проверите и недостајућу телеметрију. Одсуство сигнала активности може да значи отказ worker-а или путање прикупљања. Контролеру требају докази довољни за његову радњу, а не поверење у AI објашњење.
Измерите да ли политика помаже
Бележите проверене опоравке, неуспеле покушаје, ескалације, дуплиран рад и време током ког су корисници трпели последице. Упоредите то са претходним начином рада у сличним условима.
Задржите основни дефект као инжењерски задатак. Стално поновно покретање процеса у коме цури меморија може да смањи непосредан утицај док цурење траје. Наставите са самосталним побољшавањем да повежете запажање са трајном исправком.
Урадите вежбу
Осмислите политику опоравка за измишљени worker извоза из ове лекције. Наведите услов покретања, изузимања, дозвољену радњу, ограничење покушаја, паузу, проверу успеха и особу за ескалацију. Тестирајте је за прекид рада базе и непознат проблем интегритета података.
Преузми радни лист (Markdown)Искључивање ове опције брише сав напредак сачуван у овом прегледачу.
Напредак остаје у овом прегледачу. Без налога и праћења.
Извори и додатно читање
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗