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

• ️ Для разрешения подобных конфликтов назначается IT-экспертиза, которая представляет собой комплексное исследование технической, организационной и стоимостной составляющих проекта. Эксперт должен не только проверить наличие тех или иных компонентов инфраструктуры, но и оценить их работоспособность, интеграцию в существующую среду, соответствие техническому заданию и проектной документации, а также определить, какой объём трудозатрат и ресурсов действительно был израсходован на выполнение заявленных исполнителем операций. Без такого исследования суд или стороны часто оказываются не в состоянии объективно оценить, была ли выполнена работа в полном объёме, перевыполнена или, напротив, недовыполнена.
• Ключевая сложность IT-экспертизы объёма выполненных работ заключается в том, что значительная часть усилий специалистов (архитекторов, системных администраторов, инженеров баз данных) не имеет материального воплощения в виде железных деталей или метров провода. Это интеллектуальный труд, который оставляет после себя цифровые следы – логи, конфигурационные файлы, отчёты об автоматизированном тестировании, скрипты автоматизации. Задача эксперта – извлечь эти следы, проанализировать их и квалифицированно интерпретировать в контексте договорных обязательств и отраслевых стандартов.
• В настоящей статье мы подробно, шаг за шагом, рассмотрим все аспекты подготовки к IT-экспертизе объёма фактически выполненных работ по серверной инфраструктуре. Начиная от правового поля и заканчивая конкретными действиями на объекте, мы дадим практические инструменты для заказчиков, исполнителей и их представителей. Особое внимание будет уделено методикам, выработанным Союзом «Федерация судебных экспертов», которые стандартизируют процесс сбора доказательств и позволяют получать воспроизводимые результаты, признаваемые судами всех инстанций.
• Поскольку IT-экспертиза сопряжена с большим объёмом технической документации и необходимостью специальных знаний, мы также рассмотрим типичные ошибки сторон при подготовке материалов и предложим алгоритмы, которые помогут избежать затягивания процесса и дополнительных затрат. Начнём с фундамента – нормативно-правовой базы, которая определяет «правила игры» для эксперта и сторон.

Раздел 1. Нормативно-правовая база и процессуальные основания IT-экспертизы объёма работ

• Основанием для проведения IT-экспертизы служат нормы Арбитражного процессуального кодекса и Гражданского процессуального кодекса, согласно которым суд назначает экспертизу, если для установления обстоятельств дела требуются специальные знания в области информационных технологий. При этом под специальными знаниями понимаются не только технические навыки, но и знание методик учёта и оценки трудозатрат в IT-проектах, стандартов управления сервисами (ITIL), методологий гибкой разработки и внедрения (Agile, Scrum) – всё то, что позволяет отличать реально выполненную работу от формально зафиксированной в документах.
• Важнейшим процессуальным документом является определение суда о назначении экспертизы, в котором судья чётко формулирует круг вопросов, подлежащих исследованию, перечень материалов, передаваемых эксперту, и устанавливает сроки. От того, насколько юридически грамотно сформулированы вопросы, зависит направленность всей экспертной работы. Например, вопрос «Определить объём фактически выполненных работ» является слишком общим; гораздо эффективнее задать вопросы по конкретным этапам, оборудованию или функциям информационной системы.
• ⚖️ Помимо процессуальных кодексов, эксперт руководствуется федеральными законами об информации и защите данных, об электронной подписи, а также отраслевыми стандартами, такими как ГОСТ Р ИСО/МЭК 20000-1 (управление сервисами) и ГОСТ Р 59310-2021 (системы управления базами данных). Эти стандарты дают эксперту систему ориентиров для оценки качества выполнения работ и объёма усилий. Союз «Федерация судебных экспертов» разработал на их основе собственные методические рекомендации, адаптированные к судебной практике.
• ‍⚖️ Важно понимать, что IT-экспертиза объёма выполненных работ часто пересекается с бухгалтерской и экономической экспертизой, особенно когда речь идёт о списании затрат, расчёте упущенной выгоды или обоснованности смет. В таких случаях суд может назначить комплексную экспертизу с участием IT-специалиста и экономиста. Однако подготовка материалов для такой комплексной экспертизы требует ещё большей тщательности, так как каждый эксперт использует свой набор исходных данных.

Раздел 2. Классификация объектов серверной инфраструктуры и перечня работ

