Если вам досталась система без исходного кода и без документации — практический план, как сопровождать её, не останавливая работу

«Компания-разработчик уже не существует», «сотрудник, который всё сделал, уволился, и связаться с ним нельзя», «на сервере есть исполняемый файл и база данных, но ни исходного кода, ни спецификации найти не удаётся» — в консультациях по бизнес-системам малого и среднего бизнеса это отнюдь не редкая ситуация. И тем не менее система продолжает работать сегодня, а бизнес от неё зависит.

Худший выбор в такой ситуации — начать наугад дорабатывать код или менять окружение по наитию, потому что «всё равно непонятно». У системы без исходного кода нет гарантии, что её удастся починить, если она сломается. Но и вывод «ничего сделать нельзя, остаётся только полная пересборка», сделанный с порога, тоже преждевременен. Есть способы восстановить спецификацию даже без документации, а иногда можно прочитать внутренности даже без исходного кода. В этой статье разберём по порядку, в котором это делается на практике, шаги от полного нуля до налаженной эксплуатации и сопровождения.

1. Сначала вывод

• Первым делом нужна не доработка, а «сохранение текущего состояния». Само работающее рабочее окружение — важнейший актив. Снимите резервную копию образа диска (например, превратив его в виртуальную машину через Disk2vhd) и резервную копию базы данных, и прежде чем двигаться дальше, убедитесь, что из них можно восстановиться.¹
• Спецификацию можно восстановить даже без документации. Основные материалы — опрос пользователей, экраны и отчёты, схема базы данных, логи и наблюдение за фактическим поведением через Process Monitor.²
• Возможность восстановления исходного кода сильно зависит от технологического стека. Для .NET декомпиляторы вроде ILSpy позволяют прочитать довольно многое, тогда как для нативного кода — VB6, C++ — на восстановление реалистично рассчитывать не стоит.³⁴
• У декомпиляции есть правовые нюансы. Согласно статье 30-4 Закона об авторском праве использование в целях исследования и анализа в целом считается допустимым, но проверка договора (условий лицензии) обязательна.⁵
• Не ждите «полного понимания», прежде чем действовать. Приоритетно разбирайтесь с участками, остановка которых остановит бизнес, и с теми, что скоро потребуют изменений; изменения вносите маленькими шагами, по одному, с возможностью отката.
• Основа договора на сопровождение — квазидоверительный договор. Для исследования системы с неизвестным содержимым нельзя обещать ответственность за завершённый результат (подряд). Заключайте отдельные договоры на этап расследования и на этап доработки.

2. Почему возникает ситуация «нет вообще ничего»

Прежде чем думать о реагировании, полезно определить, к какому паттерну относится ваш случай, — это подскажет, какие зацепки могли сохраниться.

Последний паттерн легко упускают из виду, но на практике его нужно рассматривать так же, как «исходников нет». Классическая ошибка — принять старую версию исходников за эталон и доработать её, а потом выяснить, что в рабочий исполняемый файл на самом деле были внесены годы правок, которых в исходниках не было. Даже если исходное дерево найдено, не доверяйте ему, пока не соберёте его и не сверите результат с рабочим исполняемым файлом.

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

3. Что делать в первую неделю — сохранение текущего состояния и инвентаризация

3.1 Заморозка изменений

Пока расследование не завершено, правило — не трогать целевые серверы и машины. «Давайте пока обновим ОС» или «давайте приберём файлы, которые вроде бы не используются» — это именно то, что может стать фатальным. Раз исходного кода нет, варианта «просто починить», если что-то сломается, не существует. Стоит также подумать о том, чтобы взять под контроль момент применения автоматических обновлений (Windows Update, изменения поведения антивирусного ПО), чтобы они не меняли окружение сами по себе.

3.2 Резервное копирование — дублирование самого окружения как актива

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

На практике для этого чаще всего используют Disk2vhd из Sysinternals. Он позволяет преобразовать работающую систему прямо во время её работы в согласованный VHD/VHDX с помощью теневого копирования тома (VSS), создавая основу для проверочного окружения, которое можно запустить как виртуальную машину Hyper-V.¹ Преимущество в том, что это одновременно снижает риск старения физического сервера и обеспечивает проверочное окружение (учтите, что для Windows с OEM-лицензией перенос в виртуальное окружение может быть не разрешён условиями лицензии, поэтому её тип нужно проверить¹).

