Это третий пост в серии статей о подходах и направлениях в мониторинге современных бизнес-приложений. Другие публикации серии доступны по следующим ссылкам:
- Мониторинг реальных пользователей (RUM)
- Синтетические транзакции или Мониторинг Бизнес-Процессов (Business Process Monitoring)
- CMDB в роли предохранителя
С помощью АРМ-решений, о которых мы пишем в своих статьях, наша команда профессионально реализовала большое количество проектов по мониторингу. Этот опыт дает нам возможность отнести себя к немногочисленной группе специалистов в области мониторинга, способных компетентно говорить не только о возможностях каждого АРМ- инструмента, но и об их реальной отдаче. Если Вы фанат какого-то из продуктов, и у Вас иная точка зрения, мы искренне будем рады отзывам и комментариям, а также конструктивным дискуссиям (оставлять свои комментарии Вы можете внизу статьи или в User Group DevOps Hub. IT Service management организовывать дискуссии, где мы активно участвуем). А если Вы, дорогой читатель, представитель компании-производителя, то мы будем рады, если наше мнение поможет сделать Ваш продукт более совершенным и полезным для нашего сообщества пользователей и внедренцев…
Рассмотренные ранее мониторинг реальных пользователей и мониторинг бизнес-процессов помогают управлять еще одним важным аспектом предоставления сервисов. Что такое SLA, в контексте ИТ-сервисов, сегодня объяснять уже не требуется. Концепция понятна всем заинтересованным сторонам и кажется простой, но по сути – SLA это сложная штука. Управление и контроль вообще редко бывают простыми, а мы говорим об управлении качеством предоставления услуг.
Расчет SLA – это фактически учетная система, с понятными правилами и логикой. RUM и синтетические транзакции предоставляют данные, необходимые для работы подобной учетной системы. Однако не все системы мониторинга этим пользуются. Например, AppDynamics и Dynatrace сосредоточились на других направлениях и честно заявили, что не делают расчет SLA. А Dell Foglight, хотя и заявляет об имеющихся возможностях по работе с SLA, на практике имеет весьма ограниченный функционал, без какой-либо гибкости.
А ведь соглашение об уровне предоставления сервиса – это очень важный механизм взаимодействия ИТ и бизнеса. И пусть мониторинг не поможет при переговорах об SLA, но он выходит на первый план, когда требуется гарантировать точное отслеживание выполнения взятых обязательств. Многие организации разрабатывают соглашения об уровне сервиса для внутренних подразделений и внешних подрядчиков, а вот контроль реальной доступности сервисов формализован гораздо реже, поскольку в этой вроде бы простой задаче кроется немало подводных камней. Недавно мы внедряли систему мониторинга с автоматизацией расчета SLA по доступности в одной из таких организаций, и на ее примере продемонстрируем возможные нюансы.
Корректировка плановых работ задним числом
В организации нередко возникали ситуации, когда смежники, отвечающие за часть инфраструктуры, выполняли плановые работы без предварительного уведомления. При этом, с точки зрения соблюдения SLA, это считалось именно плановым простоем (то есть, не влияющим на итоговый уровень доступности)! Применительно к системе мониторинга это означает, что подобные случаи необходимо вручную вводить задним числом и корректно учитывать при расчете SLA.
Некоторые системы мониторинга при расчете SLA реализуют возможность задавать плановую недоступность и корректно исключают ее из итогового расчета. А вот изменения задним числом часто просто недоступны. Из серьезных инструментов нам удалось реализовать подобные корректировки только с помощью HP BSM.
Гибкость настройки
В этой же организации был реализован набор стандартных сервисных пакетов, которые отличались рабочими часами реагирования, временем гарантированной доступности и восстановления после сбоев. Иными словами, один и тот же сервис предлагается с различными SLA. И чем выше уровень пакета сервисной поддержки, тем дороже его стоимость. Как ни странно, HP BSM оказался одной и немногих систем мониторинга, которая позволяет создать подобные пакеты и применять шаблоны к услугам для автоматического расчета SLA согласно настройкам пакета.
Подводя итоги, можно сказать, что во многих системах, к сожалению, концепция SLA является скорее формальным направлением, а не отражает суть процесса.
Это третий пост в серии статей о подходах и направлениях в мониторинге современных бизнес-приложений. Другие публикации серии доступны по следующим ссылкам:
