Компас методологий

Ключевая идея

TODOIT: System Exposure Framework отвечает на вопрос «что не так и куда двигаться» — это диагностика. ITIL, DevOps, Agile, SRE, ISO 22301 и похожие подходы отвечают на вопрос «как чинить» — это лечение: практики, процессы и инженерные инструменты. Если нужно понять, чем TODOIT отличается от FAIR или ISO 22301 — см. сравнение подходов.

Раздел полезен после первой оценки по методологии и когда вы составляете план работ — вместе с полным отчётом. Здесь нет новых формул из частей 2–7: это практическая подсказка, как типичные на рынке практики согласуются с вашими показателями и факторами TODOIT.

В разделе «Сравнение подходов» разобраны сами подходы — что измеряют FAIR, ISO 22301, SRE и т.д. Здесь — что делать дальше после диагностики TODOIT: какой тип практик обычно подходит под какой индекс или фактор.

ITIL, DevOps и SRE намеренно пересекаются по темам (инциденты, изменения, CI/CD). Строки таблиц ниже — ориентиры, а не жёсткие «один к одному» соглашения.

После оценки у вас есть профиль (FS, MS, RS, AS) и очередность внимания по логике MS → FS → RS → AS. Ниже — справочник методологий, матрица соответствия, схемы потока и детальная карта по осям.

Уточнение про SRM. В этом разделе под этим сокращением имеется в виду только Supplier Risk Management — управление рисками поставщиков. Названия HA (High Availability), отказоустойчивость и запас по мощности (capacity) к нему не относятся: иначе смешиваются разные задачи.

Справочник методологий

В прикладной литературе и стандартах эти объекты обычно относят к разным «семействам»: ITSM, инженерия надёжности, поставка ПО, непрерывность бизнеса, управление рисками цепочки поставок, проектирование предметной области. Ниже — нейтральные определения без привязки к конкретной оценочной модели; они не подменяют официальные источники и используются как вводный ориентир.

Во второй колонке таблицы показано, к каким осям и факторам методология чаще всего подключается в логике TODOIT (FS, MS, RS, AS, факторы F/C/R/A/M). Это эвристика для планирования, а не расширение формальных формул.

SRE — развёрнутое описание

Инженерная практика SRE отвечает за бесперебойную работу сервисов — с соблюдением заранее оговорённого уровня надёжности.

• SLO и SLI — договорённости о том, каким должен быть сервис с точки зрения пользователя: доступность, время отклика, задержки и другие метрики качества.
• Error budget — допустимый объём сбоев или простоя: «запас прочности», показывающий, сколько нарушений система может «потратить», прежде чем потребуется снизить темп релизов.
• Баланс скорости и стабильности — отдельно согласуется, насколько быстро можно внедрять изменения, не жертвуя стабильностью сервиса.
• Инцидентная культура — быстрая реакция на инциденты, их разбор и внедрение улучшений, чтобы снизить вероятность повторения.

Матрица «проблема → методология»

Одна строка — типичный триггер по индексу или фактору; в реальной системе срабатывают несколько строк одновременно. Выбор практик итеративный; порядок MS → FS → RS → AS задаёт фокус, а не запрет на параллельные работы.

Поток: от диагностики к лечению

Иллюстрация типовых маршрутов «профиль → классы практик», а не полная классификация всех комбинаций FS, MS, RS, AS. При расхождении с вашим профилем приоритет у текстовых правил интерпретации и полного отчёта.

[ TODOIT Диагностика ]
        │
        ▼
   { Профиль системы }
        │
        ├─ MS < 3.0 ──► Стабилизация ──► ITIL 4, DevOps
        ├─ MS ≥ 3.0 и FS ≥ 3.0 ──► Снижение хрупкости ──► HA/DR, SRE
        ├─ FS < 3.0 и RS < 3.0 ──► Укрепление устойчивости ──► ISO 22301
        └─ FS < 3.0, RS ≥ 3.0, AS < 3.0 ──► Антихрупкость ──► Agile, Chaos
        │
        ▼
   [ Повторная оценка TODOIT ] ──► (цикл)

flowchart TB
    Start["TODOIT Диагностика"] --> Profile{"Профиль системы"}
    Profile -->|MS < 3.0| Stabilize["СТОП-ЛИНИЯ: Стабилизация"]
    Profile -->|MS ≥ 3.0 и FS ≥ 3.0| ReduceFrag["Снижение хрупкости"]
    Profile -->|FS < 3.0 и RS < 3.0| StrengthenRes["Укрепление устойчивости"]
    Profile -->|FS < 3.0, RS ≥ 3.0, AS < 3.0| Evolve["Развитие антихрупкости"]
    Stabilize --> ITIL["ITIL 4: Change & Incident Mgmt"]
    Stabilize --> DevOps["DevOps: CI/CD, Observability"]
    ReduceFrag --> HA_DR["HA / DR архитектура"]
    ReduceFrag --> SRE["SRE: Circuit Breaker, Bulkhead"]
    StrengthenRes --> ISO22301["ISO 22301: BCM, DRP, RTO/RPO"]
    Evolve --> Agile["Agile / Lean: Post-Mortem"]
    Evolve --> Chaos["Chaos Engineering: GameDays"]
    ITIL & DevOps & HA_DR & SRE & ISO22301 & Agile & Chaos --> ReEval["Повторная оценка TODOIT"]
    ReEval --> Profile