Наряду с этим сделайте резервную копию базы данных стандартными средствами СУБД. И самое важное — фактически восстановиться из резервной копии и убедиться, что система запускается. Резервная копия, не прошедшая проверку восстановлением, — лишь предполагаемая страховка. При этом, поскольку в восстановленном образе остаются рабочие настройки подключения и задачи планировщика как есть, первый запуск обязательно проводите в окружении, изолированном от сети (подробнее в главе 7). Случайно запустив образ подключённым к сети, вы рискуете тем, что окружение, задуманное как тестовое, обновит рабочую базу данных или партнёров по интеграции.

3.3 Инвентаризация — составьте список того, что вообще работает

Далее механически выявите все составляющие системы. Здесь важна не интуиция, а полнота охвата.

Если непонятно, «где вообще находится» конфигурационный файл или место вывода, быстрее всего понаблюдать за доступом процесса к файлам и реестру через Process Monitor — пути, которые приложение реально читает и куда пишет, появятся в списке напрямую.²

4. Спецификацию можно восстановить даже без документации

Когда инвентаризация показала, «что есть», следующий шаг — восстановление «что это делает». Материалы для этого есть в наличии.

• Опрос пользователей — лучшая из существующих спецификаций находится в голове у тех, кто пользуется системой каждый день. Пройдитесь по ежедневным, ежемесячным и годовым бизнес-процессам, узнавая, что на каком экране вводится и что выходит на выходе. Особенно годовая обработка (закрытие года, годовая инвентаризация, обновление учётного года) — то, что порой забывает даже ответственный сотрудник, и это распространённая точка сбоя при первом же прогоне после передачи дел.
• Экраны и отчёты — каталогизируйте все экраны и все отчёты со скриншотами и реальными образцами. Уже одно только соответствие полей ввода и вывода во многом раскрывает скелет обработки.
• Схема базы данных и данные — определения таблиц, ограничения и реальные данные кодовых значений — это окаменелости бизнес-правил. Наблюдение вроде «у этого флага используется только три значения» подскажет о спецификациях, которых не увидеть с экранов.
• Логи и журнал событий — собственные логи приложения, если они есть, раскрывают ход обработки, а журнал событий Windows — прошлые тенденции ошибок.
• Наблюдение за фактическим поведением — записывая доступ к файлам, реестру и сети через Process Monitor, можно подтвердить соответствие входов и выходов — «эта обработка в конце месяца читает CSV из этой общей папки и обменивается данными с этим сервером БД» — без единой строки исходного кода.² Впрочем, Process Monitor показывает только партнёра по обмену данными, но не то, какие таблицы и как были обновлены. Дальше нужно определять это через собственные средства трассировки/аудита СУБД (например, расширенные события SQL Server) или сверяя содержимое базы данных до и после выполнения обработки.

Здесь важно не пытаться документировать все функции в равной степени. Цель — непрерывность эксплуатации, а не энциклопедия, поэтому приоритетно наращивайте реестр по мере изучения, начиная с «обработки, остановка которой останавливает бизнес», «обработки, выдающей ошибки» и «участков, где изменения понадобятся в ближайшее время».

5. Что технически возможно без исходного кода

То, насколько можно рассчитывать на «чтение внутренностей», почти полностью определяется тем, на чём построена система. Оцените технологический стек по свойствам исполняемого файла и составу DLL, и настройте ожидания соответственно.

Для приложения на .NET, развёрнутого в обычном формате IL, ситуация довольно благоприятная — код на C#, полученный декомпиляцией, вполне практически пригоден для понимания обработки. Однако, как прямо указано и в официальной документации, комментарии, имена локальных переменных, пробелы и прочая информация, не нужная во время выполнения, теряются, поэтому такой код стоит рассматривать не как замену исходного кода, а как материал для понимания поведения.³ Есть и исключения: если применена обфускация, сложность расшифровки резко возрастает, а бинарный файл, опубликованный через Native AOT, не содержит IL, так что ожидание «раз это .NET, значит читается» не работает. При оценке технологического стека проверяйте не только язык разработки, но и формат развёртывания.

Если рядом с исполняемым файлом сохранился PDB (файл символов), иногда можно восстановить имена функций, а если есть встроенный исходный код — то и сам исходник. О том, что в нём может быть и на что можно рассчитывать, рассказано в статье «Что такое PDB (база данных программы)».

Правовые нюансы — декомпиляция только «после проверки»

То, что технически возможно, и то, что разрешено, — разные вещи. Реверс-инжиниринг, включая декомпиляцию, связан с нюансами авторского права. Согласно статье 30-4 Закона об авторском праве (введённой поправкой 2018 года и охватывающей «использование, не направленное на восприятие мыслей или чувств, выраженных в произведении»), воспроизведение или переработка в целях исследования и анализа программы в целом считаются допустимыми в пределах необходимого. Однако в статье есть оговорка: «за исключением случаев, которые неправомерно ущемляют интересы правообладателя», и, например, использование результатов анализа для создания конкурирующего продукта может получить иную оценку.⁵

