Robust Applications

Сбой (fault) и отказ (failure) — разные вещи. Сбой обычно определяется как отклонение одного из компонентов системы от рабочих характеристик, в то время как отказ — ситуация, когда вся система в целом прекращает предоставление требуемого сервиса пользователю.

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

Что делать, чтобы повысить устойчивость к ошибкам:

Парадоксально, но в подобных устойчивых к сбоям системах имеет смысл повысить частоту сбоев с помощью их умышленной генерации — например, путем прерывания работы отдельных, выбранных случайным образом процессов без предупреждения. Многие критические ошибки фактически происходят из-за недостаточной обработки ошибок; умышленное порождение сбоев гарантирует постоянное тестирование механизмов обеспечения устойчивости к ним, что повышает уверенность в должной обработке сбоев при их «естественном» появлении. Пример этого подхода — сервис Chaos Monkey компании Netflix.

Если нельзя избежать ошибок, то лучше предупреждать о них:

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

Ошибки бывают технические (сервера ломаются) и человеческие.

Чтобы снизить человеческий фактор:

Грамотно спроектированные абстракции, API и интерфейсы администраторов упрощают «правильные» действия и усложняют «неправильные».

Создать полнофункциональную “песочницу” для безопасного тестирования, экспериментов и изучения системы без влияния на реальных пользователей.

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

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

Настроить подробный и ясный мониторинг, в том числе метрик произво- дительности и частот ошибок.

Внедрение рекомендуемых управленческих практик и обучение.