В чем заключается сложность мониторинга результатов

Мониторинг результатов и совершенствование системы управления риском

Этап мониторинга результатов и совершенствования системы управле­ния риском обеспечивает обратную связь в указанной системе. Это очень важный этап, так как именно он обеспечивает гибкость и адаптивность управления риском, а также динамический характер этого процесса.

В рамках данного этапа менеджер по управлению риском должен отве­тить на следующие вопросы:

Следует ли считать систему управления риском эффективной? Каким образом пррявлялись ее узкие места?

Какие факторы повлияли на реализацию рисков за рассматриваемый период? Следует ли в связи с этим внести изменения в систему управления риском?

Все ли мероприятия, включенные в программу управления риском, сыграли свою роль в защите от неблагоприятных событий? Не следует ли заменить какие-либо меры более эффективными?

Была ли система принятия решений относительно управления риском достаточно гибкой? Не препятствовала ли она защите фирмы от риска?

‘На данном этапе прежде всего происходит обновление и пополнение информации о рисках, что является важным условием анализа рисков на первом этапе. Более полные свежие данные позволяют принимать адек­ватные и своевременные решения об управлении риском. На этой основе осуществляется оценка эффективности проведенных мероприятий. Сложность подобной оценки состоит в том, что в течение анализируемого периода риски могут не реализоваться, тогда как фирма все равно несет расходы на программу управления рисками. Поэтому час­то приходится сопоставлять реальные расходы с гипотетическими поте­рями.

Целью оценки эффективности проведенных мероприятий является адаптация системы управления риском к изменению условий функциони­рования окружающей среды и совокупности влияющих на фирму рисков. Это происходит прежде всего за счет следующих направлений:

►замены неэффективных мероприятий более эффективными в рамках выделенного бюджета на программу управления риском. Такие ме­роприятия повышают общую результативность системы управления риском;

►изменения организации выполнения программы управления риском. Так как она определяет специфику институционального фундамента защиты фирмы от соответствующих рисков, ее изменение также мо­жет способствовать росту эффективности системы управления рис­ком на уровне фирмы.

Взаимосвязи между этапами управления риском

Как уже подчеркивалось, рассмотренные этапы не обязательно реали­зуются последовательно: соответствующие мероприятия могут осуществ­ляться параллельно, возможен возврат к предыдущим этапам и т.д. Поэто­му необходимо дополнительно проанализировать логические связи между этапами (рис. 3.2).

Рис. 3.2. Логические связи между этапами управления риском

Прежде всего, существуют связи, задающие естественный порядок ме­жду этапами. Они отражают логику процесса управления риском. Однако нельзя ограничиться только ими. В частности, существуют обратные свя­зи, означающие, что имеется возможность возврата на предыдущий этап, если в результате последующего принятия решений будут выявлены важ­ные факторы, которые не были учтены ранее. Кроме того, как уже говори­лось, на этапе 5 проводится анализ всего процесса управления риском, поэтому его результаты и новая информация должны быть учтены при принятии решений на будущее (нижние стрелки на рис. 3.2). Этап 3 также занимает особое место, так как именно на нем принимается решение о со­ставе и особенностях используемых методов управления риском. Это мо­жет потребовать уточнения информации о рисках (переход на этап 1) и за­дать ограничения для процесса мониторинга и оценки эффективности (стрелка к этапу 5).

Таким образом, процесс управления риском является достаточно слож­ным как по содержанию принимаемых и реализуемых решений так и по наличию системы развитых внутренних взаимосвязей. Это определяет сложность риск-менеджмента, его относительную обособленность как сферы деятельности менеджеров и специфику принимаемых в его рамках решении.

Источник

Мониторинг как способ контроля

Обеспечить безопасность финансово–хозяйственной деятельности, сохранность активов и законность хозяйственной деятельности в условиях экономической нестабильности достаточно сложно. Контроль, наряду с планированием, учетом и анализом хозяйственной деятельности, является составляющей управления любым хозяйствующим субъектом. Руководству организации важно оперативно контролировать ход хозяйственных процессов, эффективно управлять имуществом, предупреждать негативные явления, увеличивать доходы и снижать расходы, что обусловливает необходимость получения качественной информации о функционировании ее различных подразделений и филиалов. Как правило, в поле действия функции контроля попадают отрицательные отклонения тех или иных частей управляемого объекта от заданных параметров. В общей системе управления контролируются состояние и использование финансовых и материальных ресурсов, технологические процессы производства продукции и ее реализация.

