Проблема: разработчики (и менеджеры) часто не понимают, что означает "три девятки". А уж тем более, что за этим стоит в реальности. Многие думают, что 99.9% аптайма – это почти идеальная работа сервиса. На деле эта цифра означает, что ваш сервис может лежать до 8 часов 45 минут в год. И это при условии, что у вас один единственный компонент.
А если компонентов несколько?
Представьте, что вы зависите от AWS, Cloudflare и Stripe. У каждого из них по 99.9% аптайма. Что получится на выходе?
0.999 × 0.999 × 0.999 = 0.997 = 99.7%
А это уже почти 2.2 часа простоя в месяц. Причём это ещё до того, как сломалось что-то ваше собственное.
Но ведь это всего пару часов в месяц?
Да, но не всё время простоя одинаково. Пять минут в пятницу вечером, когда у вас пиковая нагрузка, могут стоить больше, чем час простоя ночью в воскресенье. А цифры в SLA этого не показывают.
Как добиться реальной надёжности
Переход от 99.9% к 99.99% — это не просто настроить алерты получше. Это:
Использование нескольких регионов
Автоматическое восстановление без ручного вмешательства
Стратегия "что делать, если всё сломалось"
И главное – это заранее проработанный план действий: кто, что и когда делает, если что-то идёт не так.
А как считать даунтайм?
Когда будете писать SLA, обязательно уточните, что вы считаете за даунтайм. Часто туда не включают плановое обслуживание или сбои у партнёров. Это нормально – главное, чтобы это было прописано.
Аптайм – это просто число. Надёжность – это как вы его достигаете.
Если у вас есть свои формулы расчета аптайм в своих проектах, поделитесь, буду рад обсудить. Кстати, а что у вас с планом восстановления?
fossfusion
Мне кажется, в этой статье не хватает вступления, основной части и заключения
ky0
Ну что ж вы, ждёте, что Senior Cloud Applications Developer возьмёт и напишет - "не хотите зависеть от надёжности облаков, делайте на своём железе"? :)
fossfusion
Жду чего-то, что по смысловому содержанию больше заметки, которую нацарапали на салфетке