Олег Пашинин, «Философия.ИТ» — Как в «Росатоме» импортозаместили западную СЭД

Когда встала задача импортозамещения ЕОСДО, было принято решение переписать теперь уже само ядро системы

CNews: Какова история появления импортонезависимого российского ECM-продукта, платформы «Атом.Контент»?

Олег Пашинин: В 2016 году наша команда реализовала для Госкорпорации «Росатом» проект «Оптимизация интерфейсов ЕОСДО». Системы, разработанные на платформе Documentum, традиционно не отличаются дружественным интерфейсом. Бизнес-заказчик нашего проекта — управление документационного обеспечения «Росатома» — поставил цель: повысить уровень удобства и скорость работы интерфейсов системы. В рамках проекта мы изменили не только внешний вид системы, но и архитектуру ее интерфейсных компонентов. Мы использовали свободно распространяемый фреймворк, фактически начав перевод интерфейсной части на импортонезависимое ПО.

Когда два года спустя перед Госкорпорацией встала задача импортозамещения ЕОСДО, бизнес-заказчиком «Росатома» было принято решение переписать теперь уже само ядро системы. Причем так, чтобы функциональность ЕОСДО и интерфейс модифицировать не потребовалось. Это означало, что вместо контент-сервера Documentum нужно было реализовать собственный, поддержав его API и существующую модель данных. Таким образом, после объявления результатов конкурса перед его победителем — компанией «Философия.ИТ» — встала новая задача и большой вызов в рамках проекта.

CNews: Почему пошли по пути создания собственной платформы, а не внедрения уже имеющихся на рынке российских СЭД?

Олег Пашинин: Как ни странно, это вопрос бюджета и сроков. Внедрить готовую российскую систему — первое, что приходит в голову. Но давайте представим объем работ. ЕОСДО создавалась и развивалась в Госкорпорации более 10 лет. К началу проекта в системе было настроено более 100 процессов документооборота, работало 70 тысяч пользователей из 160 предприятий отрасли. Проект по оптимизации интерфейсов сделал работу пользователей удобной. К 2020 году это была большая, функциональная, производительная система, которую использовал каждый сотрудник, работающий с документами. По результатам проведенного обследования рынка, «Росатом» пришел к выводу, что в существующих системах нужно было разрабатывать заново не менее 50% функциональности и потребовалось бы переобучать более 100 тысяч пользователей.

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

К этому нужно добавить, что ни одна российская типовая СЭД до настоящего времени не обеспечивает работу с таким большим количеством пользователей и объемом данных (у нас есть опыт внедрения нескольких российских продуктов). Чтобы обеспечить необходимую производительность при такой интенсивной нагрузке — а к текущему моменту количество пользователей ЕОСДО выросло уже до 110 тысяч — архитектуру любой готовой СЭД, скорее всего, пришлось бы перерабатывать. Что вновь выливается в проект разработки новой системы. В новом подходе мы «всего лишь» переписали бы ядро — саму платформу, при этом бизнес-логика ЕОСДО остается в прежнем виде, без изменения модели и миграции данных. Никакого беспокойства для пользователей системы.

Успешный совместный опыт реализации двух больших проектов придавал уверенности

CNews: Как заказчик воспринял эту идею?

Олег Пашинин: Изначально идея казалась нереализуемой. Это можно сравнить с импортозамещением двигателя большегрузного автомобиля. Двигатель нужно сначала разработать так, чтобы его поддерживали все системы автомобиля, а затем заменить прямо во время движения. Кроме того, в рамках проекта стояла задача перейти с существующей СУБД Oracle на импортонезависимую PostgreSQL. То есть нужно было заранее готовиться к тому, что СУБД будет обеспечивать, по крайней мере, в полтора раза меньшую производительность. Однако, поскольку эта идея возникла и у самого заказчика, рассматривая в течение года варианты импортозамещения, мы пришли к выводу, что данный подход имеет право на жизнь. Наш успешный совместный опыт реализации двух больших проектов по оптимизации и развитию ЕОСДО придавал уверенности, что мы сможем реализовать эту идею.

