MICROSERVICES_ARCH Telegram 513
Code of Architecture
Заканчиваем книгу Continuous Architecture in Practice 📖 4 декабря в последнем выпуске разберем 7, 8 и 9 главы. Поговорим про надежность как атрибут качества в архитектуре и погрузимся в самые современные технологии. Обсудим: — что вообще такое надежность…
Мои заметки по этой главе (фактически краткий конспект, практически без моих вставок, будет только одна, но вообще-то спорных моментов там много) с подготовки к эфиру.

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

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



tgoop.com/microservices_arch/513
Create:
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

View MORE
Open in Telegram


Telegram News

Date: |

Choose quality over quantity. Remember that one high-quality post is better than five short publications of questionable value. Write your hashtags in the language of your target audience. ZDNET RECOMMENDS On June 7, Perekopsky met with Brazilian President Jair Bolsonaro, an avid user of the platform. According to the firm's VP, the main subject of the meeting was "freedom of expression." The main design elements of your Telegram channel include a name, bio (brief description), and avatar. Your bio should be:
from us


Telegram Микросервисы / распределенные системы
FROM American