Опыт создания инфраструктуры крупного внедрения 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.

См. также

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

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

12.11.2024    288    0    TUProgrammer    0    

0

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

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

29.10.2024    399    0    TUProgrammer    0    

1

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

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

21.10.2024    436    0    user2092247    0    

2

Кейсы автоматизации Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.

02.08.2024    3566    0    Novattor    1    

16

Кейсы автоматизации Программист Бизнес-аналитик Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

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

13.07.2024    1792    0    TUProgrammer    6    

5

Кейсы автоматизации Проектирование бизнес-процессов Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Бесплатно (free)

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

11.07.2024    1084    0    Ingraf    4    

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