CNews: Как происходил выбор архитектуры для новой ECM-платформы?

Олег Пашинин: Выбор архитектуры был продиктован несколькими обстоятельствами. С одной стороны, у нас были изначально заданные ограничения — обеспечить преемственность платформы Documentum. Это означало, что нужно было работать с теми же объектами, с той же моделью данных, поддерживать те же функциональные вызовы, которые были реализованы в Documentum. Поскольку разработка ЕОСДО выполняется на Java в монолитной архитектуре, то в результате необходимо было получить библиотеку Java-классов ядра платформы. Иначе написанная на Documentum функциональность ЕОСДО просто не заработала бы. С другой стороны, платформа Documentum была создана более 30 лет назад. Очевидно, что необходимо было реализовать технологии, появившиеся за это время и зарекомендовавшие себя в ИТ-индустрии. Написание платформы не было самоцелью, так как цель проекта — импортозамещение существующей системы. Появилась бы в результате платформа или нет, не имело для проекта принципиального значения.

CNews: Как удалось совместить данные обстоятельства?

Олег Пашинин: Поначалу никак. Среди архитекторов разгорелся спор, в результате которого сформировались два разных подхода к выбору архитектуры и реализации проекта. Первый подход утверждал, что необходимо реализовать ядро платформы с нуля на новой архитектуре с поддержкой REST API, но унаследовав объектную модель Documentum. После того, как ядро будет написано, через слой адаптера подключить бизнес-логику и интерфейсы системы к уже разработанному ядру.

Сторонники второго подхода видели большие риски в том, что после реализации ядра бизнес-функциональность нельзя будет легко переключить на новую архитектуру, а вносить изменения в ядро уже не позволят проектные сроки. Гипотеза второй команды состояла в том, что 80% ЕОСДО использует 20% вызовов Documentum. Поэтому достаточно повторить основные классы ядра, после чего в той же монолитной архитектуре переписать оставшиеся 20% функций ЕОСДО на использование новых методов. От того, какой выбрать путь на старте, зависели три с половиной года последующей реализации проекта.

Нами было принято решение двигаться на этапе проектирования параллельно двумя путями

CNews: Какой путь в результате был выбран?

Олег Пашинин: Нами было принято решение двигаться на этапе проектирования параллельно двумя путями. Одна команда реализовывала подход, в котором пыталась разработать прототип ядра платформы с нуля. Вторая — три месяца занималась исследованием Documentum Foundation Classes (DFC), пытаясь структурировать модель классов и проверить гипотезу «80x20». Команде, проверяющей первый подход, удалось добиться неплохих результатов. В реализованном ими MVP были разработаны основные классы, аналогичные классам Documentum. Разработка велась в ORM-технологии по спецификации JPA. Взаимодействие с данными осуществлялось через фреймворк Hibernate. Был реализован REST API, предоставляющий доступ к бизнес-логике. Интерфейс пользователя был разработан на фреймворке Angular, который взаимодействовал с бэкендом посредством REST-вызовов.

Гипотеза же второй команды не подтвердилась. Вывод был таким: методы Documentum и их вызовы в ЕОСДО — это сложная модель взаимосвязанных классов, которую невозможно декомпозировать таким образом, чтобы выделить в них ключевую функциональность для реализации ядра. Чтобы поддержать работоспособность ЕОСДО, необходимо переписать 80% кода платформы. С учетом того, что у нас на разработку ядра был всего год, это не представлялось возможным. Однако исследование второй команды привели еще к одному выводу. Эта же сложность в модели классов не позволит легко и быстро адаптировать бизнес-функциональность ЕОСДО к ядру, разработанному первой командой.

CNews: Как удалось найти выход из сложившейся ситуации?

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

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

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

CNews: Расскажите подробнее про процесс адаптации. Как происходила проверка того, что функциональность ЕОСДО работает на новом ядре?