Органы государственного управления принимают участие в деятельности субъектов предпринимательской деятельности, в том числе в сфере деятельности индивидуальных предпринимателей. При этом высокий государственный контроль снижает их деловую активность, способствует регрессу сферы услуг и предпринимательской деятельности. Дабы исключить такие инциденты, государство приняло курс сокращения количества проверок и уделяет больше внимания профилактической работе. Надзорные действия проводят посредством мониторинга. Само понятие «мониторинг» представляет собой процесс, предусматривающий непрерывный анализ и оценку соответствия нормам. Он осуществляется практически во всех областях деятельности.

Понятие мониторинга

В широком смысле мониторингом является форма контроля (надзора), заключающегося в наблюдении, анализе, оценке, установлении причинно– следственных связей, применяемая контролирующими (надзорными) органами в целях оперативной оценки фактического состояния объектов и условий деятельности субъекта мониторинга на предмет соответствия требованиям законодательства, выявления и предотвращения причин и условий, способствующих совершению нарушений, без использования полномочий, предоставленных контролирующим (надзорным) органам и их должностным лицам для проведения проверок. Решение о проведении мониторинга принимается руководителем контролирующего органа (в том числе территориальных органов, структурных подразделений, подчиненных организаций) или его уполномоченным заместителем, а также руководителем самой организации. Непрерывный мониторинг также является частью обычной деятельности по управлению хозяйствующим субъектом в форме постоянного руководства. У многих организаций участие в мероприятиях по мониторингу принимают внутренние аудиторы или сотрудники, выполняющие аналогичные функции.

Порядок проведения мониторинга

Перед проведением мониторинга определяется область, участок, который впоследствии будут контролировать, а также цели и задачи. Стоит определиться, что полученная информация даст впоследствии и какие меры можно приять по улучшению деятельности. Помимо вышеперечисленного нужно определиться с источниками информации и способами их получения. Некоторые источники находятся на просторах интернета в общем доступе, средствах массовой информации, в то время, как к другим имеют доступ только ограниченный круг лиц и необходимо отправлять запросы для их получения. Нужно тщательно отбирать источники. Но чем больше их будет, тем полнее и достовернее станет мониторинг. Аналогично ситуация обстоит и с территорией, попадающей под мониторинг. Должностные лица контролирующих (надзорных) органов, аудиторы вправе входить на общедоступную территорию и объекты аудируемых лиц при проведении мониторинга. В другом случае – с согласия субъекта, использовать доступные средства глобальной компьютерной сети интернет, видео– и телекоммуникационные ресурсы дистанционного контроля (надзора).

Виды мониторинга

Независимо от преследуемых целей и поставленных задач, мониторинг может быть, как внутренним, так и внешним. Он может быть организован собственными силами организации или с привлечением независимых лиц: законодательная и исполнительная власть, аудиторские организации, представители общественных организаций.

Для обобщения информации целесообразно составлять таблицу, в которую впоследствии будут заносить данные, полученные в ходе проведения мониторинга. В таблице стоит указывать источник, из которого была получена информация, дату, результат. Процесс сбора информации должен быть оперативным, а полученная информация незамедлительно заноситься в таблицу. Чем более детально будет описан процесс проведения мониторинга, тем достовернее будет полученная информация. Сводный анализ будет более точным, своевременным, удобным для чтения и понимания при использовании данного метода. Мониторинг может быть, как долгосрочным, так и краткосрочным в зависимости от объекта. Его продолжительность может занять день или месяцы, а то и годы.

Оформление результатов мониторинга

По итогам проведения мониторинга, при обнаружении отклонений, не создающих угрозу национальной безопасности, причинения вреда жизни и здоровью населения, окружающей среде, финансово–хозяйственной деятельности предписывают рекомендации по устранению и недопущению недостатков, выявленных по его результатам. При добровольном устранении нарушений не будут назначаться внеплановая проверка и применяться меры ответственности к субъекту и его должностным лицам, за исключением случаев повторного выявления нарушений. В случае не устранения нарушений и отклонения от предписания может быть назначена и организована внеплановая проверка. При выявлении отклонений или нарушений, создающих угрозу национальной безопасности, причинения вреда жизни и здоровью населения, окружающей среде, выносится требование или предписание о приостановлении или запрете деятельности субъекта.

Стоит отметить, что в соответствии с действующими в Республике Беларусь нормативно–правовыми документами, мониторинг не является одним из видов проверок, а значит не предусмотрено ограничений по количеству проведения мониторингов одного субъекта. Данное мероприятие является профилактическим, благодаря чему существенно экономит государственный бюджет и стимулирует развитие бизнеса во всех сферах.

Таким образом, использование и развитие мониторинга в Республике Беларусь будет способствовать стабилизации экономической ситуации и стимулированию деловой активности субъектов предпринимательской деятельности.