• Серверная инфраструктура в рамках IT-проекта может включать в себя несколько принципиально разных компонентов, каждый из которых требует отдельных методик проверки. Во-первых, это физическое оборудование (стойки, серверы, дисковые массивы, сетевые коммутаторы, системы бесперебойного питания, кабельная структура). Во-вторых, системное и прикладное программное обеспечение, включая операционные системы, гипервизоры, системы виртуализации, базы данных, промежуточное ПО и специализированные корпоративные приложения. В-третьих, это документация и управленческие артефакты – проектные схемы, топологии, регламенты, планы восстановления, технические паспорта и журналы изменений.
• Перечень работ, выполняемых при создании или модернизации инфраструктуры, также обширен. Это проектирование архитектуры, закупка и поставка оборудования, раскатка (инсталляция и настройка) программного обеспечения, конфигурирование сетей, настройка систем мониторинга и резервного копирования, проведение нагрузочных тестов, обучение персонала, а также миграция данных со старых систем на новые. Для эксперта важно не только проверить наличие каждого из этих этапов, но и оценить их полноту, качество и трудозатраты, что особенно критично при списании рабочего времени по нарядам.
•  Союз «Федерация судебных экспертов» рекомендует при подготовке к экспертизе обязательно прилагать к делу детализированную ведомость объёмов работ (Work Breakdown Structure – WBS) из проектной документации, если она была утверждена сторонами. Именно этот документ служит главным эталоном для сравнения. Если WBS отсутствует, эксперт вынужден реконструировать её на основании договора, спецификаций и переписки сторон, что может внести дополнительную долю субъективности в выводы.
• Кроме того, стороны должны чётко понимать, что работы по установке серверной инфраструктуры могут выполняться как в локальном центре обработки данных (ЦОД) заказчика, так и на площадках облачных провайдеров. Для облачных сред процесс проверки существенно усложняется, так как физический доступ к оборудованию отсутствует, а доказательствами служат консоли управления, журналы событий и биллинговые отчёты провайдера. Эти особенности также должны быть учтены при сборе материалов.

Раздел 3. Проектная и техническая документация как основа для сравнения фактического объёма работ

• Проектная документация в IT-проектах часто представлена в виде технического проекта, архитектурной спецификации (High-Level Design и Low-Level Design), схем связей и топологии сети, перечня конфигурационных параметров. Без этих документов эксперт не сможет определить, что именно должно было быть сделано, и будет вынужден опираться на общие стандарты, что значительно снижает точность выводов. Поэтому одной из первых задач стороны-инициатора экспертизы является сбор всей проектной документации в актуальной версии, которая была согласована с заказчиком до начала работ.
• Исполнительная документация, напротив, фиксирует то, как работы были выполнены фактически. Это акты приёмочного контроля, протоколы тестирования, журналы выполнения работ, акты скрытых (промежуточных) этапов. В IT-сфере такие акты часто составляются в электронном виде с использованием систем управления проектами (Jira, Redmine, Trello) или корпоративных порталов. Все эти записи должны быть экспортированы, заверены электронной подписью или распечатаны и подписаны участниками, чтобы их можно было приобщить к делу.
• Важным элементом являются сметы и калькуляции трудозатрат, которые обычно включают почасовые ставки специалистов, стоимость машино-часов оборудования, расходы на лицензии и накладные расходы. Эксперт проверяет, соответствуют ли заявленные часы реальному времени, которое было необходимо для выполнения перечисленных работ, используя нормативы и отраслевые метрики (например, среднее время настройки сервера, развёртывание кластера баз данных). Отклонения от среднеотраслевых показателей должны быть обоснованы особенностями проекта.
•  Союз «Федерация судебных экспертов» разработал чек-лист документов, которые должны быть предоставлены эксперту: от технического задания и проектной документации до переписки сторон и журналов системных событий. Следование этому чек-листу позволяет исключить ситуацию, когда эксперту передаются документы не в полном объёме или в нечитаемом виде. Особенно важно, чтобы все электронные документы были переданы на машиночитаемых носителях (диски, флеш-накопители) с сохранением метаданных (даты создания, авторы).

Раздел 4. Техническое задание и спецификации как ключевой документ сверки

