Методология

Этот документ фиксирует методологический каркас проекта: принцип разделения трёх ветвей роадмапа, политику контроля детализации и оси приоритетности. Документ — первичный источник правды; все решения о структуре графа и наполнении листьев должны опираться на него.

Зачем нужен этот документ

Предыдущие итерации роадмапа в Obsidian Canvas и Excalidraw разрастались до ~200 узлов и теряли навигабельность. Mermaid-графы L1+L2 inventory тоже начинали дрейфовать в ту же сторону — в граф попадал конкретный тулинг (Prometheus, Grafana, Terraform и т.п.), а компетенции дублировались между ветвями (Knowledge Management, Capacity Planning, Disaster Recovery, SLO-семейство).

Внешнее ревью методологии указало на корень проблемы: три ветви плохо разделены, а форма проекта колеблется между «эссе» и «паучком». Этот документ закрепляет один полюс — визуальная карта компетенций с минимумом текста, где листья несут материалы и best practices, а не пересказ теории.

Принцип разделения ветвей

Критерий, по которому компетенция относится к ветви, — главный объект деятельности.

Ветвь	Главный объект	На что направлена деятельность
SRE Culture	Люди и нормы	Договорённости, отношения, обмен опытом, метрики как инструмент разговора
SRE Engineering	Технические артефакты	Код, инфраструктура, инструменты наблюдаемости и автоматизации
SRE Practices	Процессы и ритуалы	Последовательность действий, операционная зрелость, повторяемые сценарии

Формулировка проверочного вопроса: «Что именно изменяется в результате этой деятельности — отношения между людьми, состояние системы или ход процесса?» Ответ определяет ветвь.

Как разрешаются пересечения

Компетенция, которая на первый взгляд относится к нескольким ветвям, разводится одним из трёх способов:

1. Перенос. Применяем критерий «главный объект» и помещаем компетенцию в одну ветвь. Пример: Capacity Planning имеет главным объектом инфраструктуру → SRE Engineering. Упоминание в IT Management под Culture снимается.

2. Разделение на разные концепты. Если за одним именем скрываются методологически разные сущности, они получают разные имена и разводятся по ветвям. Пример: Postmortem как ритуал (формат встречи, action items) → Practices; Postmortem Culture как норма (blameless-принцип, психбезопасность) → Culture.

3. Cross-link с обоснованием. Если компетенция действительно живёт на стыке и развести её — значит исказить смысл, она остаётся в одной ветви, а в другой появляется ссылка на тот же лист с явной пометкой «cross-link». Это исключение, а не правило; каждый случай документируется в inventory/overlaps.md в репозитории.

Дубль имени компетенции в двух ветвях без явной пометки cross-link — дефект, который чинится по таблице пересечений.

Политика контроля детализации

Цель — удержать роадмап в формате читаемой карты, а не графа на 200 узлов.

Лимиты графа

• Глубина. Не более двух уровней под ветвью: Branch → L1 → L2. Всё, что концептуально требует третьего уровня, выносится в leaf-страницу.
• Ширина L1. Не более 7 узлов первого уровня на ветвь.
• Ширина L2. Не более 5 узлов второго уровня под одним узлом L1.
• Целевой бюджет графа. Не более 80 узлов суммарно по трём ветвям. Если бюджет превышен, пересматривается разбиение, а не лимит.

Что не попадает в граф

• Конкретный тулинг. Названия продуктов (Prometheus, Grafana, Loki, Tempo, Terraform, ArgoCD, k6, Gatling и т.п.) не являются узлами графа. Они живут в секции «Материалы» соответствующего листа.
• Языки, утилиты, форматы. bash, jq, sed, awk, конкретные дистрибутивы Linux — материалы, не узлы.
• Внешние стандарты. SFIA-уровни, методики SRE Book — не узлы, а атрибуты листьев и контекст документа.

В графе живут концепты компетенций: «Metrics», «Distributed Tracing», «IaC», «Load Testing», «SLI-based Alerting». Один концепт — один узел.

Бюджет узлов на ветвь

Ориентировочное распределение бюджета 80 узлов:

• SRE Culture — ~20 узлов
• SRE Engineering — ~35 узлов
• SRE Practices — ~25 узлов

Распределение неравномерное: Engineering объективно шире по техническому стеку, и это нормально, пока удерживаются лимиты глубины и ширины.

Две независимые оси развития

