Перейти к содержанию

health-calc — калькулятор доступности


(Health calculator) — маленький open-source инструмент, который считает то, о чём часто забывают подумать до аварии.

Что он делает

Вы задаёте три числа:

  • целевой SLO (например, 99,5%)
  • количество инсталляций сервиса (например, 100 подов в Kubernetes)
  • интервал проверки health-check (например, 5 минут)

Калькулятор отвечает на вопрос: сколько суммарного времени простоя допускает ваш SLO за месяц, с учётом количества инсталляций и интервала проверок?

И выдаёт конкретное число. Для параметров выше: при 100 подах, проверке каждые 5 минут и SLO 99,5% за 30 дней вы можете потерять 4320 health-check ответов. Это примерно 4 инсталляции могут упасть и пролежать 9 часов — и формально SLO не нарушен.

Почему это страшно и почему это полезно

Казалось бы: «4320? Да у меня всё стабильно, что тут считать». Но health-calc подсвечивает обратную сторону. Если ваш SLO 99,99% при проверке раз в минуту на одной инсталляции — вы можете упасть всего 4 раза за месяц. Четыре. Один неудачный деплой в пятницу вечером — и бюджет исчерпан.

Инструмент нужен не чтобы строить дашборды. Он нужен на этапе проектирования. Когда вы решаете, какой SLO реалистичен, а какой — фантазия продакт-менеджера.

Сценарий использования

Идёт планирование нового сервиса. Архитектор говорит: «Сделаем SLO 99,99%». SRE открывает health-calc и показывает: «При таком SLO и нашем интервале мониторинга допустимо 4 провала health-check в месяц. У нас Aggressive deployment каждый день. Мы сожжём бюджет в первую неделю.»

Разговор переходит в конструктивное русло: какой SLO реалистичен? Может, 99,9%? А может, оставить 99,99%, но добавить rollback-автоматику и canary deployment?

Без калькулятора это спор о процентах. С ним — спор о цифрах.

Сначала — посчитали. Потом — описали в SLOzy и получили дашборды. Потом — наблюдаем в Grafana, сходятся ли предположения с реальностью.

Три инструмента замыкают цикл SRE: проектирование → автоматизация → наблюдение.



Далее: GrafanaSmith — дашборды из кода