«Большинство команд в ИТ-сфере в России сегодня не работают по методикам гибкой разработки, они просто тушат пожары. Если вы постоянно объясняете, почему что-то сломалось, вместо того чтобы объяснять, что вы создали, вы не строите систему — вы её обслуживаете. Суть не в количестве задач, а в типе этих задач. Ваша цель — сместить баланс от оперативных исправлений к плановой разработке.»
Почему работа в режиме пожара, это не работа, а обслуживание системы
В российской регуляторике, особенно в сфере информационной безопасности, часто возникают срочные задачи: надо закрыть уязвимость по предписанию ФСТЭК, доработать систему под новую редакцию 152-ФЗ, исправить инцидент. Если команда только этим и занимается, её деятельность сводится к постоянному обслуживанию уже существующей системы. Вы не двигаетесь вперёд, вы просто удерживаете статус-кво, тратя ресурсы на то, чтобы система соответствовала минимальным требованиям. Это похоже на работу системного администратора, который только перезагружает серверы и чистит логи, но никогда не внедряет новую архитектуру. Фактически, вы не занимаетесь разработкой или совершенствованием, а лишь предотвращаете коллапс.
Индикаторы, что ваша команда превратилась в пожарную службу
Распознать этот режим можно по ряду характерных признаков. Эти индикаторы показывают, что процесс вышел из-под контроля и превратился в реактивный цикл.
- Отсутствие дорожной карты. Планы на квартал или год постоянно сдвигаются или отменяются из-за «срочных» задач. У команды нет чёткого представления, над чем она будет работать через месяц.
- Ежедневные митинги превращаются в разбор полётов. Вместо обсуждения прогресса по задачам вы обсуждаете, что сломалось вчера и кому это чинить сегодня.
- Отсутствие метрик развития. Вы не можете измерить, насколько улучшилась безопасность инфраструктуры или производительность приложения за последний квартал. Зато отлично отслеживаете количество закрытых инцидентов.
- Разработчики или аналитики выполняют работу технической поддержки. Специалисты, нанятые для создания новых функций или архитектуры, тратят время на диагностику проблем в продакшене.
- Все задачи имеют высший приоритет. Если каждая входящая задача маркируется как «критическая» или «срочная», это значит, что приоритеты не расставлены, а управление отсутствует.
Источники «возгорания» в контексте 152-ФЗ и ФСТЭК
В сфере ИБ и регуляторики пожары часто имеют специфическую природу. Их источник — не просто баги в коде, а требования регуляторов и меняющееся законодательство.
- Реакция на проверки и предписания. Команда начинает судорожно дорабатывать систему только после получения официального предписания от ФСТЭК, вместо того чтобы проводить упреждающий аудит и доработки.
- Некорректная интерпретация требований. Из-за непонимания формулировок 152-ФЗ или методик ФСТЭК реализуются избыточные или недостаточные меры защиты. Позже это выливается в доработки и переделку.
- Отсутствие автоматизированного мониторинга соответствия. Состояние защиты не отслеживается в реальном времени. Проблемы обнаруживаются вручную или в худшем случае — при инциденте.
- Архитектурный долг. Система безопасности строилась точечно, под каждый новый проект или требование, без единой стратегии. Накопленные противоречия в архитектуре регулярно приводят к новым уязвимостям.
Как перейти от тушения пожаров к плановой работе: стратегия
Сдвиг требует изменения не только процессов, но и мышления команды и руководства. Цель — сделать плановую работу нормой, а не исключением.
1. Категоризация и приоритизация входящих задач
Внедрите жёсткую систему классификации. Например, разделите все задачи на четыре категории:
- Пожар (Incident): Реальный инцидент безопасности или сбой, нарушающий основной функционал. Реакция — немедленная.
Регуляторная срочность (Compliance): Задача, связанная с выполнением установленного срока по 152-ФЗ или предписанию ФСТЭК. Срок жёсткий, но работа может быть запланирована.
Технический долг (Debt): Улучшение существующей архитектуры, рефакторинг, исправление «костылей». Это инвестиции в будущую стабильность.
Развитие (Feature): Новая функциональность, улучшающая продукт или процессы. Это то, ради чего существует команда.
Внедрите правило: не более 20-30% ресурсов команды в спринт может уходить на задачи первых двух категорий («Пожар» и «Регуляторная срочность»). Остальное — плановая работа.
2. Создание буфера и планирование на основе рисков
При планировании спринта или квартала закладывайте временной буфер (например, 15-20%) специально для непредвиденных, но вероятных «пожаров». Если буфер не израсходован — команда работает по плану. Если израсходован, это сигнал к анализу причин возникновения срочных задач. Кроме того, ведите реестр регуляторных рисков. Планируйте работы по 152-ФЗ не тогда, когда пришло предписание, а на основе анализа ближайших сроков отчётности и грядущих изменений в законодательстве.
3. Инвестиции в автоматизацию и документацию
Пожарные задачи часто возникают из-за рутинных, повторяющихся операций. Автоматизация — ключ к их сокращению.
- Автоматизация проверок соответствия. Используйте скрипты или специализированное ПО для регулярной автоматической проверки настроек безопасности на соответствие требованиям ФСТЭК. Это позволит обнаруживать дрейф конфигураций до проверки.
- Стандартизация и шаблоны. Создайте стандартные, проверенные конфигурации для развёртывания новых сервисов, которые из коробки соответствуют политикам безопасности. Это убирает целый класс ошибок.
- Документирование решений. Когда вы тушите пожар, фиксируйте его причину и решение не только в тикете, но и в общей базе знаний. Это превращает разовый инцидент в коллективный опыт и предотвращает повторение.
Роль архитектуры безопасности в предотвращении «пожаров»
Хаотичные доработки под каждый новый регуляторный акт — прямой путь к постоянным проблемам. Нужна продуманная архитектура безопасности (Security by Design), которая изначально закладывает гибкость под изменения.
Например, вместо того чтобы для каждого нового сервиса придумывать, как в нём реализовать шифрование персональных данных по 152-ФЗ, создайте единый сервис-прокси или библиотеку, которая обеспечивает эту функциональность прозрачно для разработчиков. Таким образом, изменение требований к алгоритмам шифрования потребует правки в одном месте, а не в десятках приложений. Архитектура должна предусматривать точки контроля и аудита, чтобы сбор доказательств соответствия для ФСТЭК не был героической операцией по извлечению логов со всех систем.
Когда «пожары» неизбежны и как к ним готовиться
Полностью исключить срочные задачи нельзя, особенно в области, связанной с законодательством. Ключ — в управляемости процесса их обработки.
- Создайте и отрепетируйте playbook. Для типовых инцидентов (например, утечка данных, сбой СЗИ) должны быть готовые пошаговые инструкции (playbook), которые описывают первые действия, ответственных и точки коммуникации. Это сокращает время реакции и панику.
- Выделите роль/дежурного. Назначьте ответственного за приём и первоначальную оценку входящих срочных задач на ротационной основе. Это позволяет остальной команде сосредоточиться на плановой работе.
- Проводите постмортемы без поиска виноватых. После каждого серьёзного инцидента проводите разбор с фокусом на системные причины: «Что в наших процессах или архитектуре позволило этому случиться?». Цель — улучшить систему, а не наказать человека.
Измерение прогресса: от количества закрытых инцидентов к выполнению плана
Меняйте метрики, по которым оцениваете работу команды. Если вы хвалите сотрудника за то, что он героически устранил аварию в нерабочее время, вы поощряете культуру героизма и пожаров.
Вместо этого вводите и отслеживайте метрики, отражающие плановую работу:
- Процент выполнения плана разработки/доработок (Roadmap Completion). Насколько команда успевает по запланированным на квартал улучшениям безопасности.
- Коэффициент плановой работы. Отношение времени, потраченного на задачи категорий «Развитие» и «Технический долг», к общему времени работы команды. Стремитесь к значению выше 60-70%.
- Среднее время восстановления (MTTR) и среднее время между инцидентами (MTBF). Первая метрика должна снижаться (мы быстрее чиним), вторая — расти (инциденты случаются реже).
- Количество выявленных и устранённых рисков соответствия до получения предписания. Эта метрика показывает проактивность команды в области регуляторики.
Когда эти метрики станут основными для отчётов руководству, фокус команды естественным образом сместится с тушения на строительство.