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

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

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

1. Главное

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

Статья выстроена в том порядке, в котором эти шаги делают на практике. Общая картина такая.

flowchart TD
    A["Глава 3. Фиксация<br/>заморозка изменений, образ диска<br/>резервная копия БД и проверка восстановления"] --> B["Глава 3. Инвентаризация<br/>исполняемые файлы, автозапуск, задачи<br/>настройки, интеграции, учётные записи"]
    B --> C["Глава 4. Восстановление спецификации<br/>опрос, экраны и отчёты<br/>схема БД, наблюдение за поведением"]
    C --> D["Глава 5. Техническая осуществимость<br/>оценка стека<br/>декомпиляция и правовая проверка"]
    D --> E["Глава 6. Выбор стратегии<br/>продление, обёртка, частичное или полное переписывание"]
    E --> F["Глава 7. Переход к эксплуатации<br/>тестовая среда, журнал изменений, мониторинг, договор"]
    C -.->|"Реестр восстановленной спецификации —<br/>актив при любом выбранном пути"| E

Рис. 1: Общий поток передачи системы и соответствующие главы

Срок каждого этапа сильно зависит от масштаба системы (число экранов, отчётов, пакетных заданий), стека, времени, которое бизнес может выделить на опросы, и от того, какой уровень понимания считается достаточным. Поэтому до начала работ единую оценку дать нельзя. Единственный короткий путь повысить точность оценки — сначала закончить инвентаризацию из главы 3 и посчитать число объектов. Пока нет числа, срок восстановления спецификации оценить нельзя. Иначе говоря, инвентаризацию нужно закрыть быстро: если её растянуть, дальше нельзя спланировать ничего.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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

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

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

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

3. Что сделать в первую неделю — зафиксировать окружение и провести инвентаризацию

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

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

3.2 Резервное копирование — скопировать само окружение как актив

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

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

У Disk2vhd один простой экран, но неверный выбор даёт «образ, который не загружается». Идите в таком порядке.¹

1. Подготовьте место для вывода. VHD/VHDX можно создать и на самом преобразуемом томе, но официальная документация прямо говорит, что лучше писать на другой диск (внешний накопитель, NAS и т. п.) — так быстрее. Свободного места должно быть не меньше суммы занятого пространства выбранных томов.
2. Проверьте BitLocker. Disk2vhd не умеет преобразовывать тома с включённым BitLocker. Если защита включена, сначала снимите её и дождитесь окончания расшифровки, и только потом запускайте инструмент.
3. Выберите тома. Если запустить инструмент на живой системе, он покажет список её томов. По каждому диску, на котором есть выбранные тома, создаётся один VHD; разметка разделов сохраняется, но копируется содержимое только выбранных томов. Чтобы тестовая машина загрузилась, нужны и том с Windows (обычно C:), и системный раздел, без которого загрузка не идёт (раздел «Зарезервировано системой» / системный раздел EFI). Чисто данные можно не брать — сэкономите объём и время.
4. При необходимости запускайте из командной строки. Для ночного прогона можно оформить скрипт вида disk2vhd <диск:> [диск:] ... <выходной файл>. Чтобы взять все тома: disk2vhd * e:\backup\snapshot.vhdx — то есть указать *.
5. Пробную загрузку делайте в Hyper-V. В диспетчере Hyper-V создайте виртуальную машину и добавьте готовый VHD как диск IDE. При первом запуске Windows обнаружит оборудование виртуальной машины и, если драйверы уже есть в образе, поставит их сама. Если нет — поставьте интеграционные компоненты Hyper-V.
6. Не подключайте созданный VHD к исходной машине, чтобы с него загрузиться. Если подключить VHD на той же системе, Windows, чтобы не столкнуться с подписью исходного диска, назначит VHD новую подпись диска. Данные конфигурации загрузки (BCD) ссылаются на диск по подписи, поэтому виртуальная машина в таком состоянии не найдёт загрузочный диск и не стартует. Пробную загрузку всегда делайте на другой машине (хосте Hyper-V).

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

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

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

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

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

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

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

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

Шаблон опроса — кого, о чём и как записывать

«Спросить у пользователей» легко сказать и легко свести к разговору ни о чём, если не зафиксировать, кого и о чём спрашивать. На практике надёжнее развести три слоя и выделить каждому своё время.

Вопросы каждый раз одни и те же. Эти десять пунктов работают и на других системах.

1. Какие операции в этой системе обязательны каждый день? Примерно в котором часу и сколько раз?
2. Есть ли операции только раз в месяц или раз в год (закрытие периода, годовая отчётность, инвентаризация, смена учётного года)? Когда и кто делал это в последний раз?
3. Что служит источником ввода — бумага, файлы, почта? Откуда это приходит?
4. Что система выдаёт (отчёты, CSV, отправка наружу) и куда это затем уходит?
5. Если система встанет, сколько часов бизнес ещё протянет? Можно ли тогда заменить работу руками?
6. Есть ли операции, которые «только не это» — то, что по местному преданию нельзя делать? Понятна ли причина?
7. Что сейчас закрывают руками (перенос данных, пересчёт в Excel, визуальная проверка)?
8. Были ли за последний год ошибки и сбои? Как с ними справлялись?
9. Какие экраны и функции уже не используют? С какого времени?
10. Если бы можно было починить одно, что беспокоит сильнее всего?

Способ записи тоже лучше зафиксировать заранее. Ответы привязывайте к именам экранов, отчётов, таблиц — не «в конце месяца сводим», а «с экрана месячных продаж (F050) печатаем месячный отчёт по продажам». Тогда это стыкуется с таблицей инвентаризации из главы 3 и с последующим разбором базы. Если можно — записывайте звук, а на месте держите в голове только имена и порядок действий. Ответ на вопрос 5 нужен для выбора стратегии в главе 6; ответы на 6 и 7 показывают, где искать скрытые правила.

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

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

Сначала коротко определим термины этой главы.

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

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

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

То, что технически возможно, и то, что можно делать, — разные вещи. Реверс-инжиниринг, включая декомпиляцию, упирается в авторское право. По статье 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 (Program Database) — отладочная информация, символы и Source Link
• Практическое руководство по Process Monitor
• Продление жизни и миграция бизнес-приложений на VB6 / Access — таблица решений: оставить, обернуть, заменить
• Как выйти из зависимости внутренней веб-системы от режима IE
• Как заключать договоры на заказную разработку и сопровождение — договор оказания услуг и подряд по «Модельным сделкам и договорам» IPA
• Что продумать, прежде чем заказывать разработку Windows-приложения

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

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

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

Источники

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

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

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

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

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

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

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

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

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

Не во всех случаях. По статье 30-4 Закона об авторском праве Японии, введённой поправкой 2018 года (Хэйсэй 30), использование, которое не направлено на «восприятие мыслей или чувств, выраженных в произведении», — в том числе исследование и анализ программы, — в принципе допускается в пределах признанной необходимости. Исключение составляют случаи, «которые неправомерно ущемляют интересы правообладателя»; отдельно остаётся вопрос, как оценивать запрет анализа в лицензионном договоре. Перед работой проверьте условия лицензии и договор на разработку, а если есть сомнения — обратитесь к юристу.

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

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

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

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

Об авторе

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

Го Комура

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

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