Все, что может пойти не так, пойдет не так.

Часть 1: Введение (это)
Часть 2: Традиционное проектирование — Архитектурные шаблоны
Часть 3: Традиционное проектирование — Шаблоны программирования

При создании любого вида сервиса многие вещи могут пойти не так в течение его жизненного цикла, начиная от типичных ошибок разработчиков и заканчивая событиями черного лебедя, такими как отключение центра обработки данных.

При рассмотрении сложности системы и ошибок, которые влекут за собой, на следующем графике, с одной стороны, у нас есть вероятность отказа, а с другой - ранг, который определяется в порядке от наиболее вероятного к наименее вероятному.

Двигаясь слева направо, у нас есть наиболее вероятные ошибки, такие как ошибки с отклонением на 1, общие ошибки разработчика, временные ошибки, нехватка ресурсов и т. д. Затем мы пересекаем границу сбоя в реактивных операциях , которые «нам, вероятно, не следует делать». это снова» или «позвоните этому человеку, чтобы он починил».

И, наконец, Неизвестное , то есть то, чего мы не ожидаем, и то, что приходит ни с того ни с сего.

Вышеупомянутые 3 категории можно разбить на следующие (неполный список) «исправления».

1. Традиционная инженерия

• Архитектурные узоры
• Шаблоны программирования
• Стандарты кодирования
• Тестирование

• Метрики, журналы и оповещения
• Пометка функции
• Канарские испытания
• Документация
• Ротация по вызову
• Самовосстановление
• Посмертный

• Хаос Инжиниринг
• Обратное время безотказной работы

Изящная деградация

Бегать в деградированном состоянии почти всегда лучше, чем вообще не бегать.

Большая часть литературы и мышления об устойчивости развивается вокруг Изящной деградации.

Урожай ( документ здесь )

Урожай является функцией Data available / Total dataили, другими словами, правдивостью данного запроса.

Скажем, у нас есть поисковая система, состоящая из 100 разделов данных.

Если 1 раздел выйдет из строя, мы получим урожай 99%, что в большинстве случаев будет более чем нормально.

Запуск в ухудшенном состоянии тесно связан с шаблоном Fallback или резервными путями, как его также можно назвать.

Используя интеллектуальные резервные пути для отказоустойчивых зависимостей и следя за тем, чтобы ваша служба не отключалась из-за ошибки, вы по-прежнему можете обслуживать запросы своих пользователей/иждивенцев вверх по течению.

Короче говоря, пользователь скорее предпочел бы иметь опыт, чем вообще не иметь опыта.

Отказоустойчивость службы с отслеживанием состояния и без сохранения состояния

Что такое государство?

Рассмотрим простое приложение для подсчета;

Либо он может хранить текущий счет в памяти, это будет считаться приложением с отслеживанием состояния.

Или

Он мог бы хранить текущий счет в базе данных, это было бы приложением без сохранения состояния.

Однако это не означает, что если ваша служба сохраняет что-то в базе данных, она не имеет состояния.

У вас может быть приложение, которое выполняет длительные многоэтапные вычисления, это будет считаться приложением с отслеживанием состояния, поскольку состояние управляется приложением.

Учитывая отказоустойчивость такого приложения, самое худшее, что может случиться, — это отключение службы без предупреждения в середине шага.

Отслеживание шагов вычислений или промежуточных вычислений и сохранение этого состояния может быть способом обработки такого сценария.

Вопрос, который следует учитывать при проектировании и разработке высоконадежных приложений

• Какие цели и показатели надежности вы определили для своего приложения?
• Как вы обеспечили устойчивость архитектуры вашего приложения к сбоям?
• Как вы обеспечили наличие необходимых мощностей и услуг в целевых регионах?
• Как вы справляетесь с аварийным восстановлением для этой рабочей нагрузки?
• Какие решения были приняты для обеспечения соответствия платформы приложений вашим требованиям надежности?
• Какие решения были приняты для обеспечения соответствия платформы данных вашим требованиям надежности?
• Как логика вашего приложения обрабатывает исключения и ошибки?
• Какие решения были приняты для обеспечения соответствия сети и подключения вашим требованиям к надежности?
• Какие резервы надежности для масштабируемости и производительности вы сделали?
• Какие поправки на надежность для безопасности вы сделали?
• Как вы тестируете приложение, чтобы убедиться в его отказоустойчивости?
• Как вы отслеживаете и измеряете работоспособность приложений?