Источник

Этап 5. Мониторинг результатов и совершенствование системы управления риском

Этап мониторинга результатов и совершенствования системы управле­ния риском обеспечивает обратную связь в указанной системе. Это очень важный этап, так как именно он обеспечивает гибкость и адаптивность управления риском, а также динамический характер этого процесса.

В рамках данного этапа менеджер по управлению риском должен отве­тить на следующие вопросы:

Следует ли считать систему управления риском эффективной? Каким образом пррявлялись ее узкие места?

Какие факторы повлияли на реализацию рисков за рассматриваемый период? Следует ли в связи с этим внести изменения в систему управления риском?

Все ли мероприятия, включенные в программу управления риском, сыграли свою роль в защите от неблагоприятных событий? Не следует ли заменить какие-либо меры более эффективными?

Была ли система принятия решений относительно управления риском достаточно гибкой? Не препятствовала ли она защите фирмы от риска?

‘На данном этапе прежде всего происходит обновление и пополнение информации о рисках, что является важным условием анализа рисков на первом этапе. Более полные свежие данные позволяют принимать адек­ватные и своевременные решения об управлении риском.

На этой основе осуществляется оценка эффективности проведенных мероприятий. Сложность подобной оценки состоит в том, что в течение анализируемого периода риски могут не реализоваться, тогда как фирма все равно несет расходы на программу управления рисками. Поэтому час­то приходится сопоставлять реальные расходы с гипотетическими потерями.

Целью оценки эффективности проведенных мероприятий является адаптация системы управления риском к изменению условий функциони­рования окружающей среды и совокупности влияющих на фирму рисков. Это происходит прежде всего за счет следующих направлений:

►замены неэффективных мероприятий более эффективными в рамках выделенного бюджета на программу управления риском.

изменения организации выполнения программы управления риском. Так как она определяет специфику институционального фундамента защиты фирмы от соответствующих рисков, ее изменение также может способствовать росту эффективности системы управления риском на уровне фирмы.

Принципы информационного обеспечения системы управления риском

Информация является ключевым аспектом при идентификации и ана­лизе риска, так как ее наличие позволяет в дальнейшем принимать пра­вильные решения в условиях риска и неопределенности. Объем и содержа­ние необходимой информации зависят от конкретных условий, но они должны определяться рядом важных принципов.

Полезность информации. Принцип полезности состоит в том, что для принятия решений необходимо использовать лишь ту информацию, кото­рая действительно необходима для этого. Получение избыточной (излиш­ней) информации означает непроизводительную растрату ресурсов.

Эффективность управления риском. Принцип эффективности пред­ставляет собой требование, согласно которому затраты на управление рис­ком (включая стоимость получаемой для этого информации) не должны превышать эффект от снижения риска и его неблагоприятных последствий. Это, в частности, означает, что следует учитывать ограничения на затраты, связанные с получением информации.

Доступность информации. Принцип доступности информации подра­зумевает учет простоты ее получения. При этом не следует путать доступ­ность с дешевизной информации: первое является характеристикой нали­чия данных и связано с исследованием источников информации, а второе относится к количеству ресурсов (в первую очередь финансовых), которые нужно потратить на получение соответствующей информации.

Достоверность информации. Принцип достоверности заключается в учете степени доверия к тем или иным источникам информации при их использовании для анализа рисков. Понятно, что данные, характеризую­щиеся низкой степенью доверия, должны в меньшей степени влиять на процесс принятия решений или даже быть полностью исключены из этого процесса. Последнее, правда, не всегда целесообразно, так как в условиях дефицита информации некоторые полезные сведения можно получить даже из не вполне достоверных источников.

Указанные принципы отчасти являются противоречивыми. Например, принцип доступности информации может-не согласовываться с принципом полезности или достоверности, так как имеющаяся в наличии информация не обязана содержать сведения, необходимые для принятия решения по управлению риском. Таким образом, источники информации и посту­пающие из них сведения должны быть предварительно проанализированы на соответствие указанным принципам, причем такой анализ должен быть комплексным. Целью анализа является достижение такой ситуации со сбо­ром и обработкой данных, для которой характерен определенный компро­мисс между перечисленными принципами.

Источник

Организация системы мониторинга

Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.

За последние несколько лет поменялась сама парадигма мониторинга. Новая эра уже наступила, и если сейчас вы мониторите инфраструктуру как набор серверов — вы не мониторите почти ничего. Потому что теперь «инфраструктура» — это многоуровневая архитектура, и для мониторинга каждого уровня есть свои инструменты.