Остаётся и отдельный договорный вопрос о том, как трактовать случаи, когда в лицензионном соглашении на пакетное ПО или переданный материал есть пункт, запрещающий анализ. Перед тем как приступать, проверьте условия лицензии соответствующего ПО и тогдашний договор на разработку (пункт о принадлежности авторских прав), а в спорных случаях проконсультируйтесь с юристом. Если авторские права на переданный материал принадлежат вашей же компании, этот вопрос заметно упрощается. О том, как читать такой договор, также рассказано в статье «Как должен быть заключён договор на заказную разработку и сопровождение».

6. Продлить жизнь, «обернуть» или пересобрать заново

Когда понимание, полученное при расследовании, сопоставлено с реалиями бизнеса, наступает время определить курс. И здесь ответ — не «полная пересборка по умолчанию» и не «оставить как есть по умолчанию», а разбор через таблицу решений.

Определяющих факторов четыре: оставшийся срок использования, частота и концентрация запросов на изменения, влияние на бизнес в случае остановки, и уровень понимания, восстановленный в ходе расследования. Переход к полной пересборке при низком уровне понимания рискует упустить особенности старой системы вроде «никто не может объяснить, но для бизнеса это правильное поведение». Даже если выбрана пересборка, реестр спецификаций, восстановленный в главе 4, напрямую ложится в основу определения требований, так что инвестиция в расследование никогда не пропадает зря. При миграции стандартный приём — запустить старую и новую системы параллельно на определённый период и механически сверить выходные данные (отчёты, сводки, файлы) для одинаковых входных данных.

Решения о продлении жизни и миграции для конкретных технологий, таких как VB6 и Access, подробно рассмотрены в статье «Продление жизни и миграция бизнес-приложений на VB6 / Access», а об отказе от внутренних веб-систем, зависящих от режима IE, — в статье «Руководство по выходу из зависимости от режима IE».

7. Эксплуатация и сопровождение после передачи дел

Если курс — «пока продолжать эксплуатацию» (на практике так обстоит дело в большинстве случаев), следование следующим шаблонам снижает число инцидентов.

• Держите проверочное окружение — но первый запуск всегда изолируйте от сети — запустив образ диска, созданный в пункте 3.2, как виртуальную машину, вы получаете проверочное окружение, совпадающее с рабочей конфигурацией. Но в этом образе как есть сохранены рабочие строки подключения, учётные данные, задачи планировщика и автозапускаемые службы. Запустив его подключённым к сети, вы рискуете тем, что ночное пакетное задание сработает дважды и обновит рабочую базу данных, письма отправятся повторно, или будет вызван внешний API. Первый запуск всегда проводите либо с отключённым виртуальным сетевым адаптером, либо в изолированной сети, остановите задачи планировщика и автозапускаемые службы, перепишите точки подключения на тестовые, и только затем открывайте доступ в нужном минимальном объёме.
• Изменения — по одному, с возможностью отката — и изменение настроек, и применение Windows Update делайте по одному за раз. Сохраняйте образ до изменения и откатывайтесь, если возникла проблема. К этому обязательно прилагайте запись о том, что было изменено (журнал изменений).
• Растите документацию как «побочный продукт исследования» — вместо того чтобы запускать проект по написанию идеальной спецификации, добавляйте в реестр всё, что узнаёте при каждом реагировании на инцидент или доработке. Через год эксплуатации документация соберётся, начиная с наиболее важных для бизнеса участков.
• Настройте мониторинг — контроль работоспособности, свободное место на диске, журналы ошибок, а также обнаружение ситуации «файл, который обычно всегда появляется, не появился». Даже если внутренности чёрного ящика не видны, можно наблюдать за его входом и выходом.
• Разделяйте договоры на расследование и доработку — при заказе сопровождения у внешнего исполнителя нельзя обещать ответственность за завершённый результат при исследовании системы с неизвестным содержимым, поэтому разумно разделить договор по этапам: расследование и сопровождение — как квазидоверительный договор, а отдельные доработки после фиксации спецификации — как договор подряда (или квазидоверительный договор с ориентацией на результат).

8. Итог

