Система мониторинга бизнес-процессов

Анатолий Филин: Добрый день, Денис! Я хотел бы задать тебе несколько вопросов по одному из проектов, которые мы завершили довольно давно. Прошло довольно много времени, и мне давно хотелось разобраться в том, что же мы сделали, и что же из себя представляет этот проект, но все как-то руки не доходили. На сайте у нас написано про него пол странички и я не совсем понимаю, что было в точности сделано. Мне бы хотелось чтобы это стало понятно не только мне, но и всем, кто заходит на наш сайт. Возможно, когда люди поймут, что мы умеем делать, у них появится интерес заказывать аналогичные проекты.

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

Денис Елданди: Проект состоял в создании системы мониторинга. Длился он в районе полутора — двух месяцев.

Анатолий: Что представляет из себя инфраструктура компании? Что вообще требовалось мониторить?

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

Анатолий: То есть несколько десятков, это, допустим — 50? Такого порядка, да?

Денис: Допустим.

Анатолий: Это — сервера, которые распределены географически, получается, да?

Денис: Да

Анатолий: Имеет ли значение — эта инфраструктура unix-овая, или windows-овая, и то и другое, гибридное?

Денис: Гибридное.

Анатолий: То есть там были и Unix и Windows?

Денис: Да.

Анатолий: Хорошо, а вот если подойти с другой стороны — кто является пользователем того, что ты сделал, результата твоей работы?

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

Анатолий: То есть они в каком смысле являются пользователями? Они заходят в эту систему и получают оттуда какие-то сообщения? В чем это выражается?

Денис: Они получают сообщения на e-mail, заходят в систему, смотрят на веб-интерфейс. Так было в то время, и я думаю они передали эти обязанности впоследствии своим подчиненным.

Анатолий: Я понимаю более менее что означают слова “система мониторинга” когда речь идет об инфраструктурных вещах, например в таких ситуациях как: диск отказал, что-то сгорело, происходят какие-то события с оборудованием — нужно срочно что то сделать, какие-то файлы удалить, или отказало сетевое оборудование. Но здесь система называется – система мониторинга бизнес-процессов, то есть получается, что мониторится не оборудование, а какие-то более высокоуровневые вещи?

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

Анатолий: Ты можешь привести какой-либо пример?

Денис: Например — время прохождения документа по циклу документооборота. Приложение имеет http-интерфейс (страничку, на самом деле), по которому оно отдает среднее время прохождения документа за последние, например, пять минут. То есть система сама уже изначально ставит timestamp в начале процесса и смотрит на этот timestamp в конце процесса. В результате она сама знала время прохождения. Небольшой счетчик накапливает среднее время.

Анатолий: Значит, стандартное среднее время прохождения – допустим — 5 минут, а если оно будет 20 минут — значит что-то в системе поломалось, и надо разбираться, углубляться — что именно и где эта цепочка замедлилась, порвалась и так далее?

Денис: Вообще, на это смотрят обычно с другой стороны. Есть время, необходимое по регламенту, например — не более 20 минут, а если регламент нарушается — то надо принимать какие-то меры, и производится “разбор полетов”. А разбор полетов облегчается сбором дополнительных параметров, которые сами по себе в регламент не входят, например — время прохождения документа на третьем этапе. Если в процессе разбора полетов станет понятно, что время прохода документа на третьем этапе выросло, то скорее всего “рыть” надо в сторону третьего этапа.

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

Денис: Казалось бы, да. Но, как показывает практика, все высокоуровневые показатели — достаточно шумные, и если регламент у нас, допустим, 20 минут, то он будет шуметь от нуля — до девятнадцати минут. Просто потому что систему делают так, чтобы показатели не выбивались за регламент, а дальнейшее — никого не интересует. Вы хотите спросить меня, можно ли смотреть на тренд этого “главного” показателя? Да, в теории можно, но практике смысла в этом мало. Есть другие, более трендовые показатели, которые менее шумные и более гладкие, на них все и смотрят.

Анатолий: Мог бы ты привести какой-нибудь пример?

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

Анатолий: Теперь я не понимаю — как этот показатель может сообщить о какой-либо проблеме?

Денис: А он не сообщает о проблеме, он просто заставляет задуматься – «что же мы вчера сделали такого, что он сегодня вырос?».

Анатолий: То есть это — показатель, который может подскочить только в случае каких-либо изменений, например — нового релиза?

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

Анатолий: Я тебя понял. Меня вот что интересует – допустим, есть достаточно крупный бизнес, связанный с технологиями и, скорее всего, связанный с интернетом. Он зарабатывает деньги, идут какие-то платежи, собирается какая-то статистика данных. Этот бизнес может представлять из себя, допустим, интернет-магазин, баннерный сервис, или видео сервис. Понятно, что есть сотрудники, которые следят за финансовыми и бизнес-показателями — за здоровьем системы и компании в целом. Такой компании интересно настроить мониторинг, который бы занимался более высокоуровневыми процессами. Например — известно, что компания каждый день зарабатывает какое-то количество тысяч долларов, которые еще не пришли в виде платежных документов, но уже каким-то образом заработаны — либо в виде комиссий, которые только в конце месяца будут выставлены в виде инвойсов, либо с помощью кликов, если сайт зарабатывает на рекламе показов и кликов. При этом, во многих случаях руководство узнает о финансовых результатах раз в месяц. Может ли система мониторинга, о которой мы говорим, интегрирована с бизнес-процессами так чтобы дать возможность на ежедневной основе (или даже в реальном времени) руководителям получать данные о здоровье компании?

