Сравнение подходов: TODOIT, FAIR, SRE, ISO 22301

Логика сравнения

Сравнение TODOIT: System Exposure с FAIR, Google SRE, ISO 22301, NIST RMF и эвристикой антихрупкости Талеба — обзор по согласованным критериям. Оно не претендует на полноту рынка и не заменяет экспертного мнения по отдельным практикам. Зато помогает быстро понять, какую задачу решает каждый подход и с чем его разумно сочетать.

Сначала — перечень шести сравниваемых подходов: что это и кому они обычно нужны. Затем краткая матрица по осям FS, MS, RS, AS и производным EX, SQI, SEI. После этого — сводное сравнение по критериям, сценарии «что и для чего использовать», детальный разбор по трём направлениям и блок конкурентных преимуществ TODOIT.

В методологии TODOIT перед осевыми интервенциями учитывается стоп-фактор GM (Governance Multiplier); при интерпретации результатов действует порядок MS → FS → RS → AS. Для быстрой оценки используются чек-листы. Названия продуктов и стандартов принадлежат их правообладателям.

Сравнение нужно не для того, чтобы выбрать «единственно верную методологию», а для того, чтобы понять, какой инструмент за что отвечает — и увидеть, где TODOIT даёт общую карту действий, дополняя SRE и BCM, а не конкурируя с ними.

Шесть сравниваемых подходов

Ниже перечислены те же шесть подходов, что используются во всех таблицах раздела. У остальных подходов приведены ссылки на первоисточники — официальный сайт или хаб практик. TODOIT описан в разделе «Методология» на нашем сайте. Ссылки даны для справки и не являются рекламой или юридической консультацией.

TODOIT: System Exposure Framework

Оценка зрелости IT-систем по четырём осям — хрупкость, управляемость, устойчивость и антихрупкость (FS, MS, RS, AS). Производные EX, SQI и SEI связывают техническое состояние с бизнес-последствиями; есть чек-листы и матрицы приоритетов.

Аудитория: архитекторы, ИБ, владельцы продукта, бизнес, совет директоров. Первоисточник — документ методологии TODOIT.

FAIR

Factor Analysis of Information Risk — количественная модель киберриска. Оценивает частоту событий и величину потерь, выражает риск в деньгах — язык, понятный финансам и риск-менеджменту.

Ориентир: FAIR Institute.

Google SRE

Site Reliability Engineering: надёжность сервисов через SLO/SLI, error budget, инциденты и операционные практики. В сравнении — типичное применение модели зрелости SRE.

Ориентир: Site Reliability Engineering — Google.

ISO 22301 и BCM

Международный стандарт системы менеджмента непрерывности бизнеса (Business Continuity Management): политики, планы, целевые RTO/RPO, учения и аудит.

Ориентир: ISO 22301:2019.

NIST RMF

Risk Management Framework — управление рисками информационной безопасности в жизненном цикле системы: категоризация, выбор контролей, мониторинг, авторизация. Широко используется в регулируемых средах.

Ориентир: NIST — About RMF.

Концепция (анти)хрупкости

Философско-научная концепция Nassim Nicholas Taleb: хрупкость, устойчивость, антихрупкость, нелинейность и «тяжёлые хвосты» распределений. Это язык и эвристики, а не операционная IT-методология с чек-листами.

Вводная статья: Википедия — антихрупкость.

Краткое сопоставление по осям

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

Краткое сопоставление TODOIT, FAIR, SRE, ISO 22301, NIST RMF и антихрупкости по осям FS, MS, RS, AS
Подход	Измерений	Бизнес-связь	Антихрупкость	Устойчивость
TODOIT	4 (FS, MS, RS, AS)	Прямая: EX = FS × L	Ось AS (A1–A5)	Ось RS (R1–R5)
FAIR	1 (риск в деньгах)	Прямая	Нет	Косвенно
Google SRE	1 (SLO/SLI)	Косвенная — через ценность сервиса	Косвенно — обучение на инцидентах	Да
ISO 22301 / BCM	1 (непрерывность бизнеса)	Прямая	Нет	Да
NIST RMF	1 (риски ИБ и контроли)	Часто косвенная	Нет	Косвенно
Талеб	Эвристика, не шкала	Слабая для конкретного бюджета	Концепт есть · без индексов AS	Косвенно

Обозначения: есть / прямо нет / слабо косвенно / частично на уровне идеи нет шкалы

«Одно измерение» отражает доминирующую метрику в типичном применении, а не простоту внедрения. Прочерк у Талеба означает отсутствие единой операционной шкалы для IT-систем. Зрелые программы часто комбинируют несколько практик.

Сводное сравнение

Тот же состав из шести подходов — но по расширенному набору критериев: фокус, аудитория, метрики, связь с бизнесом, практическая применимость, антихрупкость, скорость оценки, масштаб и количественность.