Олег Пашинин: В программном коде новой платформы была сделана настройка, позволяющая «переключать» контент-сервер, который необходимо использовать ЕОСДО, — контент-сервер Documentum или «Атом.Контент». Разработчики на стенде адаптации запускали систему на Documentum, потом «переключали» ее на новое ядро и запускали те же процессы и функции работы с документами. Там, где система ломалась, анализировали причины и передавали новые требования команде разработки ядра. Затем выпускался новый релиз, на котором вновь проводилось тестирование работы ЕОСДО.

CNews: Как учитывались требования по информационной безопасности при разработке платформы?

Олег Пашинин: Требования по информационной безопасности составляли существенную часть ограничений, в которых мы создавали систему. Во-первых, мы поддержали модель разграничения прав Documentum, основанную на списках доступа. Во-вторых, реализовали требования ИБ по формированию паролей, аутентификации пользователей. Кроме того, мы разработали в платформе дополнительный блок средств защиты информации, позволяющий настраивать доступ пользователей к операциям в системе посредством правил доступа. Таким образом, в самом ядре платформы появился модуль, поддерживающий технологию разграничения доступа на основе описываемых правил. Через него проходят все обращения к данным и операциям системы. Если срабатывает какое-либо настроенное правило, операция для пользователя становится недоступной. Данная функциональность отсутствует в контент-сервере Documentum и является новым уникальным модулем платформы. Весь комплекс средств защиты информации решения был сертифицирован во ФСТЭК.

CNews: Вы упомянули, что в рамках проекта необходимо было осуществить переход на Postgres. Вы сразу писали платформу на целевой базе данных?

Олег Пашинин: Не совсем. Этапы проекта были спланированы таким образом, чтобы снизить риски при внедрении системы. Предполагалось, что ЕОСДО-2.0 на ядре «Атом.Контент» сначала будет запущена в опытную эксплуатацию под управлением СУБД Oracle. Параллельно стартует процесс перевода платформы и системы на СУБД Postgres, в том числе будут учтены результаты опытной эксплуатации. Поэтому нам с самого начала в «Атом.Контент» необходимо было обеспечить поддержку и Oracle, и Postgres. Мы предусмотрели это в работе двух коллективов адаптации ядра. Команда, разрабатывающая административное приложение для сертификации во ФСТЭК, использовала СУБД Postgres. Команда, адаптирующая ЕОСДО к «Атом.Контент», продолжала использовать СУБД Oracle.

В середине 2022 года изменились обстоятельства поставки оборудования, ужесточились требования по информационной безопасности. Одним из важных нововведений стал запрет на ввод в эксплуатацию любых систем, основанных на программном обеспечении от иностранных разработчиков, в частности, Oracle. Нам пришлось изменить подход. В июле 2022 года мы протестировали работу ЕОСДО-2.0 на «Атом.Контент» и СУБД Oracle, без использования Content Server Documentum. Далее команда продолжила работу над проектом, начав перевод ЕОСДО-2.0 на СУБД Postgres.

CNews: Как вам удалось обеспечить требуемую производительность системы на СУБД Postgres?

Олег Пашинин: У нас было несколько активностей, связанных с оптимизацией производительности системы. Основное решение состояло в том, чтобы перенести подсистему поисковых запросов с сервера базы данных на отдельный сервер. Это существенно снижало нагрузку на базу данных. Кроме того, нашим архитектором платформы «Атом.Контент» был разработан модуль кеширования, снижающий количество обращений к базе данных и дисковой подсистеме. Для достижения требуемой производительности был выделен этап оптимизации, в рамках которого мы регулярно запускали сценарии нагрузочного тестирования, выявляли неоптимальные запросы, корректировали индексы. Нам также пришлось изучить работу механизма оптимизации запросов, реализованного в Postgres. После понимания того, как Postgres оптимизирует запросы, мы изменили логику формирования SQL-запросов платформой. Неожиданный эффект, который мы получили, — «Атом.Контент» показал более высокую производительность, чем Documentum.

За выходные дни мы перенесли систему на платформу «Атом.Контент» и СУБД Postgres

CNews: Как прошел запуск системы в эксплуатацию? Приостановление работы системы, в которой работают 100 тысяч пользователей, должно быть чувствительным для бизнеса.