• Техническое задание (ТЗ) является тем «паспортом», по которому эксперт сверяет фактические объёмы. В ТЗ должны быть чётко прописаны функциональные и нефункциональные требования к инфраструктуре: количество и характеристики серверов, требуемый уровень доступности (SLA), необходимые показатели производительности (IOPS, пропускная способность сети), требования к безопасности, перечень развёртываемых сервисов (Active Directory, DNS, DHCP, файловые серверы, почтовые системы, СУБД). Эксперт проверяет, реализованы ли все эти требования, и если какое-то из них опущено или реализовано не полностью, это фиксируется как недовыполнение объёма.
• Спецификации оборудования и программного обеспечения, являющиеся приложением к ТЗ или к договору, содержат точные наименования, версии, количество единиц, а иногда и серийные номера. Эксперт проводит инвентаризацию физического и виртуального оборудования, сверяя его характеристики с теми, что указаны в спецификациях. Расхождения (замена модели на менее производительную, установка меньшего количества памяти, использование более ранней версии ПО) являются прямым доказательством несоответствия объёма работ.
• Важно обратить внимание на лицензионные условия программного обеспечения. Часто подрядчик заявляет о развёртывании системы, но использует ознакомительные (триальные) версии или не приобретает достаточное количество лицензий на количество пользователей или ядер процессора. Это может значительно снизить стоимость выполненных работ и создавать для заказчика риски проверок со стороны правообладателей. Эксперт проверяет лицензионную чистоту, сверяя установленные ключи с документами о приобретении.
•  Союз «Федерация судебных экспертов» в своих методиках особо подчёркивает, что при отсутствии ТЗ или его неконкретности экспертиза должна проводиться на основании общеотраслевых ожиданий, закреплённых в стандартах и лучших практиках. Однако в таких случаях заключение эксперта приобретает характер экспертного мнения, а не строгого технического отчёта, что суды учитывают при оценке доказательств. Поэтому заинтересованной стороне рекомендуется до начала работ позаботиться о составлении качественного ТЗ.

Раздел 5. Журналы системных событий и логи как объективное свидетельство работ

Одним из самых весомых доказательств фактического объёма выполненных работ являются системные логи, журналы событий операционных систем, гипервизоров, СУБД и сетевого оборудования. В этих журналах фиксируются дата и время изменений конфигурации, установка обновлений, создание виртуальных машин, настройка сетевых интерфейсов, запуск и остановка сервисов, а также пользовательские сессии администраторов. По этим метаданным эксперт может с точностью до минуты восстановить хронологию действий исполнителя.

Однако для того чтобы логи стали допустимым доказательством, их нужно правильно извлечь и сохранить. Следует использовать официальные средства выгрузки журналов (например, Windows Event Collector, syslog, аудитные базы данных) и обеспечить их нотариальное заверение или заверение электронной подписью ответственного лица. Специалисты Союза «Федерация судебных экспертов» рекомендуют выгружать логи в форматах, исключающих возможность редактирования (например, PDF с цифровой подписью или неизменяемые текстовые форматы с хеш-суммами).

Анализ логов – это трудоёмкий процесс, который требует не только технических навыков, но и понимания нормативных сроков выполнения отдельных операций. Например, на установку операционной системы на сервер в среднем уходит 40-60 минут, на настройку кластера высокой доступности – от 4 до 8 часов, на полную миграцию базы данных объёмом 1 ТБ – от 3 до 6 часов. Если в логах зафиксировано, что администратор потратил на установку ОС 15 минут, это может указывать на использование автоматизированных скриптов (что допустимо, но должно быть оговорено в ТЗ) либо на неполноту работ.

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

Раздел 6. Документы системы управления проектами как доказательство объёма работ

В современных IT-проектах широко используются системы управления проектами: Jira, Redmine, YouTrack, Trello, Azure DevOps и другие. Они содержат подробную историю задач (бэклог, спринты, эпики), назначения ответственных, переходы по статусам («в работе», «на проверке», «завершено»), комментарии, затраченное время (time tracking), а также прикреплённые файлы и скриншоты. Весь этот цифровой след является ценнейшим материалом для эксперта, поскольку позволяет связать конкретные единицы работ с конкретными исполнителями и временными затратами.

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

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

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

Раздел 7. Методы технического аудита и инструментальной проверки на объекте