TODOIT — четыре оси зрелости и производные EX, SQI, SEI; приоритет интерпретации MS → FS → RS → AS. Аудитория: архитекторы, ИБ, продукт, бизнес, board. Метрики — индексы по осям и категории зрелости. Бизнес-связь прямая через EX = FS × L. Есть чек-листы и матрицы; антихрупкость — явная ось AS. Быстрый скрининг через RS_quick и чек-листы; полная оценка глубже. Масштаб — от одной системы до портфеля.
FAIR — количественная оценка киберриска в деньгах. Аудитория: риск-менеджмент, финансы, CISO. Результат — risk в валюте за год, сценарии потерь. Бизнес-связь прямая. Модели FAIR хорошо ложатся на практику, но антихрупкости как оси нет. Скорость зависит от качества входных данных; масштаб — от сценария риска.
Google SRE Maturity — зрелость практик SRE: SLO/SLI, error budget, инциденты. Аудитория: SRE, платформенные и продуктовые команды. Метрики — attainment SLO, зрелость процессов. Бизнес-связь косвенная. Playbook SRE проверен в продакшене; антихрупкость — косвенно, через культуру обучения. Средняя скорость сбора данных; масштаб — от сервиса до организации.
ISO 22301 / BCM — непрерывность бизнеса, планы, RTO/RPO. Аудитория: BCM, операционные руководители, аудит. Метрики — соответствие требованиям BCM, показатели восстановления. Бизнес-связь прямая (потери, время простоя). Планы, тесты, сертификация — сильная практическая сторона; антихрупкости обычно нет. Оценка долгая; масштаб — организация и критические процессы.
NIST RMF — управление рисками ИБ по жизненному циклу. Аудитория: security, compliance, владельцы систем. Метрики — уровень риска, эффективность контролей, авторизация. Бизнес-связь часто косвенная. Процессы RMF и доказательства контролей хорошо структурированы; антихрупкости нет. Цикл RMF средний или долгий; масштаб — портфель IT-систем.
Талеб — концептуальная модель: хрупкость, устойчивость, антихрупкость. Широкая аудитория, не операционный чек-лист. Качественные образы без единой числовой шкалы для IT. Для конкретного инвестиционного решения связь слабая. Полезен как язык, не как регламент. Формальная оценка системы — N/A; масштаб абстрактный, не привязан к границам сервиса.

Что и для чего использовать

Схема «задача → подход → ожидаемый результат». Это не взаимоисключающий выбор: в зрелых программах подходы часто сочетаются.

[ Задача клиента ]
│
└── Что нужно?
    ├── Обосновать бюджет на модернизацию
    │   └── TODOIT: EX = FS × L
    │       └── Результат: эквивалент снижения хрупкости в $
    ├── Оценить киберриски в деньгах
    │   └── FAIR
    │       └── Результат: VaR в $
    ├── Подготовиться к аудиту ISO 22301
    │   └── ISO 22301 / BCM
    ├── Улучшить операционную надёжность
    │   └── Google SRE Maturity
    │       └── Результат: план по областям SRE
    ├── Соответствовать гос. требованиям
    │   └── NIST RMF
    ├── Исследовать нелинейные / хвостовые риски
    │   └── Эвристика Талеба
    └── Board-level стратегия устойчивости
        └── TODOIT: SQI + SEI + матрицы MS/FS
            └── Результат: приоритеты MS → FS → RS → AS

graph TD
    A["Задача клиента"] --> B{"Что нужно?"}
    B -->|Обосновать бюджет на модернизацию| C["TODOIT: EX = FS × L"]
    C --> J["Результат: эквивалент снижения хрупкости в $"]
    B -->|Оценить киберриски в деньгах| D[FAIR]
    D --> K["Результат: VaR в $"]
    B -->|Подготовиться к аудиту ISO 22301| E["ISO 22301 / BCM"]
    B -->|Улучшить операционную надёжность| F["Google SRE Maturity"]
    F --> L["Результат: план по областям SRE"]
    B -->|Соответствовать гос. требованиям| G[NIST RMF]
    B -->|Исследовать нелинейные / хвостовые риски| H["Эвристика Талеба"]
    B -->|Board-level стратегия устойчивости| I["TODOIT: SQI + SEI + матрицы MS/FS"]
    I --> M["Результат: приоритеты MS → FS → RS → AS"]

Обосновать бюджет на модернизацию — TODOIT через EX = FS × L. Результат: эквивалент снижения хрупкости в деньгах — аргумент для CFO и board.
Оценить киберриски в деньгах — FAIR. Результат: VaR в валюте по сценариям cyber risk.
Подготовиться к аудиту ISO 22301 — ISO 22301 / BCM. Результат: формальная система business continuity, планы и доказательства готовности.
Улучшить операционную надёжность — Google SRE Maturity: SLO/SLI, error budget, инцидентная культура. Результат: план по областям SRE и зрелости практик.
Соответствовать гос. и регуляторным требованиям — NIST RMF и контур контролей. Результат: структурированный цикл управления рисками ИБ.
Исследовать нелинейные и хвостовые риски — эвристика Талеба как язык и способ мышления. Результат: лучшее понимание «тяжёлых хвостов», но не готовый IT-регламент.
Board-level стратегия устойчивости — TODOIT через SQI, SEI и матрицы MS/FS. Результат: приоритеты MS → FS → RS → AS для портфеля систем.

