Определете безопасни граници за self-healing
ЗавършеноАвтоматизирайте известни действия за възстановяване с изрични правомощия, проверка и условия за спиране. Разграничете възстановяването при работа от промени в софтуера.
Проверете разбирането сиКонтролерът е рестартирал worker два пъти. Опашката продължава да расте, а базата данни е недостъпна. Какво трябва да направи политиката?Направете упражнението
Какво ще научите
- Разграничете self-healing от трайна софтуерна поправка.
- Определете ограничена политика за възстановяване и независими проверки за успех.
- Разпознайте кога автоматизацията трябва да спре и да ескалира.
Възстановете известно работно състояние
Self-healing автоматично открива определен отказ и опитва разрешено действие за възстановяване. Рестартиране на отказал процес или замяна на неработоспособна инстанция могат да бъдат примери. Действието трябва да съответства на отказа и модела на състоянието на услугата.
Kubernetes може да заменя отказали инстанции на работни натоварвания и да привежда системата в декларираното състояние. Това не поправя погрешна логика на приложението или всеки отказ на съхранението. Възстановяването на инфраструктурата и правилността на софтуера изискват различни проверки. Self-healing в Kubernetes.
Определете целта преди механизма. Възстановяване на експорта означава допустимата работа да завършва правилно. Работещ контейнер е само едно предварително условие.
Разграничете три вида промени
| Промяна | Пример | Необходимо решение |
|---|---|---|
| Възстановяване при работа | Замяна на един отказал worker без локално състояние | Предварително одобрена политика за възстановяване може да го разреши |
| Софтуерна поправка | Поправка на изтичането на памет (memory leak), което спира worker-а | Преглед, тестове, контроли за пускане и продукционна проверка |
| Промяна на политика | Увеличаване на разрешената честота на рестартиране или обхвата на достъп | Изрично одобрение от отговорника за политиката |
Агент може да предложи поправка след възстановяване. Това предложение е нова софтуерна промяна. Не трябва да наследява неограничени правомощия от контролера за възстановяване.
Контролерът също не трябва да редактира собствените си критерии за успех при неуспешна проверка. Иначе системата може да отчита подобрение, без да подобрява услугата.
Напишете политиката за възстановяване, преди да я включите
Следната политика е измислена. Числата ѝ илюстрират проектни решения; не са препоръчителни стойности по подразбиране.
| Поле на политиката | Правило за измисления worker за експорт |
|---|---|
| Задействащо условие | Липсва heartbeat от worker-а за 90 секунди и има работа в опашката |
| Предварителни условия | Друг worker е работоспособен; проверките на зависимостите преминават успешно; няма подозрение за пробив или проблем с целостта |
| Разрешено действие | Замяна на един worker с текущо одобрения артефакт |
| Защита на състоянието | Задачите използват устойчиво съхранение и проверен ключ за идемпотентност |
| Лимит | Най-много две замени за 15 минути; никога повече от една наведнъж |
| Пауза | Изчакване пет минути след замяна преди следващ опит |
| Успех | Синтетична задача завършва правилно и засегнатата опашка започва да намалява |
| Спиране и ескалация | Някое предварително условие не е изпълнено, лимитът е достигнат или успехът не може да се провери |
Използвайте идентичност с минимални права. Записвайте версията на политиката, доказателствата за задействане, действието, ресурса и резултата. Осигурете независим начин за изключване на контролера. Определете човека, отговорен за получаване на ескалация.
Тествайте неуспешни сценарии, както и успешно възстановяване
Повторен опит може да повтори страничен ефект. Worker може да запази файл и да спре, преди да потвърди задачата. Проверете идемпотентността, преди да разрешите друго изпълнение. Вижте примера за отказ в cloud native среда.
Повторните опити могат и да усилят претоварване на зависимост. Използвайте ограничени опити, максимално време за изчакване и подходящо забавяне между опитите. Избягвайте синхронизирани повторни опити между всички инстанции. AWS обяснява защо backoff и jitter помагат да се намали това усилване. Указания за повторни опити.
Тествайте измислената политика с три случая. Един спрял worker трябва да се възстанови. Отказ на базата данни трябва да предотврати повторна замяна. Неясен проблем с целостта трябва да спре автоматизацията и да поиска решение за реакция.
Проверявайте и липсваща телеметрия. Липса на heartbeat може да означава отказал worker или отказал път за събиране. Контролерът се нуждае от достатъчни доказателства за действието си, а не от увереност в AI обяснение.
Измервайте дали политиката помага
Записвайте проверени възстановявания, неуспешни опити, ескалации, дублирана работа и време с ефект върху потребителите. Сравнете ги с предишния начин на експлоатация при подобни условия.
Запазете основния дефект като инженерна задача. Многократно рестартиране на процес с изтичане на памет може да намали непосредствения ефект, докато изтичането продължава. Продължете с подобряване чрез обратна връзка, за да свържете наблюдението с трайна поправка.
Направете упражнението
Проектирайте политика за възстановяване на измисления worker за експорт в този урок. Посочете задействащото условие, изключенията, разрешеното действие, лимита на повторните опити, паузата, проверката за успех и отговорника за ескалация. Тествайте я при отказ на база данни и неизвестен проблем с целостта на данните.
Изтеглете работния лист (Markdown)Премахването на тази отметка изтрива целия напредък, запазен в този браузър.
Напредъкът остава в този браузър. Без акаунт и проследяване.
Източници и допълнително четене
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