Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. В этот раз я решил помочь вам посмотреть на свою работу в отношении надежности. Особенно полезно будет тем, у кого официально нет SR-инженеров в штате.
"У нас нет SRE"
Знакомая фраза? Слышал её не раз – от руководителей, от коллег из других компаний.
Интуитивно многие думают: "Раз у нас нет SR-инженера – значит, мы ничего не делаем для надёжности". Но давайте взглянем честно. У вас есть:
дежурства, хоть и без чёткого расписания
мониторинг, даже если он посылает алерты в один общий Telegram-чат
инженер, который каждую неделю правит пороговые значения, потому что "опять всё красное"
обсуждения инцидентов, пусть и в виде двух строк в Jira: "Сервис упал из-за OOM. Увеличили лимиты"
Вы не "ничего не делаете". Вы реагируете, пытаетесь понять, что-то чините. Просто не называете это SRE – и не видите, куда двигаться дальше.
Как увидеть то, что уже есть
Если вы читаете это – скорее всего, в вашей команде уже есть практики, связанные с надёжностью. Просто они разрознены, не названы и не связаны в единую картину.
Чтобы это увидеть, вы можете сами посмотреть на карту развития надёжности – r9y.dev (в англоязычном сегменте ее часто упоминают как SRE Maturity Map). Эта карта создана сообществом на основе реального опыта, а не только книг Google. Вот тут даже есть ее видопрезентация от авторов https://www.youtube.com/watch?v=e_OD4AnxICg.
На карте надёжности вы увидите несколько областей, обозначенных по доступности: 90%, 99%, 99.9% и так далее. Визуально это вертикальные столбцы, каждый – набор практик.
В своей практике я иногда прошу помочь коллег "со стороны" – не как экспертов, а как зеркало. Иногда свежий взгляд помогает увидеть очевидное. Но чаще всего – карта и честный разговор в команде дают тот же эффект. Ведь карта развития надёжности – это вовсе не «чек-лист для идеальных команд». Это визуальный справочник практик.
Каждая точка на карте – это конкретная практика развития надёжности, например:
Проведение постмортемов без поиска виноватых
Обеспечение плавной деградации вместо полного отказа
Использование канареечных релизов для снижения риска
Кликаете на название в карте и там ссылка с подробным описанием практики.
И вот когда вы проходите по карте взглядом, вы неизбежно ловите себя на мысли:
> "А это мы уже делаем".
> "А вот это – совсем не делаем, но больно без этого".
> "А здесь у нас странная смесь: половина из 99%, половина – из 90%".
Именно в этот момент вы понимаете:
“Так мы то, оказывается, не начинаем с нуля. Мы уже кое в чем преуспели!”
Карта развития != модель зрелости SRE
Многие называют r9y.dev "картой зрелости SRE" (SRE Maturity Map). Но это легко понять неправильно.
На самом деле это интерактивная дорожная карта практик, где:
Вы не обязаны проходить уровни по порядку
Вы можете брать практики из одного столбца или нескольких разных – в зависимости от того, где ваша боль и какие риски вы готовы нести.
Цель – не "достичь максимальных девяток", а понять, сколько непрерывности реально нужно вашему бизнесу.
Каждый пункт — это практика, а не роль. И у вас, скорее всего, что-то уже есть.
Как говорит r9y.dev:
"…to achieve the appropriate number of “nines” you need to provide value to your customers"
Ключевое слово – "appropriate". Значит достаточное, а не "максимальное".
Что может быть достаточным?
При 90% – система может быть недоступна 36.5 дней в год
При 99% – 3.65 дня
При 99.9% – 8.76 часов
Это не какой-то стандарт, который заставляет выбирать "одно из". Спросите себя: сколько ваш бизнес может себе позволить?
Важно: не все сервисы требуют одинаковой надёжности.
У вас может быть платёжный модуль на 99.95%, а внутренний дашборд аналитики – на 90%. И это нормально.
r9y.dev не требует единых девяток для всей компании. Наоборот – он помогает выбрать для каждой области свой достаточный уровень и соответствующий набор практик.
Инвестируйте в надёжность там, где это действительно важно – для пользователей и для бизнеса.
Что делать — и чего не делать
Не сравнивайте себя с Google
Не пытайтесь покрыть все области (столбцы) и пункты карты
Не внедряйте SLO, если у вас нет даже базового процесса обработки инцидентов
Вместо этого:
1. Откройте карту развития надежности
2. Пройдитесь по областям (столбцам) и точкам в них
3. Отметьте всё, что вы уже делаете – даже если это "только дежурства"
4. Спросите коман��у: "Какая наша самая острая боль? Где один шаг даст максимальный эффект?"
Замечу, что карта не говорит вам: "Вы отстаете". Она показывает: "Вот что можно улучшить – здесь и сейчас"
SRE – это то, как вы думаете
Если вы:
Спрашиваете: «Как это повлияло на пользователя?»
Пытаетесь измерить, а не гадать
Ищете системные причины, а не виноватых
– вы уже делаете SRE.
Просто ещё не назвали это своим именем.
Послесловие
Этот пост – не призыв "внедрять SRE". Это напоминание: вы не начинаете с нуля. Вы уже на пути. Осталось только увидеть это – и выбрать направление осознанно.
Предыдущие материалы по теме
И несколько вопросов хотелось бы обсудить:
Есть ли у вас сервисы, где "достаточно" 90% надёжности – и почему вы не стремитесь повысить её?
Какая SRE-практика у вас уже "работает сама собой" – хотя вы никогда не называли её так?