• Если вам досталась система без исходного кода и без документации, прежде доработки нужно сохранение текущего состояния. Снимите образ диска (например, через Disk2vhd) и резервную копию БД, убедитесь, что их можно восстановить.
• Проведите инвентаризацию исполняемых файлов, автозапуска, задач планировщика, настроек, точек интеграции и учётных записей, составив полную картину системы.
• Спецификацию можно восстановить по опросу пользователей, экранам, отчётам, схеме БД, логам и наблюдению за фактическим поведением через Process Monitor. Приоритет — не все функции, а участки с наибольшим влиянием на бизнес.
• Возможность восстановления внутренностей зависит от технологического стека. .NET достаточно хорошо читается через декомпиляцию, но это не замена исходного кода. Перед началом работы проверьте смысл статьи 30-4 Закона об авторском праве, условия лицензии и договоры.
• Курс — «продление жизни / обёртывание / частичная пересборка / полная пересборка» — определяется по оставшемуся сроку использования, частоте изменений, влиянию на бизнес и уровню понимания. Спецификация, восстановленная при расследовании, становится активом независимо от выбранного пути.
• На этапе эксплуатации базовый шаблон — проверочное окружение, изменения по одному, журнал изменений, мониторинг входа и выхода, и квазидоверительный договор.

Похожие статьи

• Что такое PDB (база данных программы) — разбираемся в отладочной информации, символах и Source Link
• Практическое руководство по Process Monitor
• Продление жизни и миграция бизнес-приложений на VB6 / Access — таблица решений: оставить, обернуть, заменить
• Руководство по выходу из зависимости от режима IE
• Как должен быть заключён договор на заказную разработку и сопровождение — выбор между квазидоверительным договором и договором подряда, уроки из «Модельной сделки и договора» IPA
• Что нужно продумать перед заказом разработки Windows-приложения

Смежные направления консультаций

KomuraSoft LLC занимается исследованием текущего состояния бизнес-систем, у которых не сохранился исходный код или документация (анализ исполняемых файлов, базы данных, фактического поведения), восстановлением спецификации по поведению, выработкой стратегии продления жизни или миграции и последующей эксплуатацией и сопровождением. Мы рады консультациям и на этапе «непонятно, с чего вообще начинать».

• Использование существующих активов и поддержка миграции
• Доработка и сопровождение существующего Windows-ПО
• Расследование сбоев и анализ первопричин
• Техническая консультация и ревью проекта
• Контакты

Источники

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Можно ли заказать сопровождение или доработку системы, у которой нет исходного кода?

Можно. Но порядок работы отличается от обычного сопровождения. Реалистичный путь — сначала сохранить и зарезервировать работающее окружение, затем провести этап расследования, восстанавливающий спецификацию по анализу экранов, отчётов, базы данных, логов и исполняемых файлов, и уже в рамках понимания, полученного на этом этапе, переходить к доработке или разработке смежной функциональности. Поскольку расследование по своей природе не позволяет заранее гарантировать результат, его обычно ведут по квазидоверительному договору, а не по договору подряда с ответственностью за завершённый результат.

Не является ли декомпиляция (реверс-инжиниринг) исполняемого файла незаконной?

Однозначно незаконной она не является. Согласно статье 30-4 Закона об авторском праве, введённой поправкой 2018 года, использование, не направленное на «восприятие мыслей или чувств, выраженных в произведении», — например исследование и анализ программы, — в целом считается допустимым в пределах необходимого. Однако есть исключение для случаев, «которые неправомерно ущемляют интересы правообладателя», а также остаётся отдельный вопрос о том, как трактовать запрет анализа в лицензионном соглашении. Перед тем как приступать, проверьте условия лицензии и договор на разработку, а в спорных случаях проконсультируйтесь с юристом или другим специалистом.

Компания-разработчик обанкротилась, и исходный код получить неоткуда. Что делать?

Прежде всего проверьте прошлые договоры и переданные материалы. Если в договоре на разработку определена принадлежность авторских прав и обязательство передать исходный код, это даёт основание для получения или использования. Если есть возможность связаться с кем-то из причастных лиц, стоит поискать и возможность договориться о передаче. Но на практике важно не останавливаться на «в итоге не получили» — исходя из предположения, что получить исходники не удастся, стоит параллельно начать сохранение и резервное копирование работающего окружения и восстановление спецификации по поведению и базе данных.

С чего начать, если у системы нет спецификации?

Прежде доработки — сначала сохранение текущего состояния. Снимите образ диска работающего рабочего окружения и резервную копию базы данных, убедитесь, что их можно восстановить. Затем проведите инвентаризацию исполняемых файлов, автозапуска, задач планировщика, настроек, точек интеграции и учётных записей, составив полную картину системы. После этого стандартный путь — опрос пользователей и наблюдение за экранами, отчётами и схемой базы данных, документируя спецификацию только для тех участков, которые важны для бизнеса.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.