Всё важное закрыто, а риски остались: что IT-аудит находит перед релизом
Зелёные статусы подтверждают, что задачи выполнены. Для решения о запуске нужна карта связей: какие части продукта затронет ошибка, насколько далеко она разойдётся и что команда сделает во время сбоя.
Я Антон Фокин, CEO Qtim. Мы подключаемся к IT-аудиту, когда работающий продукт готовят к новому этапу или накопленные изменения мешают оценить следующий релиз. Ниже разберу четыре области проверки и способ превратить замечания в решение о запуске.
Код показывает цену следующего изменения
При аудите код читают как карту будущих работ. Важно понять, где лежит бизнес-логика, сколько модулей затронет новая функция, какие участки проверяются автоматически и где результат зависит от осторожности конкретного разработчика.
Длинный метод сам по себе не останавливает релиз. Опаснее правило, которое повторяется в трёх местах. Условия расчёта скидки могут жить в личном кабинете, фоновом задании и интеграции с CRM. Команда обновит два участка, а третий продолжит считать по старой схеме. Код выполнится без ошибок, зато финансовый отчёт получит собственную версию событий.
Мы смотрим на связанность модулей, дублирование логики, обработку ошибок, тесты критических сценариев и историю изменений. Файл, который регулярно участвует в исправлениях разных функций, становится горячей точкой: каждое новое требование повышает вероятность побочного эффекта.
Ещё один сигнал — участок, который все боятся трогать. Обычно рядом есть комментарий «временно» и человек, который помнит, почему это решение пережило несколько кварталов. Аудит выясняет, какой бизнес-процесс от него зависит, как проверить результат после правки и кто отвечает за логику. Ответы показывают, где достаточно тестов, а где перед новой функцией нужен небольшой рефакторинг.
Одна правка, пять модулей: считаем радиус сбоя
Архитектурный аудит восстанавливает путь данных от действия пользователя до результата в бизнес-системе. При оформлении заказа интерфейс отправляет запрос, сервер проверяет остатки, платёжный сервис подтверждает операцию, CRM создаёт сделку, склад получает задачу. Любой участник цепочки может ответить медленно, повторить сообщение или временно стать недоступным.
Мы проверяем границы модулей, общие базы данных, синхронные цепочки, очереди, ограничения по времени ответа и повторные запросы. Отдельно ищем точки, через которые проходит слишком много сценариев. Единственный сервер без резервного маршрута для входа всех пользователей создаёт риск непрерывности бизнеса.
Название архитектурного подхода мало говорит о надёжности. Хорошо разделённое приложение с единым развёртыванием, то есть модульный монолит, бывает предсказуемее набора микросервисов с общей базой. Каждый сервис добавляет сетевое взаимодействие, отдельный выпуск, мониторинг и сценарии частичного отказа. Границы, проведённые только на диаграмме, переносят связанность из кода в сеть.
Интеграции проверяют по четырём сценариям: задержка ответа, повторная доставка, нарушение порядка событий и частичный успех. Здесь важна идемпотентность — повтор операции не должен создавать вторую оплату или ещё одну заявку. После проверки видно, какой сбой блокирует запуск, а какой команда переживёт с повторной обработкой и понятным статусом для пользователя.
Резервная копия считается рабочей после восстановления
Файл с названием «резервная копия» ещё не гарантирует возврат системы в работу. Он может оказаться неполным, зашифрованным потерянным ключом или слишком старым для нового формата базы. Поэтому аудит проверяет весь путь восстановления: что сохраняется, как часто, кто имеет доступ и сколько времени займёт запуск после сбоя.
Здесь же разбирают окружения, развёртывание, права, секреты и наблюдаемость: логи, метрики и трассировку запросов. Мониторинга «сервер отвечает» мало, когда очередь остановилась, платежи падают или письма не уходят. Для релиза важны допустимая потеря данных (RPO) и время восстановления (RTO). Эти параметры задают частоту резервного копирования и план отката.
Один человек не должен держать релиз в памяти
IT-аудит затрагивает процесс разработки: кто владеет критическими модулями, как проходят ревью, где описан выпуск и сможет ли другой специалист повторить действия автора решения. Когда релиз умеет проводить один человек, у проекта появляется фактор незаменимости (bus factor). Для системы это такая же точка отказа, как единственный сервер.
Полезная документация описывает рабочие действия: как развернуть проект, где искать метрики, как откатить версию и что проверить после изменения базы. У каждого критического участка должны быть владелец, резервный специалист и понятная процедура. Тогда сроки учитывают передачу знаний, а качество запуска меньше зависит от состава смены.
Три категории отделяют блокер от технического долга
Список из нескольких десятков замечаний легко превращает аудит в каталог тревог. Для решения перед релизом мы раскладываем выводы по влиянию на бизнес-сценарий и вероятности проблемы.
- Исправить до запуска. Сюда входят риски потери или раскрытия данных, некорректных платежей, необратимой миграции, массовой недоступности и отсутствия рабочего отката. У замечания должны быть владелец, срок и способ повторной проверки.
- Выпускать с контролем. Проблема ограничена, а команда умеет быстро её заметить и остановить. Помогают поэтапное включение, переключатель функции (feature flag), усиленный мониторинг, лимит нагрузки и сценарий отката.
- Поставить в дорожную карту. Технический долг повышает стоимость будущих изменений, но не угрожает текущему запуску. Для него фиксируют последствия, приоритет и момент, когда откладывать станет дороже исправления.
В Qtim этот путь начинается с погружения в бизнес-задачу и разбора архитектуры со стеком. Затем слабые места превращаются в приоритизированный список рисков и дорожную карту с оценкой. Выводы привязываются к порядку работ, срокам и составу релиза, иначе отчёт быстро переезжает в папку «прочитать позже».
Перед следующим релизом нужны семь ответов
Категорию для каждого замечания выбирают по конкретному сценарию: что сломается, как команда это заметит и сможет ли восстановить систему. Поэтому рядом с зелёными статусами на доске нужны ответы:
- Какие пользовательские и денежные сценарии затрагивает изменение?
- Где хранится главная версия данных для каждого из них?
- Что произойдёт при задержке, повторе или частичном сбое?
- По какой метрике команда первой увидит проблему?
- Кто принимает решение об остановке или продолжении запуска?
- Как вернуть предыдущую версию и восстановить данные?
- Какие риски команда принимает сейчас и когда вернётся к ним?
Наше правило: критический риск сдвигает запуск; контролируемый получает мониторинг и план отката; остальные замечания занимают своё место в дорожной карте с владельцем и сроком.
Когда картину релиза приходится собирать по чатам, памяти команды и диаграмме неизвестной свежести, приносите проект на IT-консалтинг и аудит разработки. Мы разберём текущую систему и поможем определить состав следующего релиза до того, как самый подробный отчёт о проблеме напишут пользователи.