Олег Пашинин: Если бы мы запускали систему на СУБД Oracle, то простой длился бы всего пару часов. Мы сохранили модель и структуру данных от платформы Documentum, поэтому потребовалось бы лишь выполнение скрипта для обогащения данных. Запуск же сразу с переводом на СУБД Postgres потребовал больше времени на миграцию данных. Но даже в этом случае мы выстроили и заранее отработали процесс таким образом, что он занял всего два дня! Перерывов в работе системы не было совсем. Для перевода ЕОСДО на «Атом.Контент» были выбраны длинные выходные — ноябрьские праздники. Весь переход произошел за три дня. В пятницу вечером пользователи завершили работу в ЕОСДО на Documentum и СУБД Oracle. За выходные дни мы перенесли систему на платформу «Атом.Контент» и СУБД Postgres. Во вторник утром пользователи зашли в ЕОСДО и продолжили работать со своими документами: 7 ноября система была запущена в промышленную эксплуатацию сразу во всей отрасли.

CNews: Как обновленное решение восприняли пользователи, работники Госкорпорации? Каков в настоящий момент статус проекта в «Росатоме»?

Олег Пашинин: Относительно выполненного объема работ можно сказать, что переход состоялся бесшовно. Первый день работы под полной нагрузкой показал, что система справляется, остановок ее работы или возврата на старую платформу и СУБД не требуется. Команда поддержки оперативно обрабатывала возникающие инциденты. Тесное взаимодействие проектной команды и команды «Росатома» позволило быстро диагностировать проблемы инфраструктуры, интеграции, функциональности, настроек и находить их решение. Несмотря на напряжение первых дней запуска, нам было приятно узнать, что пользователи отметили более быструю работу системы. Прошедший 2023 год «Росатом» закрыл в новой системе, что подтвердило ее работоспособность.

CNews: В какой момент вы поняли, что вам удалось получить работоспособную платформу, конкурирующую с лидерами западного рынка, такими как FileNet, OpenText, Documentum?

Олег Пашинин: Несмотря на постоянный прогресс и эффективность решений, которые демонстрировали наши архитекторы и разработчики, до окончания второго этапа проекта не было уверенности, что нам удалось реализовать задуманное. Мы уже понимали, что ЕОСДО-2.0 заработает, так как мы покрыли 80% классов Documentum и нам удалось преодолеть барьеры с информационной безопасностью, сертификацией во ФСТЭК, но все еще не были уверены, что «Атом.Контент» является самостоятельным продуктом, на котором можно реализовывать и другие приложения.

Для проверки мы отдали «Атом.Контент» отдельной команде разработчиков, которые не принимали участия в данном проекте и даже не являлись специалистами Java. Им была выдана документация на «Атом.Контент» и предложено реализовать эталонное приложение — прототип системы согласования и подписания документов. «Атом.Контент» являлся для них черным ящиком, с которым им пришлось взаимодействовать через REST API, опираясь на документированные функции платформы. Ребята успешно справились с задачей. Мы увидели работающее приложение, реализованное на «Атом.Контент» «сторонней» командой разработчиков.

Полученный результат убедил нас в том, что «Атом.Контент» является фреймворком, позволяющим реализовать бизнес-логику системы управления контентом в любых приложениях. Конкурентоспособность решения в сравнении с зарубежными аналогами мы определяли на тестовых стендах и в условиях реальной эксплуатации. Результаты нагрузочного тестирования показали, что решение полностью справляется с нагрузкой данного класса систем. В настоящий момент «Атом.Контент» — единственная ECM-платформа в России, обеспечивающая работу СЭД централизованной архитектуры с более 100 000 пользователей. Таких систем документооборота, реализованных на зарубежных ECM-платформах, сегодня в нашей стране, насколько я знаю, нет.

Крупные компании отходят от идеи разработки отдельных приложений и переходят к платформенному подходу

CNews: Какие существуют планы развития платформы «Атом.Контент»?