Детальная карта по осям

Ось 1: управляемость (MS) — приоритет №1

Ось 2: хрупкость (FS) — приоритет №2

Ось 3: устойчивость (RS) — приоритет №3

Ось 4: антихрупкость (AS) — приоритет №4

Жизненный цикл улучшения

Цепочка P1→…→P4 — мнемоника порядка внимания (MS → FS → RS → AS), а не взаимоисключающий алгоритм: на практике работы по осям перекрываются; критерий — где узкое место по профилю.

Диагностика → Приоритизация → Лечение → Контроль → (повтор)
  FS/MS/RS/AS     MS? FS? RS? AS?    ITIL/DevOps/HA/BCM/Chaos
  EX/SQI/SEI                      Повторная оценка, дорожная карта

flowchart LR
    subgraph Diag["TODOIT Диагностика"]
        D1["Оценка FS/MS/RS/AS"]
        D2["Расчёт EX/SQI/SEI"]
        D3["Категория системы"]
    end
    subgraph Prior["Приоритизация"]
        P1{"MS < 3.0?"}
        P2{"FS ≥ 3.0?"}
        P3{"RS < 3.0?"}
        P4{"AS < 3.0?"}
    end
    subgraph Treat["Методологии лечения"]
        T1["ITIL / DevOps: Стабилизация"]
        T2["HA / SRE: Снижение хрупкости"]
        T3["ISO 22301 / BCM: Устойчивость"]
        T4["Agile / Chaos: Антихрупкость"]
    end
    subgraph Control["Контроль результата"]
        C1["Повторная оценка TODOIT"]
        C2["Сравнение индексов"]
        C3["Обновление дорожной карты"]
    end
    Diag --> Prior
    Prior --> P1
    P1 -->|Да| T1
    P1 -->|Нет| P2
    P2 -->|Да| T2
    P2 -->|Нет| P3
    P3 -->|Да| T3
    P3 -->|Нет| P4
    P4 -->|Да| T4
    T1 & T2 & T3 & T4 --> Control
    Control --> Diag

Дорожная карта на 12 месяцев

Последовательность кварталов отражает порядок осей MS → FS → RS → AS; реальные программы могут перекрывать кварталы. Ниже — пример, а не универсальный календарь.

Ожидаемый результат за год (условный ориентир для калибровки плана, не следствие формул):

• SQI: 0.5 → 1.5+ (баланс управляемости и хрупкости)
• SEI: 0.5 → 2.0+ (потенциал эволюции)
• EX: возможное снижение порядка 40–60% при существенном снижении FS при неизменном L — пересчитывайте по EX = FS × L после повторной оценки

Пример: легаси-монолит

Сценарий из методологии (в т.ч. EX = 17.96, SQI ≈ 0.58, SEI ≈ 0.93).

Диагноз TODOIT

• FS = 4.49 — критическая хрупкость
• MS = 2.6 — слабая управляемость
• RS = 2.0 — низкая устойчивость
• AS = 1.6 — нет обучения на инцидентах
• Категория: кризис

План действий по методологиям

Ожидаемый результат через 6 месяцев

Иллюстративная цель плана; сверка категории — по правилам интерпретации методологии.

• FS: 4.49 → 3.0
• MS: 2.6 → 3.5
• RS: 2.0 → 3.0
• AS: 1.6 → 2.5
• Категория (ориентир): кризис → управляемая

Ключевые выводы

1. TODOIT не заменяет ITIL, DevOps, Agile, SRE и смежные подходы — он помогает выбрать фокус и типовой пакет практик.
2. Chaos Engineering и прочие практики оси AS не должны быть приоритетом, пока MS и управляемость изменений не на приемлемом уровне. Это не запрет экспериментов, а предупреждение о типичном порядке вложений.
3. Типовые методологии улучшают конкретные факторы TODOIT (DevOps → M5, HA → F1). Supplier Risk — отдельный контур для цепочки поставщиков (F2), не смешивайте с HA.
4. Оркестратор практик не отменяет критичность бизнеса (L); при высоком L интерпретация EX и приоритет инвестиций остаются в связке с бизнес-контекстом.
5. После внедрения практик — повторная оценка TODOIT для замера прогресса (SQI, SEI, EX).