Томас Джонсон, сооснователь и технический директор компании Multiplayer, рассказывает на портале The New Stack о том, как наблюдаемость нового поколения (Observability 2.0) решает проблему технического долга и оптимизирует рабочие процессы разработчиков.

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

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

Термин «наблюдаемость», уходящий корнями в теорию систем управления, был популяризирован командой Honeycomb в 2016 г. Они расширили определение Рудольфа Э. Калмана — «мера того, насколько хорошо внутренние состояния системы могут быть выведены из знаний о ее внешних выходах» — и переформулировали его в «способность задавать новые вопросы о вашей системе, без необходимости поставлять новый код или собирать новые данные, чтобы задать эти новые вопросы».

Пока эта концепция набирала обороты, в 2017 г. Питер Бургон предположил, что наблюдаемость состоит из «трех столпов» — метрик, журналов и трассировок — определение, которое нашло сильную поддержку в индустрии инструментов мониторинга производительности приложений (APM), так как по совпадению идеально соответствовало их продуктовым предложениям.

В последующие годы были предприняты энергичные попытки прояснить, что собой представляет наблюдаемость на самом деле, например, Бен Силгелман в 2021 г. написал статью «Развенчание мифа о „трех столпах наблюдаемости“», в которой объяснил, что «метрики, журналы и трассировки — это не „наблюдаемость“, это просто телеметрия».

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

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

В августе этого года Чарити Мейджорс предложила называть относящимися к «наблюдаемости 1.0» решения, которые тесно связаны с тремя столпами и инструментами APM. Тогда как «наблюдаемость 2.0» представляет собой выход за рамки традиционных фреймворков мониторинга и APM-инструментов и изменение подхода разработчиков к пониманию и отладке систем.

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

Observability 1.0 vs. Observability 2.0

Давайте сделаем краткий обзор и проясним разницу между двумя типами наблюдаемости:

Observability 1.0. «Наблюдаемость 1.0», тесно связанная с APM-инструментами, относится к традиционному подходу, при котором огромные объемы телеметрических данных (метрики, журналы и трассировки) собираются, а затем отображаются на инструментальных панелях — то есть на едином дашборде, к которому часто стремятся.

В Observability 1.0 основное внимание уделяется операциям: она выделяет известные проблемы после того, как ПО запущено в производство. Это полезно, если вы уже знаете, что искать — «известное неизвестное», — но производственные сбои в сложных распределенных системах часто нелинейны и трудно предсказуемы, что требует ручного исследования для поиска первопричины проблемы.

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

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

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

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

Если в Observability 1.0 акцент делался на выявлении всплесков и мониторинге состояния системы, то Observability 2.0 больше ориентирована на разработчиков. Речь идет об устранении коренных причин проблем и снижении частоты инцидентов путем внедрения наблюдаемости в сам процесс разработки — другими словами, о решении проблем до того, как они появятся на приборных панелях «наблюдаемости 1.0»!

Две основные проблемы, которые Observability 2.0 решает для разработчиков:

  1. Им нужны точные, богатые контекстом инсайты реального времени о системе, чтобы они могли полагаться на единый источник истины для понимания «неизвестных неизвестных».
  2. Более быстрая отладка, благодаря которой разработчики могут легко анализировать и понимать сложные системы.

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

Кроме того, «наблюдаемость 2.0» построена на открытых стандартах, таких как OpenTelemetry, что позволяет разработчикам использовать общий стандарт для трассировок, журналов и метрик.

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

Как Observability 2.0 изменит опыт разработчиков

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

В этом контексте наличие правильного инструментария для управления целостностью ПО оказывает огромное влияние на DX: недавний опрос Atlassian «State of Developer Experience Report 2024» показал, что восемь с лишним часов в неделю могут быть потеряны из-за неэффективности работы в условиях борьбы с техническим долгом, некачественной документации и недостаточного количества инструментов отладки.

Для улучшения DX — а значит, и способности команды доставлять надежное, масштабируемое и поддерживаемое ПО — было выявлено три основные области:

  • Циклы обратной связи. Обеспечение непрерывного совершенствования за счет быстрого обучения и внесения корректировок.
  • Управление когнитивной нагрузкой. Обеспечение точной и доступной документации.
  • Оптимизация состояние потока. Минимизация прерываний для поддержания глубокой погруженности в работу.

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

  1. Контекстная информация в реальном времени. Разработчики получают немедленную обратную связь об изменениях в системе, что помогает им быстрее и увереннее поставлять код. При использовании Observability 1.0 мне часто казалось, что отладка — это археологические раскопки: кропотливое вскрытие слоя за слоем, чтобы понять дизайн системы, архитектуру и проектные решения, прежде чем выявить первопричину проблемы. Благодаря Observability 2.0 вы получаете точную видимость в реальном времени всех компонентов и их взаимосвязей и можете легко избежать непреднамеренного архитектурного технического долга при внесении изменений.
  2. Сокращение ручного труда. Использование фреймворков наблюдаемости, таких как OpenTelemetry, для документирования означает, что ваша работающая система будет соответствовать документации без необходимости ее ручного обновления. Отладка также становится более эффективной благодаря богатым контекстом данным, что позволяет разработчикам диагностировать проблемы без просеивания чрезмерных объемов данных.

Практический пример: отладка с помощью Observability 2.0

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

Вот мой опыт относительно текущего процесса отладки и то, как, по моему мнению, он будет развиваться с появлением Observability 2.0.

  • Традиционная отладка предполагает подход, основанный на поиске: вы просеиваете данные телеметрии, просматриваете бесконечные журналы и трассировки, интуитивно подбираете шаблоны и полагаетесь на опыт, обоснованные догадки и (возможно, устаревшую) ментальную модель системы.
  • Вы пытаетесь воспроизвести проблему, хотя это не всегда возможно из-за нечетких и неполных отчетов — если таковые вообще предоставляются.
  • Наконец, вам, возможно, приходится ориентироваться в разрозненных ресурсах — документации, диаграммах архитектуры, записях о принятых решениях, API и репозиториях — только для того, чтобы полностью понять систему.

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

Не говоря уже о том, что иногда на команды оказывают давление, требуя «просто устранить проблему как можно быстрее» из-за потребностей бизнеса и горящих сроков. В случае с Observability 1.0 это может привести к устранению «симптомов» проблемы, но не ее сути.

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

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

Заключение

Эволюция наблюдаемости отражает растущую сложность современных программных систем и необходимость в более сложных инструментах для их понимания и управления.

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

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