Задайте безопасные границы самовосстановления
ЗавершеноАвтоматизируйте известные действия восстановления с явными полномочиями, проверкой и условиями остановки. Отделяйте восстановление работающей системы от изменения ПО.
Издатель TaigaКак мы пишем
Проверьте пониманиеКонтроллер дважды перезапустил worker. Очередь продолжает расти, а база данных недоступна. Что должна предписывать политика?Выполните упражнение
Чему вы научитесь
- Отличать самовосстановление от постоянного исправления ПО.
- Определять ограниченную политику восстановления и независимые проверки успеха.
- Распознавать, когда автоматизация должна остановиться и передать вопрос на эскалацию.
Восстанавливайте известное состояние
Самовосстановление автоматически обнаруживает определённый сбой и пытается выполнить разрешённое действие восстановления. Примеры — перезапуск отказавшего процесса или замена неисправного экземпляра. Действие должно соответствовать сбою и модели состояния сервиса.
Kubernetes может заменять отказавшие экземпляры нагрузки и приводить состояние к объявленному. Это не исправляет ошибочную логику приложения и помогает не при каждом сбое хранилища. Для восстановления инфраструктуры и правильности ПО нужны разные проверки. Самовосстановление Kubernetes.
Определите цель до выбора механизма. Восстановить экспорт — значит правильно завершать разрешённую работу. Работающий контейнер — лишь одно предварительное условие.
Разделяйте три вида изменений
| Изменение | Пример | Необходимое решение |
|---|---|---|
| Восстановление во время работы | Заменить один отказавший stateless worker | Это может разрешать заранее утверждённая политика восстановления |
| Исправление ПО | Исправить утечку памяти, которая останавливает worker | Review, тесты, контроль релиза и проверка в production |
| Изменение политики | Увеличить разрешённую частоту перезапусков или область доступа | Явное одобрение ответственного за политику |
После восстановления агент может предложить исправление. Это предложение — новое изменение ПО. Оно не должно наследовать неограниченные полномочия контроллера восстановления.
Контроллер также не должен менять собственные критерии успеха при неуспешной проверке. Иначе система может сообщать об улучшении без улучшения сервиса.
Напишите политику восстановления до её включения
Следующая политика вымышленная. Числа показывают варианты проектирования, а не рекомендуемые значения по умолчанию.
| Поле политики | Вымышленное правило для export worker |
|---|---|
| Триггер | Heartbeat worker отсутствует 90 секунд, и в очереди есть работа |
| Предварительные условия | Другой worker исправен; проверки зависимостей проходят; нет подозрения на компрометацию или нарушение целостности |
| Разрешённое действие | Заменить один worker с использованием текущего утверждённого артефакта |
| Защита состояния | Задачи используют устойчивое хранилище и проверенный ключ идемпотентности |
| Лимит | Не более двух замен за 15 минут; не более одной одновременно |
| Пауза | Подождать пять минут после замены перед следующей попыткой |
| Успех | Синтетическая задача завершается правильно, а затронутая очередь начинает сокращаться |
| Остановка и эскалация | Не выполнено любое предварительное условие, достигнут лимит или успех нельзя проверить |
Используйте identity с минимальными правами. Записывайте версию политики, доказательства срабатывания триггера, действие, ресурс и результат. Предусмотрите независимый способ отключить контроллер. Назначьте человека, который получает эскалацию.
Проверяйте пути сбоя наряду с успешным восстановлением
Повторная попытка может повторить побочный эффект. Worker может сохранить файл и остановиться до подтверждения задачи. Проверьте идемпотентность перед разрешением повторного выполнения. См. пример сбоя в cloud native.
Повторы также могут усилить перегрузку зависимости. Используйте ограниченное число попыток, тайм-ауты и подходящие задержки. Избегайте синхронных повторов во всём парке. AWS объясняет, почему увеличение задержек и jitter помогают уменьшить усиление нагрузки. Рекомендации по повторам.
Проверьте вымышленную политику в трёх случаях. Один остановившийся worker должен восстановиться. Недоступность базы данных должна предотвращать повторные замены. Неясное нарушение целостности должно остановить автоматизацию и запросить решение о реагировании.
Проверьте также отсутствие телеметрии. Отсутствующий heartbeat может означать отказ worker или сбой пути сбора. Контроллеру нужны достаточные для действия доказательства, а не уверенность в объяснении ИИ.
Измеряйте, помогает ли политика
Записывайте проверенные восстановления, неуспешные попытки, эскалации, повторно выполненную работу и длительность влияния на пользователей. Сравнивайте их с прежним способом эксплуатации в сходных условиях.
Сохраняйте исходный дефект как инженерную задачу. Повторный перезапуск процесса с утечкой может уменьшить немедленные последствия, пока утечка продолжается. Перейдите к самосовершенствованию, чтобы связать наблюдение с устойчивым исправлением.
Выполните упражнение
Разработайте политику восстановления для вымышленного export worker из урока. Укажите триггер, исключения, разрешённое действие, предел повторов, паузу между попытками, проверку успеха и ответственного за эскалацию. Проверьте её при недоступности базы данных и неизвестном нарушении целостности данных.
Скачать рабочий лист (Markdown)Если снять этот флажок, весь прогресс, сохранённый в этом браузере, будет удалён.
Прогресс остаётся в этом браузере. Без аккаунта и отслеживания.
Источники и дополнительные материалы
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