Денис: Очевидно, что может, но опять же — никакой умной логики, которая «из ничего» рисовала бы дневные финансовые показатели, в системе мониторинга нет. От бизнес-системы компании требуется серьезная поддержка для того, чтобы она отдавала какие-то показатели системе мониторинга, например – «сколько мы заработали сегодня?»; «если бы мы работали весь оставшийся месяц как сегодня — сколько бы мы в месяц заработали?». Однако, построение кратковременных бизнес-прогнозов на основе текущих данных возможно. Почему нет?

Анатолий: Хочу тебя спросить вот о чем. Допустим, система мониторит какие-то базовые вещи — сеть или еще что-то, и допустим где-то произошел сбой — один, второй, третий… На самом деле — это все текущие вещи, и руководителям они мало интересны. Но если я как руководитель, сегодня увижу, что на 30% упало число кликов по сравнению со среднемесячным, то я на этот факт безусловно среагирую. Т.е. меня как руководителя больше интересует не сколько мы сегодня заработали, а скорее отклонения от «нормы». Технология, о которой мы говорим, позволяет такие вещи отслеживать?

Денис: Да, конечно.

Анатолий: Хорошо, а еще хотелось бы понять, каким образом это все сделано, то есть написана ли система с нуля, использовались ли при ее написании какие-либо платформы, и вообще — что из себя конкретно представляет работа на проекте Такском?

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

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

Денис: Такском был сделан на Zenoss. Zenoss — это open source платформа, позволявшая сделать все, что было необходимо компании Такском на тот момент. К этой платформе были дописаны модули.

Open-source платформа Zenoss

Анатолий: Эта платформа требует расходов, связанных с лицензированием?

Денис: Никаких расходов, связанных с лицензированием, нет.

Анатолий: Есть ли какие-либо ограничения, связанные с работой этой платформы на различных операционных системах?

Денис: Насколько я знаю, система работает только на Linux, но я не уверен — может быть она заработает и на Windows, но, откровенно говоря, я сомневаюсь. Наверняка она заработает на FreeBSD.

Анатолий: Объясни, пожалуйста, что позволяет делать эта платформа?

Денис: Она позволяет собирать данные и «складывать» их историю в свою базу данных для отрисовки графиков. Она позволяет конфигурировать критерии для этих данных, а также — конфигурировать правило для нотификации сотрудников и операторов по e-mail. У нее есть некоторые недостатки, конечно. Но на тот момент для “Такскома” эти недостатки не являлись show-stopper-ами. Компания пришла к выводу, что платформа соблюдает баланс между своими недостатками и ценой своего внедрения и поддержки.

Анатолий: Ты употребил слово «графики». Т.е. несмотря на то, что пользователи получают нотификации, алармы, sms-ы e-mail-ы, и так далее, в основном — люди смотрят на графики, да?

Денис: Да, люди смотрят на графики. Все показатели в этой системе — численные, даже такие понятия как “работает” — “не работает” приходится кодировать в “0” и “1”. Всю историю этих показателей можно посмотреть в графиках.

Графики Zenoss

Анатолий: Хорошо, я правильно понял, что система мониторинга работает на платформе Zenoss, и вместе с ней работают скрипты и какие-то вставки в приложения? То есть существуют скрипты, которые мониторят оборудование и умеют с ним взаимодействовать, и приложения, в которых нужно вставлять компоненты, понимающее протокол Zenoss?

Денис: Да, у этой платформы очень простой API для скриптов сбора данных; его можно посмотреть на любом языке. Эти скрипты обращаются так, как необходимо, (так, как они будут написаны) в приложения за данными. Приведу простейший случай — они спрашивают html-страничку у веб-приложения. На этой страничке в зависимости от адреса есть какое-то число. http://application.server.com/monitoring/http_hits/, например. Обращаетесь по http, там простое число — 18, например.

Анатолий: Понятно. Я услышал знакомое слово http. Взаимодействие между платформой и скриптами, которые собирают данные, осуществляется по http?

Денис: Это не обязательно. Я привел пример того, что взаимодействие может происходить таким простым способом.

Анатолий: А как-то оно еще может происходить?

Денис: Вариантов множество. К примеру, оно может происходить по SNMP и по SQL. Как удобней.

Схема системы мониторинга

Анатолий: Насколько я знаю, мы ставим систему мониторинга на все системы, которые мы создаем и поддерживаем? Встает вопрос — какие платформы мы используем на собственных системах, везде ли это Zenoss?