Кроме проблем типа «упал сервер», «надо заменить винт в рейде», теперь надо понимать проблемы уровня приложения и уровня бизнеса: «взаимодействие с микросервисом таким-то замедлилось», «в очереди слишком мало сообщений для текущего времени», «время выполнения запросов к бд в приложении растет, запросы — такие-то».

У нас на поддержке около пяти тысяч серверов, в самых разных конфигурациях: от систем из трех серверов с кастомными докеровскими сетками, до больших проектов с сотнями серверов в Kubernetes. И за всем этим надо как-то следить, вовремя понимать, что что-то сломалось и быстро чинить. Для этого надо понять что такое мониторинг, как он строится в современных реалиях, как его проектировать и что он должен делать. Об этом и хотелось бы рассказать.

Как было раньше

Лет десять назад мониторинг был гораздо проще, чем сейчас. Впрочем, и приложения были попроще.

Мониторились, в основном, системные показатели: CPU, память, диски, сеть. Этого вполне хватало, потому что там крутилось одно приложение на php, и ничего больше не использовалось. Проблема в том, что по таким показателям обычно мало что можно сказать. Либо работает, либо нет. Что именно происходит с самим приложением, выше уровня системных показателей понять сложно.

Если проблема была на уровне приложения (не просто “сайт не работает”, а “сайт работает, но что-то не так”), то клиент сам писал или звонил, сообщал, что есть такая-то проблема, мы шли и разбирались, потому что сами мы такие проблемы заметить не могли.

Как сейчас

Сейчас совсем другие системы: с масштабированием, с автоскейлингом, микросервисы, докеры. Системы стали динамичными. Часто никто толком не знает, как именно все работает, на скольких серверах, как именно оно развернуто. Оно живет своей жизнью. Иногда даже неизвестно, что и где запущено (если это Kubernetes, например).

Усложнение самих систем, конечно, повлекло за собой большее количество возможных проблем. Появились метрики приложений, количество запущенных тредов у Java application, частота garbage collector pauses, количество событий в очереди. Очень важно, чтобы мониторинг также следил за масштабированием систем. Допустим, у вас Kubernetes HPA. Надо понимать, сколько запущено подов, и с каждого запущенного пода должны идти метрики в систему мониторинга приложения, в apm.

Все это нужно мониторить, потому что все это отражается на работе системы.
И сами проблемы стали менее очевидными.

Условно, проблемы можно поделить на две большие группы:
Проблемы первого рода – не работает основная, “пользовательская функциональность”.
Проблемы второго рода – что-то работает не так, как должно, и может куда-то не туда привести.

То есть теперь надо мониторить не только дискретное “работает/не работает”, а гораздо больше градаций. Что, в свою очередь, позволяет ловить проблему до того, как все рухнет.

Кроме того, теперь надо следить и за бизнес-показателями. Бизнес захотел иметь графики о деньгах, о том как часто идут заказы, сколько времени прошло с последнего заказа и так далее — это теперь тоже задача мониторинга.

Правильный мониторинг

Проектирование и вообще

Представление о том, что именно надо будет мониторить, должно быть заложено в момент разработки приложения и архитектуры, и речь даже не столько про серверную архитектуру, сколько про архитектуру приложения в целом.

Разработчики/архитекторы должны понимать какие части системы критичны для функционирования проекта и бизнеса, и заранее думать о том, что их работоспобность надо проверять.

Мониторинг должен быть удобным для админа, и давать представление о том, что происходит. Цель мониторинга – вовремя получить оповещение, по графикам быстро понять, что именно происходит и что именно нужно чинить.

Метрики и оповещения (алерты)

Алерты должны быть максимально понятными: админ, получив алерт, даже если он не знаком с системой, должен понять, о чем этот алерт, в какую документацию смотреть, или хотя бы кому позвонить. Должны быть четкие инструкции, что именно нужно делать, и как именно решать проблему.

Когда возникает проблема, очень хочется понять, из-за чего она возникла. Получая алерт о том, что у вас не работает приложение, вам очень хотелось бы знать, какие еще смежные системы ведут себя не так, какие еще есть отклонения от нормы. Должны быть понятные графики, собранные в дашборды, из которых сразу будет видно, где отклонение.

Для этого надо точно понимать, что нормально, а что не нормально. То есть должна быть достаточная историческая справка о состоянии системы. Задача заключается в том, чтобы покрыть алертами все возможные отклонения от нормы.

Когда админ получает алерт, он либо должен знать что с ним делать, либо кого спросить. Должна быть инструкция как именно нужно реагировать, и ее надо регулярно обновлять. Если у вас все работает через систему оркестрирования, то, наверное, у вас все хорошо, если все изменения происходят только через нее, в том числе и мониторинг. Система оркестрирования позволяет адекватно следить за актуальностью мониторинга.

