Дон Джонс. «Создание унифицированной системы IT-мониторинга в вашем окружении».Глава 6.Унифицированное управление на примерах

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

Содержание

Глава 1. Управление вашим IT окружением: четыре вещи, которые вы делаете неправильно
Глава 2. Устранение практики управления по отдельным участкам в IT-менеджменте
Глава 3. Соединяем всё в единый цикл управления ИТ
Глава 4. Мониторинг: взгляд за пределы ЦОД
Глава 5: Превращаем проблемы в решения
Глава 6: Унифицированное управление на примерах

Глава 6. Унифицированное управление на примерах

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

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

Практические задачи

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

Обнаружение и решение проблем

Лиза – старший системный администратор, отвечающая в своем окружении, в основном, за системы на основе Windows. Её коллега – Питер, отвечает за инфраструктуру Unix- и Linux-серверов. У них обоих есть существенные пересекающиеся области, потому что большинство бизнес-приложения компании зависят от успешной работы Windows- и *nix- ресурсов. «Конечно, это не только серверы», — говорила мне Лиза,-«Это также всё то, что работает на этих серверах: базы данных, веб-сервисы, впрочем вы сами знаете. Есть ещё люди, поддерживающие эти самые разные части, так что мы иногда тратили достаточно много времени, споря о том, чья и где была личная ошибка».

Я спросил ее по поводу примера, как все у них работало до реализации унифицированной системы управления. Она рассмеялась и показала мне файл, где она в своё время делала записи. Он выглядел как сборник заметок из тикетов, собранных на хелп-деске. Я приведу содержание здесь же, изменив имена. Я добавил несколько [редакторских] добавлений там, где мне приходилось обращаться к Лизе за дополнительными пояснениями.

ОТКРЫТО Хелп-деском в 2009‐06‐14 13:34
Пользователь настаивает, что BOS [бизнес-приложение] работает крайне медленно.
В о[череди] уже есть несколько почтовых сообщений на эту же тему. Сервер BOSDB02 медленно отвечает на пинги.

НАЗНАЧЕНО ЛХейрт [это Лиза]

ЗАМЕТКИ ЛХейрт 2009‐06‐14 15:26
BOSDB02 работает отлично, за исключением того, что SQL сжирает 100% CPU. Передано администратору СУБД.

НАЗНАЧЕНО ДШилдс [это администратор СУБД]

ЗАМЕТКИ ДШилдс 2009‐06‐14 16:53
Возможно опять индексы, SQL требуется больше времени для выполнения запросов, чем нужно. Запланируем перестроение индексов на вечер.

ЗАМЕТКИ ХелпДеск 2009‐06‐15 10:44
По прежнему получаем звонки по этому поводу

ЗАМЕТКИ ДШилдс 2009‐06‐15 11:12
Индексы перестроены

НАЗНАЧЕНО ХелпДеск 2009‐06‐15 11:34
Всё еще получаем звонки по поводу BOSDB02 – медленный пинг.

НАЗНАЧЕНО ДШилдс 2009‐06‐15 13:12
SQL всё еще работает медленно – похоже на проблемы с дисковым вводом/выводом. Фрагментация диска? Нужна серверная поддержка.

НАЗНАЧЕНО ЛХейрт

ЗАМЕТКИ ЛХейрт 2009‐06‐15 13:47
Фраментация серверного диска менее чем 2% — проблема не здесь. IO работает медленно потому что SQL очень часто дергает диски. Возможно, БД фрагментированы. Я перезвоню.

ПЕРЕДАНО ДШилдс

В этой точке диалог перешел в оффлайн, потому что в следующей записи указано «проблема решена». К несчастью, нет никакой официальной документации описывающей, что пошло не так, или что было сделано для исправления ситуации, но Лиза пояснила: «Мы продолжали перебрасывать проблему друг другу – Питер видел что-то такое в Performance Monitor, из-за чего сервер работал медленно, поэтому он перекидывал это ко мне, а я говорила ему, что это его SQL сервер виноват и возвращала проблему назад. Но у меня не было полномочий, посмотреть, что же делается внутри SQL-сервера, а он постоянно хотел сбросить тикет из очереди»

«В конце концов, всё свелось к проблеме с SAN, за которую отвечал Питер. Что-то случилось с нашим основным каналом до SAN и мы работали через медленное резервное соединение, и были еще какие-то сложности с конфигурацией канала, потому что он не работал на полную скорость. Мы видели медленную скорость обмена с диском, потому что Windows, очевидно, считала что SAN – это всего лишь один большой логически присоединенный диск. Мы запускали на самом сервере и SQL сервере все возможные виды тестов и пытались найти источник проблемы, но ни один из наших инструментов был не в состоянии показать, что реальная проблема была скрыта совсем в другом месте».

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

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

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

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

