Проблема наблюдаемости (observability) возникает во всех организациях. Я помогу вам научиться не на своих, а на моих ошибках, подскажу, как обойти грабли и подводные камни. Здесь вы найдёте подборку антипаттернов, которая поможет избежать проблем в будущем.

Меня зовут Кирилл Борисов, я в IT около 13 лет. Создавал DevOps-процессы и инфраструктуру в больших проектах, руководил группой сопровождения. Сейчас SRE-инженер в VK, в проекте VK Реклама.

Что такое наблюдаемость

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

Наблюдаемость держится на трёх столпах: метриках, журналах и трассировках. 

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

Журналы (логи) — это как раз статистика о работе системы: информация об ошибках, предупреждениях и других событиях. Так мы можем понять, что происходит с нашей системой. 

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

Антипаттерны

В интернете есть множество инструкций, как правильно создать ту или иную систему. Но все мы люди, и нам интереснее учиться на ошибках — своих и чужих. Поэтому свой рассказ я сделал в формате антипаттернов: как делать НЕ нужно. Надеюсь, у вас получится всё гораздо лучше, чем сначала получалось у меня. 

Примечание: все персонажи вымышленные, и любое совпадение с реальностью — это случайность. 

История первая

Пятница вечер, вы отдыхаете и уже готовитесь к субботе. И тут приходит письмо от руководства: «Уважаемая команда эксплуатации, с понедельника вы начинаете внедрение нового инструмента мониторинга, ну или наблюдаемости. В общем, вот вам инструкция и вендор». При этом вы понимаете, что не готовы к этому инструменту. 

Это первый антипаттерн — «Навязанный инструмент», который вам спустили сверху. Какие могут быть последствия? 

• Недостаток гибкости и расширяемости. Скорее всего, люди, которые приняли это решение, не слишком хорошо разбираются в вашем проекте, процессах, метриках, которые вы хотите собирать. 

• Зависимость от поставщика. Обычно решения, которые спускают сверху, являются проприетарными. 

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

Что делать, если вы попали в антипаттерн?

Могут быть две ситуации: либо инструмент вам уже навязали, либо вы понимаете, что его скоро могут навязать. Во втором случае советы очевидны: 

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

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

• Стремиться к разнообразию и гибкости. Это помогает адаптироваться к постоянным изменениям требований. 

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

А что делать, если инструмент уже навязан? Мы поступали очень просто: записывали все ситуации, которые инструмент не покрывает. Потом обсуждали список с вендором и решали, может ли он доработать. Если набиралась критическая масса замечаний, то инструмент можно было поменять. Благодаря этому мы перешли на Prometheus и Vectoria Metrics.

Как избежать антипаттерна?

Задайте себе такие вопросы:

• Какие проблемы предполагается решить этим инструментом?

• Как мы должны скорректировать наши методы работы, чтобы получить максимальную выгоду от его использования? Ведь не инструмент решает проблемы, а люди с его помощью.

• Какие возможности он даёт? Возможно, выбранный инструмент не удовлетворяет вашим потребностям, и можно поискать более подходящие решения. 

История вторая

Если ваш стек мониторинга наблюдаемости выглядит примерно так, то поздравляю вас — вы вместе со мной в антипаттерне «Закидывание инструментами».

Инструменты просты в понимании, но они никогда не дают хороших результатов без изменения методов работы. Если вы начинаете использовать какой-то инструмент и не внедряете его в культуру команд, то не получаете максимальной отдачи. Например, в прошлых проектах мы использовали Graphite, Prometheus, Victoria, что-то самописное — огромное количество инструментов. И чтобы получить метрики и трассировки, приходилось всё это собирать и агрегировать из кучи разных источников.

Почему возникает такой антипаттерн? 

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

• Пожалуй, самое страшное, что может быть, — подражание моде или трендам. Культ карго. Сходили на конференцию, услышали про новый инструмент, и всё — «ребята, давайте внедрять, он точно решит нашу проблему!». Предварительно настроили, что-то собрали, сделали маленький демонстратор, вроде бы помогает. И начинаем его использовать. Но этот инструмент тоже надо развивать, как внутри команды, так и внутри организации. И вот здесь начинаются сложности. Потому что чем дальше вы погружаетесь в инструмент, тем сложнее его настраивать, тем сложнее сценарии, и чаще всего на это уже ни у кого нет времени. 

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

Что делать, если вы попали в антипаттерн?

• Главный и универсальный совет: анализируйте требования и определите, что вам нужно. 

• Разберитесь, какие задачи решает инструмент, оцените его преимущества и недостатки, как его можно доработать. 

• Стандартизируйте и упрощайте. Может быть, где-то стоит использовать что-то другое? Главное, не попасть в первый антипаттерн про навязанный инструмент. Возможно, стоит использовать несколько технологий. 

