Действительно серьёзные проекты должны работать без перебоев даже в случае отказа отдельных подсистем. А причин для сбоев в работе немало — это выход из строя серверного «железа», сбои программного обеспечения, аварии на уровне дата‑центров. Но всех этих рисков можно избежать или минимизировать их последствия.
Отказоустойчивость — это способность системы продолжать полноценно работать при выходе из строя отдельных компонентов — серверов или каналов связи, сбоев на уровне отдельных модулей системы и т.д.
При этом стоит знать, что построение и сопровождение отказоустойчивой системы будет сложнее и дороже, нежели разработка и поддержка обычной системы. Подходить к проектированию каждого конкретного решения стоит с точки зрения экономической целесообразности. А для того, чтобы критерии принятия решения были объективны, нужны показатели, которые позволят измерить и сопоставить различные варианты.
Отказоустойчивость сложно измерить саму по себе, но измерению поддаётся аптайм — доступность сервиса, выраженная в процентах. Правильнее всего с точки зрения аналитики измерять аптайм за длительные интервалы — как минимум за год, а лучше — еще за больший интервал. Аптайм в диапазоне 99.8-99.9% — это нормальный показатель для обычных проектов на виртуальных хостингах или VPS — это примерно 1-2 часа неработоспособности в месяц или около 12 часов недоступности сервиса в год. Показатель около 99.95% — эквивалент 4 часов недоступности в год — уже достаточно хороший для односерверных инсталляций и для ПО, изначально не спроектированного для высокой отказоустойчивости. Если же требуемый уровень аптайма 99.99% и выше, то обычно требуется как построение соответствующей серверной инфраструктуры, так и модификация кодовой базы проекта для работы в режиме высокой отказоустойчивости.
Для обеспечения нормального уровня доступности не нужно строить отказоустойчивую систему: достаточно просто качественно написанного кода приложения, адекватных процессов сопровождения, рекомендуется пользоваться услугами профессиональных хостинговых компаний — они резервируют каналы связи, питание и охлаждение оборудования, а также для односерверных инсталляций использовать надежные выделенные серверы — лучше физические, а не виртуальные.
Для достижения высокого уровня доступности уже используются механики построения отказоустойчивых систем — в частности, дублирование всех критичных подсистем, что позволяет приложению функционировать, даже если из строя выходит один из компонентов. Основных способа тут два — горизонтальное масштабирование или дублирование всех серверов и настройка их автоматической "горячей" замены. И в том, и в другом случае выполняется дублирование всех критичных компонентов системы, разница лишь в штатных режимах работы и в механике обеспечения отказоустойчивости. При горизонтальном масштабировании компоненты работают параллельно и это к тому же повышает устойчивость к нагрузкам, а при использовании схемы с «горячей заменой» резервный компонент включается только в момент выхода из строя основного. Горизонтальное масштабирование обычно более привлекательно с точки зрения утилизации мощностей, но применимо оно не везде и часто требует более существенных доработок ПО для реализации.