Я спросил Лизу как идёт работа сейчас, после того как компания внедрила систему унифицированного управления. «Мы работаем с ней около года», — сказала она мне, -«с ней всё стало по-другому». Она показала мне тикет от проблемы, случившейся совсем недавно: «Вот, что мы теперь видим».

ТРЕВОГА 2011‐06‐14 12:13:42
УЗЕЛ Windows Server BOSDB02
Экземпляр SQL Server = DEFAULT
СИМТОМ: Время ответа SQL Server не укладывается в допустимые пределы

IP: 10.10.15.212

SQL Server СУБД показывает 34% свободно
SQL Server СУБД фрагментация <5%
Очередь дисков <1
Утилизация сети <40%
Утилизация ЦП <60%
Утилизация памяти <75%

СВЯЗАННАЯ ТРЕВОГА 2011‐06‐14 12:10:52
УЗЕЛ Маршрутизатор MBS3667
Неисправность интерфейса

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

Рис 6.1: Визуальная трассировка аварийных извещений.
Лиза также сообщила, что команда начала тратить существенно меньше времени на взаимный перенос тикетов. Когда система рассматривается в виде единого целого, то стало понятнее, на каком участке произошел сбой. «Проблема становится огромной, если она находится за пределами датацентра. У нас есть большое число приложений, работающих через SalesForce.com, и если у этих ребят что-то случается, или, что чаще, один из провайдеров начинает работать медленнее, чем обычно, то наши пользователи видят, что «наше» приложение начинает работать медленнее. Но система мониторинга знает о зависимостях и обычно к этому времени она уже известила нас о начинающихся проблемах. Мы у себя рассылаем сообщение о приложениях, зависящих от работы этих сервисов, и начинаем звонить провайдеру сервиса, чтобы зарегистрировать у него тикет».

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

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

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

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

Выполнение пользовательских заказов

Кевин рассказал о еще одной стороне унифицированного управления. «Мы не только отвечаем за открытие тикетов по проблемам. Мы также открываем тикеты по рутинным операциям изменений». Я попросил его привести пример того, как это делалось до внедрения системы объединенного управления. Он показал мне тикет из архива:

ОТКРЫТ Хелпдеск 2010‐08‐12 15:50
Пользователю BDOUDS нужен новый сайт SharePoint размещенный в
intranet/projects/universitybid. Пользователь будет администратором сайта.

НАЗНАЧЕНО ДжХольц

ЗАМЕТКИ ДжХольц 2010‐08‐13 08:27
Отослано сообщение руководителю Билла для подтверждения. Также послано сообщение в отдел специальных проектов

ЗАМЕТКИ ДжХольц 2010‐08‐16 11:12
Руководитель Билла, КХики, подтвердила заявку. Всё еще жду подтверждения со стороны отдела специальных проектов.

ЗАМЕТКИ ДжХольц 2010‐08‐18 11:05
Всё еще жду ответа от специальных проектов. Пока прекратил заниматься виртуальной машиной.

ЗАМЕТКИ ХелпДеск 2010‐08‐20 10:34
Пользователь запрашивает статус.

ЗАМЕТКИ ДжХольц 2010‐08‐20 11:34
Скажите ему, чтобы сам связался с отделом специальных проектов. Мне нужно от них подтверждение, так как это выходит за пределы их бюджета.

ЗАМЕТКИ ДжХольц 2010‐08‐22 13:11
Подтверждение от специальных проектов получено. Поднял сайт и назначил пользователя BDOUDS в качестве пользователя сайта.

СТАТУС УСТАНОВЛЕН В ЗАВЕРШЕНО 2010‐08‐22 13:12

«Такое случалось постоянно. Кто-то мог позвонить нам за получением доступа или чем-то еще. Мы назначали тикет кому-нибудь в ИТ, но потом они начинали разбираться кто за него будет отвечать. В итоге нам пришлось создать толстую книгу», добавил он, показывая на толстую папку с тремя кольцами, стоящую на его полке, «по которой мы могли узнать, кто и за что отвечает». А затем надо было пытаться услышать от них ответ и ждать… Сколько это могло занимать? Конкретно эта проблема заняла у нас две недели. Это идиотизм, конечно, но всё это время пользователи звонили нам узнать состояние дел, а мы были не способны ничего им сказать, потому что ничего не знали. Сама работа после получения одобрения у Джеффа заняла всего 10 минут».

А как это выглядит при внедренном унифицированном управлении?

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

Рисунок 6.2: Документированный порядок, используемый для автоматизированных согласований/одобрений при запросе элемента каталога.