Детальный разбор

Сжатый разбор по трём линиям сопоставления. Формулировки сверены с текущей редакцией методологии: оси FS, MS, RS, AS; в линии последствий — BR и RC; приоритет интерпретации MS → FS → RS → AS.

1. Оценка рисков и хрупкости

Детальный разбор: оценка рисков и хрупкости — TODOIT, FAIR, SRE, ISO 22301, NIST RMF, Талеб
Подход	Как смотрит на хрупкость	Сильные стороны	Слабые стороны
TODOIT	Многослойная модель: причины (F1–F4) → механика разрушения (C, BR) → последствия (RC, L); связь FS и EX с L	Связь архитектуры с бизнес-ущербом через EX = FS × L Повышенные веса F1, F2 в базовом FS	Нужна калибровка шкал между экспертами
FAIR	Вероятностная модель: частота событий × величина потерь	Финансовый язык понятен бизнесу Привычная постановка потерь (VaR) для киберрисков	Не оценивает архитектурные причины хрупкости
NIST RMF	Контрольно-процедурный: выбор контролей по категориям и жизненному циклу	Покрытие регуляторных требований Встраивание в жизненный цикл системы	Упор на compliance, а не на то, «как ломается система» архитектурно
Талеб	Чувствительность к волатильности параметров; «хвосты» распределений	Выявление скрытых нелинейностей и тяжёлых хвостов Не требует полной параметризации	Слишком абстрактно для типичной инженерной оценки в срок

Вывод: TODOIT занимает отдельную нишу — явно связывает техническую архитектуру и последствия сбоя с бизнес-метрикой EX. Ни один из перечисленных аналогов не дублирует методологию целиком.

2. Управляемость и операционная зрелость

Детальный разбор: управляемость и операционная зрелость — сравнение подходов
Подход	Как смотрит на управляемость	Сильные стороны	Слабые стороны
TODOIT	Пять факторов M1–M5; MS — их среднее	Простая агрегация MS Пороги интерпретации для решений	Менее детализировано, чем узкоспециализированные модели зрелости
Google SRE Maturity	Много областей: мониторинг, capacity, изменения, on-call и др. — с уровнями зрелости	Глубокая проработка операционных практик Проверено в крупном продакшене	Тяжело для быстрой «одним проходом» диагностики Слабее явная связь с архитектурными решениями
ISO 22301 / BCM	Процессы: политики, планы, тесты, обучение	Признанный стандарт для аудита BCM Организационная устойчивость	Не заменяет оценку технической управляемости конкретной системы

Вывод: для быстрой архитектурно-инженерной диагностики TODOIT выигрывает компактностью оси MS и связью с FS / EX. Для глубокой операционной трансформации модель зрелости в духе Google SRE часто остаётся ориентиром по практикам.

3. Антихрупкость и эволюция через стресс

Детальный разбор: антихрупкость и эволюция через стресс — сравнение подходов
Подход	Как смотрит на антихрупкость	Сильные стороны	Слабые стороны
TODOIT	Ось AS (A1–A5): постмортемы, тесты, chaos, data-driven, устранение классов сбоев; SEI = AS × MS / FS	Практично и измеримо в одной модели с FS и MS SEI для сравнения систем	Мало внешних отраслевых бенчмарков
Академические модели	Формальные определения чувствительности к стрессу и волатильности	Теоретическая строгость Применимы к сложным системам	Трудно операционализировать без исследовательского ресурса
FAIR, ISO 22301, NIST RMF	Нет отдельной оси AS в типичном применении	—	Нет или только косвенно — например, postmortems без индекса A1–A5

Вывод: среди практических подходов с явным измеримым AS и связкой с RS, MS и FS у TODOIT мало прямых аналогов — это одно из сильных отличий методологии.

Смысл сравнения не в том, чтобы заменить все практики одной методологией. TODOIT показывает, где система слаба и что важнее сейчас; смежные подходы дают инструменты «лечения». Подробнее о связке диагностики и практик — на странице Компас.

Конкурентные преимущества TODOIT

Четыре оси в одной модели

Ни один из перечисленных аналогов не объединяет хрупкость, управляемость, устойчивость и антихрупкость в одной согласованной системе с явной иерархией интерпретации MS → FS → RS → AS.

Бизнес-ориентированная подверженность (EX)

EX = FS × L — аргумент для CFO и board: снижение FS при заданном L напрямую снижает подверженность потерям.

Иерархия вмешательств

Порядок MS → FS → RS → AS снижает риск типичной ошибки: усиление «эволюции под стрессом» или chaos engineering при низкой MS или без базы FS / RS.

Два режима работы

От быстрого скрининга (RS_quick, чек-листы) до глубокого архитектурного аудита по всем осям — можно начать с короткой оценки и углубляться по мере необходимости.

Интегральные индексы SQI и SEI

Позволяют сравнивать системы и отслеживать динамику. При этом SEI не подменяет отдельный учёт AS и RS — производные дополняют, а не заменяют оси.