– Алексей, расскажите, пожалуйста, когда возникла необходимость мониторинга ИТ, как формировались методики и решения для его проведения?
– Когда ИТ бурно развивались в начале 2000-х, появлялось много видов нового оборудования и ПО. Российские компании вбирали в себя новые технологии тоннами. Но как гарантировать их работоспособность? Было два пути контролировать состояние ИТ. В первом случае администраторы своими силами организовывали мониторинг: сами писали скрипты, продумывали метрики, которые помогали составить картину работоспособности ИТ-ландшафта. Или компания предпочитала альтернативный вариант и использовала локальные системы мониторинга от производителей оборудования и софта. Но на тот момент эти системы отслеживали только работу компонентов «своего» вендора, не дружили друг с другом, а сам результат мониторинга на выходе был примитивный. О глубоком уровне мониторинга, например, транзакционном или автоматизированном исследовании логов тогда речи не шло.
Появление первых универсальных систем мониторинга, которые могли работать в гетерогенной среде, стало прорывом. Эту нишу начали осваивать крупные производители, как HP, IBM, Microsoft, BMC. Они поглощали нишевые компании, разрабатывающие универсальные продукты мониторинга. В то же время параллельно развивался сегмент платформ Open Source, среди которых Nagios, Zabbix, позже Prometheus.
Руководитель направления мониторинга «Инфосистемы Джет» Алексей Акопян
– Какие сейчас имеются средства для организации мониторинга инфраструктуры, приложений, бизнес-процессов?
– Сейчас на рынке представлены разные виды систем мониторинга. Это и универсальные ИТ-инструменты, комплексно обеспечивающие мониторинг ИТ-инфраструктуры, приложений, бизнес-процессов. В то же время есть и специализированные решения, которые отдельно фокусируются на отслеживании параметров этих трех сегментов. Они более эффективны. Специализация их сильная и слабая сторона одновременно. Это особенно заметно в случаях, когда компания заинтересована организовать мониторинг приложений, а «под ним» есть серьезная ИТ-инфраструктура. Тогда появляется необходимость использовать дополнительно еще средства мониторинга ИТ-инфраструктуры. А следом встает вопрос интеграции нескольких продуктов.
Состояние ИТ-инфраструктуры, приложений и бизнес-процессов связаны. Нельзя их отделять друг от друга, делать мониторинг одной сферы, не наблюдая другой.
– Грамотно организованный мониторинг - каким он должен быть? Велико ли в нем участие человека, или большее значение имеют правильно подобранные средства автоматизации? Какими компетенциями должен обладать специалист, ответственный за мониторинг?
– Результаты мониторинга должны быть понятными людям, которые будут с ними работать. Вот главный критерий успешности проекта внедрения подобных систем. А для этого все данные, предоставляемые системой, должны быть правильно интерпретированы, их не должно быть слишком много. На своей практике мы часто сталкивались со случаями, когда на мониторинг ставят максимум систем, а по факту оказывается, что потом с этими данными невозможно работать. Большой поток данных с ложными срабатываниями, события разного уровня важности - как из этого выделить причину той или иной проблемы? Частые срабатывания триггеров подрывают доверие к системе мониторинга.
Компании часто поддаются соблазну решить задачу мониторинга ИТ-инфраструктуры, внедрив определенный ИТ-инструмент. Но это не гарантирует предотвращения ЧС. Универсальных инструментов, которые выявят настоящие и потенциальные проблемы, - не существует. Гораздо действеннее сначала определить подход к мониторингу, проанализировать процессы компании и разработать карту мониторинга, а уже потом выбирать под него инструменты. Это задача команды внедрения. И у нее должен быть широкий технический кругозор, понимание не только технологий мониторинга, но и того оборудования и систем, с которыми система будет работать. Как собирать информацию, как предобрабатывать данные и какие скрипты для этого написать - это задачи для команды внедрения, их решения нет в самой системе мониторинга.
– Какова роль интегратора в этом процессе? На каких участках помощь интегратора незаменима?
– Порой системы мониторинга создаются вне сервисного подхода. Тот или иной компонент ИТ-инфраструктуры или приложение рассматривается сам по себе, в отрыве от бизнес-функции, которую они поддерживают. Система мониторинга в этом случае лишь фиксирует факт «пожара» на ограниченном участке и не дает максимального эффекта: не показывает причины и не сообщает, к чему способен привести сбой. Более действенно, если она строится от бизнес-сервиса. Например, компания хочет понимать, как работает ее документооборот или финансовый процесс. Тогда, опираясь на структуру сервиса, система мониторинга «покрывает» компоненты ИТ-инфраструктуры и ПО, поддерживающее эти сервисы, отслеживает их доступность и качество.
Нередко мы встречаемся с ситуациями, когда система мониторинга не полностью интегрирована в процессы компании и результаты ее работы словно повисают в воздухе. В этом случае она становится бесполезной. Выявленные системой мониторинга слабые стороны ИТ-инфраструктуры должны регистрироваться как инциденты в Service Desk и прорабатываться. Мониторинг должен быть частью ИТ-процессов, интегрирован с системами учета оборудования, управления инцидентами и «обвязан» соответствующими регламентами.
Собственно, чтобы спроектировать, внедрить систему мониторинга, интегрировать ее с необходимыми ИТ-компонентами и нужен ИТ-интегратор.
– Каким опытом обладает в данной сфере ваша компания? Расскажите о нескольких интересных и показательных проектах.
– Наша компания давно занимается мониторингом и вырастила серьезную практику в этой сфере. Сейчас помимо коммерческих систем, например, AppDynamics, в нашем портфеле несколько решений на базе Open Source. Особенно мы гордимся своим проектным опытом. Сегодня продукты с открытым исходным кодом на слуху, но далеко не все команды умеют встроить их в ИТ-ландшафт крупных компаний. Мы это делаем. Например, когда создавали ИТ-инфраструктуру для новой АИС ОСАГО или построили систему мониторинга бизнес-приложений на стэке ELK для крупного телекомоператора. Еще выделяется своими результатами проект по внедрению системы мониторинга пользовательского опыта для банка федерального масштаба, где нам удалось выявить причины замедления сервисов. Банк сократил на 25 % число инцидентов, приводящих к простою ИТ-систем, и в первый же год сэкономил 30 млн рублей. Другое слагаемое экономии появилось в итоге оптимизации работы 1000 сотрудников фронт-офиса, которые испытывали сложности в работе с приложениями или ПК. Время проведения операций по обслуживанию клиентов в среднем сократилось на 10%, и банк, таким образом, перестал терять еще 70 млн в год.
– Ваше экспертное мнение о перспективах развития направления мониторинга ИТ и роста его значимости для компаний в целом и разных категорий пользователей.
– Сейчас мы переживаем очередную волну подъема интереса к мониторингу. Многие компании уже перешли в эпоху цифровизации. ИТ-ландшафт усложняется, ИТ становится все более критичной составляющей предоставляемых сервисов, к тому же выросли требования к их доступности - они должны не просто работать, а «летать». В некоторых отраслях простои обходятся безумно дорого. Например, мы опросили ТОП-10 ритейлеров. Средняя стоимость одного часа простоя составляет от 20 до 50 млн рублей. Потери компании от сбоев работы бизнес-приложений составляют от 300 до 800 млн рублей в год. Системы мониторинга способны предотвратить эти сбои и поэтому целесообразность их внедрения сомнений не вызывает.
– Большое спасибо за беседу!