Роадмап оперирует двумя ортогональными осями: priority (обязательность для роли) и SFIA (уровень зрелости инженера). Компетенция может быть Must Have даже на L3 (Junior) или Nice to have на L6+ (Principal). Не путать.

Priority — обязательность для роли

• 🔴 Must Have — без компетенции инженер не может выполнять основную работу.
• 🟡 Mandatory — компетенция, которой ожидаемо владеет любой SRE на стабильном этапе работы.
• 🟢 Nice to have — расширяет возможности, но не блокирует.
• 🔵 On Demand — изучается, когда проект требует.

Priority L1 живут только в src/data/roadmap.ts (поле priority). Цветовая разметка на странице /priorities/ генерируется из этого поля автоматически.

SFIA — уровень зрелости инженера

Хранится в :::note[Метаданные листа] callout каждой leaf-страницы (поле SFIA-уровни), уровни 3..7 соответствуют Junior → Principal. См. фреймворк SFIA.

В данных roadmap.ts SFIA-уровни не отражаются — для них есть отдельный источник (метаданные внутри листа).

Чек-лист перед коммитом изменений в граф или листья

• Новый узел проходит по критерию «главный объект деятельности» — однозначно одна ветвь.
• Узел не дублирует уже существующий в другой ветви (если дублирует — фиксируется в inventory/overlaps.md и решается переносом / разделением / cross-link).
• Глубина не превышает L2; иначе содержимое уходит в leaf-страницу.
• Ширина не превышает лимиты (7 / 5).
• В графе нет названий продуктов; тулинг помещён в материалы листа.
• Целевой бюджет (80 узлов) не превышен.

Источники структуры

Структура графа компетенций распределена по нескольким файлам, каждый отвечает за свой срез. Это важно знать, чтобы при правках не дублировать данные и не вызывать рассинхрон.

Файл	За что отвечает	Чего там НЕТ
src/data/roadmap.ts	L1-узлы каждой ветви и их порядок, priorities L1, leaves под L1	L2 концепты, SFIA-уровни
src/content/docs/sre-{culture,engineering,practices}.mdx	L1 + L2 inventory концептов (как nested list под каждым L1)	priorities, leaves (рендерятся из roadmap.ts через BranchView.astro)
inventory/overlaps.md (в репозитории, не на сайте)	решения по пересечениям компетенций между ветвями	сами компетенции
src/content/docs/leaves/<branch>/<slug>.md	содержимое одного листа: умения / материалы / best practices / связанные	priorities (там — в roadmap.ts)

Инвариант L1. Набор и порядок L1 в roadmap.ts должен совпадать с L2-inventory секциями в sre-{culture,engineering,practices}.mdx. При изменении L1 (переименование, добавление, удаление) — синхронизировать оба источника одним PR.

Priorities L1 живут только в roadmap.ts. Цветовая разметка на странице /priorities/ генерируется автоматически.

L2 концепты живут только в L2-inventory секциях sre-{culture,engineering,practices}.mdx. Это потенциальные подкомпетенции; не каждый L2-узел становится leaf-страницей.

Leaves регистрируются в roadmap.ts под соответствующим L1; исходники — в src/content/docs/leaves/<branch>/<slug>.md.

Внешние источники методологии

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

• Google SRE Book — каноничная книга про SRE-практики и принципы.
• Google SRE Workbook — прикладные приёмы (SLO, alerting on SLOs, on-call); главный источник по SLI-based алертингу.
• SFIA — DevOps View — формальная рамка уровней зрелости компетенций; используется в :::note метаданных листьев как SFIA-уровни.
• DORA Research — эмпирика производительности команд доставки; источник DORA-метрик и базы для разделения ветвей.

Эти ссылки — фундамент, на котором строится граф и листья. Конкретные материалы по каждой компетенции (книги, статьи, доклады, инструменты) живут в секции «Материалы» соответствующего листа, а не здесь.

Связанные документы

• Мотивация — зачем существует проект, для кого, дисклеймер.
• Формат проекта — как устроена карта, шаблон листа, правила контрибуции.
• inventory/overlaps.md — все известные дубли L1/L2 и принятые решения (рабочий артефакт в репозитории).
• inventory/tlroadmap-review.md — что у соседнего проекта берём, что не берём (рабочий артефакт в репозитории).
• Шаблон листа — src/content/docs/leaves/_template.md в репозитории (Astro игнорирует _-префиксированные файлы, поэтому шаблон не публикуется как страница, но виден в GitHub UI).