• Обучайте и рассказывайте, что вы делаете. Мы, как команда эксплуатации, рассказываем другим, какие инструменты используем, чтобы коллеги знали, что у нас есть, и не придумывали своего.

Как избежать антипаттерна?

Задайте себе такие вопросы:

• Кто будет вникать в этот инструмент? Потому что просто поставить — легко, а использовать в большой организации может оказаться сложно. Потребуется опыт и желание этот опыт применять. 

• Кто будет его изучать и настраивать? На маленьких инсталляциях всё просто, но чем больше, тем сложнее. И уже нужен будет отдельный человек, который станет этим заниматься. 

• Каких результатов вы хотите добиться с помощью внедрения этого инструмента? Какую проблему решит? Может ли эту проблему решить один из уже используемых инструментов?

История третья

Мой любимый антипаттерн — «Избранный». Обычно какая-то определённая группа людей, в моём случае это была команда эксплуатации в одном из проектов. 

Важно помнить, что наблюдаемость ценна, только когда пользу от неё получают все в компании. Я встречал множество команд, в которых инженер, настраивающий мониторинг — единственный, кто за ним следит. Обычно эту роль играли старшие инженеры или руководители службы. И кроме них в наблюдаемость никто больше не был вовлечён. 

То есть суть в том, что вы делаете мониторинг, понятный только вам. И скорее всего, вы не покрываете все сценарии. 

Какие последствия у этого антипаттерна? 

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

• Это личный инструмент, и другие команды не хотят тратить на него силы. Вы «стоите на страже» и не даёте людям расширять его. 

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

Что делать, если вы попали в антипаттерн?

Советы простые, но вся методология DevOps крутится вокруг культуры коммуникаций. А её недостаток выливается в антипаттерны, о которых я рассказываю. Поэтому:

• Превратите наблюдаемость в культуру. Рассказывайте про неё, как она может помочь. Сделайте так, чтобы каждый мог вносить в неё вклад. 

• Устраивайте демо-сессии по вашему стеку. Ходите к командам, мотивируйте их. 

История четвёртая

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

Пример такого плохого интервала выборок — загрузка процессора. Например, фиксируете среднюю загрузку за 5 минут. В этом интервале у вас может быть момент, загрузка подскочила до 100 %, но усреднённое значение будет, скажем, 20-25 %. Вроде бы неплохо, но при этом мы упускаем из виду всплеск до 100 %, когда с приложением что-то было не так. А если слишком уменьшить интервал, то мы дополнительно нагружаем систему мониторинга. Возможно, мы тогда выловим проблему, но затрудним сбор других метрик. 

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

Ещё одна причина антипаттерна — неправильное соотношение интервалов выборки: для разных метрик могут требоваться интервалы разной длины. 

Как избежать антипаттерна?

• Тщательно анализируйте требования к системам мониторинга и метрикам. Подберите оптимальный интервал для каждой метрики. 

• Учитывайте характеристики данных. Мы учитываем скорость измерения, важность детализации. Возможно, для быстро изменяющихся метрик не потребуются короткие интервалы. 

• Тестируйте и оптимизируйте каждую метрику, чтобы понять, всё ли сделано правильно. 

• Используйте адаптивные интервалы выборки. 

История пятая

Этот антипаттерн — «Непонимание системы». Например, команда эксплуатации поверхностно разбирается в системе. И не потому, что не хочет. Бывает так, что у разработчиков просто нет времени на подробную передачу знаний. Это снова проблема коммуникаций, и далеко не только в DevOps. 

Чтобы достичь стоящих перед нами (или клиентами) целей, мы должны отслеживать надёжность всех сервисов. А в случае этого антипаттерна:

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

• Мы не разбираемся в сервисах, от которых зависим. 

• Не понимаем, что наша система может быть критически важной частью какой-то другой системы. 

• Мы отслеживаем только серверные метрики, но при этом забываем про метрики фронтенд-приложений.

Что делать, если вы попали в антипаттерн?

Капитан с вами:

• Изучите, как работает и от кого зависит ваша система. 

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

• Обязательно поговорите с бизнесом, чтобы понять, какие микросервисы и пути пользователя наиболее важны, на что нужно обратить внимание, где подстелить соломку, где-то донастроить наблюдаемость — добавить метрики, журналы и так далее. 

История шестая

Антипаттерн «Непонятные дашборды». Или «безумные». Это ситуация, есть огромное количество панелей, или одна огромная, сложная и перегруженная. Это затрудняет не то что анализ, а вообще понимание происходящего. Из-за избыточности и усложнённости графиков мы что-то фиксируем, но при этом не знаем, работает ли наше приложение в целом. Но ведь наша цель — предоставлять пользователям понятную и полезную информацию о состоянии системы. 

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

