Ерошко: Методы, способы и средства обеспечения отказоустойчивости автоматизированных систем

Лекции/2.2.600_Методы_способы_средства_обеспечения_отказоустойчивости/eroshko.md

@@ -0,0 +1,95 @@
+# Методы, способы и средства обеспечения отказоустойчивости автоматизированных систем
+
+
+# Что такое отказоустойчивость и стабильность?
+
+Под **отказоустойчивостью** будем понимать свойство системы, которое позволяет максимально сохранять работоспособность при отказе отдельных конкретных компонентов системы либо связанных систем и восстанавливать работоспособность системы при восстановлении отказавших компонентов или связанных систем. Давайте рассмотрим подробнее эти 2 момента:
+
+- Деградация работоспособности системы должна быть прямо пропорциональна "величине" отказа. То есть, если упал сервис, отвечающий за некую некритичную функциональность — вся система не должна при этом падать. Да, небольшой кусочек не работает, но это не влияет на стабильность остальной части функционала.
+
+- **Стабильность** системы предполагает самостоятельного восстановления работоспособности после сбоя как компонентов системы, так и всей системы в целом. К примеру, если пропадала сеть на некоторое время — то у стабильных систем после восстановления подключения все компоненты продолжат работать и данные вернутся в консистентное состояние без ручного вмешательства со стороны команды эксплуатации.
+
+
+## Наглядное сравнение
+
+![](eroshko1.png)
+
+Если в стабильной системе из нормального состояния равновесия шарик в центре чуть-чуть подтолкнём в сторону — он, конечно же, ненадолго отклонится от равновесия (т.е. система перейдёт в некоторое неидеальное состояние), но после этого шарик быстро вернётся в нормальное состояние. В случае же плохо спроектированных и построенных систем — даже лёгкого воздействия на шарик достаточно, чтобы система начала деградировать с нарастающей скоростью. При этом сам по себе шарик не вернётся в нормальное состояние в таких системах.
+
+
+## Как измерить отказоустойчивость и стабильность?
+
+Но как же определить является ли наша система отказоустойчивой и стабильной? И на сколько? Как в идеале замерить эти свойства, чтобы двигаться к цели согласно некой метрике, а не наощупь?
+
+Единственный способ спроектировать систему, которая будет устойчива к сбоям — проводить **стресс-тесты** (resilience testing / chaos engineering), по результатам тестов делать выводы, менять архитектуру и подходы к написанию кода, снова запускать тест... и так до бесконечности :)
+
+**Количество пройденных тестов** и будет метрикой отказоустойчивости отдельных компонентов и системы в целом. Только на основе метрики делаем вывод о повышении или понижении стабильности системы.
+
+Создание таких тестов — уже непростая инженерная задача. Для начала необходимо описать и автоматизировать сценарии отказа (легла сеть, закончилось место на диске, внешний сервис отвечает ошибками, сеть тормозит или доставляет только 50% пакетов, выключилось электричество на конкретном физическом хосте или во всё дата-центре и т.д.) — а потом запускать их в произвольном порядке, да и ещё и в случайных комбинациях друг с другом ??. Тесты позволят нам и получить измеримую метрику (прошли 10 тестов из 50), и понять какие отказы наиболее критичны, т.к. сразу же приводят к краху всей системы.
+
+
+## Принципы построения отказоустойчивых систем
+
+### Отсутствие единой точки отказа (No SPoF - Single Point of Failure)
+
+Принцип применим ко всем уровням эксплуатации — от точки деплоя (любой Nginx или микросервис в системе) до уровня дата центров. Рассмотрим этот принцип на примерах репликации и балансировки небольших компонентов системы:
+
+![](eroshko2.png)
+
+Для его реализации сервисы должны быть готовы к запуску в нескольких экземплярах — как минимум не должны хранить состояния (быть stateless-сервисами). Давайте рассмотрим обратный пример, когда у нас сервис хранит состояние и неготов к горизонтальному масштабированию. Пусть в нашей схеме сессия пользоавтеля хранится на самом бэкендовском сервисе:
+
+![](eroshko3.png)
+
+### Проектирование с учётом отказов (Design for Failure)
+
+В любой системе происходят отказы и падения, поэтому важно уже на этапе проектирования архитектуры держать в уме, моделировать и закладывать обработку нештатных ситуаций. Рассмотрим основные базовые идеи концепции:
+
+**Постепенная деградация (Graceful degradation)** — это возможность частично деградировать функционала системы в случае отсутствия/неработоспособности её компонентов. Рассмотрим на схеме вариант построения системы с последовательной связанностью и полной деградацией при отказе:
+
+![](eroshko4.png)
+
+Другой вариант частичной деградации — потеря или отложенное предоставление некритичных данных. Например, мы можем показать позже срок доставки товара (или не показывать вовсе) в случае проблем с компонентом расчета доставки, при этом вся остальная информация и возможность купить будут доступны.
+
+В худшем варианте, если некий BFF или API Gateway дожидается синхронного ответа от каждого компонента и только потом отдаёт результирующий html — страница отобразится пользователю только после отрабатывания самого медленного компонента (или суммы времени всех, если запросы строятся ещё и последовательно, а не параллельно). При падении одного из компонентов (например, не самого важного раздела с похожими товарами) в нетолерантном к отказам варианте проектирования пользователь бы в принципе ничего не увидел кроме страницы с ошибкой.
+
+Помимо отложенной доставки или потери данных, в случае их критичности — можем деградировать в их актуальности взамен полного отсутствия при помощи кэширования. К примеру, если источник актуальных данных недоступен — берём предсохранённые данные из кэша: в зависимости от сценария, тут может быть как частичная деградация (актуальные данные лучше старых, но старые лучше их отсутствия) так и отсутствие деградации вовсе (пусть в 99% случаев закэшированные данные соответствуют актуальным).
+
+## Выводы
+
+На основе рассмотренных принципов и подходов можно сформулировать следующие ключевые выводы:
+
+### Основные положения
+- **Отказоустойчивость** и **стабильность** — взаимосвязанные, но различные свойства системы, требующие целенаправленного проектирования и тестирования
+- Отказоустойчивость обеспечивает постепенную деградацию функциональности при отказах компонентов
+- Стабильность гарантирует самостоятельное восстановление системы после сбоев
+
+### Методология оценки
+- Единственный эффективный способ оценки — **стресс-тестирование** и **chaos engineering**
+- Количество пройденных тестов служит объективной метрикой отказоустойчивости
+- Автоматизированные сценарии отказа позволяют выявить наиболее критические точки системы
+
+### Архитектурные принципы
+1. **Отсутствие единой точки отказа** — фундаментальный принцип, требующий:
+   - Stateless-архитектуры сервисов
+   - Готовности к горизонтальному масштабированию
+   - Репликации критических компонентов
+
+2. **Проектирование с учётом отказов** — включает:
+   - Реализацию постепенной деградации функциональности
+   - Стратегии обработки частичных отказов (кэширование, отложенные данные)
+   - Параллельную обработку запросов вместо последовательной
+
+### Практические рекомендации
+- Критически важные данные должны быть доступны через кэширование при недоступности источников
+- Некритичный функционал может временно деградировать без влияния на основную систему
+- Архитектура должна допускать частичные отказы без полного прекращения работы
+
+### Непрерывный процесс
+Создание отказоустойчивой системы — **итерационный процесс**, включающий:
+- Регулярное тестирование на устойчивость к сбоям
+- Постоянное совершенствование архитектуры
+- Анализ метрик и адаптацию к новым угрозам
+
+Только комплексный подход, сочетающий продуманную архитектуру и регулярное тестирование, позволяет создать действительно стабильную и отказоустойчивую систему.
+
+Источник: habr.com

