Опыт создания инфраструктуры крупного внедрения 1C:ERP УХ на импортозамещенной платформе

08.09.23

Архитектура - Кейсы автоматизации

Актуальный состав экосистемы крупного внедрения 1C:ERP УХ выходит далеко за рамки прода, препрода, разработки и нагрузочного тестирования. Особенно явно это проявляется при переходе на импортозамещенную платформу. В статье расскажем о том, как обеспечить инфраструктуру для крупного внедрения 1С на базе Linux и PostgreSQL, и что при этом нужно учитывать.

 

Меня зовут Евгений Филиппов, я работаю экспертом в компании IBS. Расскажу про свой опыт создания инфраструктуры на импортозамещенной платформе, который сформировался в ходе нескольких крупных проектов. Считаю важным донести до людей те вещи, которые мы там увидели.

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

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

Если бы мы говорили про внедрение на 50 или 70 пользователей, там, наверное, можно было бы обойтись какими-нибудь серверами или рабочими станциями, которые есть в загашнике.

Но когда мы говорим про внедрение большого масштаба, нужно учитывать не только экономические факторы (ядра, память, скорость и размер дисков и т.д.) Нужно учитывать еще экологические и социальные факторы.

Если возникает дисбаланс, система начинает перекашиваться в одну из сторон, и устойчивого развития не возникает. Получается, что «хвост вытащили – нос увяз, а нос вытащили – хвост увяз».

Меня часто просят посчитать оборудование для продуктивного контура внедрения. Но в экосистеме всей компании продуктив – это только фиолетовая часть (см. рис. выше). Почему-то считается, что остальное можно где-то раздобыть по остаточному принципу: либо взять «на сдачу», либо найти какой-то сервер на складе.

Но на крупном внедрении таких возможностей практически нет.

А если мы переходим на импортозамещенную платформу, то таких возможностей может не быть в принципе. Потому что если у вас есть сервера под Windows и MS SQL Server, то совершенно не факт, что у вас есть все нужное для того, чтобы поднять всю инфраструктуру на Linux и PostgreSQL.

Вкратце по слайду. Здесь я поделил всю инфраструктуру на три зоны.

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

  • Вторая зона – зона переходных данных, она на разных этапах проекта может относиться то к конфиденциальным, то к не конфиденциальным данным. Например, сегмент нагрузочного тестирования. Пока у нас нет базы с мигрировавшими данными, у нас там какие-то тестовые данные, которые мы сгенерировали с помощью обработок. Туда можно пускать всю команду разработки. Но после того, как в этом сегменте появляются копии продуктивных баз для нагрузочных тестов, мы его уже начинаем относить к проду. Именно поэтому он называется зоной переходных данных. Аналогично с сегментом обучения, который сразу выстраивается из того, на каких НСИ мы пользователей учим. Если пользователи заводят собственные НСИ: «Организация1», «Организация2», организация «Ромашка», понятно, что это ничего секретного. Если у нас все-таки там есть продуктивные НСИ, то мы этот сегмент относим к проду.

  • И, наконец, третья зона – зона DEV – это зона прочих данных, где может работать вся команда разработки, внешние подрядчики, специалисты субподрядчиков. Туда можно пускать всех, кто вообще работает на проекте. Здесь никаких конфиденциальных данных в принципе быть не должно, только какие-то тестовые.

Все это на крупном проекте нужно каким-то образом создать, поднять, настроить, а также нужно посчитать и выделить на это бюджет.

  • Если мы рассчитываем только продуктив, то хорошо, когда у нас в поддержке, консультировании и разработке работают 5 человек – мы их где-то на чем-то можем посадить работать.

  • Но когда в поддержке, консультировании и разработке начинают работать сотни человек, мы их «где-то на чем-то» посадить работать уже не сможем.

  • А если нам надо одновременно обучить порядка 1800 пользователей за три недели, то понятно, что на ноутбуке это не сделаешь. И люди, которые готовят эту работу, они тоже просто так откуда-то не возьмутся. Подготовка трех недель обучения может составить примерно 9 месяцев работы команды обучения.

