Калькулятор трудозатрат SOC или как защитить свой FTE

Привет, Хабр! В прошлой статье мы разбирались, почему «Mean Time» метрики в отрыве от контроля качества превращают SOC в дорогой автокликер и как мы пересобрали еженедельную отчетность, внедрив контроль качества.
В конце статьи я обещал рассказать о калькуляторе трудозатрат SOC. Инструмент готов, и теперь можно перейти от общих рассуждений к цифрам.

Сегодня поговорим о проблеме, которая обсуждается заметно реже, чем SLA, MTTD и MTTR, но напрямую влияет и на эти показатели, и на устойчивость команды. Это управление загрузкой SOC: понимание того, сколько работы действительно выполняет команда, сколько ресурса у неё осталось и можно ли безболезненно взять на себя ещё одну функцию.

Отдельно разберём, как перегрузка приводит к выгоранию аналитиков первой линии, почему «все заняты» – плохой аргумент в разговоре с руководством и как перевести этот разговор на язык часов, FTE и управляемых сценариев.

Проблема, о которой обычно вспоминают слишком поздно

Если SOC работает хорошо, его работа часто остаётся незаметной для бизнеса. Не произошло утечки, не было простоя, инцидент быстро локализовали – значит, будто бы ничего особенного не случилось.

На этом фоне у руководства может возникнуть вполне логичный вопрос:

Если команда закрыла 800 алертов за месяц, почему она не может дополнительно заниматься уязвимостями, согласованиями или ходить на проверки в проекты?

Само по себе число закрытых алертов почти ничего не говорит о загрузке команды. За ним могут скрываться:

• первичный триаж;

• сбор дополнительного контекста;

• передача кейсов между сменами;

• эскалация на L2 и L3;

• реагирование на инциденты;

• сопровождение SIEM, SOAR, EDR и других платформ;

• разработка и тюнинг правил корреляции;

• подключение новых источников событий;

• подготовка отчётности;

• актуализация runbook и базы знаний;

• консультации и сервисные запросы.

Часть этой работы видна в тикетах, часть – в SIEM или SOAR, а часть вообще существует только в календарях и головах сотрудников.

Зато есть цифры: «мы закрыли 800 алертов за месяц». Но что это значит? Нормально это или мало? Можно ли на эту же команду повесить ещё и IR для дочек? А если можно – то сколько человек нужно добавить, чтобы не скатиться в режим вечной погони за временем из прошлой статьи?

Без прозрачной модели трудозатрат аргумент «нам тяжело» почти всегда проигрывает аргументу «у вас же есть свободные руки».

Когда перегрузка превращается в выгорание

Выгорание в SOC возникает не только из-за большого объёма работы. Важен характер этой работы.

Аналитик L1 может провести смену, последовательно выполняя один и тот же цикл:

алерт → контекст → проверка → вердикт → комментарий → следующий алерт.

При этом значительная часть событий оказывается ложными срабатываниями или не требует глубокого расследования. Человек постоянно принимает решения, но редко видит конечный результат своей работы. Он не всегда может сказать: «Именно благодаря мне атака не произошла».

В профессиональных исследованиях и публикациях эта проблема обычно описывается через несколько связанных факторов:

• высокую плотность алертов;

• большое количество false positive;

• недостаток контекста в карточке события;

• постоянную работу в режиме срочности;

• нехватку времени на развитие и обучение;

• отсутствие понятного карьерного роста;

• несоответствие между ответственностью и доступными ресурсами.

Проблема, с которой мы столкнулись, не уникальна. Она часто встречается в ключевых отраслевых исследованиях:

В материалах SANS проблема выгорания SOC-аналитиков рассматривается как замкнутый цикл: высокая нагрузка приводит к усталости и снижению качества, затем опытные сотрудники уходят, а оставшаяся команда получает дополнительную нагрузку. Такой цикл становится самоподдерживающимся.
Исследования профессионального сообщества также связывают усталость от алертов не только с ухудшением самочувствия сотрудников, но и с ростом вероятности пропуска важных событий. Чем больше времени уходит на низкоценные алерты, тем меньше его остаётся на расследование, threat hunting и улучшение детектирования.

В исследовании ISC2 за 2025 год отдельно подчёркивается, что для устойчивости кибербезопасности важны не только технические навыки, но и достаточное количество ресурсов, коммуникация, способность решать проблемы и поддержка сотрудников. Только 55% респондентов согласились, что их организация располагает ресурсами для подготовки к инцидентам в ближайшие два-три года.

Пример из жизни:
Некоторое время назад наш SOC столкнулся с неприятной ситуацией: из команды ушёл один из опытных аналитиков L1. Причина была банальной и болезненной – выгорание из-за бесконечной рутины.
Это был один из первых аналитиков, он уже знал всю инфраструктуру, ориентировался в типовых алертах с закрытыми глазами. Но в какой-то момент пришёл с заявлением.
Диалог был простой – сотрудник из смены в смену делает одно и то же – алерт, контекст, вердикт, следующий. Он не чувствовал, что делает что-то важное, и хотел более интересных задач. Задачи были, но времени на них не хватало.
И на уровне ощущений было понятно, что он действительно перегружен. Но фактических аргументов не было.

