мониторинг приложений
Прежде чем говорить о мониторинге приложений, выясним сначала, чем же так страшны эти самые приложения, что их надо как-то особенно "мониторить". Затем будет рассказано о том, как должна выглядеть "идеальная" система мониторинга и что необходимо знать, чтобы ее внедрение в организации не закончилось "как всегда".
"маленькие" большие проблемы или зачем нужен мониторинг?
Итак, чем опасны приложения (читай "программное обеспечение")?
К настоящему моменту около 90% бизнес-процессов коммерческих и государственных предприятий автоматизировано с использованием компьютеров и, соответственно, программного обеспечения (ПО). ИТ сегодня есть абсолютная необходимость в любом бизнесе, проблемы в ИТ способны уже повлиять не только на жизнеспособность отдельного бизнеса, но даже на национальные экономики. Сфере этой уделяется огромное внимание, отсюда разумно было бы предположить, что и программное обеспечение должно становиться с каждым днем лучше и надежнее.
В действительности это не так. ПО все более усложняется, что приводит к экспоненциальному росту количества связей и зависимостей между компонентами, и в результате надежность программ в целом снижается.
Вот печальная статистика:
- на 1000 строк кода программ приходится 100-150 ошибок (по материалам National Institute of Standards and Technology (NIST), 2002); - из всех проектов разработки ПО лишь 29% завершены успешно; 53% завершены с проблемами; 18% провалены (2004 CHAOS Report, the Standish Group Gartner, Inc.);
- 80% приложений до внедрения не тестируются вообще или тестируются вручную, без использования специализированных методик и соответствующего обеспечения (Researchers from Carnegie Mellon University);
- сопровождение программных продуктов "съедает" 60-80% затрат на весь производственный цикл;
- 40% времени разработчики тратят не на разработку, а на поддержку уже "боевой" системы;
- 40% от времени незапланированного простоя приложений обусловлено ошибками в них (Gartner Inc.).
Несмотря на это, большинство компаний рассматривают задачи диагностики как второстепенные и затратные. Но скупой платит дважды, и, как видно из приведенных далее историй, в результате даже относительно небольшие технологические проблемы могут обратиться для всего бизнеса крупной катастрофой.
2003 год. Север США и Канада. Массовые перебои в электроснабжении. Во вторник 14 августа 2003 года на северо-востоке Соединенных Штатов и в восточной части Канады произошли крупные перебои в снабжении электроэнергией. Это был наиболее крупный инцидент подобного рода за всю историю США. Пострадало около 10 миллионов жителей канадской провинции Онтарио (около трети всего населения Канады) и 40 миллионов жителей восьми американских штатов (примерно седьмая часть населения США). Принесенный ущерб оценивается примерно в шесть миллиардов долларов.
Согласно отчету американо-канадской комиссии по расследованию причин катастрофы от 19 ноября 2003 года, одной из главных ее причин стали проблемы с автоматизированной системой управления компании FirstEnergy, которая не предприняла вовремя спасательных действий, а также не оповестила о надвигающейся катастрофе другие управляющие центры. Произошло это из-за ошибки в программном обеспечении системы XA/21 производства компании General Electric Energy. Система контроля не подала необходимый сигнал об аварии, а обслуживающий персонал не обладал достаточной квалификацией, чтобы заметить неадекватное поведение системы. В течение полутора часов никто даже не догадывался, что система, призванная предупреждать об отклонениях параметров энергосети от нормы, просто не функционирует. В результате аварийная ситуация и соответствующий риск перегрузки привели к лавинообразному отключению около сотни других электростанций.
Август 2000 года. Банк Barclays (Англия). Полная остановка обслуживания. В августе 2000 года после неудачного апгрейда ПО в банке Barclays все его активные интернет-пользователи внезапно получили доступ к информации о счетах друг друга. Устранение ошибки потребовало полной 10-часовой остановки обслуживания.
Следующий пример показывает, к чему может привести недооценка влияния ошибок в программном обеспечении на бизнес в целом.
2004 год. Hewlett-Packard, неудачная миграция в SAP. Летом 2004 года в компании Hewlett-Packard стартовал проект миграции системы заказов серверов в SAP. В процессе внедрения из-за непредусмотренного заранее расхождения между теорией и практикой заказы определенных видов "застряли" между старой и новой системами. С технической точки зрения проблема не рассматривалась как критическая и была устранена за несколько недель. Однако для бизнеса последствия неожиданно оказались весьма серьезными. В течение всего лета были задержаны заказы на сумму в $120 млн, а конкуренция в торговле серверами весьма высока, и сам род бизнеса подразумевает своевременность поставок. В результате значительная часть клиентов ушла в Dell или IBM, чистый ущерб достиг $40 млн, что превышало бюджет всего проекта миграции ($30 млн.
В целом, по подсчетам аналитиков, годовой ущерб от сбоев в программном обеспечении в США составил в 2004 году $60 млрд, что составляет 0,6% валового продукта страны.
Конечно, системы мониторинга не есть "серебряная пуля", делающая вычислительные комплексы абсолютно надежными и полностью свободными от ошибок. Но они могут существенно облегчить тестирование приложений еще на стадии разработки, позволят наблюдать актуальную картину "уровня здоровья" системы и выявлять корневые причины сбоев в "боевой" системе, а в конечном счете, по накопленной статистике даже оценивать заранее возможные последствия тех или иных действий, выделять "особо опасные" участки и/или вообще дадут возможность пересмотреть подход к выполнению тех или иных действий.
Например, в случае с HP, ошибка руководства компании заключалась не в допущении самих сбоев ПО (полностью избавиться от них все равно нельзя), а в непроведении анализа возможного влияния сбоев на весь бизнес — действии, которое не может быть произведено силами только лишь ИТ. Прежде чем заменять "боевую" систему, надо было провести прогон на параллельном стенде или хотя бы перед переходом на новую версию сохранить действующий резервный экземпляр старой.
Теперь, обосновав актуальность темы, вернемся к вопросам диагностики ПО. Первая типичная ситуация, с которой мы сталкиваемся, когда предлагаем свои услуги, представляется примерно так: "У нас уже есть система диагностики, которая прилагается к нашей прикладной системе". Итак, мониторинг как побочный продукт производства...
мониторинг как побочный продукт производства
Речь пойдет о средствах отладки и диагностики, поставляемых разработчиками вместе с прикладной системой. Вообще-то совсем без инструментария подобного рода невозможно ни разработать, ни эксплуатировать ни один нетривиальный программный продукт, поэтому можно считать, что инструментарий этот всегда есть при каждой программной системе.
Ради справедливости стоит отметить, что несомненным преимуществом такой ad-hoc диагностики является то, что создаются эти инструменты теми же людьми, что и сами объекты диагностики, поэтому люди эти достаточно хорошо представляют себе, так сказать, "матчасть".
И все бы хорошо, если бы речь шла о небольших программах. Но для банковских и биллинговых систем, включающих в себя массу разнородного "железа" и программных компонентов, такого рода инструментарий становится неадекватным в силу некоторых неприятных свойств, о которых расскажем далее. Неполнота и неадекватность. Системы диагностики, разработанные параллельно с диагностируемым ПО, "заточены" на проблемы, выявленные в ходе разработки. Часто к моменту ввода системы в эксплуатацию многие из них бывают решены, а соответствующие тесты теряют актуальность. Работа системы в "боевом" режиме выявляет новые проблемы, но диагностический аппарат для них разрабатывать уже некому.
Система в состоянии "боевой" эксплуатации живет в условиях, сильно отличающихся от тестовых. Причем это может касаться не столько масштабов нагрузки, сколько масштабов критичности тех или иных функций. В описанной выше истории с системой сбыта в HP основные проблемы возникли, когда, в отличие от этапа лабораторного тестирования, пользователями системы оказались обычные люди, неподготовленные потребители продукции, которым не удавалось самостоятельно сформировать необходимый заказ. Менеджеры компании, планировавшие реформу системы сбыта, не сумели заранее оценить масштаб проблемы и предусмотреть роковые последствия.
Неоднородность и неинтегрируемость частей друг с другом. Различные части большой прикладной системы разрабатываются разными людьми, а зачастую и разными компаниями, при этом используются разные программные продукты, библиотеки и т.д. Естественно, совместимость между компонентами в итоговом продукте должна быть, иначе он просто не будет работать. Если те же люди создают заодно и средства диагностики, то стимулы унифицировать эти средства у них обычно отсутствуют. Результат (как в песне: "Я его слепила из того, что было") представляет собой набор разнообразных инструментов, функционирование которых, системные требования к которым, их зависимости от других программных продуктов и процедуры установки не только не укладываются в определенную систему, но чаще всего вообще не документированы. В результате такие средства невозможно объединить в единую систему даже между собой, что, конечно, затрудняет (точнее, делает невозможным) отторжение этих средств от разработчика и передачу заказчику, который, вдобавок ко всему, степенью подготовки и менталитетом сильно отличается от разработчика.
Неинтегрируемость со средствами мониторинга системотехники. Заказчик прикладной системы хочет знать, насколько она отвечает требованиям его бизнеса и в какой степени справляется с его бизнес-задачами. Ему интересно, например, сколько записей об оказанных услугах обрабатывается в настоящее время его биллинг-системой, или что происходит со счетами в банковской системе, сколько записей или счетов ожидает обработки и как долго длится это ожидание. Если что-то идет не так, заказчик хочет видеть масштаб и серьезность неполадок, понимать, насколько быстро их можно устранить и как это в целом отразится на его бизнесе.
В отличие от разработчика, этому самому бизнесу в общем-то все равно, вызваны данные неполадки ошибкой в ПО или выходом из строя кондиционера в серверном помещении, поэтому мониторинг работы программных продуктов должен осуществляться параллельно с мониторингом соответствующих аппаратных средств, а данные из обоих источников должны сходиться в какой-то точке, преобразуясь в единую картину, для бизнеса интересную и понятную. Разработчиков же вопросы "железа" интересуют во вторую очередь, а созданные ими элементы системы диагностики не только сами не затрагивают аппаратную часть, но и не могут быть соединены с другими, предназначенными для этой аппаратной части диагностическими средствами.
Тенденциозность. Хоть и нечасто, но бывает, что при вводе системы в эксплуатацию мнения разработчиков и заказчиков о том, какое поведение этой системы считать нормальным, а какое критическим или аварийным, могут расходиться. Это может внести определенный элемент субъективности при выборе как самих диагностических параметров и их критических значений, так и алгоритмов измерений.
Ограниченные возможности представления и экспорта данных. Информация, получаемая самодельными средствами диагностики, предназначается исключительно для оператора. Выводится она чаще всего в окна на экране или в журнальные файлы так называемого "свободного" формата (то есть формат как таковой отсутствует). Средства представления обычно весьма ограничены и нерасширяемы.
С другой стороны, нам часто хочется не только посмотреть, что и как "чувствует" прикладная система в данный момент, но и заглянуть в прошлое, например, чтобы понять, что случилось с ней вчера вечером, накопить данные и "повертеть" их в виде графиков и диаграмм, посмотреть статистику за последний день или месяц, экспортировать все это в отчет или базу данных, агрегировать технические показатели и пересчитать их в бизнес- показатели и т.д., и т. п.
Самодельные средства обычно не только сами не умеют делать всего этого, но и не позволяют отдать данные в другую систему, ту, которая умеет. Преодолеть все эти недостатки призваны так называемые промышленные системы мониторинга.
промышленная система мониторинга
Итак, мы подошли к идее приобретения промышленной системы. Некоторое количество таковых имеется в продаже, но прежде чем отправляться на рынок, надо бы сначала самим понять, чего мы ожидаем от покупки. Наша идеальная система мониторинга должна:
- иметь средства обнаружения сбоев;
- иметь средства накопления исторических данных и статистики;
- обеспечивать удобное и разнообразное представление накопленной информации;
- позволять преобразование низкоуровневых данных в "бизнес-картину" вообще и KPI в частности;
- предоставлять шлюзы в другие промышленные системы представления и обработки информации и/или API для построения такого рода шлюзов; - иметь достаточный набор готовых модулей для мониторинга стандартного оборудования и «стандартного» ПО;
- предоставлять возможность разработки собственных модулей для мониторинга заказных приложений.
Рассмотрим подробнее, что даст выполнение этих требований.
Средства обнаружения сбоев. В случае обнаружения сбоя формируется аварийное сообщение и оповещаются все, кто отвечает за объект.
Кроме того, если способ устранения сбоя известен, система должна обеспечивать автоматическую или полуавтоматическую его реализацию (Recovery Actions).
К сожалению, это случается очень редко. Обычно на момент внедрения системы мониторинга нет данных о наиболее характерных неполадках и способах их устранения. Побочным эффектом внедрения "правильной" системы мониторинга может стать накопление таких знаний и придание им формы Recovery Action.
Средства сбора статистики. Система должна не только показывать, что происходит "на текущий момент", но и накапливать исторические данные, что даст возможность проводить их статистическую обработку, получать усредненные характеристики качества работы прикладной системы, обнаруживать тенденции и корреляции между значениями различных показателей и сбойными ситуациями. Такой взгляд в прошлое позволяет в какой-то степени предвидеть будущее и предотвращать неприятности.
Средства отображения информации. Хотелось бы, чтобы система позволяла не только "по-всякому" показывать пользователям состояние прикладной системы, но делать это по-разному для разных пользователей. Например, оператору дежурной смены обычно можно и нужно видеть только часть системы, за работоспособность которой он непосредственно отвечает, причем с максимальной детализацией и возможностью запуска "корректирующих воздействий". Руководителю же дежурной смены, может быть, такая детализация не нужна, но ему необходимо видеть панораму всей прикладной системы и статистику. Бизнес-аналитикам нужны данные, "переваренные" до бизнес-терминов. Каждому должно быть доступно лишь то, что ему нужно, причем в наиболее удобном для него виде.
Средства преобразования в "бизнес-картину". При необходимости наша система должна уметь пересчитывать сотни и тысячи низкоуровневых показателей в единицы и десятки ключевых параметров (KPI), необходимых для бизнеса.
Владимир Цишевский, ведущий консультант отдела проектирования вычислительных комплексов, компания Jet Infosystems
"маленькие" большие проблемы или зачем нужен мониторинг?
Итак, чем опасны приложения (читай "программное обеспечение")?
К настоящему моменту около 90% бизнес-процессов коммерческих и государственных предприятий автоматизировано с использованием компьютеров и, соответственно, программного обеспечения (ПО). ИТ сегодня есть абсолютная необходимость в любом бизнесе, проблемы в ИТ способны уже повлиять не только на жизнеспособность отдельного бизнеса, но даже на национальные экономики. Сфере этой уделяется огромное внимание, отсюда разумно было бы предположить, что и программное обеспечение должно становиться с каждым днем лучше и надежнее.
В действительности это не так. ПО все более усложняется, что приводит к экспоненциальному росту количества связей и зависимостей между компонентами, и в результате надежность программ в целом снижается.
Вот печальная статистика:
- на 1000 строк кода программ приходится 100-150 ошибок (по материалам National Institute of Standards and Technology (NIST), 2002); - из всех проектов разработки ПО лишь 29% завершены успешно; 53% завершены с проблемами; 18% провалены (2004 CHAOS Report, the Standish Group Gartner, Inc.);
- 80% приложений до внедрения не тестируются вообще или тестируются вручную, без использования специализированных методик и соответствующего обеспечения (Researchers from Carnegie Mellon University);
- сопровождение программных продуктов "съедает" 60-80% затрат на весь производственный цикл;
- 40% времени разработчики тратят не на разработку, а на поддержку уже "боевой" системы;
- 40% от времени незапланированного простоя приложений обусловлено ошибками в них (Gartner Inc.).
Несмотря на это, большинство компаний рассматривают задачи диагностики как второстепенные и затратные. Но скупой платит дважды, и, как видно из приведенных далее историй, в результате даже относительно небольшие технологические проблемы могут обратиться для всего бизнеса крупной катастрофой.
2003 год. Север США и Канада. Массовые перебои в электроснабжении. Во вторник 14 августа 2003 года на северо-востоке Соединенных Штатов и в восточной части Канады произошли крупные перебои в снабжении электроэнергией. Это был наиболее крупный инцидент подобного рода за всю историю США. Пострадало около 10 миллионов жителей канадской провинции Онтарио (около трети всего населения Канады) и 40 миллионов жителей восьми американских штатов (примерно седьмая часть населения США). Принесенный ущерб оценивается примерно в шесть миллиардов долларов.
Согласно отчету американо-канадской комиссии по расследованию причин катастрофы от 19 ноября 2003 года, одной из главных ее причин стали проблемы с автоматизированной системой управления компании FirstEnergy, которая не предприняла вовремя спасательных действий, а также не оповестила о надвигающейся катастрофе другие управляющие центры. Произошло это из-за ошибки в программном обеспечении системы XA/21 производства компании General Electric Energy. Система контроля не подала необходимый сигнал об аварии, а обслуживающий персонал не обладал достаточной квалификацией, чтобы заметить неадекватное поведение системы. В течение полутора часов никто даже не догадывался, что система, призванная предупреждать об отклонениях параметров энергосети от нормы, просто не функционирует. В результате аварийная ситуация и соответствующий риск перегрузки привели к лавинообразному отключению около сотни других электростанций.
Август 2000 года. Банк Barclays (Англия). Полная остановка обслуживания. В августе 2000 года после неудачного апгрейда ПО в банке Barclays все его активные интернет-пользователи внезапно получили доступ к информации о счетах друг друга. Устранение ошибки потребовало полной 10-часовой остановки обслуживания.
Следующий пример показывает, к чему может привести недооценка влияния ошибок в программном обеспечении на бизнес в целом.
2004 год. Hewlett-Packard, неудачная миграция в SAP. Летом 2004 года в компании Hewlett-Packard стартовал проект миграции системы заказов серверов в SAP. В процессе внедрения из-за непредусмотренного заранее расхождения между теорией и практикой заказы определенных видов "застряли" между старой и новой системами. С технической точки зрения проблема не рассматривалась как критическая и была устранена за несколько недель. Однако для бизнеса последствия неожиданно оказались весьма серьезными. В течение всего лета были задержаны заказы на сумму в $120 млн, а конкуренция в торговле серверами весьма высока, и сам род бизнеса подразумевает своевременность поставок. В результате значительная часть клиентов ушла в Dell или IBM, чистый ущерб достиг $40 млн, что превышало бюджет всего проекта миграции ($30 млн.
В целом, по подсчетам аналитиков, годовой ущерб от сбоев в программном обеспечении в США составил в 2004 году $60 млрд, что составляет 0,6% валового продукта страны.
Конечно, системы мониторинга не есть "серебряная пуля", делающая вычислительные комплексы абсолютно надежными и полностью свободными от ошибок. Но они могут существенно облегчить тестирование приложений еще на стадии разработки, позволят наблюдать актуальную картину "уровня здоровья" системы и выявлять корневые причины сбоев в "боевой" системе, а в конечном счете, по накопленной статистике даже оценивать заранее возможные последствия тех или иных действий, выделять "особо опасные" участки и/или вообще дадут возможность пересмотреть подход к выполнению тех или иных действий.
Например, в случае с HP, ошибка руководства компании заключалась не в допущении самих сбоев ПО (полностью избавиться от них все равно нельзя), а в непроведении анализа возможного влияния сбоев на весь бизнес — действии, которое не может быть произведено силами только лишь ИТ. Прежде чем заменять "боевую" систему, надо было провести прогон на параллельном стенде или хотя бы перед переходом на новую версию сохранить действующий резервный экземпляр старой.
Теперь, обосновав актуальность темы, вернемся к вопросам диагностики ПО. Первая типичная ситуация, с которой мы сталкиваемся, когда предлагаем свои услуги, представляется примерно так: "У нас уже есть система диагностики, которая прилагается к нашей прикладной системе". Итак, мониторинг как побочный продукт производства...
мониторинг как побочный продукт производства
Речь пойдет о средствах отладки и диагностики, поставляемых разработчиками вместе с прикладной системой. Вообще-то совсем без инструментария подобного рода невозможно ни разработать, ни эксплуатировать ни один нетривиальный программный продукт, поэтому можно считать, что инструментарий этот всегда есть при каждой программной системе.
Ради справедливости стоит отметить, что несомненным преимуществом такой ad-hoc диагностики является то, что создаются эти инструменты теми же людьми, что и сами объекты диагностики, поэтому люди эти достаточно хорошо представляют себе, так сказать, "матчасть".
И все бы хорошо, если бы речь шла о небольших программах. Но для банковских и биллинговых систем, включающих в себя массу разнородного "железа" и программных компонентов, такого рода инструментарий становится неадекватным в силу некоторых неприятных свойств, о которых расскажем далее. Неполнота и неадекватность. Системы диагностики, разработанные параллельно с диагностируемым ПО, "заточены" на проблемы, выявленные в ходе разработки. Часто к моменту ввода системы в эксплуатацию многие из них бывают решены, а соответствующие тесты теряют актуальность. Работа системы в "боевом" режиме выявляет новые проблемы, но диагностический аппарат для них разрабатывать уже некому.
Система в состоянии "боевой" эксплуатации живет в условиях, сильно отличающихся от тестовых. Причем это может касаться не столько масштабов нагрузки, сколько масштабов критичности тех или иных функций. В описанной выше истории с системой сбыта в HP основные проблемы возникли, когда, в отличие от этапа лабораторного тестирования, пользователями системы оказались обычные люди, неподготовленные потребители продукции, которым не удавалось самостоятельно сформировать необходимый заказ. Менеджеры компании, планировавшие реформу системы сбыта, не сумели заранее оценить масштаб проблемы и предусмотреть роковые последствия.
Неоднородность и неинтегрируемость частей друг с другом. Различные части большой прикладной системы разрабатываются разными людьми, а зачастую и разными компаниями, при этом используются разные программные продукты, библиотеки и т.д. Естественно, совместимость между компонентами в итоговом продукте должна быть, иначе он просто не будет работать. Если те же люди создают заодно и средства диагностики, то стимулы унифицировать эти средства у них обычно отсутствуют. Результат (как в песне: "Я его слепила из того, что было") представляет собой набор разнообразных инструментов, функционирование которых, системные требования к которым, их зависимости от других программных продуктов и процедуры установки не только не укладываются в определенную систему, но чаще всего вообще не документированы. В результате такие средства невозможно объединить в единую систему даже между собой, что, конечно, затрудняет (точнее, делает невозможным) отторжение этих средств от разработчика и передачу заказчику, который, вдобавок ко всему, степенью подготовки и менталитетом сильно отличается от разработчика.
Неинтегрируемость со средствами мониторинга системотехники. Заказчик прикладной системы хочет знать, насколько она отвечает требованиям его бизнеса и в какой степени справляется с его бизнес-задачами. Ему интересно, например, сколько записей об оказанных услугах обрабатывается в настоящее время его биллинг-системой, или что происходит со счетами в банковской системе, сколько записей или счетов ожидает обработки и как долго длится это ожидание. Если что-то идет не так, заказчик хочет видеть масштаб и серьезность неполадок, понимать, насколько быстро их можно устранить и как это в целом отразится на его бизнесе.
В отличие от разработчика, этому самому бизнесу в общем-то все равно, вызваны данные неполадки ошибкой в ПО или выходом из строя кондиционера в серверном помещении, поэтому мониторинг работы программных продуктов должен осуществляться параллельно с мониторингом соответствующих аппаратных средств, а данные из обоих источников должны сходиться в какой-то точке, преобразуясь в единую картину, для бизнеса интересную и понятную. Разработчиков же вопросы "железа" интересуют во вторую очередь, а созданные ими элементы системы диагностики не только сами не затрагивают аппаратную часть, но и не могут быть соединены с другими, предназначенными для этой аппаратной части диагностическими средствами.
Тенденциозность. Хоть и нечасто, но бывает, что при вводе системы в эксплуатацию мнения разработчиков и заказчиков о том, какое поведение этой системы считать нормальным, а какое критическим или аварийным, могут расходиться. Это может внести определенный элемент субъективности при выборе как самих диагностических параметров и их критических значений, так и алгоритмов измерений.
Ограниченные возможности представления и экспорта данных. Информация, получаемая самодельными средствами диагностики, предназначается исключительно для оператора. Выводится она чаще всего в окна на экране или в журнальные файлы так называемого "свободного" формата (то есть формат как таковой отсутствует). Средства представления обычно весьма ограничены и нерасширяемы.
С другой стороны, нам часто хочется не только посмотреть, что и как "чувствует" прикладная система в данный момент, но и заглянуть в прошлое, например, чтобы понять, что случилось с ней вчера вечером, накопить данные и "повертеть" их в виде графиков и диаграмм, посмотреть статистику за последний день или месяц, экспортировать все это в отчет или базу данных, агрегировать технические показатели и пересчитать их в бизнес- показатели и т.д., и т. п.
Самодельные средства обычно не только сами не умеют делать всего этого, но и не позволяют отдать данные в другую систему, ту, которая умеет. Преодолеть все эти недостатки призваны так называемые промышленные системы мониторинга.
промышленная система мониторинга
Итак, мы подошли к идее приобретения промышленной системы. Некоторое количество таковых имеется в продаже, но прежде чем отправляться на рынок, надо бы сначала самим понять, чего мы ожидаем от покупки. Наша идеальная система мониторинга должна:
- иметь средства обнаружения сбоев;
- иметь средства накопления исторических данных и статистики;
- обеспечивать удобное и разнообразное представление накопленной информации;
- позволять преобразование низкоуровневых данных в "бизнес-картину" вообще и KPI в частности;
- предоставлять шлюзы в другие промышленные системы представления и обработки информации и/или API для построения такого рода шлюзов; - иметь достаточный набор готовых модулей для мониторинга стандартного оборудования и «стандартного» ПО;
- предоставлять возможность разработки собственных модулей для мониторинга заказных приложений.
Рассмотрим подробнее, что даст выполнение этих требований.
Средства обнаружения сбоев. В случае обнаружения сбоя формируется аварийное сообщение и оповещаются все, кто отвечает за объект.
Кроме того, если способ устранения сбоя известен, система должна обеспечивать автоматическую или полуавтоматическую его реализацию (Recovery Actions).
К сожалению, это случается очень редко. Обычно на момент внедрения системы мониторинга нет данных о наиболее характерных неполадках и способах их устранения. Побочным эффектом внедрения "правильной" системы мониторинга может стать накопление таких знаний и придание им формы Recovery Action.
Средства сбора статистики. Система должна не только показывать, что происходит "на текущий момент", но и накапливать исторические данные, что даст возможность проводить их статистическую обработку, получать усредненные характеристики качества работы прикладной системы, обнаруживать тенденции и корреляции между значениями различных показателей и сбойными ситуациями. Такой взгляд в прошлое позволяет в какой-то степени предвидеть будущее и предотвращать неприятности.
Средства отображения информации. Хотелось бы, чтобы система позволяла не только "по-всякому" показывать пользователям состояние прикладной системы, но делать это по-разному для разных пользователей. Например, оператору дежурной смены обычно можно и нужно видеть только часть системы, за работоспособность которой он непосредственно отвечает, причем с максимальной детализацией и возможностью запуска "корректирующих воздействий". Руководителю же дежурной смены, может быть, такая детализация не нужна, но ему необходимо видеть панораму всей прикладной системы и статистику. Бизнес-аналитикам нужны данные, "переваренные" до бизнес-терминов. Каждому должно быть доступно лишь то, что ему нужно, причем в наиболее удобном для него виде.
Средства преобразования в "бизнес-картину". При необходимости наша система должна уметь пересчитывать сотни и тысячи низкоуровневых показателей в единицы и десятки ключевых параметров (KPI), необходимых для бизнеса.
Владимир Цишевский, ведущий консультант отдела проектирования вычислительных комплексов, компания Jet Infosystems
Сетевые решения. Статья была опубликована в номере 02 за 2007 год в рубрике технологии