В качестве примера мы обсуждали разрешение на доступ, и я спросил о том, как это было раньше, когда надо кому-то было его получить. «Ничего не делалось», — признал Кевин, — «Единожды получив доступ, он оставался у пользователей до тех пор, пока человек не уходил из компании. Мы это не отслеживали. Теперь это видно в общем каталоге. Если вам что-то не нужно, то вы можете ‘вернуть это в магазин’, оно пройдёт через специальный порядок согласований и мы получаем тикет, в котором указано какой доступ и откуда надо убрать. Различные менеджеры периодически проводят проверку полномочий лиц, имеющих доступ к их ресурсам, а потом сообщают нам — кому и что надо убрать или оставить. Больше этой работой ИТ не занимается».

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

«Узелки на память» при выборе системы унифицированного ИТ менеджмента

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

• Последовательность работ. Решения для унифицированного управления должны предлагать потоки работ, помогающие автоматизировать согласования и управления сервисами. Составление последовательностей работ должно быть по максимуму реализовано в виде обычных перемещений мышью, чтобы программирование было сведено до минимума.
• Агенты. Я знаю, есть огромная пропасть между теми людьми, кого вполне устраивает расстановка агентов, и теми, кто этого категорически не приемлет; но я бы рекомендовал выбирать решение, в котором можно реализовать оба этих подхода. В некоторых случаях безагентный способ сбора данных себя прекрасно показывает, хотя при этом могут проблемы, связанные с производительностью и количеством выполняемых запросов, по сравнению с инсталлированным агентом. Я думаю, что гибридный подход для большинства организаций является наилучшим, и решение для мониторинга должно его поддерживать.
• Интеграция оповещений. Когда проблема возникает, решение унифицированного управления должно однозначно сообщать об этом определенным лицам; также оно должно открывать тикет в хелпдеске и автоматически искать подобные сигналы оповещения в прошлом. При такой работе существенно ускоряется время решения проблемы и такой тип «автоматизации знаний» реально важен.
• Согласования. Как я указывал раньше, «тикеты» не всегда нужны для работы с проблемами – они иногда нужны для другой работы, типа запросов на изменения. Унифицированное управление должно поддерживать потоки пересмотров/согласований для данных запросов, так что ИТ получает возможность уйти от своей традиционной роли «контролёра-распределителя» и вместо этого просто обрабатывает тикеты, назначенные для выполнения со стороны бизнеса.
• Обнаружение и размещение. Унифицированное решение для управления должно помогать находить определяемые узлы и сервисы и размещать на них агенты для мониторинга. Обнаружение должно происходить более или менее постоянно, либо должно периодически выполняться на регулярной основе, так что бы могли быть зафиксированы все изменения в вашем окружении.
• Маршрутизация. Тикеты – для проблем или для запросов должны автоматически маршрутизироваться через определяемые вами бизнес-правила. Другими словами, тикеты должны попадать к правильным специалистам настолько быстро, насколько это возможно.
• Расписание. Унифицированная система управления должна иметь встроенный календарь, позволяющий помещать задачи в расписание. Данный функционал помогает разрешать конфликты за окна обслуживания и позволяет выполнять работы по обслуживанию в правильное время.
• Каталог. Это ключевая часть решения для унифицированного управления, позволяющая ему работать в качестве управляемой системы самостоятельной помощи. В дополнение к этому, каталог помогает работать совместно над соответствием(compliance) бизнес-процессов выбранной в вашем окружении модели, такой, например, как ITIL. Каталог обеспечивает пользователей перечнем «заказываемых продуктов», но не совсем так, как это происходит в онлайновом веб-магазине. «Покупки» пользователей преобразовываются в тикеты, проходящие через необходимые проверки и согласования и, в последствии, передаваемые в ИТ на исполнение.
• Коммуникации. Пользователи не только должны иметь возможность создавать тикеты, но еще и просматривать их состояние в оговоренном для них месте, где ваша команда своевременно отображает изменение статуса. Веб-портал является традиционным способом таких коммуникаций, но еще лучше системы, позволяющие наладить такой информационный обмен через системные(почтовые) пользовательские ящики, благо в системе пользователи находятся постоянно.
• Интерфейс. В унифицированной системе не может быть много интерфейсов, и какое бы решение вы не выбирали, у вас должен быть и веб-интерфейс, а также его версия для мобильных устройств.
• Измерения. Если вы занимаетесь мониторингом клиентов, оплачивающих ваши услуги, у вас должна быть возможность выставлять счета за их использование. Даже если вы при этом работаете только с внутренними «клиентами», возможность выставлять оплату за потребление ИТ-ресурсов может стать весьма важной, если ваши менеджеры от бизнеса захотят усовершенствовать свою стратегию управления. Не стоит рассматривать ИТ как чисто затратную вещь, если потребляемые ресурсы могут (и должны) отслеживаться и распределяться на службы, реально их потребляющие.
• SLA. Система унифицированного управления должна помогать вам как в определении, так и в мониторинге соглашений об уровне сервисов (SLA) основанных на фактически сложившихся цифрах.
• Тренды. Решение для унифицированного управления должно включать в себя СУБД, хранящую результаты измерений производительности компонентов, дающую возможность хранить и правильно обрабатывать исторические тренды. Эта БД может помочь вам определить и отслеживать SLA, а также выполнять планирование емкости вашего окружения.
• Опросы. Закрытие очередного цикла работ с вашими пользователями является важным событием, кроме того технические SLA не являются единственным способом измерения успеха ваших дел, и не важно, знаете ли вы про это или нет. Возможность делать опросы среди ваших пользователей помогает вам определять SLA на их языке и позволяет создавать более приемлемые и ожидаемые условия их соблюдения.
• Отчеты. Посмотрите на отчетность и индикаторы, предоставляющие управленческую и исполнительскую информацию, такую как рабочая нагрузка, соответствие SLA и так далее. Да, даже индикаторы, помогающие конечным пользователям видеть что их окружение работает должным образом, могут в итоге поспособствовать ИТ службе на её долгом пути в демонстрации того, насколько точно она реагирует и следует потребностям бизнеса.
• Визуализация. Возможность наглядного отображения вашего окружения помогает в анализе поиска исходных причин и решения проблем.
• Всё в одном месте. Как я уже несколько раз упоминал в данном руководстве, основная ценность системы объединенного управления заключается в единстве – возможности собирать и отслеживать в одном месте все факторы, влияющие на производительность, используя единые наборы метрик, тревожных извещений, идентификаторов и так далее. Единый подход и единый взгляд на проблемы помогает освободиться от традиционного управления по участкам, на которых построено ИТ, и при возникновении проблемы позволяет сконцентрироваться на ней всему персоналу и более быстро находить исходную причину.
• Сохранение знаний. Унифицированная система управления должна помогать вашей организации сохранять критические знания, превращая тикеты, собранные на хепл-деске в автоматизированную базу знаний с возможностью поиска.
• Предварительно загружаемая информация. Если тревожное извещение создает тикет, то тикет должен автоматически включать в себя максимальное количество деталей: IP-адрес, время ответа и так далее. Чем больше информации включено в тикет, тем меньше специалистам нужно времени, чтобы разобраться в проблеме, тем быстрее будет найдено решение.

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