Вот тут и выясняется, что у SOC обычно нет инструмента планирования ресурсов. Есть интуиция руководителя, есть ощущения команды, есть «нам кажется, что мы перегружены». А для разговора с топ-менеджментом нужны не ощущения, а цифры с прозрачной методикой расчетов.
В итоге либо SOC молча берёт на себя чужую работу и постепенно выгорает, либо отказывается – и выглядит «негибким». Оба сценария плохие.

Почему SOC выгорает быстрее других команд

Выгорание в SOC – это не про «тяжёлую работу». Тяжело везде. Это про специфический набор факторов, которые в сумме дают эффект выхлопной трубы:

1. Конвейерный характер работы L1. Сотни алертов в день, большинство из которых – ложные сработки. Мозг не получает дофаминового подкрепления от «полезной» работы, потому что 90% закрытых кейсов – это «ничего не произошло».

2. Отсутствие видимого результата. Ты не можешь показать бизнесу «предотвращённую атаку» – её просто не случилось. А вот «мы закрыли 800 алертов» – это цифра, которая обесценивает саму работу до уровня статистики.

3. Постоянный когнитивный стресс. Даже ложный алерт требует концентрации. После 30-40 таких решений в смену мозг переходит в режим энергосбережения – и качество падает.

4. Режим бесконечного цейтнота. Когда не следишь за перегрузкой сотрудников, команда начинает жить от дедлайна до дедлайна. Нет времени на обучение, на рефакторинг правил, на нормальный отдых между сменами. И это не «пиковая нагрузка» – это постоянный режим.

5. «Бесплатные» задачи сверху. Бизнес видит, что SOC работает с алертами, и решает, что есть свободные руки.

Что мы хотели получить от калькулятора

Задача была не в том, чтобы построить систему учёта каждой минуты каждого сотрудника. Такой подход быстро превращается в микроменеджмент и требует постоянны споров о точности нормативов.

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

• сколько часов требует текущий объём работы;

• какие роли перегружены;

• где есть свободный ресурс;

• какие задачи фактически выполняет L1;

• сколько времени уходит на Run и Change;

• что произойдёт при росте потока алертов;

• сколько FTE потребуется для новой зоны ответственности;

• что выгоднее: нанять человека, перераспределить задачи или автоматизировать процесс.

Главный принцип модели: мы смотрим на «среднюю температуру по больнице», но по отдельным ролям сотрудников и с привязкой к блокам услуг.

Калькулятор не должен доказывать, что SOC «занят». Он должен показывать, какой объём работ требуется, какой ресурс доступен и какие управленческие решения возможны.

Модель состоит из девяти листов, каждый решает свою задачу.

Ручной ввод данных необходим только в основных местах: на листе «Настройки» и в распределении блоков (при необходимости). Остальные значения рассчитываются автоматически. Это снижает риск случайно изменить формулу или нарушить структуру модели.

Структура калькулятора

В модели работа SOC разделена на восемь блоков:

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

Справочник операций и формула трудозатрат

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

Итого часов = Объём × Норматив × (1 − Экономия автоматизации) × CSC

• CSC (Cognitive Strain Coefficient) – ключевое нововведение. По умолчанию CSC = 1.15 (норма), может повышаться до 1.25-1.35 в периоды кризиса.

• Экономия – доля времени, которую забирает SOAR/автоматизация (от 0% до 90%).

В калькуляторе предусмотрены четыре уровня автоматизации:

Это не означает, что автоматизация полностью заменяет человека. Например, при полном уровне аналитик может продолжать контролировать результат и обрабатывать исключения. В модели учитывается именно снижение трудозатрат на типовой сценарий.

Коэффициент когнитивной нагрузки

Одинаковый объём часов не всегда означает одинаковую нагрузку.

Час спокойной работы над правилом корреляции и час плотного потока алертов – не одно и то же. В последнем случае сотрудник постоянно переключается между контекстами, принимает решения и работает в условиях дефицита времени.

Для этого в модели используется CSC:

• 1,00 – благоприятные условия;

• 1,15 – обычная высокая плотность работы;

• 1,25 – повышенная нагрузка;

• 1,35 и выше – кризисный режим.

CSC не является медицинской или научной оценкой состояния сотрудника. Это управленческий коэффициент, который помогает не выдавать расчёт «чистых часов» за полную картину реальной нагрузки.

Полезная ёмкость и статусы загрузки

Номинальный рабочий месяц сам по себе не равен времени, которое сотрудник может тратить на плановую работу SOC.
Для L1 в примере используется коэффициент 0,80, для остальных ролей – 0,75.

В эти 20–25% неполезной для расчёта ёмкости входят:

• встречи;

• обучение;

• перерывы;

• административные задачи;

• коммуникации;

Так выглядит блок "Настройки", в котором задаются вышеуказанные показатели:

Распределение работы между ролями

В текущей версии предусмотрены пять ролей:

Для каждого блока задаётся доля участия ролей:

Калькулятор проверяет, чтобы сумма по каждому блоку составляла 100%. Это защищает модель от ситуации, когда доли ролей назначены приблизительно и итоговые часы перестают иметь смысл.

Пример расчета: почему L1 перегружена при 3 аналитиках

Давайте рассмотрим реальный кейс через калькулятор.
Вводные: 3 аналитика L1. График: день/ночь/отсыпной/выходной по 12 часов. 800 алертов в месяц. Расчёт ёмкости:

• Номинальные часы: 3 × 168 = 504 часа.

• Полезная ёмкость (коэф. 0.80 - так как часть времени неизбежно уходит на совещания, созвоны, перерывы): 403 часа.

• Расчёт трудозатрат: мониторинг, реагирование, сервисный портфель и прочее на L1: ~549 часов.

Загрузка L1: 549 / 403 = 136% – статус OVERLOADED.** И без тонких расчетов каждый понимает, что тремя аналитиками не закрыть дежурство 24/7. Но с калькулятором мы понимаем, какие блоки активностей и на кого можно временно перераспределить и какими цифрами нам защищать FTE перед руководством.

Важное отступление про смены: смены (день/ночь/отсыпной/выходной) намеренно пока не учитывались в данной версии калькулятора как отдельный сущностный слой. Мы смотрим на общий пул часов и «среднюю температуру». Но особенности графика 2/2 по 12 часов своеобразны: сотрудникам сложнее распределять время на восстановление, и именно это является скрытым драйвером выгорания, который сложно зашить в классическую формулу FTE.

Run и Change: почему SOC может незаметно деградировать

В калькуляторе работа разделена на два типа.

Run – то, что нужно делать для поддержания текущей работы:

• мониторинг;

• триаж;

• реагирование;

• сервисные запросы;

• отчётность;

• сопровождение;

• устранение типовых ошибок.

Change – то, что делает SOC лучше:

• разработка новых правил;

• подключение источников;

• тюнинг детектирования;

• threat hunting;

• рефакторинг контента;

• развитие playbook;

• анализ результатов тестов и пентестов.

В текущем примере доля Change составляет около 12%. Для этой модели целевым ориентиром выбран уровень не менее 20%.

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

Получается замкнутый цикл:

• появляются новые источники и правила;

• растёт количество алертов;

• аналитики тратят всё больше времени на ручной триаж;

• на тюнинг и автоматизацию времени не остаётся;

• шум увеличивается;

• команда ещё сильнее загружается.

На Dashboard это может выглядеть вполне благополучно: алерты закрываются, SLA соблюдается. Но доля Change показывает, что система уже работает на поддержание текущего состояния.

What-if сценарии

Отдельный лист «Сценарии» нужен для того, чтобы обсуждать изменения до их запуска.

Pasted image 20260928104144.png

Вместо предположения «наверное, справимся» появляется сценарий с цифрами
Калькулятор не принимает решение за руководителя. Он показывает цену решения.

Ограничения модели

Я сознательно не делаю из калькулятора «истину в последней инстанции». Модель имеет ряд «узких мест»:

1. Инженерные работы. Работы SIEM/SOAR пока считаются по средним месячным цифрам. Я проговорил это с коллегами-инженерами, и мы пришли к неким усредненным значениям. В планах – декомпозировать эти работы и считать их по количеству задач в сервис-деске, чтобы модель стала точнее.

2. Нормативы нужно калибровать. Заложенные значения – стартовые. Их нужно ежеквартально сверять с фактическими данными из тикетов.

3. Модель не учитывает квалификационный рост. L1 второго года работы и L1 первой недели – это разные люди, но в модели они считаются одинаково.

4. Модель не учитывает сменный график, а также отпуска и больничные. Необходимо учитывать особенности графика.

5. Калькулятор не заменяет контроль качества. Он показывает, сколько часов нужно, но не говорит, правильно ли эти часы потрачены.

Что получилось в итоге

Калькулятор позволяет:

• оценить месячные трудозатраты SOC;

• сопоставить их с полезной ёмкостью команды;

• увидеть перегрузку по ролям;

• подробно рассмотреть L1;

• показать участие аналитиков в работе с контентом;

• оценить влияние автоматизации;

• разделить Run и Change;

• смоделировать рост объёмов;

• обосновать FTE;

• показать руководству стоимость новых задач;

• вовремя заметить отсутствие резерва.

Но главная ценность инструмента не в диаграммах и не в цветах статусов, а в нормальном управление ресурсами

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

А дальше появляются механические вердикты, снижение качества, раздражение, увольнения и ещё большая нагрузка на оставшихся сотрудников.
Поэтому контроль загрузки – это не только способ обосновать новый FTE. Это один из инструментов защиты качества детектирования и людей, которые этот SOC поддерживают.

Вопросы к сообществу:

• Как вы обосновываете FTE для SOC?

• Считаете ли полезную ёмкость отдельно от номинальных рабочих часов?

• Учитываете ли в модели участие L1 в разработке и тюнинге контента?

• Как у вас устроен резерв на всплески нагрузки?

• Какие признаки выгорания аналитиков вы замечаете раньше всего?

• Используете ли вы ротацию между мониторингом, threat hunting и detection engineering?