Третья проблема антипаттерна — неправильное представление данных. Если непосвящённый увидит на панели какие-то графики, он может сделать ошибочные выводы. 

Что делать, если вы попали в антипаттерн?

• Правильно выделите пользовательский путь.

• Сосредоточьтесь на ключевых метриках, которые помогут решить, работает ли ваше приложение. 

• Ипользуйте паттерн single pane of glass. Это дашборд здоровья вашего сервиса: на нём отражен только основные компоненты, только чтобы понять, насколько хорошо работает приложение. А дальше можно погружаться в каждый процесс и проверять его работу. 

История седьмая

Представьте ситуацию, когда у вас в почте отдельная папка с сотнями непрочитанных оповещений. Со средой эксплуатации что-то происходит, но вы не читаете. Этот антипаттер называется alert fatigue, «Перегруженность оповещениями». Он возникает тогда, когда у вас огромное количество каналов, почтовых рассылок, рабочих чатов, из которых всё идут и идут оповещения. Вы устаёте от них, не хотите уже читать, отключаете звуковые сигналы. И рано или поздно пропускаете серьёзные проблемы. 

Что делать, если вы попали в антипаттерн?

Сначала разделите каналы на две категории: назойливые и неназойливые. Назойливые каналы — это те, которые так или иначе отвлекают вас во внерабочее время, заставляют прервать свои дела и отреагировать. Например, звонок по телефону. А к неназойливым можно отнести каналы и чаты в мессенджерах, почту. 

Разделив каналы на категории, чётко определите серьёзность оповещений. Если какое-то оповещение критически важное и требует срочного реагирования, то обязательно отправляйте его в навязчивый канал. Например, позвоните инженеру. И тогда у людей будет складываться понимание, что если им звонят, значит, проблема серьёзная, необходимо поднять трубку и каким-то образом отреагировать. А если вы будете звонить каждый раз по проблемам, которые терпят до завтрашнего дня, то однажды на ваш действительно срочный звонок могут просто не ответить. 

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

История восьмая

Недавно я сделал вот такую панель:

Выглядит красиво, но из неё вообще ничего не понятно. Этот антипаттерн называется «Большая и тупая метрика». Это следствие того, что метрики собирают без определённой цели и понимания, как их использовать для анализа системы. Когда плохо понимают потребности пользователей, лепят на дашборды всё, что могут, недостаточно фильтруют и агрегируют. В моём примере это была задержка по всем потокам, которые приходят в наш Nginx. Ну и о чём она мне говорит? На самом деле ни о чём. 99 миллисекунд — это хорошо или плохо? Это по какому сервису? 

Что делать, если вы попали в антипаттерн?

• Определите цели мониторинга. Что вы хотите отслеживать? Для каких сервисов? 

• Обязательно фильтруйте и агрегируйте метрики. Чтобы понимать, какой сервис за что отвечает и какие сервисы с какими вообще можно агрегировать. 

• Постоянно обновляйте и оценивайте метрики. Всё меняется, и когда-то метрика могла быть очень важной, а потом становится никому не нужна. 

История девятая

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

Например, однажды мы выкатили релиз, по мониторингу всё хорошо, но пользователи даже не могли авторизоваться. Мы не до конца отследили пользовательский путь. В технических метриках везде были 200-е коды ответа, а люди жаловались в техподдержку. 

Что делать, если вы попали в антипаттерн?

Выделите критический пользовательский путь — поток, через который проходит пользователь и который имеет наибольшую ценность для нашего бизнеса. О нём всегда нужно помнить при построении системы наблюдаемости, мониторинга, трассировки, журналирования. Объясню на примере интернет-магазина. В нём можно выделить три пользовательских пути:

• возможность оформить заказ;

• возможность добавлять товары в корзину;

• возможность просматривать товары. 

Они все важны, но можно выделить самый важный. Если клиент не сможет просматривать товары, он будет недоволен и, скорее всего, попробует ещё раз позднее. При этом люди, у которых уже есть товары в корзине, смогут их покупать, у них не будет проблем. А если клиент положил товары в корзину и не может оформить заказ, то есть он уже потратил время и готов потратить деньги, тогда он будет максимально расстроен, а бизнес не заработает. Поэтому возможность оформить заказ — это критический пользовательский путь. 

Заключение

Анализируйте требования ко всем системам наблюдаемости. Выясните, какие у вас проблемы и как вы хотите их решать. Сосредоточьтесь на пользователе — технические метрики важны, но в отрыве от пользовательских метрик они чаще всего бесполезны. Превращайте наблюдаемость в продукт, рассказывайте о нём, показывайте, что вы делаете. И тогда тех проблем, которые возникали у меня, возможно, у вас не будет.