Лекции/2.2.600_Методы_способы_средства_обеспечения_отказоустойчивости/eroshko_voprosi.md

@@ -0,0 +1,29 @@
+Что такое отказоустойчивость системы?
+Отказоустойчивость — это свойство системы, которое позволяет максимально сохранять работоспособность при отказе отдельных компонентов или связанных систем и восстанавливать её при восстановлении этих компонентов. Это означает, что система должна продолжать функционировать, даже когда некоторые её части выходят из строя.
+
+Как должна вести себя система при отказе некритичного сервиса? 
+Деградация работоспособности системы должна быть прямо пропорциональна "величине" отказа. Если перестал работать сервис, отвечающий за некритичную функциональность, вся система не должна падать. Небольшая часть функциональности может быть недоступна, но это не должно влиять на стабильность основной части системы и критически важных функций.
+
+Что подразумевает стабильность системы? 
+Стабильность системы предполагает самостоятельное восстановление работоспособности после сбоя как отдельных компонентов, так и всей системы в целом. Например, после восстановления сетевого подключения все компоненты стабильной системы должны продолжить работу, а данные должны вернуться в консистентное состояние без какого-либо ручного вмешательства со стороны команды эксплуатации.
+
+Какой основной метод используется для оценки отказоустойчивости системы?
+Единственный эффективный способ оценки отказоустойчивости — проведение стресс-тестов (resilience testing) и chaos engineering. Это означает необходимость создания автоматизированных сценариев отказа различных компонентов системы и последующего анализа поведения системы в этих условиях.
+
+Что является измеримой метрикой отказоустойчивости системы?  
+Количество успешно пройденных тестов на устойчивость к различным сбоям служит объективной метрикой отказоустойчивости как отдельных компонентов, так и системы в целом. На основе этой метрики можно делать выводы о повышении или понижении стабильности системы после внесения изменений в архитектуру или код.
+
+Что означает принцип "Отсутствие единой точки отказа" (No SPoF)? 
+Это фундаментальный принцип, применимый ко всем уровням эксплуатации системы. Он требует, чтобы ни один компонент системы не был единственным и критически важным для работы всей системы. Для его реализации сервисы должны быть готовы к запуску в нескольких экземплярах и, как минимум, не должны хранить состояние (быть stateless-сервисами).
+
+Как принцип постепенной деградации (Graceful Degradation) помогает при отказах?
+Постепенная деградация — это возможность системы частично сохранять функциональность при отсутствии или неработоспособности некоторых её компонентов. Вместо полного отказа система может либо временно отключить некритичные функции, либо использовать закешированные данные, либо предоставлять основной функционал с ограниченными возможностями.
+
+Как кэширование помогает обеспечить отказоустойчивость системы?
+Кэширование позволяет системе деградировать в актуальности данных взамен их полного отсутствия. Если источник актуальных данных недоступен, система может использовать предварительно сохранённые данные из кэша. В зависимости от сценария, это может быть как частичная деградация (когда старые данные лучше, чем их полное отсутствие), так и практически полное сохранение функциональности.
+
+Почему последовательная обработка запросов может быть опасной для отказоустойчивости?
+При последовательной обработке запросов отказ одного компонента может привести к полной блокировке работы всей системы. Если система дожидается ответа от каждого компонента последовательно, то при недоступности любого из них вся цепочка обработки прерывается, что делает систему уязвимой к единичным отказам.
+
+Является ли создание отказоустойчивой системы разовым действием?
+Нет, создание отказоустойчивой системы — это непрерывный итерационный процесс, который включает регулярное стресс-тестирование, анализ результатов, совершенствование архитектуры и подходов к написанию кода, а затем повторное тестирование. Этот цикл должен повторяться постоянно для поддержания и улучшения устойчивости системы к сбоям.