РЕШЕНИЕ

Консолидированная система автоматизации ИТ-процессов

Введениe

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

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

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

Проблема

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

Давайте рассмотрим эти минусы подробнее:

• Отсутствие документации, или частичная/разрозненная документация.
• Сценарии создаются под решение конкретной проблемы и сразу же запускаются в эксплуатацию. Так как проблема решена – о документации забывается. Причиной этого может быть и представление, что сценарий нужен лишь на 1-2 раза, но, как показывает практика, нет ничего более постоянного, чем временное. Часто сценарии, написанные на 1 раз, работают годами.
• Компетенцией по сценарию обладает лишь его автор. Впрочем, даже автор сценария, написанного 5 лет назад, может столкнуться с большими проблемами при попытках в нём разобраться или изменить его.
• Из-за отсутствия стандартов документирования, организация может сталкиваться с существенными проблемами при уходе администратора в отпуск, его увольнении или повышении. Процесс передачи опыта осложнён (часто администратор не может даже вспомнить все использующиеся сценарии, написанные и внедрённые им самим).
• Расположение сценариев. Сценарий, от ежедневной исправной работы которого зависит крайне важный бизнес-процесс организации, может постоянно выполняться с персонального ноутбука администратора. А потом ноутбук ломается, или администратор уезжает в отпуск, забрав его с собой и забыв про сценарий (про который кроме него, может, никто даже и не знает).
• Стандартизация разработки сценариев.
• При отсутствии единого стандарта написания сценариев, в них может наступить хаос. Так, для Windows систем, рядом со сценариям на Windows PowerShell могут соседствовать сценарии на VB Script, CMD, Python или даже на sh, запускаемом через cygwin. Каждый стремится разрабатывать на том, что ему больше нравится, и в такой свободе по началу не видно проблем, до тех пор пока в сценарии не потребуется разобраться или сделать изменения человеку, который не имеет никакого понятия об этом языке.
• Даже при разработке сценариев на одном языке присутствуют такие проблемы, как стиль написания сценариев. Это далеко не только эстетический фактор, но и такие моменты, как, например, обработка ошибок или журналирование. Воистину ужасен и сложен для понимания код сценариев, которые были созданы одним человеком, а затем подправлены другими.
• Совместная разработка или даже поддержка осложнена. Очень сложно уверенно определить, кто внёс в сценарий изменение, приводящее к уничтожению важных данных каждое четвёртое полнолуние.
• Сценарии могут зависеть как от установленных локально на сервере дополнительных компонентов (разумеется, не документированных), так и от индивидуальных настроек авторов, например псевдонимов. Это опять же осложняет их эксплуатацию.
• Журналирование. Мало в какие сценарии при разработке закладывается функциональная возможность ведения журналов выполнения и ошибок. Обычно автор предполагает, что «будут проблемы – добавлю», однако такой подход не поможет в случаях, когда требуется получить историческую информацию о выполнении сценария, или при разборе причин разового, невоспроизводимого сбоя.
• Аудит. В общем случае невозможно отследить, кто и какие изменения произвёл в сценарии. Даже при включённом аудите изменения файлов невозможно отличить исправление одного параметра от добавления новой функциональности или тотальной переработки сценария.
• И последняя, но весьма важная проблема разработки сценариев – учет ее целесообразности. Хотя, по большей части, сценарии автоматизации действительно позволяют сэкономить время, иногда трата времени на их написание может быть неокупаемой в принципе.

Решение

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

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

• Процесс принятия решения о необходимости разработки сценария для автоматизации операции.
• Предпочтительные языки сценариев и методы интеграции с системами.
• Допустимость использования сторонних дополнительных компонентов.
• Подходы к размещению и запуску сценариев.
• Стили и рекомендации для организации кода.
• Организация совместной работы.
• Журналирование процесса работы.

Второй – это система для автоматизации и координации автоматизированных процессов, "оркестратор", такой как Microsoft System Center Orchestrator или VMware vCenter Orchestrator. Orchestrator обладает возможностью разработки сложных сценариев автоматизации в графическом интерфейсе, называемом «процедурами» runbook). Графическое представление существенно облегчает чтение и понимание логики процедур для администраторов, независимо от предпочитаемого ими языка программирования. Кроме того, Orchestrator позволяет выполнять и обычные сценарии на любых языках, в том числе и удалённо, на системах или *nix, что позволит сохранить уже имеющиеся активы и процессы без необходимости их тотальной переработки.

Orchestrator также позволяет получить следующие преимущества:

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

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

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

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