Мои заметки по этой главе (фактически краткий конспект, практически без моих вставок, будет только одна, но вообще-то спорных моментов там много) с подготовки к эфиру. Мы перешли от потребности в высокой доступности к потребности в полной доступности с предоставлением хотя бы минимально-функционирующего сервиса в случае возникновения любой проблемы. Сбой (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, перезагрузить, ограничить нагрузку) - Знать что искать, – это про мониторинг для отслеживания ситуаций, которые привели или могут привести к снижению доступности - Знать, что произошло, чтобы иметь возможность учиться на ошибка - Знать, чего ожидать, – используя накопленную информацию и предсказательные модели определять потенциальные проблемы