Начните с того, что можно проверить без чтения кода: кому принадлежат репозиторий, домен и облачные аккаунты, собирается ли продукт по инструкции, есть ли резервные копии, из которых умеют восстанавливаться, и как выкатываются релизы. Если здесь всё в порядке, а сомнения касаются качества кода, безопасности или архитектуры, нужен независимый взгляд: консультация — для одного вопроса, выборочный обзор — для одной зоны риска, полный технический аудит — перед ростом, сменой подрядчика или сделкой.
Содержание
- Почему «всё работает» — ещё не ответ
- Что владелец может проверить сам — без чтения кода
- Сигналы, что нужен взгляд со стороны
- Консультация, выборочный обзор или полный аудит: что выбрать
- Как подготовить проверку: объём, доступы, данные
- Что должно быть в отчёте — и чего в нём быть не может
- Как использовать результат
Почему «всё работает» — ещё не ответ
Продукт, который открывается и проходит демо, может одновременно быть дорогим в развитии, зависеть от одного человека и хранить данные так, что их нельзя восстановить после сбоя. Владелец видит интерфейс, а эти свойства спрятаны в коде, настройках и процессах. Поэтому вопрос «хорошо ли сделан продукт» полезно разбить на три вопроса, на которые можно ответить по отдельности.
- Контроль: принадлежат ли вам код, домен, аккаунты и данные и сможете ли вы продолжить работу, если подрядчик завтра исчезнет?
- Развиваемость: можно ли добавлять функции без того, чтобы каждая новая стоила дороже предыдущей и ломала старые?
- Риски для пользователей и данных: что произойдёт при утечке ключа, ошибке в правах доступа, сбое базы или неудачном релизе?
Первый вопрос владелец закрывает сам — это вопрос документов и доступов. Второй и третий требуют чтения кода и инфраструктуры, и здесь собственной проверки обычно недостаточно, даже если в компании есть технический сотрудник: у него нет времени на системный разбор или он сам участвовал в разработке.
Что владелец может проверить сам — без чтения кода
Эти пункты проверяются за один созвон с подрядчиком и пару часов работы с аккаунтами. Ни один из них не требует технической подготовки — только доступа и настойчивости.
- Репозиторий с кодом находится в организации или аккаунте вашей компании, вы — владелец, а подрядчик работает с ограниченной ролью. В GitHub, например, роли идут от
ReadдоAdmin, и полный доступ нужен только тем, кому он действительно необходим. - Домен зарегистрирован на вашу компанию, доступ к регистратору и DNS — у вас.
- Хостинг, база данных, почтовый сервис, платёжный провайдер, аналитика и сторонние API оформлены на корпоративную почту, а не на личный ящик разработчика.
- Есть список всех внешних сервисов, которые использует продукт, с указанием, кто за них платит и где лежат ключи доступа.
- Новый разработчик может собрать и запустить продукт по инструкции из репозитория. Попросите подрядчика показать это на чистой машине во время созвона.
- Тестовое и рабочее окружения разделены: эксперименты не происходят на базе с реальными клиентами.
- Резервные копии делаются автоматически, и известна дата последнего успешного восстановления из копии — не только её создания.
- Понятно, как изменение попадает в рабочую версию и как откатить неудачный релиз.
- Ошибки пользователей где-то фиксируются: есть журнал или сервис мониторинга, и кто-то его смотрит.
- Задачи, обсуждения и демо ведутся в системе, к которой у вас есть доступ, а не только в личной переписке.
Если несколько пунктов не выполняются, это ещё не приговор качеству кода, но это прямой риск для бизнеса: продукт фактически принадлежит тому, у кого доступы. Такие пункты стоит исправить до любого аудита — они не требуют разбора кода и обычно решаются передачей прав и настройкой.
Сигналы, что нужен взгляд со стороны
Качество кода и архитектуры видно по последствиям задолго до того, как кто-то откроет репозиторий. Ниже — ситуации, в которых внешняя проверка обычно окупается, потому что от её результата зависит дорогое решение.
- Каждая новая функция занимает больше времени, чем похожая полгода назад, а оценки подрядчика регулярно не сходятся с фактом.
- Релизы ломают то, что раньше работало, и это обнаруживают пользователи, а не команда.
- Подрядчик не может внятно объяснить, как устроена часть системы, или знания сосредоточены у одного человека.
- Вы меняете подрядчика или команду и хотите понять, что передаёте и что получаете.
- Впереди инвестиции, продажа бизнеса или крупный клиент, который задаст вопросы о безопасности и надёжности.
- Был инцидент: утечка, потеря данных, долгий простой — и нужно понять, единичный ли это случай.
- Продукт собран быстро, в том числе с помощью AI-ассистентов, и готовится к реальным пользователям.
Для разговора о процессе поставки полезно опираться на метрики, которые описывает исследовательская программа DORA. Это не оценки «хорошо/плохо», а вопросы, на которые зрелая команда отвечает цифрами из своих систем.
Время внесения изменения
- Вопрос подрядчику
- Сколько проходит от готового изменения в коде до его появления в рабочей версии?
- Что настораживает
- Никто не знает, или ответ «зависит от того, когда соберёмся выкатить»
Частота релизов
- Вопрос подрядчику
- Как часто выходят обновления?
- Что настораживает
- Релизы редкие и большие, каждый — событие с риском
Доля неудачных релизов
- Вопрос подрядчику
- Какая часть релизов потребовала срочного отката или исправления?
- Что настораживает
- Это не отслеживается
Время восстановления
- Вопрос подрядчику
- Сколько занимает восстановление после неудачного релиза?
- Что настораживает
- Откат не отработан, восстановление — ручная импровизация
Консультация, выборочный обзор или полный аудит: что выбрать
Форматы проверки различаются глубиной и тем, какой вопрос они закрывают. Ошибка в обе стороны стоит денег: полный аудит ради одного вопроса избыточен, а короткая консультация не скажет ничего о системе в целом.
Консультация
- Когда подходит
- Есть конкретный вопрос: стоит ли переписывать модуль, нормальна ли выбранная архитектура, как оценить предложение подрядчика
- Что вы получаете
- Разбор вариантов и рисков, рекомендация и несколько следующих шагов
- Чего не будет
- Анализа всего кода и гарантий
Выборочный обзор
- Когда подходит
- Риск в одной зоне: права доступа, платежи, интеграция, конкретный модуль
- Что вы получаете
- Короткий отчёт: находки в этой зоне и явные границы проверки
- Чего не будет
- Выводов о системе в целом
Полный технический аудит
- Когда подходит
- Перед ростом, сменой подрядчика, инвестициями или сделкой
- Что вы получаете
- Резюме для владельца, находки с доказательствами по доменам, приоритеты и план работ
- Чего не будет
- Исправлений — это отдельный проект; заключения «уязвимостей нет»
Тест на проникновение
- Когда подходит
- Нужна проверка устойчивости к атаке по согласованным правилам
- Что вы получаете
- Отчёт специализированной проверки в оговорённых границах
- Чего не будет
- Это отдельная услуга со своими правилами взаимодействия, а не часть обычного аудита
Отдельно от разовых проверок существует code review — регулярное рецензирование изменений внутри команды. Руководство Google по инженерным практикам перечисляет, на что смотрит рецензент: дизайн изменения, функциональность, сложность, тесты, именование, комментарии, стиль и документацию. Если в команде подрядчика такого процесса нет, это само по себе находка: каждое изменение попадает в продукт, не пройдя второй пары глаз.
Как подготовить проверку: объём, доступы, данные
Запишите решение и вопросы
Что вы решите по итогам и какие вопросы должен закрыть отчёт. Это определяет глубину и не даёт проверке расползтись.
Согласуйте объём
Какие репозитории, окружения, модули и интеграции входят в проверку, а какие — нет. Всё, что вне объёма, в отчёте должно быть помечено как «не проверялось».
Выдайте доступ только на чтение
Индивидуальный и временный, для конкретного человека. Писать в репозиторий и менять настройки проверяющему не нужно.
Не передавайте секреты и реальные данные клиентов
Для проверки достаточно кода, схемы данных и тестового окружения. Если без данных не обойтись, их обезличивают заранее.
Соберите то, что уже есть
Схему системы, список интеграций, известные проблемы, историю инцидентов. Отсутствие документации — тоже информация, скрывать его не нужно.
Предупредите текущего подрядчика
Его объяснения — часть картины: многие решения выглядят странно без контекста, в котором их принимали.
Отзовите доступы после завершения
Зафиксируйте, у кого и до какой даты был доступ, и закройте его, когда отчёт получен.
Что должно быть в отчёте — и чего в нём быть не может
Ценность аудита — в проверяемости. Каждая находка должна позволять вашей или любой другой команде воспроизвести проблему, оценить её и проверить исправление. Минимальный набор полей находки:
- что именно наблюдали и где — компонент, окружение, файл или экран;
- доказательство: ссылка на код, запрос, конфигурацию или снимок, без секретов и персональных данных;
- влияние на бизнес простыми словами и вероятность, что проблема проявится;
- критичность и уверенность — насколько факт доказан, а не предположен;
- рекомендация, примерный класс трудозатрат и шаги повторной проверки;
- ограничения: что могло повлиять на вывод.
Полезный отчёт
- Резюме для владельца на одной-двух страницах и технические детали для команды
- Каждая находка подкреплена доказательством
- Явно указано, что не проверялось
- Приоритеты привязаны к последствиям для бизнеса
- По нему может работать любая команда
Бесполезный отчёт
- Выгрузка автоматического сканера без разбора
- Оценки «код плохой» без примеров
- Критичность завышена, чтобы продать исправления
- Нет границ проверки — непонятно, что осталось за кадром
- Рекомендации вида «переписать всё»
Как использовать результат
Отчёт аудита — инструмент для решения, а не приговор команде. Обычно из него вырастает один из трёх сценариев: текущий подрядчик исправляет находки по приоритетам; продукт передаётся другой команде, и отчёт становится частью передачи; или планируется поэтапная переработка отдельных модулей вместо переписывания всего продукта. Последний вариант чаще всего безопаснее: система продолжает работать, а риск каждого шага ограничен.
Хорошая практика — повторная проверка критичных находок после исправления по шагам, записанным в отчёте. Тогда вы знаете не только что риск был, но и что он закрыт.