Здесь начинают соединяться и экономические факторы, и социальные.

 

Обзор сегментов экосистемы и основные драйверы требований к оборудованию в каждом из них

Но еще немного про экономику.

Когда мы говорим про крупные внедрения, начинают проявляться драйверы роста мощностей, которые не проявляются в условиях, когда мы работаем не с ERP УХ.

  • Например, если у нас используется ERP УХ, и у нас в продуктиве в одном кластере несколько баз, то количество баз в кластере начинает являться драйвером роста ресурсов.

  • Дальше посчитайте, сколько места нужно на бэкап и на зону саппорта. Допустим, у вас суммарный размер основных баз занимает 2 терабайта. Чтобы консультанты могли нормально работать и могли делать какие-то эксперименты для пользователей, вам нужно от 3 до 7 копий каждой базы. 2 умножить на 7 – это уже 14 терабайт. Это еще один драйвер роста ресурсов.

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

 

Реальные сроки формирования команды с навыками Linux и PostgreSQL у заказчиков, ключевые моменты ее обучения и вовлечения

Теперь перейдем к социальным факторам.

То, что нужно обучать сотрудников (пользователей) заказчика – это понятно. Но сначала задумайтесь о том, кто все это хозяйство будет поддерживать. Если ранее ваша информационная система размещалась на какой-то другой платформе, то, как правило, у вас не выстроены связи между специалистами по Линуксу, 1С-никами и специалистами по PostgreSQL.

Я не говорю о том, что какой-нибудь разработчик не может поднять PostgreSQL у себя на ноутбуке. Конечно, может. Большинство это умеет делать. Но человек, который умеет профессионально сопровождать 1С, Linux и PostgreSQL, именно сопровождать, отвечать на вопросы, консультировать – это уже уровень 1С:Эксперта по ТВКВ с соответствующим ценником и дефицитом на рынке.

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

Да и со стороны партнера тоже нужно понимать, что нам нужны админы, которые будут сопровождать часть этой системы длительное время, на весь период ее разработки и внедрения.

За что я сразу агитирую:

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

Тогда:

  • во-первых, они все шишки набьют на этапе внедрения;

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

Опять же, здесь вопрос не в том, что кто-то что-то не умеет делать. Свою часть работы умеет делать каждый. Но связки могут выстраиваться неэффективно.

Чтобы связки заработали нормально, требуется время. И нужно внедрять новые регламенты для запуска определенных изменений в командах, которые привыкли администрировать Linux или PostgreSQL по старым регламентам для других систем.

 

Неожиданные, но показательные сложности с логистикой при использовании Z-платформы 1С, их решение

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

Например, есть неожиданные, но показательные сложности с логистикой при использовании Z-версии платформы.

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

Это не особенности программного продукта, это особенности перехода с одной системы, имеющей формуляр, на другую систему, имеющую формуляр. Чистая бюрократия.

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

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

Если у вас платформа Z, вам нельзя разводить зоопарк релизов внутри экосистемы, потому что это может вызвать и реальные сложности:

  • На сервере Linux не может быть штатным способом установлено несколько платформ. Умельцы ставят, но это внештатная возможность.

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

  • В случае с платформой Z нельзя просто так взять и поднять релиз платформы – вы можете перейти только на следующий релиз Z.

  • А еще вам нужно обучить админов быстро обновлять релизы у пользователей и избегать большого количества ручной работы. Если обновлять через автоматическую раздачу нового релиза тонкого клиента, то в случае, когда много пользователей утром в понедельник откроют 1С, это приведет к тому, что у вас все каналы связи лягут.

Все это влияет на экологию системы в целом.

 

Точки опоры при сайзинге оборудования

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

  • Мы подключили к системе саппорт – оборудование подросло.

  • У нас увеличился расход оперативной памяти на продуктивных серверах из-за размещения нескольких баз ERP УХ в кластере – у нас оборудование подросло.

  • Мы включили сегмент обучения на 1000 пользователей – оборудование подросло.

  • У нас стало 100 разработчиков вместо 5 – оборудование подросло.

