Как сделать ИТ прозрачным для бизнеса (спойлер: настроить тру бизнес-мониторинг)
Чтобы разобраться в этом вопросе, предлагаю ввести два понятия: бизнес-процесс и бизнес-система. Как подсказывает капитан очевидность, доступность бизнес-процесса говорит о работе бизнеса, а бизнес-системы об ИТ. В реальной жизни эти две сущности связаны по рукам, ногам и головам. Если загибается система, то загибается и сам процесс, который она поддерживала. Об этом отправляются уведомления, лампочки на условной Grafana краснеют и какой-нибудь верхнеуровневый чувак видит, что остановился условный бизнес-процесс продажи товаров через интернет-магазин. Дядя вице-президент по продажам берет трубку, звонит и велит готовить бизнес-гель…
Но теперь представим, что система не загнулась, а на некоем сервере неожиданно до 99,5% подскочила утилизация CPU. Настроенные связи, конечно, сразу же передали влияние дальше по цепочке и вот уже руководство в своем кабинете видит, что процесс приобрел недобрый красный оттенок. Дядя вице-президент по продажам берет трубку, звонит и велит готовить бизнес-гель… А зря. Продажи-то идут. Ему объясняют, что ничего, мол, страшного, айфоны мы как продавали так и продаём, просто одному и сервачков фермы плохо. Ложечки нашлись, но осадочек остался. Очевидно, что подобные вещи не должны быть видны руководству и решаться внутри ИТ.
Так как же не пропустить мелкие проблемы (которые могут превратиться в крупные) и не отвлекать бизнес по пустякам?
На доступность процесса должны влиять только напрямую связанные с этим показатели: количество проданного товара, выручка, новые регистрации клиентов, успешные оплаты заказов и другие. Для систем должно быть отдельное представление с возможностью просмотра связанных процессов. Таким образом владелец системы сможет спокойно решать сугубо ИТшные вопросы без лишних нервяков для бизнеса. Коммерческие системы с таким функционалом мне не встречались, но реализовать этот подход самостоятельно не составит особого труда.
Чтобы разобраться в этом вопросе, предлагаю ввести два понятия: бизнес-процесс и бизнес-система. Как подсказывает капитан очевидность, доступность бизнес-процесса говорит о работе бизнеса, а бизнес-системы об ИТ. В реальной жизни эти две сущности связаны по рукам, ногам и головам. Если загибается система, то загибается и сам процесс, который она поддерживала. Об этом отправляются уведомления, лампочки на условной Grafana краснеют и какой-нибудь верхнеуровневый чувак видит, что остановился условный бизнес-процесс продажи товаров через интернет-магазин. Дядя вице-президент по продажам берет трубку, звонит и велит готовить бизнес-гель…
Но теперь представим, что система не загнулась, а на некоем сервере неожиданно до 99,5% подскочила утилизация CPU. Настроенные связи, конечно, сразу же передали влияние дальше по цепочке и вот уже руководство в своем кабинете видит, что процесс приобрел недобрый красный оттенок. Дядя вице-президент по продажам берет трубку, звонит и велит готовить бизнес-гель… А зря. Продажи-то идут. Ему объясняют, что ничего, мол, страшного, айфоны мы как продавали так и продаём, просто одному и сервачков фермы плохо. Ложечки нашлись, но осадочек остался. Очевидно, что подобные вещи не должны быть видны руководству и решаться внутри ИТ.
Так как же не пропустить мелкие проблемы (которые могут превратиться в крупные) и не отвлекать бизнес по пустякам?
Нужно отключить зависимость визуализации бизнес-процессов от доступности бизнес-систем.
На доступность процесса должны влиять только напрямую связанные с этим показатели: количество проданного товара, выручка, новые регистрации клиентов, успешные оплаты заказов и другие. Для систем должно быть отдельное представление с возможностью просмотра связанных процессов. Таким образом владелец системы сможет спокойно решать сугубо ИТшные вопросы без лишних нервяков для бизнеса. Коммерческие системы с таким функционалом мне не встречались, но реализовать этот подход самостоятельно не составит особого труда.
Создавайте два несвязанных контура мониторинга: бизнес-процессов и бизнес-систем. У ответственных за бизнес-процесс лиц должна быть возможность взглянуть на связанные с процессом системы.
Аномалии != Алерты
Есть такое понятие Alert Fatigue, буквально означает «усталость от оповещений». Такое бывает когда BDSM — основной стиль работы ИТ в компании. Некоторые готовы обрабатывать тысячи событий в минуту и даже считают, что кому-то кроме них это нужно. ОК, если это летящий Syslog, который просто анализируется и не ОК, если это добро прилетает в консоль событий. Действия системы алертинга (буду так его называть, но на самом деле это система оповещений о событиях) можно разделить на 4 категории:
TP — True Positive. С показателем всё ок и оповещения нет
TN — True Negative. С показателем всё хреново и система об этом уведомляет
FP — False Positive. С показателем всё ок и прилетает оповещение, то бишь это ложное срабатывание
FN — False Negative. С показателем всё хреново и оповещения нет.
Первые два хорошо, вторые два не очень (а последний вообще ужасный). Посмотрите видео выступления Бетси Николс на конференции «Мониторама», которая интересно рассказывает о научном подходе к снижению шума и показывает непонятные математические формулы. Она главный научный сотрудник Netuitive Inc., где отвечает за технологии компании в области науки, аналитики, моделирования и алгоритмов. Бетси применяла математику для создания игр, оптимизации полетов космических кораблей, управления производственными процессами, оптимизации цепочки поставок, моделей безопасности ИТ и управления рисками.
Видео
Слайды презентации
Есть такое понятие Alert Fatigue, буквально означает «усталость от оповещений». Такое бывает когда BDSM — основной стиль работы ИТ в компании. Некоторые готовы обрабатывать тысячи событий в минуту и даже считают, что кому-то кроме них это нужно. ОК, если это летящий Syslog, который просто анализируется и не ОК, если это добро прилетает в консоль событий. Действия системы алертинга (буду так его называть, но на самом деле это система оповещений о событиях) можно разделить на 4 категории:
TP — True Positive. С показателем всё ок и оповещения нет
TN — True Negative. С показателем всё хреново и система об этом уведомляет
FP — False Positive. С показателем всё ок и прилетает оповещение, то бишь это ложное срабатывание
FN — False Negative. С показателем всё хреново и оповещения нет.
Первые два хорошо, вторые два не очень (а последний вообще ужасный). Посмотрите видео выступления Бетси Николс на конференции «Мониторама», которая интересно рассказывает о научном подходе к снижению шума и показывает непонятные математические формулы. Она главный научный сотрудник Netuitive Inc., где отвечает за технологии компании в области науки, аналитики, моделирования и алгоритмов. Бетси применяла математику для создания игр, оптимизации полетов космических кораблей, управления производственными процессами, оптимизации цепочки поставок, моделей безопасности ИТ и управления рисками.
Видео
Слайды презентации
Многим Zendesk известен как инструмент автоматизации Service Desk. В квадрант Gartner этот вендор не входит просто потому что умеет автоматизировать только несколько процессов. Поделюсь с вами любопытной статистикой, которую Zendesk публикует по результатам биг-дата-машин-лёрнинг аналитики своих клиентов. В агрегированном виде это выглядит так:
📌94% пользователей удовлетворены результатом обращения в службу поддержки
📌8 ответов от службы поддержки потребовалось для закрытия обращения
📌20 часов заняло время закрытия обращения
📌4 часа прошло до первого ответа от службы поддержки
📌259 запросов в месяц получает служба поддержки
📌39% запросов решается после одного ответа от службы поддержки
У Zendesk ещё много других интересных исследований на основе данных своей клиентской базы. Например, они говорят, что процент удовлетворенности обратившихся через чат пользователей самый большой и составляет 92%. Не обессудьте, но просмотр полных версий отчётов потребует от вас адреса электронной почты.
📌94% пользователей удовлетворены результатом обращения в службу поддержки
📌8 ответов от службы поддержки потребовалось для закрытия обращения
📌20 часов заняло время закрытия обращения
📌4 часа прошло до первого ответа от службы поддержки
📌259 запросов в месяц получает служба поддержки
📌39% запросов решается после одного ответа от службы поддержки
У Zendesk ещё много других интересных исследований на основе данных своей клиентской базы. Например, они говорят, что процент удовлетворенности обратившихся через чат пользователей самый большой и составляет 92%. Не обессудьте, но просмотр полных версий отчётов потребует от вас адреса электронной почты.
Вчерашняя статья на Хабре о безопасности системы мониторинга Zabbix. Рассказывают как можно перехватить zbx_sessionid, получить доступ к Zabbix и выполнить произвольный скрипт на удалённом мониторящемся сервере. Все описанные проблемы решаются двумя простыми шагами: настройкой HTTPS и шифрованием данных между агентом/сервером/прокси. Не забывайте включать шифрование везде где только можно, особенно при использовании SaaS.
Хабр
Система мониторинга как точка проникновения на компьютеры предприятия
Это продолжение памятки про систему мониторинга Zabbix, опубликованной недавно в нашем блоге. Выражаем огромную благодарность пользователю Shodin, который внес з...
Небольшой обзор статьи на Хабре о подходе к снижению количества ложных срабатываний и своевременном оповещении.
Telegraph
И снова о снижении ложных срабатываний
Несколькими постами выше я уже писал про борьбу Бетси Николс с ложными срабатываниями. Вчера на Хабрахабре появилась интересная статья по связанной тематике — снижению количества ложных срабатываний. Автор предлагает делить обработку событий в системе мониторинга…
А если лень делать свой машин лернинг, ребята из anomaly.io уже сделали такую тулзу. Но просят за неё денег. Если у вас все остальные части системы мониторинга бесплатные, то $1440 в месяц вообще же не деньги, правда?
Anomaly
Anomaly Detection and Monitoring Service
Anomaly detection in real time by predicting future problems. Detect unusual patterns and monitor any time series metrics using math and advanced analytics.
Вау! 2 дня назад Appdynamics объявил о поддержке мониторинга SAP . Теперь умеет инструментировать ABAP и код в БД.
На днях при разговоре с заказчиком мне сказали: "к нам приходил Oracle и не смог ничего предложить для мониторинга наших микросервисов. Неужели у вас есть что-то для нашего ненаглядного Kubernetes?" Я ответил: "да полно разных инструментов!" Некоторые думают, что микросервисы это далекий космос, который недостижим для именитых вендоров решений для мониторинга. Ну для некоторых именитых недостижим, но есть же и другие инструменты, которые пока не доросли до попадания в квадрант APM Gartner (а может им это даже и не нужно). О таких инструментах я готовлю статью на Хабре, а пока вот тоже не менее интересно пишут о Kubernetes.
Сегодня три интересных статьи-сравнения из блога Overops (мониторинг кода с коллстэками, строчками кода и переменными на вход во время аварии). Статьи прошлых лет, но подход, который используют вендоры, остался без существенных изменений. Интересно проследить историю приобретений и как это отразилось на дальнейшей стратегии компаний. Статьи на английском.
1. ELK vs. Splunk
2. Appdynamics vs. NewRelic
3. Appdynamics vs. Dynatrace
Приятного чтения!
1. ELK vs. Splunk
2. Appdynamics vs. NewRelic
3. Appdynamics vs. Dynatrace
Приятного чтения!
OverOps
The fastest way to why: Instantly identify critical issues and fix them quickly.
OverOps issue root cause analysis at runtime instantly pinpoints why a critical issue broke your complex backend Java or .Net application in pre-prod and production. Eliminate the detective work of searching logs for the cause. Resolve issues in minutes.
В 2017 году Google выпустил книгу Site Reliability Engineering, где описываются вопросы поддержания работоспособоности веб-приложений как это видит для себя интернет-гигант. Я готовлю перевод одной из глав о мониторинге и скоро его здесь опубликую, а пока предлагаю вашему вниманию ссылку на книгу для ознакомления. В онлайне можно читать абсолютно бесплатно. После прочтения будете лихо готовить концепции по мониторингу и говорить, что Google использует точно такой же подход 🙂
Кстати, вчера началась ежегодная конференция Monitorama, посвященная мониторингу, DevOps и близким к этому штукам. Есть стрим на их сайте с записями предыдущих дней. А если захочется посмотреть прошлогодние видосы (не в виде стрима, а отдельных выступлений) — приходите к ним на канал в Vimeo. Из прошлогодних выступлений больше мне всего запомнилось о сравнении типов событий от систем мониторинга.
Vimeo
Monitorama
Monitorama is a member of Vimeo, the home for high quality videos and the people who love them.
Если увлекаетесь контейнерами, кубернейтсом и сопутствующими штуками, посмотрите 20 докер-экспертов и 15 кубернейтс-экспертов в блоге New Relic. В статьях приведены ссылки на соцсети, блоги и сайты этих людей, в которых можно следить за последними новостями и узнавать некоторые полезные для работы вещи.
Есть такой ивент консолидатор (или, по-нашему, зонтичная система мониторинга) BigPanda. Когда смотришь на эту картинку, понимание величины рынка мониторинга приходит само собой. Разумеется, это только малая часть этих систем. И обратите внимание на классификацию: Enterprise Suits, APM, Log Management и т.д. Актуальную версию можно посмотреть на странице bigpanda.io/resource-library/monitoringscape. На этой странице у каждой системы указано в каком формате она работает: SaaS или on-prem.
В начале июня писал о конференции Monitorama, посвящённую DevOps, но по большей части мониторингу. На их канале на Vimeo появились записи выступлений. Кстати, теперь они проводят такую же конференцию и в Европе в Амстердаме. Поэтому если у вас есть два свободных дня в начале сентября и €700 — почему бы вам не зарегистрироваться?
Серфинг в сети натолкнул меня на одно интересное решение и идею написания этой статьи. Для Хабра она не очень катит, а вот для личного блога самое оно
Medium
Трейсинг информационных потоков распределённого приложения и другие подходы к мониторингу
Специально для телеграм-канала Мониторим ИТ.
Есть такой зверь Customer Impact Assessment (CIA), на русский переводится как оценка влияния на пользователя. Думаю, вам уже понятно, что контексте предоставления ИТ-сервиса этот процесс может оказаться очень полезен. Это ретроспектива (обычно недельная) всех зафиксированных событий/инцидентов. Если вы сейчас скажете:"да хрена лысого я смогу все свои события за неделю просмотреть, мне на это жизни не хватит", значит что-то с вашим мониторингом не то. И это дополнительный повод проводить такую оценку, потому что так вы добьётесь снижения количества ложных/шумовых событий, выявите пару-тройку причинно-следственных связей возникших инцидентов и со спокойной душой передадите это разработчикам. После нескольких таких итераций нагрузка на колл-центр/техподдержку снизится сама собой.
В книге Site Reliability Engeneering Google рассказывает о 4 золотых сигналах (или метриках), на которые они рекомендуют ориентироваться в мониторинге приложений. Инженеры Google считают фундаментальными метрики: время задержки (latency), трафик (traffic), количество ошибок (errors) и насыщенность (saturation). Ниже расскажу подробнее.
1. Время задержки (latency). Время, затрачиваемое на обработку запроса, с уделением особого внимания различию между задержкой выполнения успешных запросов и задержкой выполнения неудачных запросов.
2. Трафик (traffic) Метрика уровня спроса на услугу — количества запросов к сервису. Например, количество HTTP-запросов в секунду в случае мониторинга HTTP REST API.
3. Количество ошибок (errors) Количество неудачных запросов. Ошибки могут быть явными (например, ошибки HTTP 500) или неявными (например, HTTP 200 OK с телом ответа, имеющим слишком мало элементов).
4. Насыщенность (saturation) Метрика уровня нагруженности сервиса. Показатель использования системы с упором на ресурсы, которые наиболее ограничены (например, утилизация памяти, диска или процессора). По мере приближения к высокой нагрузке качество сервиса ухудшается.
Будьте как Google — контролируйте эти метрики!
1. Время задержки (latency). Время, затрачиваемое на обработку запроса, с уделением особого внимания различию между задержкой выполнения успешных запросов и задержкой выполнения неудачных запросов.
2. Трафик (traffic) Метрика уровня спроса на услугу — количества запросов к сервису. Например, количество HTTP-запросов в секунду в случае мониторинга HTTP REST API.
3. Количество ошибок (errors) Количество неудачных запросов. Ошибки могут быть явными (например, ошибки HTTP 500) или неявными (например, HTTP 200 OK с телом ответа, имеющим слишком мало элементов).
4. Насыщенность (saturation) Метрика уровня нагруженности сервиса. Показатель использования системы с упором на ресурсы, которые наиболее ограничены (например, утилизация памяти, диска или процессора). По мере приближения к высокой нагрузке качество сервиса ухудшается.
Будьте как Google — контролируйте эти метрики!
Ниже мой небольшой инсайт. Может быть вам полезен, если занимаетесь пресейлами и/или продажами ИТ-продуктов. Поставьте, лайк, если материал был полезен.
Интервью — обязательная часть пресейловых активностей по продвижению решений мониторинга. (конечно, не только мониторинга, но мы тут только об этом). Как ещё узнаешь о болях клиента? Если вы интегратор (или вендор) — ваша задача решить проблему клиента, если клиент — задача опять-таки решить проблему. Получается, задачи обоих сторон идентичны. Customer Development — методика эффективного интервью для выявления реальных потребностей клиента. Если правильно её применять, можно заметно повысить КПД интервью для обоих сторон: продающая сторона будет решать реальную проблему, а покупающая лучше разберётся в своих задачах. Как следствие: не нужно встречаться повторно, созваниваться и вести дополнительную переписку для уточнения деталей. Как видите, сплошной win-win. И ничего сложного. Что нужно же делать? А вот что.
1. Гипотеза
Перед встречей сформулируйте несколько гипотез, которые позволят выявить проблемы клиента, о которых он мог и не догадываться. Перечень гипотез подскажет только прошлый опыт. Например:
- у вас дофига событий, вам они не досаждают?
- у вас дофига консолей мониторинга, ваша дежурная смена ещё не обзавелась фасеточным зрением как мухи?
- насколько быстро удаётся решать проблемы при наличии текущих систем мониторинга?
- и так далее.
Все свои гипотезы нужно оставить на время, когда клиент уже расскажет о своих проблемах, чтобы не сбивать его с мысли.
2. Процедура интервью
Во время интервью (и это показывает опыт) важно:
- не продавать
- задавать открытые вопросы
- искать причину мотивации собеседника
- спрашивать про прошлое и настоящее
- просить привести примеры конкретных ситуаций
- занимать нейтральную позицию, не учить жизни
2. Подготовленный гайд
Сделанная заранее домашка (вопросы) поможет узнать всё что хотелось и ни о чём не забыть. В гайд входят также и гипотезы. А вопросы могут быть такими:
- как сейчас вырешаете задачу мониторинга? — вопрос про реальный опыт.
- почему вас беспокоит текущий подход к мониторингу? — открытый вопрос, вопрос про реальные мотивы приглашения вас как экспертов
- каковы последствия этой ситуации? — поможет оценить важность проблемы для клиента.
- расскажите подробнее, что произошло в последний раз? — выявит подробности о ситуации и причинах появления проблемы.
- что ещё пытались сделать? — поможет понять серьезность немерений клиента при решении проблемы.
- как решаете проблему сейчас? — открытый вопрос для выявления текущих альтернативы для сравнения вашего предложения с потенциальными конкурентами
- с кем ещё стоит поговорить об этом? — поможет приобрести новый контакт. Если вас порекомендовали, значит вы попали в целевую аудиторию и верно нащупали боли.
2. Правильные люди
У интервьюируемого должно быть правильное представление о текущей ситуации. Желательно, чтобы на встрече были не только люди из ИТ, но и присутствовал бизнес, чтобы вы могли услышать две точки зрения (бывает очень полезно). В общем, главное найти людей, у которых есть полное представление о ситуации.
Кроме всего сказанного, разумеется нужно: иметь позитивный настрой, быть доброжелательным и улыбаться 🙂
Интервью — обязательная часть пресейловых активностей по продвижению решений мониторинга. (конечно, не только мониторинга, но мы тут только об этом). Как ещё узнаешь о болях клиента? Если вы интегратор (или вендор) — ваша задача решить проблему клиента, если клиент — задача опять-таки решить проблему. Получается, задачи обоих сторон идентичны. Customer Development — методика эффективного интервью для выявления реальных потребностей клиента. Если правильно её применять, можно заметно повысить КПД интервью для обоих сторон: продающая сторона будет решать реальную проблему, а покупающая лучше разберётся в своих задачах. Как следствие: не нужно встречаться повторно, созваниваться и вести дополнительную переписку для уточнения деталей. Как видите, сплошной win-win. И ничего сложного. Что нужно же делать? А вот что.
1. Гипотеза
Перед встречей сформулируйте несколько гипотез, которые позволят выявить проблемы клиента, о которых он мог и не догадываться. Перечень гипотез подскажет только прошлый опыт. Например:
- у вас дофига событий, вам они не досаждают?
- у вас дофига консолей мониторинга, ваша дежурная смена ещё не обзавелась фасеточным зрением как мухи?
- насколько быстро удаётся решать проблемы при наличии текущих систем мониторинга?
- и так далее.
Все свои гипотезы нужно оставить на время, когда клиент уже расскажет о своих проблемах, чтобы не сбивать его с мысли.
2. Процедура интервью
Во время интервью (и это показывает опыт) важно:
- не продавать
- задавать открытые вопросы
- искать причину мотивации собеседника
- спрашивать про прошлое и настоящее
- просить привести примеры конкретных ситуаций
- занимать нейтральную позицию, не учить жизни
2. Подготовленный гайд
Сделанная заранее домашка (вопросы) поможет узнать всё что хотелось и ни о чём не забыть. В гайд входят также и гипотезы. А вопросы могут быть такими:
- как сейчас вырешаете задачу мониторинга? — вопрос про реальный опыт.
- почему вас беспокоит текущий подход к мониторингу? — открытый вопрос, вопрос про реальные мотивы приглашения вас как экспертов
- каковы последствия этой ситуации? — поможет оценить важность проблемы для клиента.
- расскажите подробнее, что произошло в последний раз? — выявит подробности о ситуации и причинах появления проблемы.
- что ещё пытались сделать? — поможет понять серьезность немерений клиента при решении проблемы.
- как решаете проблему сейчас? — открытый вопрос для выявления текущих альтернативы для сравнения вашего предложения с потенциальными конкурентами
- с кем ещё стоит поговорить об этом? — поможет приобрести новый контакт. Если вас порекомендовали, значит вы попали в целевую аудиторию и верно нащупали боли.
2. Правильные люди
У интервьюируемого должно быть правильное представление о текущей ситуации. Желательно, чтобы на встрече были не только люди из ИТ, но и присутствовал бизнес, чтобы вы могли услышать две точки зрения (бывает очень полезно). В общем, главное найти людей, у которых есть полное представление о ситуации.
Кроме всего сказанного, разумеется нужно: иметь позитивный настрой, быть доброжелательным и улыбаться 🙂
Я тут задумался: а почему Kubernetes иногда ещё называют K8s? Вы не поверите! Цифра 8 означает всего лишь количество букв между k и s. Век живи — век гугли. 👍 — если знали, 👎 — если не знали, 👀 — если не знали что такое Kubernetes.