Крупные проекты по внедрению решений на платформе 1С:Предприятие:
особенности, этапы, инструменты
Особенности крупных проектов
Выделим здесь только две особенности: масштаб проектов и тотальное импортозамещение. Безусловно, их гораздо больше, но представляется, что по состоянию на март 2024 г. именно эти две влияют на реализацию крупных корпоративных проектов.
Говоря о масштабе, подразумеваем проекты, где в рамках одной системы регистрируются десятки тысяч пользователей. Представление о том, что 1С:Предприятие – это система, где одновременно работает 300-500 пользователей, уже не соответствует действительности. Нами реализованы и достаточно надежно эксплуатируются внедрения на 30 000 и более пользователей.
Тотальное импортозамещение означает, что уже ни один новый проект не стартует на Windows; все они должны запускаться на Linux-решениях и на российской СУБД. Сейчас на рынке около 12 российских СУБД-решений, похожих на Postgres, но со своими особенностями. По размерам речь идёт о базах данных на десятки терабайт. «Тотальность» импортозамещения состоит в том, что для ранее внедрённых решений на платформе 1С, реализованных на стеке Misrosoft, сейчас необходима миграция на Linux- и Postgres-системы, а это можно считать отдельным крупным проектом.
Задачи на разных этапах проекта внедрения
Если разложить процесс внедрения решения на некие стандартные этапы, получим набор задач, которые необходимо выполнять на каждом из них для успешной реализации проекта. Считаем, что об этом нужно говорить, хотя и представляется, что всем всё понятно по умолчанию.
Во-первых, зачастую про многие из этих задач заказчики или забывают, или сознательно опускают в процессе внедрения, а это будет иметь последствия для проекта. Во-вторых, практика крупных внедрений решений на платформе 1С:Предприятие ещё не настолько сформирована, и у многих партнеров нет готового чек-листа, который помог бы и партнеру, и заказчику не упустить задачу. Поэтому предлагая подобие такого чек-листа, мы надеемся, что он поможет и заказчикам, и партнерам.
Первый этап, наиболее сложный на сегодняшний момент – это этап проектирования. Чаще всего встречается задача внедрить систему на платформе 1С:Предприятие, очень похожую на SAP, который до этого внедряли и дорабатывали в течение 25 лет. В начале такого проекта в первую очередь смотрят на решение проблемы функционального покрытия: например, есть 1С:ERP, 1С:Управление холдингом, 1С:Документооборот и так далее, итого 16 решений, которые выбрали и которые покрывают информационный ландшафт. Далее следует понимание, что ни одно из этих решений в исходном виде не подходит, и нужно их кастомизировать, а в итоге при таком подходе приблизиться к требуемому результату можно через год-полтора. Наше мнение – не нужно пытаться сделать SAP из 1С:Предприятие, это путь в никуда. Нужно заново определить целевую техническую архитектуру.
По большому счёту, в первую очередь, это определение показателей назначения. То есть необходимо в терминологии ГОСТ договориться, сколько пользователей будет в системе, какие у нее должны быть показатели производительности, сколько лет она должна хранить информацию и через сколько лет эту информацию удалять.
Казалось бы, очевидные вопросы, но по нашему опыту в технических заданиях на создание систем в 90% случаев об этом ничего не написано. Поэтому при работе с заказчиком (а если вы заказчик – то при работе с подрядчиком) определение показателей назначения должно идти под номером один в списке задач. Далее работаем с архитектурой и сайзингом.
Приведем пример. У заказчика была единая система SAP, в которой работало 4000 пользователей. Стоит задача перейти на решения на платформе 1С:Предприятие, и заказчик рассуждает следующим образом: «Мы посчитали, в 1С:Управление холдингом будет 4000 пользователей, в 1С:ЗУП ещё 4000, в 1С:Промышленная безопасность 4000, и в 1С:МТО также 4000. Итого нужно запустить решение на 16000 пользователей». Уточняем: «Но это ведь одни и те же люди?» – Заказчик: «Да. Но системы-то будут разные, «кусочки» систем у этих пользователей разные». Здесь важно избежать ошибок и грамотно поработать на этапе проектирования, иначе можно собрать многомиллиардный ЦОД, в котором будут обрабатываться данные этих четырежды учтенных пользователей.
Следующий этап – внедрение. Это всегда очень живой и кипучий процесс, когда все что-то делают, что-то деплоят прямо в «Прод» (то есть, переводят исходный код в рабочее состояние на конкретных серверах), т.к. стоит задача удовлетворить требования заказчика здесь и сейчас. На этом этапе главная задача – построить качественную систему управления разработкой. Это означает ввести нормальное управление требованиями, управление конвейерами, ГИТы, тесты, возможно, динамическую инфраструктуру. Такая система позволит, во-первых, снизить риски реализации текущих активностей (того самого деплоя в «Прод»), во-вторых, даст вам правильную платформу, базис, на котором ваша новая система будет существовать всю дальнейшую жизнь.
Далее проект переходит на стадию опытно-промышленной эксплуатации (ОПЭ). Самое страшное, что ждёт на этом этапе – нагрузочный тест. На моей практике, ни одна система, в которой сразу после этапа внедрения делали нагрузочный тест, его не проходила. Проблема заключается в том, что приходится оперативно заниматься оптимизацией, а времени на это, как правило, нет. Сроки всегда поджимают или даже заканчиваются, поэтому на этапе ОПЭ рекомендации следующие. Первое, рассмотреть вынесение нагрузочного тестирования на более ранние этапы проекта. Второе, начинать мониторинг показателей проекта уже на этапе опытно-промышленной эксплуатации. По результатам мониторинга вы обнаружите самые сложные проблемы внедряемого решения, и вовремя примете меры по их устранению. В этом случае 20% усилий дадут вам 80% результата.
Идём дальше: решение в рамках проекта запустили, оно находится в промышленной эксплуатации, и теперь возникает вопрос, как его поддерживать. На этом этапе важно уделять основное внимания в части отказоустойчивости, disaster recovery (аварийное восстановление, инструмент реагирования на критические сбои в IT-инфраструктуре компании, направленный на быстрое восстановление работы всех систем) – то есть процессам, связанным с функционированием решения.
Безусловно, разработка не останавливается, поступают новые релизы от вендора, приходится быстро, буквально за несколько недель, проводить большие циклы тестирования и «поднимать» версии базового решения до версии вендора. Это требует внимательного, вдумчивого подхода к технологическим аспектам. Опыт работы показывает, что на этом этапе поможет предварительная сборка целевой инфраструктуры, ручное и автоматическое тестирование, проведение полного нагрузочного тестирования. Далее возникнут вопросы управления лицензиями, и те самые вопросы импортозамещения, связанные с переездом на Linux- и Postgres-системы. Если заранее подумать об этих вопросах, запланировать их в своем чек-листе, проблем с внедрением крупных систем на платформе 1С:Предприятие будет существенно меньше.
Инструментарий
Бытует мнение, что в среде 1С в целом мало инструментов, и поэтому всегда нужно использовать инструментарий других экосистем. Это мнение ошибочно, и очень хочется привести тот арсенал инструментов, который предлагает среда 1С. Начнем с проектирования.
При проектировании, как это ни удивительно, самое главное – мозги, Visio и Excel☺ Придется рисовать много схем и таблиц, обсуждать с заказчиком (а если вы заказчик – то с подрядчиком) и только после этого переходить к действиям. Непосредственно в процессе проектирования, как функционального, так и технического, поможет СППР (система поддержки проектирования прикладных решений). Также можно использовать решение КИП (корпоративный инструментальный пакет) - это набор из шести конфигураций. Мы, например, применяем в основном Центр контроля качества, Центр управления производительностью, Центр администрирования. На сегодняшний день в 1С:Предприятии появилось много новых инструментов на уровне платформы, такие как 1С:Аналитика, Дата акселератор и пр., и мы убеждены, что они должны быть в наличии и использоваться при реализации крупного проекта. Считаем необходимым наличие нормального интеграционного слоя. Хотя есть распространенное мнение, что решения ESB-класса постепенно отмирают, но это тема для отдельного обсуждения. В наших проектах мы успешно используем для интеграции шину данных 1С:Интеграция КОРП, также есть решение 1С:Шина.
Переходим ко внедрению, и здесь выясняется, что в среде 1С:Предприятие практически нет конвейеризации как таковой, да и вообще управления сборкой на уровне платформы. Зато есть наработанная практика работы с классическим GIT-ом, Jenkins или GitLab – как больше нравится. Есть статические анализаторы кода – это и SonarQube, и поставляемый вендором инструмент автоматической проверки конфигураций (АПК).
Мы чаще всего используем оба, так как при этом обеспечивается наиболее полное соответствие стандартам разработки и отсутствие ошибок. Также на этапе внедрения активно используются мессенджеры, для самых разных задач вроде ведения логов, коммуникации по конкретным трекам управления проектом, выпуска релизов и т.д. Мониторинг, как упоминали выше, можно смело запускать уже на этапе внедрения. Чем раньше начнёте мониторить проект, тем больше ошибок сможете обнаружить и устранить своевременно, без ущерба для промышленной эксплуатации. В помощь разработчикам вашего проекта – инструменты автообновления/ автообслуживания баз данных и создание «эталонных» баз для новых участников. В лучших практиках мы встречали автоматизированные портальные запросы на выдачу таких баз. Это значит, что когда на проект приходит новый программист, создается заявка, в ответ автоматически формируется отдельная виртуальная машина, на которой уже есть преднастроенная среда разработки, автоматически создается база, она подключается к хранилищу – и уже через полчаса новый программист может приступить к работе.
На этапе ОПЭ важно проведение повторяемого нагрузочного тестирования для анализа качества продукта, полученного на предыдущих этапах. Здесь уже совершенно необходимо настроить адекватный мониторинг с анализом логов среды (если не было сделано на этапе внедрения). Мониторим систему на производительность, ищем ошибки, проводим анализ логов, представляем результат мониторинга в визуализированном виде. Проверяем механизмы отказоустойчивости и катастрофоустойчивости. Повышаем производительность решения по результатам тестов и мониторинга. На этапе ОПЭ особо хочется выделить обратную связь. Нужно очень настойчиво делиться этой обратной связью с программистами, написавшими код, который в рамках опытной эксплуатации был выделен красным цветом и требует рефакторинга.
Когда выходим на этап промышленной эксплуатации, основная задача – чтобы при выпуске новых релизов и обновлений не ухудшалась производительность и не страдала стабильность решения. Для этого проводим постоянный мониторинг (да, снова он) загрузки оборудования и логов технологического журнала, своевременно реагируем на инциденты, заранее готовимся к обновлениям на релизы вендора, налаживаем работу с автоматическим тестированием.
Особенностью этапа промышленной эксплуатации является то, что остальные треки/стримы, которые были в решении, не останавливаются– вы всё время развиваете, дорабатываете, выпускаете, тиражируете. В этом состоянии система будет пребывать постоянно. И на этом этапе помогут уже упомянутые на предыдущих этапах инструменты, плюс service desk, такие как JIRA, 1С:ITIL.
В заключение хочется сказать, что те сложности и недоработки, которые приходится устранять на этапах ОПЭ и промышленной эксплуатации, в основном порождены программистами на этапе внедрения. Это происходит, когда команды, приходящие внедрять проекты на крупной корпоративном рынке, обладают недостаточно прокачанными навыками программирования, как ни банально это звучит, а также, когда, идя на поводу у заказчика реализуют то, что реализовывать было нельзя.
Поэтому простые советы коллегам: постоянно повышайте квалификацию своей команды, давайте честную и прямую обратную связь, аргументируйте заказчику свою позицию и отстаивайте ее. Залог успеха на этапе реализации - в грамотном планировании и проектировании, уделении внимания технической архитектуре на самом раннем этапе проекта.
Будем рады, если статья окажется полезна нашим коллегам, партнерам и заказчикам.
Хотите получить наш чек-лист? Пишите на rvv@it-expertise.ru