Олег Пашинин: Мы понимаем, что за один год написать такой же объем функциональности, который реализован в зарубежных платформах, невозможно. Для полноценной платформы продукту «Атом.Контент» не хватало фреймворка разработки пользовательского интерфейса и модуля автоматизации бизнес-процессов. В августе 2023 года в «Росатоме» стартовал новый проект по разработке и внедрению Централизованного Электронного Архива (ЦЭА). Проект реализуется на платформе «Атом.Контент» и предусматривает ее дальнейшее развитие. На текущей момент ведется разработка фреймворка для UI и интеграция в платформу движка BPM. Реализация электронного архива будет уже с использованием данных компонентов.

В рамках этого проекта платформе нужно будет пройти еще одно серьезное испытание — обеспечить производительность системы до 1 млн объектов в день. Крупные компании сейчас отходят от идеи разработки отдельных приложений и переходят к платформенному подходу, аналогичному Platform V Сбера. По планам заказчика, «Атом.Контент» должна стать сервисом — одним из инфраструктурных компонентов, обеспечивающих функцию хранения контента для любых приложений «Росатома».

Продукт развивается тогда, когда на нем есть проекты. Еще один проект, запущенный в «Росатоме» в сентябре этого года, — «Импортозамещение СЭД международного бизнеса». Этот проект также будет реализован на платформе «Атом.Контент».

CNews: Можно ли говорить, что у платформы есть перспективы продаж — продвижения на российском рынке?

Олег Пашинин: Сейчас на рынке существует потребность замены ECM зарубежных производителей — IBM FileNet, OpenText, Documentum. Некоторые компании пытаются реализовать импортозамещение своими силами. Но на мой взгляд, с точки зрения платформенных ECM альтернатив решению «Атом.Контент» сейчас на рынке нет. Текущая база ЕОСДО на Postgres — около 20 терабайт, объем контента — несколько сотен терабайт. Этим управляет «Атом.Контент». ИТ-директора, которые имеют опыт реализации больших проектов, понимают риски, связанные со значительной нагрузкой и масштабом сложных систем. Поэтому, думаю, интерес к «Атом.Контент» со стороны крупных компаний будет расти. Использование продукта особенно выгодно тем заказчикам, у которых на текущий момент внедрен Documentum, т. к. переход на «Атом.Контент» — это сохранение сделанных ранее инвестиций.

CNews: Как именно возможно тиражировать решение?

Олег Пашинин: Сейчас платформа «Атом.Контент» — это фреймворк для разработки систем документооборота, электронных архивов, систем управления знаниями, любых корпоративных приложений, где необходимо управление контентом предприятия. Силами собственных разработчиков или внешних подрядчиков компании могут создавать для себя подобные системы. «Атом.Контент» может также встраиваться в системы класса ERP, CRM, BPM, BI в качестве средства управления контентом. Вендором платформы является «Росатом», который осуществляет поставку лицензий.

CNews: Насколько легко разработчикам начать использовать «Атом.Контент»?

Олег Пашинин: Разработка на «Атом.Контент» ведется на языке Java во фреймворке Spring Boot. Поэтому для Java-разработчиков использование «Атом.Контент» — это просто подключение еще одного компонента в знакомый им фреймворк. Решение повторяет объектную модель и систему классов платформы Documentum, которая присутствует в России уже около 25 лет. За это время выросло большое количество специалистов, знающих данную платформу. На собственном опыте мы видим, что для разработчиков Documentum переход на «Атом.Контент» происходит быстро и без затруднений. При этом они автоматически переходят от старых технологий к использованию современных. В компании «Гринатом», которая входит в Госкорпорацию «Росатом», создано подразделение развития платформы, подготовлен комплект документации и обучающих материалов. С каждым новым проектом платформа будет обзаводиться новыми полезными функциями и привлекать к себе новых сторонников. Уверен, что «Атом.Контент» встанет в один ряд с лучшими российскими цифровыми решениями и приобретет заслуженную популярность в среде ИТ-профессионалов.

Короткая ссылка на материал: //cnews.ru/link/a20616