Комментарии 5
Примечание: если говорить совсем корректно в терминах теории надёжности, то доступность следует воспринимать как коэффициент готовности.
Точнее так:
Кг - это вероятность застать систему в работоспособном состоянии (ничего не отвалилось), а коэф. доступности - вероятность застать систему в свободном состоянии, т.е. готовой принять \ обработать нагрузку (не занята).
К расчету надежности дублированной группы. Отказоустойчивые конфигурации (резервирование) – сложная штука и нормальный расчет коэффициента готовности реального отказоустойчивого сервера (например, реального кластера) еще не встречал (у кого есть – покажите). Там должен быть как минимум параметр «вероятность отказа, не обнаруженного внутренней системой контроля», т.к. идеальных систем нет. Состояние необнаруженного отказа - это например, когда узел поломан (не обрабатывает нагрузку), но keep-alive "исправлено" шлет остальным узлам (или резервные узлы не переключаются при отсутствии на входе сигнала "пока жив" от соседа). Даже один не обнаруженный из пятисот обнаруженных отказов изменит характер зависимости.
Считать Кг реальной системы нужно марковскими цепями (граф состояний, отражающих резервирование, и далее решение системы уравнений), т.к. последовательно-параллельные статические схемы не передадут даже качественно модель отказов системы с резервом.
Есть какие-либо показатели и расчеты (примеры) Business continuity & Operational resilience?
Запихнуть в одну, даже очень длинную, статью весь учебник по теории надёжности - задача такой же достижимости, как и задача получения виртуалки с доступностью 100%, я не ставил себе такой цели :)
Цель - дать всем общее представление, коллегам-инфраструктурщикам - аргументы в переговорах, а коллегам-менеджерам - понимание, где искать заветные "девятки" доступности.
"Доступность для самых маленьких" получилась. Можно топам, которые не глубоко в специфике давать почитать, а младшему командному составу сократить до методички можно, мы же просто в формулы перевели и считаем метрики.
Да, всё так. Рассказ про доступность "на пальцах", плюс пул аргументов для разговоров с топами и бизнесом.
Насчёт методички для младшего командного состава не соглашусь - на митапах мои расчёты (очень упрощённые) были часто откровением для devops-инженеров, sre-инженеров, разработчиков и их лидов. И пришлось рассказывать подробно, как в статье, с обоснованием "почему нельзя вопрос обеспечения доступности полностью переложить на инфру".
Доступность IT-систем: поругаться или договориться?