Поговорим еще раз про даунтаймы, а именно, про восстановление работы после них. Записывайте себе в конспект, это будет на экзамене (ну если будете сдавать
AWS Solution Architect).Никто не хочет, чтобы их инфраструктура или приложения падали, но это все равно происходит. Поэтому главное, что должен сделать Хороший разработчик, это быть готовым к этому событию.
Когда мы планируем reliability и availability нашего решения, мы хотим, чтобы наш сервис восстанавливался быстро и без потери информации. Чтобы формализовать эти требования, мы можем определить два параметра —
RTO (Recovery Time Objective) и RPO (Recovery Point Objective).RTO. Сколько времени максимально, наше решение должно восстанавливаться после инцидента. Например, ⚡️ ударила прямо в наш сервер, через сколько времени наш сервис должен опять работать и работать нормально? Этот параметр поможет нам определиться с availability стратегией.
Если для восстановления работы нам нужно заказать и настроить новый сервер, то на это может уйти день. А если у нас всегда параллельно работает такой же сервер, и нам нужно только переключить трафик — то минуты.
RPO. Потерю какого количества актуальной информации может “стерпеть” компания? Измеряется во времени. Например, 🦡 перегрыз провода, произошло замыкание и сгорел
HD. Данные за последние два часа нельзя восстановить. Это приемлимо? Зная RPO можно определиться со стратегией резервного копирования.Определение
RTO и RPO это бизнес задача, в которой учитывается пользовательский опыт, возможные финансовые потери от даунтайма, репутационные потери. А вот реализация этих требований, это уже задача Хорошего разработчика. Очевидно, что чем строже требования, тем дороже будут ежедневные траты на поддержку этих требований 💸.⬛️ Еще раз — Хороший разработчик готов к тому, что все сломается. На этот случай у него есть стратегия. Хорошо, когда эта стратегия подготовлена на основе бизнес требований, которые формализованы в
RTO и RPO.У вас в команде определены эти параметры? Пишите в комментариях.
#хардскиллы, 🌄Instagram |🤝Patreon