Выезд эксперта на объект (или удалённый доступ к серверной инфраструктуре) представляет собой наиболее ответственный этап экспертного исследования. Эксперт проверяет физическое наличие оборудования, его серийные номера, рабочие индикаторы, состояние кабельной структуры и охлаждения. Для виртуальной и облачной инфраструктуры эксперту предоставляются учётные записи с правами чтения в системах управления (vCenter, AWS Console, Azure Portal), чтобы он мог проверить конфигурации виртуальных машин, объёмы дисковых хранилищ, настроенные сети и балансировщики нагрузки.

Инструментальная проверка включает запуск штатных диагностических утилит (например, sysinfo, dmidecode, lscpu для Linux, systeminfo для Windows, а также специализированного ПО для проверки RAID-массивов, файловых систем и производительности). Эксперт может выполнить стресс-тесты, имитирующие пиковую нагрузку, чтобы проверить заявленную пропускную способность и отказоустойчивость. Если тесты показывают, что система не достигает заявленных характеристик или работает нестабильно, это фиксируется как несоответствие объёма или качества работ.

Все действия эксперта на объекте, все команды, выполненные в консолях, и их выводы должны быть зафиксированы в протоколе осмотра, который подписывается присутствующими сторонами. При удалённом доступе ведётся видеозапись экрана (screen recording) для исключения обвинений в подмене данных. Союз «Федерация судебных экспертов» разработал регламенты удалённого доступа, которые гарантируют, что эксперт работает только с необходимыми разделами инфраструктуры и не вмешивается в критичные бизнес-процессы заказчика.

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

Раздел 8. Формирование доказательной базы: упаковка цифровых артефактов

Цифровые артефакты – логи, конфигурационные файлы, дампы баз данных, скриншоты, видео, – так же как и физические образцы, требуют правильной «упаковки» для обеспечения их целостности и неизменности. Эксперты используют криптографические хеш-суммы (MD5, SHA-256), которые вычисляются для каждого файла или архива. Контрольные суммы включаются в акт приёма-передачи, и любое изменение файла приводит к изменению хеша, что легко обнаруживается при повторной проверке.

Все цифровые материалы должны быть записаны на оптические диски (DVD, Blu-ray) или флеш-накопители, которые не допускают повторной перезаписи (защита от записи), либо переданы через защищённые облачные хранилища с фиксацией времени загрузки. Носители снабжаются этикеткой с номером дела, кратким описанием содержимого и хеш-суммой. Союз «Федерация судебных экспертов» настаивает на том, чтобы создавалось как минимум две копии – одна для эксперта, вторая для суда (или для страховки в случае утери).

При передаче виртуальных машин целиком (например, для исследования в изолированной среде) используется экспорт в форматы OVA/OVF или VMDK, при этом также вычисляются хеш-суммы. Эксперту важно получить не только текущее состояние систем, но и их снапшоты (моментальные снимки) на разные даты, чтобы проследить эволюцию конфигурации. Это позволяет выявить периоды, когда работы фактически не велись, хотя исполнитель отчитывался об их проведении.

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

Раздел 9. Перечень обязательных документов для передачи эксперту

Для успешной IT-экспертизы объёма работ необходимо сформировать исчерпывающий пакет документов, включающий как юридические, так и технические файлы. Список стартует с копии определения суда о назначении экспертизы с чётко сформулированными вопросами. Далее следуют все договоры, приложения к ним, дополнительные соглашения, спецификации, техническое задание, проектная документация (HLD/LLD), акты приёма-передачи отдельных этапов, а также акты осмотра инфраструктуры, составленные до возникновения спора.

Обязательными являются платёжные поручения или иные документы, подтверждающие оплату оборудования, лицензий и услуг, а также сметы и калькуляции. Эксперт сопоставляет заявленные объёмы работ с затратами – иногда грубое расхождение между тем, что оплачено, и тем, что фактически выполнено, становится очевидным именно на этом этапе. К пакету прилагаются переписка сторон по электронной почте, корпоративные чаты (Slack, Teams) и протоколы совещаний, где обсуждались технические детали.

Важнейшим техническим блоком являются выгрузки из систем мониторинга (Zabbix, Prometheus, Nagios), которые показывают историю загрузки процессора, памяти, дисковых операций и сетевого трафика. Эти данные не только подтверждают, что оборудование было введено в эксплуатацию, но и показывают интенсивность его использования, что может свидетельствовать о завершённости миграции или о том, что система работает, но под нагрузкой, не соответствующей проектной.

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

Раздел 10. Организация доступа и взаимодействие сторон на этапе исследования

