Pull to refresh
111.48
АСКОН
Russia's largest engineering software developer

Обновление корпоративного ПО: вариант для PDM/PLM-систем

Reading time6 min
Views6.6K
Большинство крупных организаций сталкивается с трудностями в выполнении массового обслуживания ПО. Эти трудности носят как объективный, так и субъективный характер. Объективной трудностью является неоднородность ИТ-инфраструктуры, полностью преодолеть которую невозможно. Однако руководители ИТ-отделов и системные администраторы не всегда уделяют должное внимание этой проблеме. Главной субъективной трудностью является отношение к обслуживанию корпоративного ПО как к обслуживанию коробочного и, как следствие, вера в существование «магической зелёной кнопки»: нажал — и всё установилось (обновилось). На практике такой сценарий, увы, нереализуем.



В чём же заключается разница?


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

Обслуживание корпоративного ПО зачастую тоже пытаются проводить по итерационному сценарию, однако «цена» итерации при этом возрастает многократно. Время, затрачиваемое на настройку рабочего места, в случае массового развертывания нужно умножать на количество установок, и безобидные 20 минут уже при 10 компьютерах превращаются как минимум в 3,5 часа рабочего времени, потраченного, фактически, на механические (т. е. хорошо автоматизируемые) операции.



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

Эффективное управление таким процессом при сколько-нибудь значительном количестве рабочих мест без отработанной методики невозможно. Суть этой методики заключается в том, что проблемы необходимо выявлять предварительно, а устранять — централизованно, причём делать это до выполнения обслуживания ПО. Казалось бы, всё просто? Но даже, если такая методика имеется, для её реализации необходим инструмент, не сложнее решаемой задачи.

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

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

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


Структура Комплекса решений АСКОН на платформе ЛОЦМАН:PLM, с ним и работает ЦОК

Чтобы облегчить работу администраторам программного комплекса АСКОН, автоматизирующего управление жизненным циклом изделия, мы разработали решение, которое можно отнести к «среднему классу». Оно не требует программирования, хотя позволяет выполнять доверенные (подписанные) скрипты в случае необходимости дополнительных послеустановочных действий. При этом оно не содержит избыточного функционала, сложного в освоении и обучении. Мы назвали его «Центр обслуживания Комплекса».

«Центр обслуживания Комплекса». Основные отличительные моменты решения


Легковесность с учетом специфики. Продукт не перегружен лишним функционалом, сфокусирован на максимально простом решении основной задачи — массовом обслуживании (установке, обновлении) продуктов АСКОН, таких, как ЛОЦМАН:PLM, САПР ТП ВЕРТИКАЛЬ, справочник Материалы и Сортаменты, справочник Стандартные изделия, КОМПАС-3D и других, с учетом их специфики.

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



Централизованная диагностика. Очевидно, что для успешного обслуживания ПО необходима работоспособная инфраструктура. Проблема в том, что продуктовые администраторы часто не имеют прямого доступа к центральным, жизненно важным объектам ИТ-инфраструктуры (AD DS, DNS, DHCP, групповые политики и пр.). И даже имей они его — просто ли с ходу разобраться в многоуровневой архитектуре, которую, к тому же, ещё и не ты проектировал? Поэтому сбор, хранение и отображение диагностической информации об аппаратной и программной конфигурации рабочих мест и основных настройках ОС критически необходима для обслуживания ПО. Опять же, осуществляется он лишь в том объёме, что необходим для практической работы. Частично решается задача инвентаризации аппаратуры и ПО.



Локализации проблем. Наши наблюдения показывают, что существенная часть сбоев и ошибок (от 30% до 50%), возникающих при эксплуатации корпоративного ПО, вызвана проблемами инфраструктуры. К сожалению, на крупных предприятиях со строго регламентированной организационной структурой (в силу целого ряда причин) имеет место неявное перетекание той доли ответственности за неработоспособность продуктов, которая лежит на общесистемных администраторах, к администраторам продуктов. Мы решаем задачу локализации посредством непрерывного мониторинга инфраструктуры с накоплением полученных данных для последующего анализа.

Интеграция в продуктовый портфель. Как правило, крупные производители корпоративного ПО стараются тем или иным способом решать задачи массового обслуживания своих продуктов. До сих пор таких инструментов у АСКОН не было. Теперь мы делаем шаг на встречу заказчику и закрываем ещё один сегмент автоматизации бизнес-процессов.

В целом мы надеемся, что данное решение будет востребовано в промышленности и, прежде всего, при обслуживании сложных PDM/PLM-систем. Хотя, как уже было сказано выше, номенклатура обслуживаемого ПО ограничена только используемым для развертывания механизмом (Windows Installer). Правда, справедливости ради надо отметить, что вряд ли кому-нибудь придет в голову использовать для корпоративной системы «легкий» инсталлятор типа NSIS.

Ну и в качестве заключения немного конкретных цифр. Испытания системы в «боевых условиях» показали, что с её помощью даже при минимальном уровне начальной подготовки продуктивной среды можно обновлять/устанавливать от 65 до 70 компьютеров в час! Это что-то около минуты на один компьютер при том, что все операции может выполнить один человек. Сравнение с цифрами, приведенными в начале статьи (30 рабочих мест за один рабочий день силами четырех человек), подтверждает прирост производительности труда как минимум на порядок.

Александр Юхименко, руководитель группы разработки Единого инсталлятора Комплекса.
Tags:
Hubs:
+4
Comments9

Articles

Information

Website
ascon.ru
Registered
Founded
Employees
501–1,000 employees
Location
Россия