Мониторинг должен расширяться после каждой аварии — если внезапно возникла какая-то проблема, которая проскочила мимо мониторинга, то, очевидно, надо замониторить эту ситуацию, чтобы в следующий раз проблема не была внезапной.

Бизнес-показатели

Полезно мониторить время с последней продажи, количество продаж за период. Если выложили релиз, то что изменилось: есть ли просадки по бизнес-показателям? На это отвечает, конечно, A/B тестирование, но графики тоже хотелось бы иметь. И надо мониторить действия конечного пользователя: писать скрипты на phantomjs, которые повторяют покупку, проходят по всем этапам основного бизнес-процесса.

Также вам, наверное, интересно знать, работает ли сервис логистики, или не свалился ли в очередной раз IpGeoBase. (Комментарий редактора: IpGeoBase — сервис, который использует большое число интернет-магазинов на 1С-Битрикс для определения местоположения пользователя. Чаще всего это делается непосредственно в коде загрузки страницы, и когда падает IpGeoBase — у нас перестают отвечать десятки сайтов. Кто-нибудь пожалуйста, скажите программистам, что это надо обрабатывать и делать таймаут, и кто-нибудь — пожалуйста попросите IpGeoBase не падать).

Нужно понимать, зависит ли просадка по бизнес-показателям от вашей системы, или от внешней.

Мониторинг мониторинга

Сам мониторинг тоже должен хоть как-то мониториться. Должен быть какой-то внешний кастомный скрипт, который будет проверять, что мониторинг работает нормально. Никому не хочется проснуться от звонка, потому что ваша система мониторинга упала вместе со всем дата-центром, и вам об этом никто не сказал.

Основные инструменты

В современных системах, которые масштабируются, у вас наверняка используется Prometheus, потому что аналогов в принципе нет. Для того, чтобы просматривать удобные графики от Prometheus нужна Grafana, потому что в Prometheus графики так себе. Нужен также какой-то APM. Либо это самописная система на Open Trace, jaeger и или что-то подобное. Но это редко кто делает. В основном используется либо New Relic, либо специфичные системы для стеков, типа Dripstat. Если у вас не одна система мониторинга, не один Zabbix, вам еще нужно понимать, как собирать эти метрики, и как раздавать алерты; кого оповещать, кого поднимать, в каком порядке, к кому какой алерт относится, и что с ним вообще делать.

Zabbix — не самая удобная система. Есть проблемы с кастомными метриками, особенно, если система масштабируется, и вам нужно определить роли. И хотя можно строить очень кастомные графики, алерты и дашборды, все это не очень неудобно и нединамично. Это статичная система мониторинга.

Prometheus — отличное решение для сборки огромного количества метрик. У него примерно те же возможности, что у Zabbix по кастомным алертам. Можно выводить графики и строить алерты по любым диким сочетаниям нескольких параметров. И это все очень здорово, но очень неудобно смотреть, поэтому к нему добавляется Grafana. Grafana очень красивая. Но сама по себе не очень помогает для мониторинга систем. Зато по ней удобно все читать. Лучше графиков, наверное, и нет.

ELK и Graylog — для сбора логов по событиям в приложении. Может быть полезно для разработчиков, но для подробной аналитики обычно не достаточно.

New Relic — APM, тоже полезный для разработчиков. Есть возможность понять, когда у вас в приложении прямо сейчас что-то идет не так. Понятно, какие из внешних сервисов не очень хорошо работают, или какая из баз медленно отвечает, либо какое системное взаимодействие просаживается.

Свой APM — если вы написали свою систему на Open Tracing, zipkin или jaeger, то, наверное, вы знаете, как именно это должно работать, и что именно, и в какой части кода идет не так. New Relic тоже позволяет это понять, но это не всегда удобно.

Заключение

О том какие показатели надо мониторить лучше думать в время проектирования системы, заранее подумать о том какие части системы критичны для ее работы и о том, как проверять их работу.
Алертов не должно быть слишком много, алерты должны быть актуальными. Должно быть сразу понятно, что сломалось и как это чинить.
Чтобы правильно замониторить бизнес-показатели, надо понять как устроены бизнес процессы, что нужно вашим аналитикам, хватает ли инструментов чтобы замерить нужные показатели, и как быстро можно узнать, если что-то пойдет не так.

В следующем посте мы расскажем как правильно спланировать мониторинг современной инфраструктуры, на всех уровнях: на уровнях системы, приложений и бизнеса.

Источник