Мониторинг и наблюдаемость: как эффективно управлять критичной ИТ-инфраструктурой бизнеса
Мониторинг и наблюдаемость ИТ-ландшафта: в чем разница
Между классическими системами мониторинга и наблюдаемости есть принципиальное различие: последние определяют способность компании видеть реальную картину происходящего. Если традиционные инструменты мониторинга отвечают на вопрос, что сломалось, то платформы наблюдаемости позволяют понять, как именно и почему произошел сбой, где возникла ошибка и как она повлияла на сквозной бизнес-процесс.
Основой для такого анализа становится телеметрия — метрики, журналы, события и трассировки, которые собираются из разных компонентов ИТ-ландшафта и позволяют связать технические сигналы с состоянием сервисов.
При этом частота сбоев, время, затраченное ИТ-службой на их устранение, и реакция пользователей на возникающие проблемы являются важными сигналами для принятия решения о внедрении инструментов или их модификации.
Участники рынка подчеркивают, что на разных стадиях развития компании могут сталкиваться с ограничениями, связанными с применением систем мониторинга и наблюдаемости.
Первое — проблема "зеленой панели управления". Она встречается в организациях, которые еще недостаточно зрелые или которые уже начали активный рост и фокусируются в основном на инфраструктурной части. Для этого чаще всего используются системы мониторинга, но безупречные показатели инфраструктуры не гарантируют, что пользователи не сталкиваются со сбоями. Когда ИТ-команды мыслят в основном категориями серверов и сетей, ошибки в бизнес-логике могут оставаться незамеченными: инфраструктура работает штатно, но приложение дает сбои. Тогда в дело вступают современные платформы наблюдаемости: они помогают смотреть гораздо глубже в программный код и отслеживать состояние каждой отдельной пользовательской транзакции.
Вторая крайность — "красная панель управления", когда из-за избытка данных становится сложно выделить важные сигналы. По словам руководителя отдела интеллектуальных платформ компании "ЛАНИТ-проекты" Максима Гречнева, на первых этапах внедрения платформы наблюдаемости нередко оказываются перегружены метриками, уведомлениями об ошибках и данными, которые собирают различные инструменты: "Получается, что панель управления все время красная, мигает — непонятно, что действительно является проблемой, или ее вовсе нет, — рассказывает эксперт. — Поэтому, чтобы перейти к полноценной наблюдаемости, нужно строить внутреннюю систему аналитики и корреляции собираемых данных".
Здесь в том числе помогают механизмы ИИ и машинного обучения — они позволяют определять аномалии в каждой метрике с учетом сезонности, времени суток, а также автоматически строить цепочки зависимостей возникающих событий.
Проактивный мониторинг и ресурсно-сервисная модель
Выбор инструментов зависит от архитектуры системы и зрелости бизнес-процессов. Классический мониторинг подходит для контроля доступности оборудования в относительно статичной инфраструктуре. Максим Гречнев отмечает, что при разделении крупной системы на десятки независимых компонентов, за которые отвечают разные команды, транзакции становятся распределенными. На первый план выходят время взаимодействия между компонентами и сетевые задержки, а загрузка процессоров становится менее значимым показателем.
Руководитель отдела автоматизации инфраструктуры и аналитики данных ЛАНИТ Сергей Дмитриев поясняет, что в распределенной среде один сбой может вызвать множество уведомлений на разных уровнях — от серверов до приложений. Корреляция событий учитывает время возникновения инцидента, топологию зависимостей с учетом весовых коэффициентов сервисов. Поэтому система понимает, какие сигналы являются следствием одной проблемы.
Эксперт также добавляет, что проанализировать ранние признаки деградации, а не только уже случившиеся отказы можно и в проактивном режиме. Среди них — рост задержек, накопление очередей, ухудшение производительности отдельных узлов или изменение нормального профиля нагрузки.
Увидеть проблемы до их фиксации в случаях, когда сбои могут затрагивать несколько сервисов, также помогает ресурсно-сервисная модель, рассказывает Сергей Дмитриев. Это карта зависимостей, которая позволяет оценить взаимное влияние компонентов ИТ-ландшафта. Она показывает, как конкретные серверы, виртуальные машины, сети, базы данных и другие компоненты влияют на конечные цифровые сервисы компании.
Системы наблюдаемости и поиск "слепых зон"
Современные системы наблюдаемости решают сложные инженерные задачи и помогают бизнесу снижать риск простоев. Наблюдаемость дает сквозное понимание взаимосвязей между инфраструктурой, приложениями, интеграциями и бизнес-процессами, поэтому помогает быстрее находить первопричины инцидентов.
Обеспечение высокого уровня наблюдаемости инфраструктуры информационных систем позволяет снизить риски сбоев и информационных багов до использования систем в промышленной эксплуатации. Особое внимание уделяется устранению "слепых зон": при внедрении нового оборудования или миграции инфраструктуры компании нередко сталкиваются с тем, что не все элементы ИТ-среды остаются доступными для контроля.
"Современная платформа наблюдаемости должна не только опираться на заранее построенную модель, но и уметь выявлять новые элементы по журналу событий, метрикам, трассировкам и сетевым взаимодействиям. В случае отсутствия сбора данных с новой системы косвенные признаки проблем можно отслеживать при помощи поиска аномалий в данных. Наиболее подходящими данными для такого анализа будут трассировки, при помощи которых можно отследить обращения к сервисам от новых неподключенных систем", — объясняет Сергей Дмитриев.
Эксперт подчеркивает, что качество наблюдаемости необходимо проверять на этапе разработки. Во время хаос-тестирования инженеры убеждаются, что собранные метрики помогут определить первопричину сбоя. Для снижения риска ошибок при настройке также применяются практики GitOps (подход к управлению ИТ-инфраструктурой, при котором Git-репозиторий служит единым источником достоверной конфигурации — прим. ТАСС).
Спикер отмечает, что наибольшую ценность компаниям приносит единый контур мониторинга и наблюдаемости: корреляция событий, ресурсно-сервисная модель и "умные алерты" (интеллектуальные оповещения), которые нужны для того, чтобы отделять первопричину от множества вторичных сигналов.
Бюджет ошибок
Показатели наблюдаемости могут стать одним из аргументов при распределении бюджетов между ИТ-командой и бизнес-заказчиком. Инструменты наблюдаемости помогают связывать бизнес-метрики с техническими метриками, показывая, как они друг на друга влияют. Это позволяет провести более глубокую аналитику, получить представление о стоимости ошибки или сбоя, чтобы сделать вывод о том, сколько денег компания может сэкономить и сколько может не потерять, если улучшить какую-то техническую метрику, рассказывает Максим Гречнев.
Достаточно распространенной практикой в компаниях является так называемый "бюджет ошибок", добавляет эксперт: "Современная команда, отвечающая за работоспособность бизнес-системы, состоит не только из технических специалистов — в нее также входят представители бизнеса, инженеры по эксплуатации. Таким образом, она является диверсифицированной, а бюджет бизнеса и бюджет ИТ объединяются. При этом задачи различаются".
Практика показывает, что большинство ошибок и сбоев в работе систем связаны с появлением нового функционала. Когда в большой системе что-то меняется, чаще всего это вызывает какие-то проблемы, добавляет спикер. Смысл "бюджета ошибок" в том, что для конкретной команды определяется уровень качества или доступности их систем. А "бюджет ошибок" выступает противоположной величиной: чем выше уровень качества, тем меньше он израсходован. Когда "бюджет ошибок" за какой-то период у команды заканчивается, все изменения останавливаются: бизнес перестает генерировать новый функционал, все ресурсы переключаются на ИТ-функционал, на повышение доступности и надежности систем.
Пример единого контура мониторинга
В одном из проектов специалисты ЛАНИТ объединили в единый контур данные по инфраструктуре, приложениям и процессам, чтобы связать технические события с состоянием бизнес-сервисов и перейти от реактивного реагирования к проактивному управлению устойчивостью.
Заказчиком выступила крупная компания с распределенной ИТ-инфраструктурой и критичными цифровыми сервисами. Для нее команда спроектировала многоуровневую систему на базе отечественного ПО и решений с открытым исходным кодом.
В единое "озеро данных" были сведены метрики, журналы и события из разных контуров — от инфраструктурного слоя до прикладных систем. Далее были настроены механизмы автоматического выявления отклонений, правила корреляции событий и интеллектуальные оповещения. Это помогло отфильтровать информационный шум и выделить критически важные инциденты.
Отдельной задачей стало создание единого контура мониторинга с консолидированным представлением данных и визуальным контролем состояния ИТ-сервисов в режиме реального времени. Для этого была интегрирована система визуализации, обеспечивающая минимальное время отклика при отображении данных, а также возможность удобного редактирования панелей управления под задачи разных ролей.
Специалистами ЛАНИТ была разработана ресурсно-сервисная модель и аналитические панели с консолидированным представлением о состоянии сервисов и инструментами быстрого анализа причин отклонений.
В результате заказчик получил инструмент проактивного управления устойчивостью ИТ-сервисов, который значительно сократил число избыточных уведомлений для дежурных инженеров и время поиска причин инцидентов. За счет ресурсно-сервисного подхода компания смогла видеть не только состояние отдельных систем, но и их влияние на конечные сервисы.
Вывод
Мониторинг и наблюдаемость — не взаимозаменяемые, а взаимодополняющие подходы. Их оптимальное сочетание каждая компания определяет с учетом используемых инструментов, частоты и продолжительности инцидентов, а также времени, за которое сбой становится заметен пользователям.
Грамотная комбинация этих практик позволяет перейти от реагирования на проблемы к их предупреждению и сделать эксплуатацию ИТ-систем более устойчивой.