Способы приобретения унифицированной системы управления ИТ

Я хотел бы коротко обрисовать различные подходы, используемые вендорами при реализации решений для унифицированного управления. Хотел бы сразу подчеркнуть, что я не считаю какие-то способы «правильными» или, наоборот «неверными». Правильным является тот вариант, который правилен для вас, а что для вас хорошо – вы решаете самостоятельно.

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

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

Кроме того, существуют модульные фреймворки (pluggable frameworks). К таким системам я бы отнёс решения типа HP OpenView. При использовании данных систем вы покупаете базовый продукт, а затем начинаете к нему докупать отдельные части и модули. Такие системы предлагают большую гибкость, и если вы собираетесь работать с решениями от крупного вендора, то вы сумеете найти в его каталоге решения под практически все ваши задачи. Эти решения несут за собой риск превращения в массивные проекты, отнимающие большое количество времени и сил, да и модули не настолько хорошо интегрированы как вам может потребоваться. Схема лицензирования может быть очень и очень сложной, потому что плагины лицензируются отдельно базового продукта.

Другая модель лицензирования – оплата по мере использования (pay as you go). В этой модели, в решении предлагается вся функциональность, какая только может потребоваться, но вы не включаете её всю сразу. Вместо этого, вы активируете только то, что нужно и оплачиваете только это. По мере роста ваших потребностей, вы начинаете платить немного больше. Такая реализация больше похожа на «облачную» модель, где ваши потребности постепенно растут, но вы платите только за то, чем фактически пользуетесь. Здесь вам необходимости отдельно приобретать плагины, а если они и есть, то обычно их поставляет тот же вендор решения. Число сторонников данного подхода, среди многих моих клиентов растёт.

И в последнюю очередь надо подумать о том, где решение будет развёртываться. В век «облаков» у вас есть определенный выбор – размещать ваши решения для мониторинга и управления внутри вашего датацентра или просто приобрести такой сервис как услугу, размещающуюся в датацентре у провайдера. В любом случае, в вашем окружении инсталлируются программные агенты. Я не буду углубляться в спор «локальное размещение против выносного», возможно вы уже определились с тем, что для вас хорошо, а что нет; но вам, несомненно, потребуется рассмотрение в отношении конкретного решения. Вне зависимости от выбранной стратегии, было бы хорошо, если бы у вашего решения была возможность использовать оба варианта.

Заключение

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

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

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

Удачи.