Технический аудит системы: риски, стоимость владения, передаваемость
Технический аудит нужен тогда, когда надо принять решение о деньгах, а данных для него нет. Покупать эту компанию с ее системой или нет. Продолжать с текущим подрядчиком или менять. Развивать то, что есть, или переписывать. Во всех трех случаях нужен независимый взгляд на код, архитектуру и риски.
Мы разбираем систему и отвечаем на конкретные вопросы: сколько стоит ею владеть, что в ней опасно, можно ли ее развивать и что будет, если разработчик уйдет.
Когда его заказывают
- Перед сменой подрядчика. Надо понять, что вы получаете и сколько будет стоить принять это в работу. Новая команда всегда скажет, что «здесь все плохо» — аудит дает независимую оценку.
- Перед покупкой бизнеса или доли. Система может быть основным активом, а может быть основным обязательством. Разница в деталях, которые не видны из презентации.
- Когда развитие замедлилось. Каждая новая функция делается дольше предыдущей. Обычно это симптом, и стоит понять, чего именно.
- После инцидента. Утечка, потеря данных, долгий простой. Вопрос не только «что случилось», но и «что еще может».
- Когда все держится на одном человеке. Разработчик, который знает систему один, — это риск, который лучше оценить до того, как он реализуется.
- Перед решением переписывать. Самое дорогое решение из возможных. Стоит принимать его на основании фактов, а не усталости.
Что мы смотрим
Как проходит аудит
- Определяем вопрос. Аудит перед покупкой компании и аудит перед сменой подрядчика — разные работы. Формулируем, на какое решение должен повлиять результат.
- Получаем доступ. Код, база (можно обезличенную копию), серверы, документация, задачи. Чем полнее доступ, тем точнее выводы; при ограниченном доступе честно помечаем, что осталось непроверенным.
- Смотрим код и архитектуру. Не построчно, а по срезам: как устроены ключевые части, есть ли повторы одной логики в трех местах, что произойдет при изменении в типовом сценарии.
- Проверяем безопасность. Пароли и ключи в коде, права доступа, известные уязвимости в используемых библиотеках, обработка персональных данных, следы прежних инцидентов.
- Проверяем эксплуатацию. Есть ли резервные копии и разворачивались ли они хоть раз, как выкладываются обновления, что показывает мониторинг, сколько времени занимает откат.
- Пробуем развернуть с нуля. Самая показательная проверка. Если по имеющейся документации система не поднимается на чистом сервере, передача не завершена, какие бы акты ни были подписаны.
- Считаем стоимость владения. Что стоит поддерживать это дальше, что стоит привести в порядок, что стоит переписать. С цифрами по каждому пункту.
Где здесь искусственный интеллект
- Обзор большой кодовой базы. Быстрый разбор структуры, поиск дублирующейся логики и мест, которые меняются чаще всего. На сотнях тысяч строк это меняет масштаб работы.
- Поиск подозрительных мест. Пароли в коде, небезопасные запросы, отсутствие проверки прав. Модель находит кандидатов, разработчик проверяет каждый — автоматика здесь дает и пропуски, и ложные срабатывания.
- Восстановление документации. Описание того, как устроена система, по самому коду. Полезно, когда документации нет вообще, — а это типичная ситуация.
- Анализ истории изменений. По журналу правок видно, какие части системы самые хрупкие: они переписываются чаще всего и обычно чинятся в спешке.
Ручную работу это не заменяет. Оценка архитектурных решений и понимание, почему сделано именно так, требуют человека: часть странных на вид решений оказывается разумной, если знать историю проекта.
Что вы получаете
- Оценка состояния по каждому направлению — коротко и без технического жаргона там, где отчет будут читать не программисты.
- Список рисков с приоритетом — что может привести к потере данных, простою или утечке, и насколько это вероятно.
- Что делать в первую очередь — обычно несколько вещей, которые дешево исправить и которые снимают большую часть риска.
- Оценка стоимости владения — во что обойдется поддержка и развитие в текущем состоянии и после приведения в порядок.
- Ответ на вопрос «развивать или переписывать» — с обоснованием и с оценкой обоих вариантов, а не с одним рекомендуемым.
- Оценка передаваемости — сколько времени займет у новой команды войти в проект.
Разберем систему и дадим независимую оценку
Опишите ситуацию: меняете подрядчика, покупаете бизнес, решаете судьбу системы. В ответ — план аудита, перечень необходимых доступов, сроки и стоимость. Отчет пишем так, чтобы его можно было показать и техническому специалисту, и собственнику.
Мы не заинтересованы в выводе «надо переписать»: если систему выгоднее развивать, так и напишем.
Сроки и стоимость
Сроки зависят от размера системы и от того, насколько полный доступ удалось получить. Аудит по одному коду без доступа к серверам и без разговора с разработчиками возможен, но выводы будут осторожнее.
Частые находки
- Резервные копии, которые никто не восстанавливал. Они есть, они настроены, и никто ни разу не проверял, разворачиваются ли они. Примерно в половине случаев выясняется, что нет.
- Пароли и ключи в репозитории. Классика, особенно в проектах, которые начинались быстро и без процесса.
- Нет тестового окружения. Обновления выкладываются сразу на боевой сервер, потому что второго просто нет.
- Библиотеки, которые не обновлялись годами. Часть из них с известными уязвимостями, и это самая простая для исправления категория риска.
- Развернуть систему заново невозможно. Сервер настраивали руками, инструкции нет, человек уволился. Система работает, пока работает.
- Нет истории изменений кода. Или она началась с одного коммита «initial» полгода назад, хотя проекту четыре года.
- Данные не разделены по правам. Любой сотрудник с доступом к системе технически может увидеть все.
Как читать результат
Отчет об аудите легко превратить в список претензий, по которому невозможно принять решение. Поэтому мы разделяем находки на четыре категории, и в этом основная польза документа.
Опасно
То, что может привести к потере данных, длительному простою или утечке. Исправляется в первую очередь независимо от планов на систему. Таких пунктов обычно немного, и они почти всегда недорогие.
Дорого в поддержке
Решения, из-за которых каждое изменение занимает больше времени, чем должно. Не мешают работать сегодня, но определяют стоимость развития на годы вперед.
Некрасиво, но работает
То, что вызвало бы спор между программистами и ничего не меняет для бизнеса. Такие пункты мы отмечаем и прямо пишем, что трогать их не нужно.
Требует решения бизнеса
Например, система не рассчитана на десятикратный рост. Это не дефект, а ограничение, и вопрос в том, планируется ли такой рост.
Что нужно с вашей стороны
Аудит идет быстрее и точнее, когда доступ полный. Минимально нужен код с историей изменений и возможность задать вопросы тому, кто систему делал. Желательно — доступ к серверам на чтение, копия базы (можно обезличенная), документация, если она есть, и система задач.
Отдельно стоит предупредить текущего разработчика или подрядчика. Аудит за спиной портит отношения и почти всегда становится известен, а нормальная формулировка — «мы планируем развитие и хотим независимую оценку» — принимается спокойно. Хороший разработчик часто сам рад внешнему взгляду и заранее говорит, где у него болит.
Если доступа к людям нет совсем — например, при покупке бизнеса или при разрыве отношений с подрядчиком, — аудит все равно возможен, просто выводы будут осторожнее, а часть вопросов останется с пометкой «не проверено».
Аудит перед сменой подрядчика
Это отдельный жанр, и здесь важна честность. Новая команда почти всегда говорит, что предыдущая сделала плохо: это дает основание для переписывания, а переписывание — большой проект.
Мы стараемся отвечать на другой вопрос: сколько будет стоить принять эту систему в работу и развивать ее дальше. Иногда ответ — «нормально, входить можно за неделю». Иногда — «войти можно, но первым делом придется закрыть вот эти три дыры». Иногда действительно «дешевле переписать», и тогда в отчете есть расчет, почему.
Если аудит заказан у нас, а работать вы будете с другим подрядчиком, это нормально: отчет пишется так, чтобы им мог пользоваться кто угодно.
Дальше по теме
Частые вопросы
Когда нужен технический аудит?
Перед сменой подрядчика, перед покупкой бизнеса, когда каждая новая функция делается дольше предыдущей, после инцидента с данными или простоем, когда систему знает один человек, и перед решением переписывать — это самое дорогое решение из возможных, и принимать его стоит по фактам.
Что именно вы проверяете?
Шесть направлений: архитектуру, качество кода, безопасность, данные, эксплуатацию (резервные копии, мониторинг, выкладку) и передаваемость — сможет ли другая команда продолжить без автора. Последнее обычно и есть настоящий предмет аудита, остальное важно ровно настолько, насколько на него влияет.
Сколько это занимает и стоит?
Экспресс-оценка с основными рисками и ответом на главный вопрос — 3–7 дней. Полный аудит с разбором архитектуры, безопасности, данных и эксплуатации — 2–4 недели. Сроки зависят от размера системы и полноты доступа.
Что нужно предоставить?
Минимально — код с историей изменений и возможность задать вопросы тому, кто систему делал. Желательно доступ к серверам на чтение, копию базы (можно обезличенную), документацию и систему задач. При ограниченном доступе аудит возможен, но часть выводов будет с пометкой «не проверено».
Нужно ли предупреждать текущего подрядчика?
Да. Аудит за спиной портит отношения и почти всегда становится известен. Формулировка «мы планируем развитие и хотим независимую оценку» принимается спокойно, а хороший разработчик часто сам рад внешнему взгляду и заранее говорит, где у него болит.
Вы скажете, что надо все переписать?
Только если это действительно так, и тогда с расчетом. Мы не заинтересованы в таком выводе: переписывание — самое дорогое решение. Обычно ответ звучит иначе: войти в систему можно, но сначала надо закрыть вот эти несколько дыр. В отчете оцениваются оба варианта, а не один рекомендуемый.
Что чаще всего находится?
Резервные копии, которые ни разу не восстанавливали (примерно в половине случаев они не разворачиваются); пароли и ключи в репозитории; отсутствие тестового окружения; библиотеки, не обновлявшиеся годами; невозможность развернуть систему заново, потому что сервер настраивали руками; отсутствие истории изменений кода.
Обязательно ли потом работать с вами?
Нет. Отчет пишется так, чтобы им мог пользоваться кто угодно: и ваш технический специалист, и другой подрядчик, и собственник без технического образования. Аудит — отдельная работа и не привязывает вас к нам.