SRE Maturity Assessment

«Мы на третьем уровне зрелости». После этой фразы я спрашиваю, что из неё следует, и чаще всего не следует ничего. Я регулярно вижу оценку, которая заканчивается числом: его показывают на слайде, сравнивают с соседней командой и убирают до следующего года. Работа проделана честная, а план после неё остался прежним.

SRE Maturity Assessment — периодическая оценка того, насколько развиты практики надёжности у команды или сервиса. Она идёт по нескольким областям, по шкале, записанной заранее, и с доказательством под каждый уровень. Итогом служит короткий список: два-три шага на ближайшие полгода и то, чем команда в эти полгода заниматься не будет.

Границы с соседями. Иерархия надёжности задаёт порядок, в котором практики строятся в сервисе; шкала зрелости говорит, насколько развита каждая из них. Это разные вопросы, и путают их постоянно. Team Topologies отвечает за организационную форму, DORA Metrics меряют результат поставки, а не практики. Месячный срез живёт в SLO / Budget Review; оценка зрелости медленнее и приходит раз в полгода.

Что должен уметь

Главный навык на уровне L5 — превратить оценку в отказ. Найти шесть областей, где команда отстаёт, умеет любой, кто прочитал шкалу. Выбрать из них две и вслух сказать про остальные четыре «не сейчас» гораздо труднее. По моим наблюдениям, оценка без такого отказа всегда кончается планом подтянуть всё сразу, и через полгода не подтянуто ничего.

Участвует в оценке своей команды: приносит доказательства по своей области и отличает «документ есть» от «практика работает».
Читает шкалу до оценки и задаёт вопросы к формулировкам уровней, пока их ещё можно поправить.

Проводит оценку сервиса по готовой шкале: уровень ставит по ссылке, числу или документу, а не по ощущению команды.
Засчитывает уровень, только когда выполнены все предыдущие, и записывает, чего не хватило до следующего.
Формулирует шаг так, чтобы следующая оценка могла его проверить: владелец, срок и признак, по которому уровень изменится.

Правит описания уровней под свою организацию до первой оценки и после неё не меняет, чтобы оценки оставались сравнимы.
Назначает целевой уровень по критичности сервиса и объясняет, почему для внутреннего инструмента третий уровень — разумный потолок.
Сводит результат к двум-трём шагам и явно называет области, которые в этот раз остаются без изменений.
Дописывает раздел о том, чего шкала не видит: дежурства, отношения с продуктом, зависимости от других команд.

L6+

Не даёт оценке стать показателем работы команды и основанием для рейтинга: как только за уровень начинают спрашивать, его начинают подрисовывать.
Использует оценки нескольких команд для решений о вложениях, а не для сравнения команд между собой.
Проверяет поверх шкалы главное: меняются ли после инцидентов правила, лимиты и проверки, или разбор остаётся ритуалом.

Материалы

Книги

Steve McGhee, James Brookbank — Enterprise Roadmap to SRE (Google). Отчёт о разрыве между энтузиазмом по поводу SRE и тем, насколько скромно он приживается в больших организациях. Начинается с оценки существующей среды и ожиданий, то есть с той же точки, что и этот лист.

Статьи и доклады

Martin Fowler — Maturity Model (2014). Обязательно прочитать до первой оценки. Одна мысль оттуда стоит всей остальной литературы по теме: настоящий итог оценки — не уровень, а список того, над чем работать дальше.
r9y.dev — карта практик надёжности, разложенная по эрам от 90,0% до 99,999% доступности, с действиями для разработки, инфраструктуры и работы с людьми. Лучшая из известных мне моделей в одном отношении: ступень привязана к результату, а не к установленной оснастке.
Microsoft — Reliability Maturity Model (Azure Well-Architected Framework). Пять уровней от Get resilient до Stay resilient. По моим наблюдениям, из опубликованного это ближе всего к готовой лестнице для надёжности; полезна она ещё и тем, что у каждого уровня названы компромиссы и риски, а не только достижения.
CNCF — Cloud Native Maturity Model. Пять уровней, и на каждом четыре измерения: люди, процесс, политика, технология. Пример модели, где одна шкала сознательно заменена сеткой.
Мой разбор — Digital Immune System: инженерия устойчивости как продукт (jtprog.ru, август 2026). В разделе «Чужие лестницы зрелости» сравниваю готовые модели и прихожу к выводу, на котором стоит этот лист: по моим наблюдениям, зрелость точнее описывает замкнутая петля, чем этаж, на который поднялся и остался.

Инструменты

Таблица областей и уровней — markdown в репозитории команды или обычная электронная таблица. По моим наблюдениям, чаще берут именно её: оценка раз в полгода не оправдывает отдельного инструмента, а сравнить две таблицы можно глазами.
Карта r9y.dev как готовая шкала — имеет смысл, когда своей шкалы нет и писать её некому. Цена понятная: чужие формулировки уровней придётся принять как есть.
Опрос команды — быстрый способ собрать ощущения, но не замена доказательствам. Ощущение почти всегда выше факта, поэтому опрос я беру только как повод для разговора.

