С чего начинается внедрение мониторинга в организации
Зачем нужен комплексный мониторинг ИТ и бизнесу и КАК его внедрять?
На «Хабре» есть статьи о том, как внедрять мониторинг. В них описано, как надо и не надо организовывать систему мониторинга. Все эти статьи мы прочитали и поняли, что чего-то не хватает. Здесь не будет информации о важности разработки ресурсно-сервисной модели и о том, как уменьшить число ложно-позитивных сообщений о проблеме. Мы поделимся лайфхаками в работе команды, которые помогают реализовывать подобные проекты. Дальше будут такие рекомендации, которых в других статьях нет. Советы собраны на основе нашего опыта.
Комплексный мониторинг позволяет компаниям понять, где они теряют деньги
В компаниях всегда есть бизнес-подразделения. Они смотрят, где компания может больше зарабатывать и меньше тратить. Часто они обращают внимание на внутренние ИТ-системы. Если в ИТ-системах возникают инциденты, компания будет терять деньги. Например, рухнула платёжная система. Или регистрация стала сложнее, потому что её модифицировали. Или процесс оплаты неудобен для пользователей – в нем 10 кликов вместо 2.
Чем сложнее архитектура бизнес-приложения, тем больше людей необходимо для ее обслуживания: мониторить системы, анализировать и диагностировать инциденты, вникать, как эти инциденты влияют на клиентов. Итог – потрачены часы на выяснение причин сбоя, кто виноват и что делать. Пока это делается, клиенты страдают, деньги компании тратятся, а время устранения инцидентов растёт. Компании приходится смотреть на шлейф всех этих проблем, а не в светлое будущее. Дальше разберёмся, почему так происходит.
Есть кое-что, что мешает быстро обнаруживать источник проблем. Это разрозненность средств мониторинга. Все вместе они не дают единой картины для всех ИТ-компонентов, которые влияют на работу бизнес-приложения. Бывает так, что задачи похожи или даже одинаковые, но повторно их решают другие люди другими инструментами. Нередко приходится сверять друг с другом показатели одних и тех же метрик.
Что будет, если вот это все заставить работать вместе? О плюсах комплексного мониторинга – далее.
Преимущества комплексного мониторинга
Внедрение единого комплексного мониторинга для бизнес-процессов и ИТ-систем – логичное решение. Вот, что сможет делать компания, которая внедрила комплексный мониторинг:
Оперативно обнаруживать и решать проблемы в работе приложений до того, как они повлияют на пользователей;
Оценивать качество работы приложений на основе объективного мониторинга работы пользователей с приложением, а не обращаться в службу поддержки;
Анализировать клиентский опыт на протяжении всего процесса взаимодействия пользователя с системой;
Оценивать работу подрядчиков. Сравнивать их по количеству пользователей, которые выбирают данную платформу;
Получить единую точку доступа к общей картине состояния ИТ, возможность исследования «вглубь» – до сырых данных, а также анализировать корреляции.
Какие правила при внедрении комплексного мониторинга мы выработали
Совет №1: Выделите отдельную целостную команду разработки системы комплексного мониторинга.
Вот, кто должен быть в команде:
Специалист по Data Science
Бизнес- и системные аналитики должны быть вовлечены в проект на 100% и играть роль Product Owner’а. Они общаются с командой разработки основного продукта компании: от администраторов до руководителей. Бизнес- и системные аналитики пишут требования к системе мониторинга, планируют релизы и проводят UAT. Они обучают конечных пользователей системы мониторинга.
ИТ-роли в команде можно совмещать: разработчик системы мониторинга и инженер данных, администратор и DevOps инженер.
Совет №2: Заведите мониторинг препродуктивной среды. Потом синхронизируйте релизные циклы команды разработки основного продукта и команды разработки системы мониторинга
Бизнес ставит задачу разработчикам оптимизировать процесс взаимодействия пользователей с платформой. Например, процесс регистрации, оформления покупки, оплаты или возврата средств. Это влечет за собой изменение логов и логики построения KPI. Чтобы это сделать, нужно строить синхронные процессы изменения логики бизнес-процессов сайта и их KPI. Это важно, чтобы одним утром после релиза не обнаружить, что мониторинг не работает.
Совет №3: Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно
Мониторинг не универсален. Он много от чего зависит. Например, от архитектуры систем и взаимодействия между ними, от пользователей мониторинга и их видения.
В проектах разработки и внедрения системы комплексного мониторинга лучше использовать спринты и Agile-подход. Процесс разработки в нашей команде упрощенно выглядит так:
Определяем один показатель или один бизнес-процесс для мониторинга
Делаем небольшие выгрузки данных, достаточные для построения KPI. Чем больше выгрузок, тем лучше. Изучаем данные и определяем минимально достаточные источники для построения KPI.
Реализуем KPI на основе выгрузок и демонстрации пользователя мониторинга.
Дорабатываем источники данных и их подключения.
Разрабатываем KPI на основе живых данных.
Дальше релиз и получение обратной связи.
Потом планируем доработки на основе отзывов. Усложняем KPI путём подключения новых источников. Повторяем цикл.
Совет №4: Не планируйте ресурсные затраты на разработку мониторинга на основе объема систем, покрываемых мониторингом, или по количеству метрик и KPI, запланированных в разработку – вы все равно промахнетесь
Этот пункт вытекает из предыдущего. Наша команда начала разрабатывать мониторинг с зафиксированным объемом и количеством KPI. Сначала мы реализовали несколько дашбордов. Потом перешли на спринты и запланировали только набор бизнес процессов, которые будут мониториться. В результате (а может в процессе) перехода выработался процесс разработки KPI. Тот, что описан выше.
Совет №5: Дайте пользователям системы мониторинга больше свободы
Пускай у пользователей будет возможность исследовать данные, на основе которых вычисляется KPI. Ещё хорошо, если они смогут реализовывать простейшие вычисления и разрабатывать собственные метрики.
Продуктовая команда знает о своем продукте всё. При общении с системными аналитиками они могут упустить некоторые детали в работе или архитектуре систем. Если дать им доступ к изучению сырых данных, вы повышаете интерес конечных пользователей к мониторингу. Может так получиться, что продуктовая команда заметит отклонение показателей. Тогда она начнёт исследовать причины отклонений. Для этого команда сформирует новые метрики – так в будущем обнаруживать подобные проблемы будет проще. Команде мониторинга останется только формализовать метрику и запустить в работу.
Совет №6: Предусмотрите возможность отображения показателей на дашбордах в разрезе разных отрезков времени
Рассмотрим пример: мы разрабатываем бизнес KPI «Процент успешно завершенных регистраций пользователей на сайте». Для разработки KPI необходимо выбрать промежуток времени, в рамках которого мы будем наблюдать за показателем, а также на основе исторических данных определить уровни критичности. Уровень критичности, или важность проблем, определяет какой процент успешно завершенных регистраций считается обычным поведением (обычно обозначается зеленым цветом), или, когда процент успешно завершенных регистраций очень мал, сигнализирует о серьезных проблемах и обозначается красным цветом. В зависимости от промежутка времени, за который мы рассчитываем «Процент успешно завершенных регистраций», уровень критичности может быть разным. Процесс регистрации, как правило состоит из двух основных шагов: заполнение формы на сайте и подтверждение почты путем перехода по ссылке из письма. Некоторые пользователи выполняют регистрацию за пару минут, а другим – требуется вспомнить или восстановить забытый пароль от своей почты, что может занять более 5 минут. Если мы будем вычислять Процент успешных регистраций в рамках 5 минут, то мы «потеряем» пользователей, которые завершат регистрацию за 7-8 минут, что может значительно повлиять на Процент успешных регистраций, и система будет сигнализировать о проблеме.
Поэтому, разрабатывая KPI, мы ориентируемся и выбираем промежуток согласно оценке от бизнес аналитика, но обязательно добавляем другие промежутки времени в интерфейс, чтобы иметь возможность анализировать реальное поведение пользователей.
Совет №7: Настраивайте self-мониторинг, чтобы сохранить доверие к системе мониторинга
Совет №8: Используйте стандартный функционал продвинутой аналитики «из коробки». Например, «Автоматический ML»
Когда мы подключаем новый источник, мы уже знаем, какие поля и значения мы будем использовать. Ещё мы знаем, как будем строить KPI. По возможности, подгружаем в систему мониторинга исторические данные.
Однако, мы всегда прогоняем их через встроенные аналитические инструменты. Полученные показатели и графики оставляем «пожить» в течение какого-то времени и «пережить» инциденты. В половине случаев обнаруживаем новые зависимости от других показателей и интересные аномалии. На основе этого рождаются новые KPI.
Совет №9: Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии
Есть показатели, разрабатываемые в рамках комплексного мониторинга, а есть – в рамках инфраструктурного. Они сильно различны по своей природе и имеют совершенно разные понятия «нормы» и отклонения от нее.
«Комплексные» KPI строятся на основе корреляции разнородных бизнес и ИТ-показателей. Как правило, этим показателям присваивают веса, которые определяют влияние на «комплексный» KPI. Поэтому сразу определить понятие «нормы» и построить грамотный алертинг бывает очень сложно.
Команда разработки мониторинга должна брать на себя роль поддержки на какое-то время при релизе каждого нового дашборда или KPI. Это позволит получать обратную связь без посредников и дорабатывать «на ходу». Оповещений не должно быть много.
Есть специалист поддержки, который отвечает за решение проблемы или поиск её причин. Действия этого специалиста должны быть максимально понятными и простыми. Написано множество статей про лечение событийной усталости и о том, как грамотно настраивать алертинг.
Совет №10: Ведите историю инцидентов
ИТОГ: Выгоды от внедрения системы мониторинга
Мы собрали их пять. Вот они:
Система комплексного мониторинга является зонтичным решением для существующих систем мониторинга. Она объединяет агрегированные данные из других узкоспециализированных систем.
Комплексное решение закрывает все «слепые зоны», не покрытые существующими в компании системами мониторингами – сбор сырых данных из систем источников в комплексный мониторинг.
Появляется единая точка для анализа данных и расследования причин инцидентов.
Бизнес-аналитики, маркетологи, администраторы и руководители подразделений смотрят на одни и те же данные.
Все события имеют корреляцию по времени.
Ещё раз все наши рекомендации кратко:
Комплексный мониторинг внедряет отдельная команда, а не участники продуктовой команды;
Не упускайте мониторинг препродуктивной среды;
Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно;
Для внедрения комплексного мониторинга больше подходит Agile методология и отсутствие жестко зафиксированного скоупа;
При планировании закладывайте ресурсы продуктовой команды на доработку и изменение источников данных;
Пользователи системы мониторинга должны иметь возможность «покрутить» данные и метрики;
Дашборды должны иметь фильтры для настройки отображения метрик в разрезе 5 минут и 1 часа;
Разрабатывайте мониторинг для системы мониторинга. Особое внимание стоит уделить точкам взаимодействия системы мониторинга с источниками данных;
Аналитический функционал системы мониторинга, поставляемый «из-коробки», может быть полезен;
Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии. Пусть команда разработки мониторинга поживет с ними сама, чтобы понаблюдать за количеством оповещений и по возможности сократить их количество;
Ведите историю инцидентов.
Статью подготовил консультант компании Accenture Анастасия Астафьева
Что такое система мониторинга и контроля?
Елена Филипова, руководитель корпоративного Проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Managment Institute, квалификация Project Managment Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»
Известно, как не любят всевозможных проверяющих. Для многих контролер – это кто-то в форме, указывающий на ошибки и выписывающий штраф, но никак не делающий жизнь лучше и удобнее. С другой стороны, даже на бытовом уровне понятно, что без должного внимания невозможно обеспечить не только соблюдение правил, но и корректное информирование руководства о текущей ситуации. Соответственно, без правильной информации нельзя своевременно корректировать методы производства и улучшать их. Именно поэтому без контроля невозможно и управление само по себе. Идеальна ситуация, когда мониторинг производится легко и ненавязчиво без вмешательства в работу людей. Но при этом его достаточно, чтобы обеспечить лиц, принимающих решения, качественной и своевременной информацией о статусе производства и создать основу для принятия нужных решений. Баланс между этими категориями найти весьма сложно, но возможно, если применять системный подход к контролю управления проектами.
Фундаментальные уровни контроля КСУП
Основной вопрос о контроле управления проектами возникает тогда, когда его слишком мало или слишком много. И в том, и в другом случае управление страдает. Если контроля непомерно мало, то успешность результатов слишком нестабильна: каждый проект управляется по-своему, участники проектов в разных командах подчиняются своим собственным правилам, руководству поставляется в разное время разнородная информация, возникают неожиданности и провалы. Если же контроля чересчур много, то движение проектов становится слишком костным: менеджеры проектов не могут быть гибкими, возникает очень много требований к отчетности, руководство завалено избыточной информацией, и несмотря на это нет возможности принимать качественные решения.
При становлении КСУП особенно высок риск достаточно быстрого перехода от первой ситуации ко второй. Я бы сказала, что это самый скорый шаг к уничтожению системы управления проектами. При длительной обкатке КСУП, наблюдении и анализе применяемых инструментов, правильной подготовке персонала можно построить действительно качественную систему контроля. Тогда под присмотром будет то, что на самом деле необходимо выполнять, при этом появится возможность оперативно обрабатывать и своевременно использовать данные.
Подчеркну, что для этого необходимо длительное время, по крайней мере, пара лет. Если же попытаться быстро начать контролировать то, что сотрудники еще не умеют делать, а руководство еще не научилось оценивать и корректно реагировать, тогда вместо пользы можно получить только сизифов труд и головную боль. Но можно ли при низком уровне зрелости проектного управления все-таки создать реально качественную систему контроля? Да, задачей КСУП и является построение такой системы. Важно помнить, что применяемые методы мониторинга и контроля должны соответствовать вашему уровню зрелости, то есть готовности людей, инфраструктуры и методологии.
Удивительно, что не смотря на степень зрелости, возможности инфраструктуры и особенности бизнеса основа такой системы всегда опирается на фундаментальные элементы КСУП. Такими постоянными уровнями контроля являются:
Вот как описывает связь этих элементов PMBoK:
Система мониторинга должна охватывать все три уровня, чтобы можно было связать выполнение конкретного проекта и достижение целей организации. Все данные контроля, необходимые на верхнем уровне, должны декомпозироваться и спускаться до уровня исполнения, а все измерения нижнего уровня должны иметь четкие пути эскалации и понимание возможностей анализа и агрегации на верхние уровни. Только тогда на основании такой системы возникает возможность целостного сквозного управления. Под контролем выполнения проекта и получения его результата нужно иметь ввиду достижение стратегических целей. И наоборот, ставя перед собой стратегическую задачу и отслеживая ее реализацию, вы вынуждены контролировать окупаемость ваших инвестиций, достижение новых выгод и прибыли, а, значит, появление новых продуктов и сервисов.
Подбор инструментов для мониторинга и контроля необходим на каждом уровне. Надо понимать, что с ростом зрелости система будет неизбежно видоизменяться. Будут применяться более профессиональные инструменты, совершенствоваться процессы, выстраиваться более качественное реагирование на данные измерений, могут даже определиться новые органы для осуществления мониторинга и контроля. Но на этапе старта КСУП система еще не может использовать все свои возможности, поэтому важно сосредоточиться на минимально возможном наборе инструментов контроля, который максимально поддерживает все имеющиеся процессы.
При выборе таких инструментов стоит придерживаться некоторых принципов:
Во второй части публикации мы дадим рекомендации, как подготовить стартовый набор инструментов, который бы запускал корректные процессы контроля в организации. И заострим внимание на том, что подлежит контролю на каждом уровне управления.
Что такое система мониторинга и контроля? Часть 2
В одной из наших недавних публикаций мы уже подробно разобрали, какие уровни управления и контроля существуют в корпоративной системе управления проектами (КСУП), какие между ними есть различия и какими принципами руководствоваться при выборе инструментов мониторинга для вашей компании. Сегодня остановимся на том, как подготовить стартовый набор инструментов, который бы запускал корректные процессы контроля в организации. И заострим внимание на тех объектах и процессах, которые подлежат контролю на каждом уровне управления.
Елена Филипова, руководитель корпоративного Проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Managment Institute, квалификация Project Managment Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»
Стартовая система контроля, которая работает
При создании КСУП важно правильно подготовить стартовый набор инструментов и методов, который бы запускал корректные процессы управления. Персонал еще может быть не готов к использованию инструментов системы. В частности, ИСУП запустили в тестовом режиме, методология слаба и не обкатана, организационные структуры не доказали свою эффективность – все это вполне обычная ситуация для старта КСУП. При этом контроль как никогда важен и для помощи участникам системы, и для принятия необходимых решений руководством. Так как же это организовать? Предлагаю воспользоваться довольно простым набором процессов мониторинга и контроля, который годами доказывает свою эффективность при старте управления проектами.
Все эти процессы могут контролироваться в компании и до появления элементов КСУП. Вне зависимости от наличия проектов в организации проверяется исполнение поручений по важным решениям, проходят обязательные совещания, ведется отчетность по основным результатам деятельности, распределяются дефицитные ресурсы. Но для КСУП важно связать эти элементы на всех трех уровнях, чтобы данные служили друг другу и обеспечивали сквозное проникновение информации и соответствующих решений. Например, контроль коммуникаций на уровне проекта должен обеспечивать корректные показатели для принятия решений на уровне программы. А итоги совещаний на уровне программы должны формировать данные для топ-менеджмента уровня портфеля. В обратную сторону также: установка новой стратегической цели порождает создание новых программ, отмену или корректировку существующих, а модернизация программ неизбежно ведет к серьезным изменениям в управлении проектами, в частности, смене состава контрольных точек проекта, вплоть до остановки проектов или срочного нового старта.
Определим главные элементы контроля каждого уровня.
1. Уровень проекта. Контроль проекта – это, прежде всего, контроль получения результатов во всех его проявлениях. Основными шагами достижения результата являются несколько ключевых процессов управления, которые и необходимо контролировать:
Что подлежит контролю? Примеры:
Поскольку мы говорим о старте, то контроль должен быть частый, постоянный и не очень строгий. На этом уровне речь идет об управлении людьми, конкретными проектными командами, которые составляют основу КСУП, поэтому очень важно, чтобы они приняли принципы системного управления проектами и поддержали новые инструменты и методы. Такой подход обеспечивается самим построением процессов управления. Например, чтобы постоянно контролировать качество подготовки Устава, необходимо указать, что этот документ может быть подписан только после согласования с Проектным офисом. Этот же подход может применяться и для контроля качества подготовки плана контрольных точек, коммуникаций, изменений и т.п. Все необходимые документы, качество которых критично для управления проектом и которые играют ключевую роль в методологии, должны обязательно проверяться, корректироваться и разъясняться специалистами Проектного офиса. Со своей стороны, ПрОф не должен выступать в роли полицейского, а быть, скорее, консультантом, соратником и путеводителем Руководителей проектов в новом мире. В своей практике я всегда обязывала сотрудников Проектного офиса предоставлять необходимые шаблоны, регламенты, прототипы, примеры заполнений и материалы аналоговых проектов для ускорения подготовки нужных данных. Кроме того, именно ПрОф обязан самостоятельно направлять готовые документы по процессам управления и информировать участников проектов по итогам принятых решений. Таким образом, управление проектами сможет встать на новые рельсы, не создавая систему штрафов и наказаний, будет обучать участников проектной деятельности и мягко корректировать существующие методы.
2. Уровень программы проектов. Здесь, прежде всего, важно выстроить контроль получения выгод и достижения целей. Это обеспечивается своевременным запуском проектов и других элементов программы, а также мониторингом использования результатов проектов и их применимости в бизнесе.
На уровне программы осуществляется контроль:
На этом уровне, как нигде, важно соблюдать регулярность выполнения мониторинга. Систематически проверять, как выполняется план: какие проекты завершены, какие в реализации и старт каких только ожидается. По выполненным проектам регулярно, не реже одного раза в квартал, проверять, насколько достигнуты ожидаемые выгоды, какие тренды окупаемости зафиксированы, планово ли используются полученные результаты. Кроме того, следить за выполнением решений, принятых на основе данных контроля, и распространять информацию об этих решениях на уровень проектов.
3. Уровень портфеля проектов. На этом шаге важно понимать, достигает ли ваша организация своих стратегических целей, выполняет ли свою миссию. На языке КСУП это означает, что необходимо регулярно пересматривать стратегический план, готовить решения о требуемых шагах для получения необходимой ценности бизнеса, запускать новые программы и проекты или прекращать, если это целесообразно.
Важно, чтобы все решения, которые касаются более низких уровней, были своевременно доведены до соответствующих заинтересованных сторон. Например, Руководители проектов должны понимать видение топ-менеджмента, угрозы и возможности, которые являются причинами стратегических изменений в управлении. Тогда сотрудники организации будут более лояльны к руководству, а выполнение проектов будет соответствовать решению высокоуровневых задач.
Уровень портфеля поддерживает контроль:
Ценность рассмотренного подхода для построения системы мониторинга и контроля проектов в том, что такая система заранее определена по основным точкам и нацелена на получение главных результатов и целей. При этом, поскольку она многоуровневая и целостная, данные контрольных измерений одного уровня неизбежно влияют на другие. Эта взаимосвязь обеспечивает логику настройки, способность гибко менять инструменты согласно преобразованиям самой КСУП и росту зрелости организации, а также предоставлять своевременную информацию для качественного управления на всех уровнях. Точек контроля немного, но достаточно для принятия необходимых решений.
Не стоит искусственно наращивать систему дополнительными элементами, а сосредоточиться только на необходимых бизнесу показателях, для которых есть четкое понимание использования. Прежде, чем создавать еще один вид контроля – проверку, аудит, отчет – подумайте и убедитесь в такой необходимости. На моей практике было немало руководителей, которые требовали все больше контроля и отчетов, но при этом совершенно не пользовались этими данными, утяжеляя систему и усложняя жизнь простых исполнителей. Опираясь же на минимальный набор эффективно работающих процессов для управления и контроля, вы даже на старте КСУП сможете ориентировать их на достижение ваших целей.