Создание устойчивой системы: наш путь к наблюдаемости в Intercom

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

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

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

В этом посте мы рассмотрим путь к построению более сильной культуры наблюдаемости и уроки, которые мы извлекли на этом пути.

Что мы подразумеваем под наблюдаемостью в Intercom?

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

Давайте разберем это еще немного:

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

Этап 1: Проблема и решение

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

«Метрики легко добавить и понять, но в них отсутствуют важные атрибуты (например, идентификатор клиента), что затрудняет проведение расследования».

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

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

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

Почему следы?

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

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

Некоторые типы визуализации, которые могут быть основаны на трассировках

Этап 2: Реализация трассировки

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

«Вместо того, чтобы оснастить наше приложение трассировками с нуля, мы использовали существующую библиотеку трассировки, которая уже оказалась в зависимостях»

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

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

Предоставление товарищам по команде возможности использовать трассировки

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

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

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

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

Этап 3: Выбор подходящего поставщика

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

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

«Мы хотели иметь полный контроль над тем, как будут собираться и сохраняться данные»

Контроль выборки и хранения : мы хотели иметь полный контроль над тем, как данные будут отобраны и сохранены. Детерминированная выборка помогла нам быстро приступить к работе, но мы хотели быть более избирательными и сохранять больше «интересных» следов (например, ошибок, медленных запросов), используя интеллектуальную динамическую выборку, оставаясь при этом ниже лимита контракта.

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

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

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

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

После трудного года работы мы завершили техническую часть программы наблюдения. Вот чего мы достигли:

• Наше основное монолитное приложение было автоматически оснащено высококачественными трассами с множеством атрибутов.
• У инженеров был небольшой набор удобных методов для добавления пользовательских инструментов в свой код.
• Мы развернули Honeycomb Refinery для динамической выборки данных и сохранения большего количества «интересных» трассировок. Мы призвали инженеров настраивать собственные правила хранения для более детального контроля. Для самых ценных транзакций и когда это экономически целесообразно, мы предложили 100% сохранение, чтобы предоставить людям необходимые данные.

Этап 4: Расширение внедрения

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

Трассировка в среде разработки

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

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

Ярлыки запросов Slackbot

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

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

Этап 5: Размышления и следующие шаги

Измерение принятия

Измерение окупаемости инвестиций (ROI) инструментов наблюдаемости является сложной задачей. Отслеживание количества активных пользователей является хорошим индикатором того, как часто инженеры взаимодействуют с инструментами, и мы получили большую пользу от показателей использования Honeycomb.

На этой диаграмме показано увеличение числа активных пользователей Honeycomb с момента включения функции наблюдения.

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

Гистограмма, показывающая количество проблем GitHub, в которых Honeycomb упоминается в заголовке или описании.

Неожиданные рабочие процессы

Создание прочной основы для наблюдения позволило реализовать рабочие процессы, о которых мы раньше не могли и мечтать. Вот некоторые из наших любимых:

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

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

Что дальше?

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

Заинтересованы в присоединении к нашей команде? Ознакомьтесь с нашими открытыми инженерными ролями здесь.