Спасибо за замечание! 🙌 Вы абсолютно правы — корректнее было бы подписать линию как «SLO (целевой уровень доступности)», а не «стабильность». Доступность действительно измеряется в процентах, а стабильность — более широкое понятие (MTBF, отсутствие сбоев и т.п.). В статье я имел в виду именно доступность по SLO. Поправлю, чтобы не путать термины.
Раньше дежурства у нас действительно были «за спасибо» просто часть обязанностей, без всякой компенсации. Сейчас подход поменяли: ночные срочные подъёмы всё ещё остаются обязанностью инженеров, но за это дают полноценный отгул (как оплачиваемый выходной) на следующий день. Это сильно сглаживает нагрузку: можно спокойно выспаться и восстановиться.
Точно ранбуки это первый шаг, а второй это превратить его в скрипт/автоматизацию. Мы тоже так пошли часть шагов из ранбука обернули в Ansible-скрипты, кое-где добавили auto-healing в Kubernetes. Теперь часть проблем чинится сама, а дежурный просто получает уведомление
Полностью согласен. Я и писал скорее из перспективы небольшой команды, где приходится совмещать роли DevOps/SRE и первой линии. Runbook-и и грамотный on-call сильно спасают, пока не выросли до масштаба с полноценной поддержкой.
А дальше уже логично строить отдельный саппорт и разгружать инженеров, иначе, как вы и сказали, дежурства линейных специалистов начинают работать в минус.
Ох, знакомая боль 😅 У меня раньше тоже каждый алерт был как загадка на «угадай сервис по намёку». В итоге понял, что без runbook-ов и нормальной фильтрации это чисто игра в рулетку.
Спасибо за замечание! 🙌 Вы абсолютно правы — корректнее было бы подписать линию как «SLO (целевой уровень доступности)», а не «стабильность». Доступность действительно измеряется в процентах, а стабильность — более широкое понятие (MTBF, отсутствие сбоев и т.п.). В статье я имел в виду именно доступность по SLO. Поправлю, чтобы не путать термины.
мем нашел
Раньше дежурства у нас действительно были «за спасибо» просто часть обязанностей, без всякой компенсации. Сейчас подход поменяли: ночные срочные подъёмы всё ещё остаются обязанностью инженеров, но за это дают полноценный отгул (как оплачиваемый выходной) на следующий день. Это сильно сглаживает нагрузку: можно спокойно выспаться и восстановиться.
Точно ранбуки это первый шаг, а второй это превратить его в скрипт/автоматизацию. Мы тоже так пошли часть шагов из ранбука обернули в Ansible-скрипты, кое-где добавили auto-healing в Kubernetes. Теперь часть проблем чинится сама, а дежурный просто получает уведомление
Полностью согласен. Я и писал скорее из перспективы небольшой команды, где приходится совмещать роли DevOps/SRE и первой линии. Runbook-и и грамотный on-call сильно спасают, пока не выросли до масштаба с полноценной поддержкой.
А дальше уже логично строить отдельный саппорт и разгружать инженеров, иначе, как вы и сказали, дежурства линейных специалистов начинают работать в минус.
Ох, знакомая боль 😅 У меня раньше тоже каждый алерт был как загадка на «угадай сервис по намёку». В итоге понял, что без runbook-ов и нормальной фильтрации это чисто игра в рулетку.
Спасибо за внимательность! 🙌 Это моя опечатка — имелось в виду SLI (Service Level Indicator), а не «SOI». Уже поправил в тексте.