Доступ к серверной инфраструктуре – это критический элемент экспертизы. Заказчик обязан предоставить эксперту и представителям сторон (по согласованию) физический доступ в серверную комнату или ЦОД, а также сетевой доступ к системам управления, консолям и журналам. Для удалённой работы выдаются отдельные учётные записи с правами «только чтение» или создаются временные VPN-туннели. Все действия эксперта должны быть залогированы, чтобы исключить возможность обвинений во вмешательстве в работу систем.

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

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

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

❌ Раздел 11. Типичные ошибки при подготовке к IT-экспертизе объёма работ

⚠️ Самая грубая ошибка – это предоставление эксперту неактуальной версии документации. Подрядчик часто передаёт черновики ТЗ или старые версии спецификаций, а заказчик не проверяет их соответствие утверждённым редакциям. В результате эксперт вынужден анализировать объём работ по неправильному эталону, что приводит к ошибочным выводам. Перед экспертизой стороны должны совместно сверить, какая именно версия документа была согласована в договоре.

⚠️ Вторая ошибка – неполный вывоз логов и записей систем управления. Часто из-за спешки экспортируются только задачи со статусом «закрыто», но упускаются комментарии, история переходов и журнал времени. Это лишает эксперта возможности оценить, сколько раз задача переоткрывалась, сколько времени фактически было потрачено на исправление ошибок и насколько менялся объём работ в процессе.

⚠️ Третья ошибка – попытка «причесать» данные перед экспертизой, удаляя из логов «лишние» записи или редактируя конфигурационные файлы. Такие действия легко обнаруживаются при анализе хеш-сумм и контрольных точек, и суд, как правило, делает из этого негативные выводы, вплоть до признания всей позиции стороны недобросовестной. Союз «Федерация судебных экспертов» неоднократно сталкивался с такими случаями и всегда фиксирует признаки модификации.

⚠️ Четвёртая ошибка – игнорирование документации по безопасности и соответствию отраслевым стандартам (например, стандарты PCI DSS или 152-ФЗ для персональных данных). Если эти требования были заявлены в ТЗ, но не выполнены, объём работ должен считаться неполным, даже если всё оборудование установлено и включено. Это часто упускают из виду, сосредотачиваясь только на железе.

️ Раздел 12. Роль Союза «Федерация судебных экспертов» в унификации IT-экспертиз

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

 Союз регулярно проводит обучение экспертов по специализированным программам, включающим курсы по современным системам виртуализации (VMware, Hyper-V, KVM), облачным платформам (AWS, Azure, GCP), системам управления базами данных и контейнеризации (Docker, Kubernetes). Это гарантирует, что эксперты владеют актуальными знаниями и могут квалифицированно анализировать даже самые современные архитектуры, включая микросервисные и бессерверные.

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

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

Раздел 13. Особенности подготовки для арбитражного процесса

В арбитражных судах споры по IT-контрактам – обычное дело, поскольку крупные проекты реализации серверной инфраструктуры часто заключаются между крупными юрлицами. Арбитраж отличается повышенной требовательностью к формальным доказательствам: акты выполненных работ должны быть подписаны без замечаний, либо замечания должны быть мотивированы. Поэтому при подготовке к экспертизе следует уделить особое внимание фиксации всех промежуточных сдач, даже если они не были подписаны официально.

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

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

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

Раздел 14. Особенности подготовки для гражданских дел (споры с малыми подрядчиками)

‍ В судах общей юрисдикции IT-экспертизы объёма работ чаще всего связаны со спорами между владельцами бизнеса и небольшими студиями-интеграторами, где бюджет проекта может составлять несколько миллионов рублей. Здесь стороны часто пренебрегают формальной документацией, полагаясь на устные договорённости и электронную переписку. Задача эксперта в таком случае – собрать рассыпанную мозаику доказательств и реконструировать реальный объём.

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

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

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

Раздел 15. Формулирование вопросов эксперту по IT-экспертизе объёма работ

✍️ Правильно поставленные вопросы – это основа успешной экспертизы. Нельзя спрашивать «Какой объём работ выполнен?». Надо разбивать на компоненты: «Соответствует ли фактический перечень установленного серверного оборудования и лицензионного ПО перечню, указанному в спецификации №2 к договору, а если не соответствует, то в чём именно выражено расхождение?». Второй блок вопросов должен касаться времени: «Соответствуют ли фактические трудозатраты (в человеко-часах) на настройку виртуальной инфраструктуры объёму, указанному в смете, с учётом отраслевых нормативов?».