Денис: Нет, не везде Zenoss. Так, в видео-хостинге мы используем Zenoss, а в проекте Shopium, например, — Nagios. И у той и у другой платформы есть как свои преимущества, так и недостатки, поэтому — где-то удобна одна платформа, а где-то — другая.

Анатолий: Можешь ли ты еще что-нибудь рассказать интересное — либо про сам проект, либо вообще про системы мониторинга?

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

Анатолий: Так, интересно, а что конкретно продавать?

Денис: Инсталляцию.

Анатолий: Ты имеешь в виду — сделать платформу и заниматься ее продажей?

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

Анатолий: Хорошо. А насколько все-таки недостатки открытых и свободных систем существенны? Настолько ли, чтобы заказчики захотели что-то другое?

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

Анатолий: В каких случаях, например? Можешь ли ты привести пример, когда показатели более естественно в каком-то другом виде просматривать?

Денис: Например, в случае с критериями работоспособности.

Анатолий: Но ведь показатели в любом случае — либо численные, либо бинарные (то есть, фактически тоже численные), “0-1”.

Денис: “0-1” как раз не очень удобно рассматривать на графике, который рисует численное.

Анатолий: Скажи, а эти системы расширяемы, можно ли к ним что-то дописывать, приписывать, плагины или еще что-то?

Денис: Дописывать можно, но в связи с тем, что, например, Zenoss написана в очень неудачном фреймворке на Python-е – делать это проблематично.

Анатолий: Такой общий вопрос: насколько полезны системы мониторинга?

Денис: Они действительно полезны. Кроме вполне очевидного, того, о чем я уже говорил, то есть — быстро среагировать, когда что-то сломалось, или чуть менее очевидного — среагировать до того как что-то сломается, они очень полезны для разбора полетов. Эти системы позволяют быстро узнать — в каком месте что сломалось, и как это чинить. Обычной и очень хорошей практикой является постоянное добавление новых параметров мониторинга, которые определяются на основе восстановления после очередного сбоя. Как правило, после починки какой-нибудь ошибки в коде, система пополняет знания о том, что, например, «если бы мы следили за этим, мы смогли бы предугадать такую-то проблему”. И эти данные добавляются в систему.

Анатолий: И система стабилизируется…

Денис: Стабилизируется — громко сказано. Система становится чуть более прогнозируемой. Это, естественно, итеративный процесс.

Анатолий: Система мониторинга позволяет использовать накопленные знания и, что главное, не повторять ошибок…. Не наступать на те же грабли?

Денис: Да.

Анатолий: В ValueCommerce тоже использовалась система мониторинга. После того как она была установлена, и заработала, у нас круглосуточно дежурили операторы, — они следили за событиями, смотрели на экраны, и так далее. Это типичное использование системы мониторинга, или, в основном, она не требует присутствия операторов? От чего это зависит?

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

Что интересно — они приходят к такому знанию вполне самостоятельно. Например, они видят что, допустим, каждый день ломается какой-нибудь элемент системы. Если они в этом случае позвонят ответственному инженеру, он скажет им: “нет, все нормально». Как правило, если разбудить инженера среди ночи (а ведь ошибки в системе могут возникнуть и в такое время), днем он не особенно будет стремиться изменить систему таким образом, чтобы следующей ночью его не разбудили. Это какой-то странный человеческий фактор. А операторы могут вписать себе эту ошибку в runbook, и потом подать заявку на изменение критерия, чтобы в три часа ночи ошибка больше не появлялась. Как правило, подобные time-based критерии вредны, и они вынуждают инженеров-таки задуматься — “почему у нас в три часа ночи параметр отклоняется? Наверняка что-то у нас неправильно работает”.

Анатолий: То есть, наличие оператора полезно в ряде случаев, но не является всегда необходимым, и в какой-то степени зависит от размера инфраструктуры, от размера бизнеса и так далее? Видимо, наличие операторов также зависит и от рисков, связанных с эксплуатацией конкретной системы?

Денис: Да. Например, если с точки зрения конкретного бизнеса тот факт, что система сломается ночью, ничего страшного не значит, то круглосуточные операторы не очень нужны.

Анатолий: Тем не менее — нотификация в виде алармов, sms пойдет дежурному инженеру, в случае если что-то сломалось?

Денис: Опять же, скажу так. Многие предлагают: “давайте мы будем отправлять sms инженерам”. На самом деле, инженеры — тоже люди. Они могут быть пьяные, телефон у них может быть выключен. В результате — они могут sms не получить.Тогда предлагают: «давайте мы сначала одному инженеру отправим sms, а если не починится — следующему, а потом — их менеджеру”. Вроде бы это звучит как более-менее рабочая схема, но на практике — приводит к тому, что люди просто отключают телефоны на ночь.

Анатолий: В компании Такском используются круглосуточные операторы?

Денис: Да. Но по факту Такском использует не операторов, а дежурного инженера, который находится по ночам в офисе.

Анатолий: Спасибо за интервью, Денис!

Денис: Да, всегда пожалуйста, был рад помочь.