Шаблоны

Оценка зрелости SRE — заготовка из этого репозитория: шесть областей на шкале от 0 до 5, уровень с доказательством, целевой уровень, план и сравнение с прошлой оценкой. Шкала в ней авторская, это сказано в шапке.
Ежемесячный SRE Review — повестка месячного обзора операционных практик. Между двумя оценками зрелости он показывает, движется ли что-нибудь.

Best practices

Общепринятой модели зрелости SRE нет, и это видно, если положить рядом три публичные. У Microsoft пять уровней названы по тому, чему учится команда: от Get resilient до Stay resilient. У CNCF тоже пять, но это стадии освоения cloud native, и каждая расписана по четырём измерениям. Карта r9y.dev делит путь по девяткам доступности, от 90,0% до 99,999%. Совпадает только привычка к числу пять. Основания деления у всех разные, и команда, которая по одной модели стоит на четвёртой ступени, по другой окажется на второй.

Я вывожу из этого простое правило: шкалу выбирают один раз и дальше сравнивают себя только с собой. Заготовка в этом репозитории устроена так же. Её шкала ни у кого не взята, в шапке шаблона это написано прямо, и описания уровней предлагается поправить до первой оценки. После первой оценки они замораживаются, иначе вторую не с чем сравнить.

Итог оценки — список, а не уровень. У Мартина Фаулера это сказано в одной фразе: уровень служит промежуточным результатом, нужным только затем, чтобы понять, чему учиться дальше. На практике фраза переводится в жёсткое ограничение. Из оценки выходят два-три шага, у каждого есть владелец и признак, по которому следующая оценка увидит изменение. План поднять все области сразу — верный знак, что оценка была проведена ради числа.

Одна шкала прячет отстающую область. Лестница из пяти ступеней удобна тем, что даёт один номер, и ровно этим плоха: телеметрия у команды может быть на четвёртой ступени, а разбор инцидентов на первой, и среднее «около трёх» не говорит ни о том, ни о другом. Поэтому я оцениваю по областям и смотрю на разрыв между ними. Самый большой разрыв обычно важнее самого низкого уровня.

Уровень ставится по доказательству. «У нас есть постмортемы» — это ещё не третий уровень. Третий начинается со ссылки на последний разбор и на задачи, которые после него закрыты. Правило отнимает у оценки лёгкость и возвращает ей смысл: без него команда оценивает свои намерения. Там, где доказательства нет, честная оценка — предыдущий уровень.

Высший уровень не обязан быть целью. Во многих лестницах наверху стоит автоматика, которая чинит систему сама, и её охотно продают как то, с чего начинают. Мне ближе другой критерий, и он не про автоматику. После инцидента что-то меняется в правилах: появляется проверка, сдвигается лимит, переписывается политика. Если цикл «инцидент, разбор, изменение правил» замыкается, команда зрелая на любом уровне шкалы. Если не замыкается, пятый уровень по телеметрии ничего не значит.

У оценки зрелости есть условия, при которых она не работает, и главное из них одно: оценку нельзя привязывать к вознаграждению и к рейтингу команд. Как только за уровень спрашивают, шкала перестаёт что-либо мерить. Второе условие — масштаб. Команде из пяти человек с одним сервисом полноценная оценка почти бесполезна: все пробелы и так на слуху, хватит часа у доски. Третье — частота. Уровни меняются медленно, и оценка чаще раза в полгода показывает шум, а не движение.

Связанные листья

SLO / Budget Review — месячный ритм, в котором видно, выполняются ли шаги из оценки.
Team Topologies — организационная форма; оценка зрелости часто показывает, что разрыв лежит в ней, а не в инструментах.
DORA Metrics — результат поставки в числах. Хороший второй взгляд: практики выросли, а метрики стоят — значит, оценка была щедрой.
Postmortem Culture — откуда берётся цикл «инцидент, разбор, изменение правил», которым я проверяю зрелость поверх шкалы.
Career Ladders — зрелость человека, а не команды; это другой предмет и другая шкала.
Production Readiness Review — оценка одного сервиса на рубеже; оценка зрелости смотрит на команду во времени.

Открытые вопросы

Порядок уровней в собственной шкале я не считаю доказанным. В области мониторинга у меня логи и трассировки стоят выше алертинга, а SLO оценивается отдельной строкой, и я знаю модели, где порядок обратный. Проверить шкалу можно только одним способом: пройти по ней несколько команд и посмотреть, не перескакивает ли кто-нибудь через уровень. Таких данных у меня нет.

Рядом лежит оценка организации целиком. Шесть областей описывают команду и сервис, но не то, как принимаются решения о надёжности выше команды: кто может остановить релизы, есть ли у надёжности цена в деньгах, кто отвечает за сквозные зависимости. Это отдельная ось, и хорошей шкалы для неё я не видел.

И самооценка против взгляда со стороны. Своя команда знает больше, чужой рецензент льстит меньше. Какое сочетание даёт честный результат при разумных затратах, я не знаю. Если у вас есть опыт перекрёстных оценок между командами, расскажите через PR.