Третий блок – о качестве и полноте выполнения функций: «Обеспечивает ли развёрнутая система заявленный уровень доступности 99.95% и пропускную способность не менее 10 Гбит/с согласно протоколам нагрузочного тестирования?». Четвёртый – о наличии скрытых дефектов: «Имеются ли в системе не устранённые критические ошибки, препятствующие её штатной эксплуатации, и если да, то какой объём работ необходим для их устранения?».

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

Общее количество вопросов не должно превышать 10-12, иначе экспертиза становится излишне дорогой и длительной. При необходимости можно подать отдельное ходатайство о дополнительных вопросах, если в процессе исследования возникнут новые обстоятельства.

Раздел 16. Фото- и видеофиксация при осмотре серверной инфраструктуры

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

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

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

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

Раздел 17. Практические кейсы из деятельности Союза «Федерация судебных экспертов» (с подробным описанием)

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

Кейс 1. Спор о модернизации вычислительного кластера для научно-исследовательского института.

Заказчик (НИИ) заключил с интегратором контракт на модернизацию вычислительного кластера на сумму 48 миллионов рублей. Работы включали поставку 20 серверов нового поколения, настройку высокоскоростной сети InfiniBand, установку системы управления очередями заданий (Slurm) и миграцию расчётных данных с устаревшего оборудования. По окончании срока работ подрядчик предоставил акт о полном выполнении, однако заказчик отказался подписывать его, заявив, что ряд критических функций не работают: производительность кластера оказалась на 40% ниже заявленной, а механизмы автоматического восстановления узлов после сбоев не были настроены. Подрядчик настаивал на том, что все работы выполнены по договору, а снижение производительности вызвано особенностями расчётных задач заказчика.

‍ Для разрешения спора суд назначил комплексную IT-экспертизу с привлечением Союза «Федерация судебных экспертов». Эксперты тщательно подготовились: они запросили у сторон все версии ТЗ, детальные логи настройки Slurm, выгрузки из системы мониторинга нагрузки (Ganglia), а также протоколы приёмочных тестов, которые проводились на стадии ввода в эксплуатацию. В ходе выездного осмотра эксперты провели контрольные нагрузочные испытания, используя эталонные вычислительные задачи, аналогичные тем, что решает НИИ.

Анализ показал, что интегратор действительно поставил оборудование согласно спецификации, но при настройке кластера не учёл архитектуру подсистемы памяти (Non-Uniform Memory Access – NUMA), в результате чего планировщик задач распределял нагрузку неоптимально. Кроме того, эксперты обнаружили, что не были активированы лицензионные ключи на продвинутые функции управления энергопотреблением, что также снижало максимальную частоту процессоров. Трудозатраты на настройку, зафиксированные в логах, составляли только 60% от заявленных в смете, при этом часть операций (например, настройка автоматического резервирования) была выполнена шаблонными скриптами без учёта специфики заказчика.

Эксперты Союза пришли к выводу, что работы выполнены не в полном объёме: отсутствует настройка тонкой оптимизации памяти, не развёрнута система автоматического аварийного переключения, а также не проведено обучение персонала работе с новыми функциями. Стоимость недовыполненных работ была оценена в 12 миллионов рублей. Суд принял это заключение, обязав подрядчика либо выполнить недостающие работы, либо вернуть разницу. Данный кейс иллюстрирует, как важно эксперту не ограничиваться проверкой наличия оборудования, но и исследовать качество его настройки и интеграции.

Кейс 2. Спор о виртуализации и облачной миграции в крупной розничной сети.

Крупная сеть супермаркетов решила перенести свою учётную систему и кассовое программное обеспечение в частное облако на базе VMware, а также развернуть резервный ЦОД для обеспечения непрерывности. Договор с подрядчиком составлял 85 миллионов рублей и включал поставку 15 физических хостов, системы хранения данных (СХД) на 200 ТБ, настройку Site Recovery Manager и миграцию 120 виртуальных машин. По завершении срока работ подрядчик сдал проект, но в течение двух недель после сдачи в основном ЦОД произошёл сбой хранилища, из-за которого были потеряны данные за три дня, так как система репликации не была должным образом настроена. Заказчик обвинил подрядчика в невыполнении работ по настройке отказоустойчивости.

