В команде 9 человек (и аналитики и администраторы и разработчики)
Перестройку мы начали 2 года назад. Но сломать стереотипы удалось за год
Нет. Команда занимается только задачами развития мониторинга (но это не всегда толькл наши задачи, это включает в себя и обучение пользователей работы с инструментами)
Да. Без ITSM можно конечно, но тогда это получается разорванным использованием. Когда есть связь между бизнесом (сценариями) и ИТ (инфраструктурой) - пользователям самим по себе становится понятно, что и как работает
Мы очень много систем видели ) но мониторить надо не только само устройство. А то для чего оно работает\для кого. Понимать что от этого устройства зависит. На что его падение пострадает. Иногда надо посчитать его SLA-доступность :)
А вообще, надо смотреть не в мониторинг, а алерты получать )
Естественно, что мониторинг ради мониторинга никому не нужен. Интеграция с ServiceDesk есть. При этом инциденты заводятся не просто "куда-то", а на тех специалистов, которые могут решить конкретную проблему (это уже наши наработки в рамках INC mngm). И эти инциденты обогащаются той информацией, которая помогает администраторам их быстро решить. CMDB и INC - на базе продуктов BMC. И это работает и из Zabbix'a и из Grafana. Поэтому широко используются API
Мы строим все вокруг ресурсно-сервисного подхода, когда с помощью триггеров, зависимостей и порогов автоматически создаются и маршрутизируются инциденты на администраторов. А администраторы знают, что с этими инцидентами делать. Это уже внутренние процессы, которым следуют
Более того, мы рекомендуем в мониторинг и не смотреть (ну кроме уже совсем критичных сервисов), как раз пороги и алерты в этом помогают. Надо на алерты реагировать, а не на графики смотреть
Про инциденты, обогащение, возможно, будет в следующий раз :)
API Zabbix используется для сверки и получения данных. Например, для анализа инфраструктуры (что есть на мониторинге) и сверки элементов с CMDB, таким образом контролируем, что все мониторится и никто не проскочил мимо:)
Да. Мы делаем зонтичный мониторинг с очень сильной автоматизацией. Вендоры к нам уже приходили и приходят, но если год назад мы смотрели на их решения открыв рот, сейчас такого нет. Да, с одной стороны они дадут "все в одной коробке", но то, что мы научились и можем делать сейчас - не так уж и сильно отличается от коробочных решений. Зато за нами большая свобода с точки зрения автоматизации.
В этом и был смысл, уйти от доменов и понятий, а сделать мониторинг общедоступным и понятным, с акцентом на то, какие сервисы и клиенты, которые пользуются этим сервисом, пострадали.
Сделана единая платформа мониторинга сервисов в рамках оператора. Мониториться в ней будут все клиентские сервисы
Спасибо )
Добрый день. Спасибо
В команде 9 человек (и аналитики и администраторы и разработчики)
Перестройку мы начали 2 года назад. Но сломать стереотипы удалось за год
Нет. Команда занимается только задачами развития мониторинга (но это не всегда толькл наши задачи, это включает в себя и обучение пользователей работы с инструментами)
Да. Без ITSM можно конечно, но тогда это получается разорванным использованием. Когда есть связь между бизнесом (сценариями) и ИТ (инфраструктурой) - пользователям самим по себе становится понятно, что и как работает
Мы очень много систем видели ) но мониторить надо не только само устройство. А то для чего оно работает\для кого. Понимать что от этого устройства зависит. На что его падение пострадает. Иногда надо посчитать его SLA-доступность :)
А вообще, надо смотреть не в мониторинг, а алерты получать )
Спасибо за комментарий
Естественно, что мониторинг ради мониторинга никому не нужен. Интеграция с ServiceDesk есть. При этом инциденты заводятся не просто "куда-то", а на тех специалистов, которые могут решить конкретную проблему (это уже наши наработки в рамках INC mngm). И эти инциденты обогащаются той информацией, которая помогает администраторам их быстро решить. CMDB и INC - на базе продуктов BMC. И это работает и из Zabbix'a и из Grafana. Поэтому широко используются API
Мы строим все вокруг ресурсно-сервисного подхода, когда с помощью триггеров, зависимостей и порогов автоматически создаются и маршрутизируются инциденты на администраторов. А администраторы знают, что с этими инцидентами делать. Это уже внутренние процессы, которым следуют
Более того, мы рекомендуем в мониторинг и не смотреть (ну кроме уже совсем критичных сервисов), как раз пороги и алерты в этом помогают. Надо на алерты реагировать, а не на графики смотреть
Про инциденты, обогащение, возможно, будет в следующий раз :)
API Zabbix используется для сверки и получения данных. Например, для анализа инфраструктуры (что есть на мониторинге) и сверки элементов с CMDB, таким образом контролируем, что все мониторится и никто не проскочил мимо:)
Да. Мы делаем зонтичный мониторинг с очень сильной автоматизацией. Вендоры к нам уже приходили и приходят, но если год назад мы смотрели на их решения открыв рот, сейчас такого нет. Да, с одной стороны они дадут "все в одной коробке", но то, что мы научились и можем делать сейчас - не так уж и сильно отличается от коробочных решений. Зато за нами большая свобода с точки зрения автоматизации.
Добрый день
В этом и был смысл, уйти от доменов и понятий, а сделать мониторинг общедоступным и понятным, с акцентом на то, какие сервисы и клиенты, которые пользуются этим сервисом, пострадали.
Сделана единая платформа мониторинга сервисов в рамках оператора. Мониториться в ней будут все клиентские сервисы