tgoop.com/microservices_arch/513
Last Update:
Мои заметки по этой главе (фактически краткий конспект, практически без моих вставок, будет только одна, но вообще-то спорных моментов там много) с подготовки к эфиру.
Мы перешли от потребности в высокой доступности к потребности в полной доступности с предоставлением хотя бы минимально-функционирующего сервиса в случае возникновения любой проблемы.
Сбой (fault) – это некоторое случайное состояние/условие, возникновение которого может привести к тому, что система или ее компонент не будут работать должным образом. Сбой может привести к отказу.
Отказ (failure) – отклонение системы или компонента от требуемого поведения.
Доступность (Availability) - отношение времени фактической доступности системы ко времени которое она могла быть доступна.
Лучше определять доступность применительно к конкретным сценариям, а не системе в целом, но даже в этом случае есть проблемы с измерением доступности в девятках:
- бизнес хочет максимум (но это дорого)
- на практике бизнес не видит разницы между пятью и тремя девятками
- девятки не берут во внимание момент наступления отказа (утро воскресенья vs черная пятница)
Надежность (Reliability) – вероятность работы программного обеспечения без отказов (failure) в течение заданного периода времени в заданной среде. Строится поверх доступности, система может быть доступной, но не надежной
Доступность и надежность – это наблюдаемое поведение реальной системы.
Способы достижения доступности и надежности:
– Высокая доступность (high-availability) в основном через кластеризацию и репликацию всей системы и/или всей базы данных соответственно, – заточены под большие, монолитные системы.
– Устойчивость (Resilience) – каждая часть системы несет ответственность за доступность системы в целом путем адаптации своего поведения при возникновении сбоев, например, через ретраи или автоматический рестарт процессов, ограничение распространения ошибок.
Авторы утверждают, что HA больше применима для крупных систем с относительно редкими сбоями и длительным восстановлением после сбоя, что слабо подходит под архитектуру, в которой много более гранулярных компонентов и падение любого в отдельности может быть более частым, а соответственно, мы должны принять, что отказы происходят и сосредоточиться на дизайне, обеспечивающем функционирование и предоставление сервиса в случае, если даже часть системы отказала.
Аспекты предотвращения отказов, все три применяются к людям, процессам и технологиям (Jean Pariès, John Wreathall, David Woods, and Erik Hollnagle, Resilience Engineering in Practice: A Guidebook (CRC Press, 2013))
- Знать что делать для того, чтобы можно было продолжить оказание сервиса (добавить capacity, перезагрузить, ограничить нагрузку)
- Знать что искать, – это про мониторинг для отслеживания ситуаций, которые привели или могут привести к снижению доступности
- Знать, что произошло, чтобы иметь возможность учиться на ошибка
- Знать, чего ожидать, – используя накопленную информацию и предсказательные модели определять потенциальные проблемы
BY Микросервисы / распределенные системы
Share with your friend now:
tgoop.com/microservices_arch/513