Подготовка к экспертизе в данном случае была особенно сложной, так как часть инфраструктуры находилась в облаке провайдера, и физический доступ к ней отсутствовал. Экспертам Союза предоставили учётные записи vCenter, доступ к системам бэкапа Veeam и журналы сетевых устройств. Также были запрошены скриншоты консолей управления СХД и протоколы миграции. Для проверки настроек репликации эксперты сымитировали аварийное отключение основного ЦОД (в тестовом режиме) и зафиксировали, что резервный ЦОД не активировался автоматически, а время восстановления (RTO) составило более 8 часов вместо заявленных 30 минут.

Кроме того, в ходе анализа логов было установлено, что подрядчик не выполнил полную синхронизацию данных между центрами – было скопировано лишь 60% всех виртуальных дисков, а для остальных была настроена асинхронная репликация с 4-часовой задержкой, что не соответствовало требованиям заказчика о синхронной репликации. Трудозатраты, зафиксированные в системе управления проектами, также не совпадали: на настройку SRM было заявлено 120 часов, а фактически из логов следовало, что администраторы потратили на эту задачу 45 часов, причём часть операций была выполнена по умолчанию без кастомизации.

Заключение экспертов Союза признало объём выполненных работ завышенным на 25% от стоимости контракта, а работы по настройке репликации и аварийного переключения – невыполненными в полном объёме. Суд постановил соразмерное уменьшение цены и обязал подрядчика за свой счёт завершить настройку репликации в двухнедельный срок. Кейс наглядно показывает, как отсутствие документальных подтверждений тестов аварийного переключения и фрагментарность логов могут сыграть против исполнителя.

Кейс 3. Спор о поставке и настройке серверов баз данных для государственного учреждения.

️ Государственное учреждение заключило контракт с системным интегратором на поставку четырёх серверов баз данных (кластер на базе Oracle RAC) и организацию резервного копирования с использованием ленточной библиотеки. Сумма контракта – 22 миллиона рублей. После установки оборудования заказчик начал эксплуатацию, однако через месяц столкнулся с критическими ошибками в работе баз данных – наблюдались частые сбои соединений, а также потеря данных на одной из нод кластера. Заказчик инициировал экспертизу, утверждая, что подрядчик не выполнил работы по настройке кластеризации и не обеспечил синхронизацию данных между узлами.

В ходе подготовки экспертам Союза были предоставлены не только стандартные документы, но и дампы системных логов Oracle (alert.log), журналы CRS (Cluster Ready Services), а также настройки сетевых параметров кластера. Эксперты также получили доступ к ленточной библиотеке и проверили её конфигурацию. Оказалось, что подрядчик действительно установил все четыре сервера и инсталлировал Oracle, но не настроил корректно механизм кластерного взаимодействия – не были оптимизированы параметры тайм-аутов и интерконнекта, что приводило к «расколам мозга» (split-brain) в кластере. Кроме того, в настройках резервного копирования были указаны некорректные пути к устройствам, из-за чего бэкапы записывались в локальную файловую систему, а не на ленточную библиотеку, что делало резервирование бесполезным.

Анализ трудозатрат показал, что специалист, указанный в актах как исполнитель, вообще не имел сертификации по Oracle RAC, а его действия в логах соответствовали базовой инсталляции без последующей тонкой настройки. Эксперты пришли к выводу, что выполнено только 45% от объёма работ, предусмотренных ТЗ, а именно: установка ОС и СУБД, но не настройка кластерной группировки, не настройка резервирования и не проведение нагрузочного тестирования. Суд удовлетворил иск заказчика, признав контракт исполненным не в полном объёме и обязав подрядчика выплатить неустойку.

Кейс 4. Спор о развёртывании системы виртуализации на базе Microsoft Hyper-V с функцией Live Migration.

Среднее предприятие приобрело у интегратора два новых хоста Hyper-V, общее хранилище (SAN) и заказало миграцию 50 виртуальных машин с физических серверов, а также настройку высокодоступной среды с возможностью «живой» миграции виртуалок без остановки служб. Стоимость работ составила 8,2 миллиона рублей. После сдачи работ заказчик начал использовать систему, но при попытке провести Live Migration виртуальные машины зависали на 3-5 минут, что делало эту функцию неприменимой для критичных сервисов. Заказчик обвинил подрядчика в невыполнении настройки, а подрядчик сослался на недостаточную производительность сетевой инфраструктуры заказчика.

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

