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

Не нужно далеко ходить за ответом: тщательная оценка косвенных убытков, обусловленных простоями, показывает, что перебои выливаются в кругленькую сумму недополученного дохода. Согласно статистическим данным, представленным одной из исследовательских фирм из Новой Англии, остановка трети крупных бизнес-приложений кассовых терминалов всего лишь на 1 ч приводит к убыткам в виде недополученного дохода в размере 1—2 млн долл. Если этого недостаточно, вот еще факт: та же фирма обнаружила, что часовая остановка 14% крупных корпоративных CRM-приложений приведет к недополученному доходу в размере 1—2 млн долл.

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

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

Правильный подход

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

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

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

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

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

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

Определение уровней сервиса

Определение уровней сервиса стратегических бизнес-приложений — в любом случае удачная идея, безотносительно к управлению и мониторингу. Представители всех подразделений компании должны определить для своих стратегических бизнес-приложений соответствующие уровни сервиса. Например, обязательна ли постоянная доступность приложений PeopleSoft (24 ч в день 7 дней в неделю)? Каков график перерывов на обслуживание сервера, поддерживающего приложение J.D. Edwards? Подобные вопросы позволяют выяснить, какие уровни сервиса необходимы.

Уровни сервиса известны очень давно, но во многих компаниях не спешат их определять и соблюдать, потому что на это требуется время и ресурсы. Тем не менее эти уровни критически важны как для внутренних, так и для внешних систем. Без них уровни доступности конкретных систем, которые предоставляют либо ожидают бизнес-пользователи, сотрудники отдела сопровождения ИТ-систем и персонал других подразделений, будут различаться. Кроме того, уровни сервиса позволяют подразделениям рассматривать друг друга как поставщиков услуг, а так как стратегические бизнес-системы все чаще работают в режиме поставщика прикладных сервисов (application service provider, ASP), то уровни сервиса станут неоценимым инструментом управления предприятием.

Рассуждая таким образом, мы приходим к Web-сервисам, которые по природе своей диктуют четко определенные уровни сервиса, так как от этого зависит производительность их работы. Судите сами: Web-службы позволяют перенести приложение в Web и обеспечить поддержку B2B-связей, партнеров и отношений с другими пользователями, находящимися за пределами компании; но при этом образуются дополнительные уровни, и нужно прикладывать дополнительные усилия по поддержке транспортных технологий, например, популярного протокола SOAP. Если не соблюдать осторожность, подобные дополнения могут отрицательно сказаться на производительности. Как же решать эту проблему? Уровни сервиса, уровни сервиса и еще раз уровни сервиса.

Вы можете определить этот уровень в договоре о гарантированном уровне сервиса (SLA) или в аналогичном соглашении (service-level objective, SLO). SLA-договоры обычно заключаются с внешними, а SLO — с внутренними поставщиками услуг. Разница между ними в том, что SLA — это подписанный договор между бизнес-пользователем и внутренним или внешним поставщиком сервиса, а SLO не заключается на бумаге, но поставщик соглашается обеспечивать определенный уровень сервиса. SLA дают ИТ-организации определенную гарантию. Как правило, клиент и поставщик оговаривают в таком контракте взаимовыгодный уровень сервиса, а за «недопоставку» сервиса следуют определенные финансовые санкции.

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

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

Техническая задача

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

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

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

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

  • пересмотр каркаса — следует убедиться, что план предусматривает мониторинг всех компонентов стратегических бизнес-приложений;
  • оценка ПО средствами таких условно-бесплатных средств, как Multi Router Traffic Grapher;
  • составление описи всех имеющихся инструментальных средств, чтобы определить подходящие для каркаса (такие, как HP OpenView, Unicenter компании Computer Associates или IBM Tivoli);
  • определение протоколов связи с центральным хранилищем данных;
  • закупка нужного ПО — она выполняется после принятия окончательного решения.

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

Инвентаризация приложений

Если при чтении этой статьи вы все чаще задумываетесь о «быстрых» решениях «на скорую руку», которые позволят хоть как-то следить за здоровьем ваших стратегических бизнес-приложений — без построения каркаса, организации собраний и разработки SLA-контрактов, — считайте, что вам повезло. Можно усовершенствовать мониторинг таких приложений без развертывания инструментальных средств и корпоративного каркаса.

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

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

Отдыхайте

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

Рон Бек (Ron Beck) — директор по проектированию и разработке в компании Tallan (Хартфорд, штат Коннектикут), которая занимается поставками технологических решений в области разработки ПО, создания инфраструктуры и креативного дизайна. С ним можно связаться по e-mail: rbeck@tallan.com.