Когда этот бег в песчаную горку вообще закончится? На что можно опереться?

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

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

  • Более того, эту работу нужно будет потом передать заказчику, чтобы они могли это делать в проде. А нормально заказчик сможет ее делать после появления в штате эксперта по технологическим вопросам крупных внедрений. Потому что эффективное взаимодействие с ЦКТП 1С возможно только при наличии 1С:Эксперта в команде – оно идет только через 1С:Эксперта.

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

 

Система регулярных бэкапов и призыв к компании Postgres Professional

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

  • Потому что dt-шниками здесь не обойдешься.

  • Если баз много, ручками даже через средства СУБД не накопируешь.

  • А штатный способ архивирования резервного копирования в PostgreSQL, который указан на ИТС, подразумевает необходимость архивирования кластера целиком. И если у нас в кластере несколько баз, тратится очень много времени на восстановление этого большого кластера на отдельный сервер, а потом на перекачку всего этого хозяйства по сети на другой сервер. И хорошо если при этом админы не ошибутся и не забудут заблокировать базу, которая восстанавливается. то есть, эта операция – очень затратна и по ресурсам, и по времени и по человеческому фактору.

Здесь вот у меня большое желание обратиться с призывом к компании Postgres Professional.

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

Пожалуйста, сделайте Postgres Pro более admin friendly!

Потому что это тоже социалка – универсального админа, который будет владельцем этой системы, в такой системе не будет.

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

 

Импортозамещение – это не только про продуктив

 

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

Чтобы создать новую экосистему крупного внедрения 1С, все это нужно учитывать.

Многие из этих вещей придется делать с нуля. Удачи вам в этом нелегком деле.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

См. также

Кейсы автоматизации Платформа 1C v8.2 1С:Консолидация Россия Управленческий учет Бесплатно (free)

На примере масштабного внедрения 1С:Консолидация статья описывает этапы подготовки МСФО-отчётности: от методологии и архитектуры импорта до сверки ВГО, бизнес-процессов и раскрытия для Лондонской биржи. Материал основан только на реальном опыте и полностью применим на практике.

вчера в 15:30    65    0    user2147486    0    

0

Взгляд со стороны Заказчика Внедрение изменений Кейсы автоматизации Бесплатно (free)

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

21.02.2025    1214    0    KrisSh    0    

7

Интеграции Кейсы автоматизации Инструменты управления проектом Бесплатно (free)

Задачи производственного планирования решить на 1С сложно – не хватает средств гибкой визуализации, недостаточно производительности для анализа и расчетов в реальном времени, недоступны многопоточные вычисления в режиме in-memory. Расскажем о том, как интегрировать APS-систему с 1С:ERP УХ, спрятав ее за фасадом привычного 1С-интерфейса.

20.02.2025    923    0    user1934826    1    

2

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Управленческий учет Бесплатно (free)

Документ «Производство без заказа» позволяет управлять производством в 1С:ERP без формирования этапов и заказов. Расскажем о том, почему этот документ незаменим в непрерывном производстве, и как с его помощью настроить учет производственных процессов через SCADA и «книжный учет» выпуска от отгрузки.

18.02.2025    1449    0    Программе    0    

5

Кейсы автоматизации Платформа 1С v8.3 1C:Бухгалтерия Россия Бесплатно (free)

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

12.11.2024    995    0    TUProgrammer    0    

0

Кейсы автоматизации Платформа 1С v8.3 1C:Бухгалтерия Россия Бесплатно (free)

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

29.10.2024    745    0    TUProgrammer    0    

1

Кейсы автоматизации Бизнес-аналитик Платформа 1С v8.3 1C:Бухгалтерия Россия Управленческий учет Бесплатно (free)

Сфера деятельности заказчика: Капитальный ремонт нефтегазовых скважин. Численность сотрудников компании: 4 300 сотрудников. Срок автоматизации системы управления: 6 месяцев. Внедренное решение: Бюджетир.

21.10.2024    711    0    user2092247    0    

3
Оставьте свое сообщение