Кроме того, сравнительный анализ времени, указанного в журнале выполнения работ, показал, что специалист потратил на настройку всего 2 часа, тогда как согласно методике Microsoft на полноценную настройку Live Migration для такого количества машин требуется не менее 12-14 часов с учётом отладки. Эксперты сделали вывод о неполноте работ и завышении трудозатрат в акте. Суд обязал подрядчика в течение 10 рабочих дней выполнить корректную настройку миграции за свой счёт.

Кейс 5. Спор о завершении проекта по построению корпоративной системы хранения данных (СХД) с функцией дедупликации и автоматического тиражирования.

️ Крупный холдинг заказал построение единого хранилища данных на базе решения Dell EMC с общей ёмкостью 500 ТБ, функциями дедупликации, сжатия и автоматического тиражирования данных между двумя географически распределёнными площадками. Контракт стоил 120 миллионов рублей. Подрядчик сдал проект, но через месяц заказчик обнаружил, что система дедупликации работает не на всех томах, а автоматическое тиражирование периодически прерывается с ошибками. Холдинг заявил, что объём выполненных работ не соответствует оплате, и обратился в суд.

Эксперты Союза получили доступ к администрированию СХД, выгрузили все логи системы, конфигурации политик хранения и отчёты о ёмкости. Проведённые исследования показали, что подрядчик активировал дедупликацию только на тестовых томах (менее 5% от общего объёма), тогда как основные тома были настроены без этой функции. Тиражирование было включено, но расписание синхронизации было задано некорректно – приходилось на часы пиковой нагрузки, что вызывало тайм-ауты и прерывания. Кроме того, не было выполнено обучение администраторов холдинга, хотя этот пункт входил в объём работ.

Трудозатраты, зафиксированные интегратором, были проверены по времени работы с консолями – оказалось, что реальное время настройки политик и проверки тиражирования в три раза меньше заявленного. Эксперт пришёл к выводу, что фактический объём выполненных работ составляет примерно 55% от полного объёма, и дал детальную калькуляцию недостающих работ. Суд обязал подрядчика завершить все невыполненные функции и вернуть часть аванса, пропорциональную недовыполнению.

Раздел 18. Резюмирующий алгоритм подготовки к IT-экспертизе объёма выполненных работ

Итак, обобщая весь приведённый материал, представим пошаговый алгоритм, который позволит сторонам максимально эффективно подготовиться к IT-экспертизе объёма фактически выполненных работ по серверной инфраструктуре.

✅ Шаг 1. Тщательное изучение определения суда, фиксация всех вопросов и сроков, анализ наличия всех необходимых документов из перечня, рекомендованного Союзом «Федерация судебных экспертов».

✅ Шаг 2. Сбор и систематизация договорной, проектной и исполнительной документации, выделение актуальных версий ТЗ, спецификаций, смет и дополнительных соглашений, исключение черновиков и устаревших редакций.

✅ Шаг 3. Извлечение и подготовка цифровых артефактов: логи системных событий, журналы управления виртуальными машинами, конфигурационные файлы, дампы баз данных, выгрузки из систем мониторинга и систем управления проектами (Jira, Redmine и др.) с хеш-суммами для обеспечения неизменности.

✅ Шаг 4. Организация доступа эксперта к физической инфраструктуре (серверная, ЦОД) и к системам удалённого управления; подготовка учётных записей с необходимыми правами (только чтение, без возможности внесения изменений).

✅ Шаг 5. Проведение совместного с экспертом и представителями сторон осмотра, выполнение инструментальных проверок, запуск тестов (нагрузочных, отказоустойчивости), фиксация всех этапов на фото и видео с масштабными линейками и табличками с реквизитами дела.

✅ Шаг 6. Оформление протоколов осмотра и актов отбора цифровых данных, подписание их сторонами без возражений (либо с занесением замечаний в отдельный акт разногласий), передача всех материалов эксперту с описью.

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

✅ Шаг 8. Ознакомление с проектом заключения и подготовка обоснованных письменных возражений или уточнений (если таковые имеются), участие в судебном заседании по исследованию экспертизы, подготовка вопросов для допроса эксперта.

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

Итоговое заключение

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

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

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

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте  https://krimexpert.ru