Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Наблюдаемость 2.0
Тестирование — это сквозная проблема; Как и базы данных
Очень важно последовательно тестировать все изменения базы данных на протяжении всего конвейера. Разработчики компании DST Global предлагают рассмотреть, как этого можно достичь с помощью современного подхода.
Мы все знакомы с принципами DevOps: создание небольших, хорошо протестированных инкрементов, частое развертывание и автоматизация конвейеров, чтобы исключить необходимость выполнения действий вручную. Мы внимательно следим за нашими приложениями, настраиваем оповещения, откатываем проблемные изменения и получаем уведомления при возникновении проблем.
Однако, когда дело доходит до баз данных, нам часто не хватает такого же уровня контроля и прозрачности. Отладка проблем с производительностью может быть сложной задачей, и нам может быть сложно понять, почему базы данных замедляют работу. Миграции и модификации схем могут выйти из-под контроля, что приведет к серьезным проблемам.
Для преодоления этих препятствий необходимы стратегии, которые упрощают миграцию и адаптацию схемы, обеспечивая эффективные изменения структуры базы данных с минимальным временем простоя или влиянием на производительность. Очень важно последовательно тестировать все изменения на протяжении всего конвейера. Давайте рассмотрим, как этого можно достичь.
Автоматизируйте свои тесты
Базы данных подвержены многим типам сбоев, но зачастую они не подвергаются такому же тщательному тестированию, как приложения. Хотя разработчики обычно проверяют, могут ли приложения читать и записывать правильные данные, они часто упускают из виду, как это достигается. Ключевые аспекты, такие как обеспечение правильного использования индексов, избежание ненужной отложенной загрузки или проверка эффективности запросов, часто остаются без контроля.
Например, мы фокусируемся на том, сколько строк возвращает база данных, но не анализируем, сколько строк ей пришлось прочитать. Аналогичным образом, процедуры отката редко тестируются, что делает нас уязвимыми к потенциальной потере данных при каждом изменении. Чтобы устранить эти пробелы, нам нужны комплексные автоматизированные тесты, которые заблаговременно выявляют проблемы, сводя к минимуму необходимость ручного вмешательства.
Мы часто полагаемся на нагрузочные тесты для выявления проблем с производительностью, и, хотя они могут показать, достаточно ли быстры наши запросы для работы, у них есть существенные недостатки. Во-первых, нагрузочные тесты дорого создавать и поддерживать, требуя тщательного соблюдения требований GDPR, анонимизации данных и приложений с отслеживанием состояния. Более того, они происходят слишком поздно в процессе разработки. Когда нагрузочные тесты выявляют проблемы, изменения уже реализованы, проверены и объединены, что вынуждает нас вернуться к чертежной доске и, возможно, начать все сначала. Наконец, нагрузочные тесты отнимают много времени, зачастую на заполнение кэшей и проверку надежности приложений требуются часы, что делает их менее практичными для раннего выявления проблем.
Миграции схем часто выходят за рамки наших тестов. Обычно мы запускаем наборы тестов только после завершения миграции, то есть мы не оцениваем, сколько времени они заняли, вызвали ли они перезапись таблиц или вызвали ли они узкие места в производительности. Эти проблемы часто остаются незамеченными во время тестирования и становятся очевидными только при развертывании в рабочей среде.
Другая проблема заключается в том, что мы тестируем базы данных, которые слишком малы, чтобы выявить проблемы с производительностью на ранней стадии. Такая зависимость от неадекватного тестирования может привести к потере времени на нагрузочные тесты и оставить критические аспекты, такие как миграция схемы, совершенно непроверенными. Такое отсутствие покрытия снижает скорость нашей разработки, приводит к возникновению проблем, нарушающих работу приложений, и препятствует гибкости.
Решение этих проблем заключается во внедрении ограждений базы данных. Ограждения базы данных оценивают запросы, миграцию схем, конфигурации и дизайн базы данных во время написания кода. Вместо того чтобы полагаться на запуск конвейера или длительные нагрузочные тесты, эти проверки можно выполнять непосредственно в IDE или среде разработчика. Используя возможности наблюдения и прогнозирования производственной базы данных, Guardrails оценивает планы выполнения, статистику и конфигурации, гарантируя, что все будет работать бесперебойно после развертывания.
Постройте наблюдаемость вокруг баз данных
При развертывании в рабочей среде динамика системы может со временем меняться. Загрузка ЦП может резко возрасти, использование памяти может вырасти, объемы данных могут увеличиться, а схемы распределения данных могут измениться. Быстрое выявление этих проблем имеет важное значение, но этого недостаточно. Современные инструменты мониторинга заваливают нас необработанными сигналами, оставляя нам возможность собрать воедино аргументы. Например, они могут указывать на увеличение нагрузки на процессор, но не могут объяснить, почему это произошло. Бремя расследования и выявления коренных причин полностью лежит на нас. Этот подход устарел и неэффективен.
Чтобы действительно двигаться быстро, нам необходимо перейти от традиционного мониторинга к полной наблюдаемости . Вместо того, чтобы быть заваленными необработанными данными, нам нужна действенная информация, которая поможет нам понять основную причину проблем. Ограждения базы данных обеспечивают такое преобразование. Они соединяют точки, показывая, как взаимодействуют различные факторы, выявляя проблему и предлагая решения. Вместо простого наблюдения за скачком использования ЦП, ограждения помогают нам понять, что недавнее развертывание изменило запрос, что привело к обходу индекса, что привело к увеличению нагрузки на ЦП. Благодаря этой ясности мы можем действовать решительно, исправляя запрос или индекс для решения проблемы. Этот переход от «видения» к «пониманию» является ключом к поддержанию скорости и надежности.
Следующей эволюцией в управлении базами данных является переход от автоматического расследования проблем к автоматизированному разрешению. Многие проблемы можно решить автоматически с помощью хорошо интегрированных систем. Инструменты наблюдения могут анализировать проблемы с производительностью и надежностью и генерировать необходимые изменения кода или конфигурации для их решения. Эти исправления могут применяться автоматически или требовать явного одобрения, что гарантирует немедленное устранение проблем с минимальными усилиями с вашей стороны.
Помимо быстрого устранения проблем, конечная цель состоит в том, чтобы в первую очередь предотвратить возникновение проблем. Частые откаты или неудачи препятствуют прогрессу и гибкости. Настоящая гибкость достигается не за счет быстрого решения проблем, а за счет разработки систем, в которых проблемы возникают редко. Хотя реализация этого видения может потребовать дополнительных шагов, оно представляет собой окончательное направление для инноваций.
Metis дает вам возможность преодолеть эти проблемы. Он оценивает ваши изменения еще до того, как они будут зафиксированы в репозитории, анализируя запросы, миграции схем, планы выполнения, производительность и правильность во всех ваших конвейерах.
Каждый должен принять участие
Наблюдение за базой данных предполагает упреждающее предотвращение проблем, продвижение к автоматическому пониманию и разрешению, а также включение проверок, специфичных для базы данных, на протяжении всего процесса разработки. Полагаться на устаревшие инструменты и рабочие процессы уже недостаточно; нам нужны современные решения, которые адаптируются к сегодняшним сложностям. Ограждения базы данных обеспечивают такую поддержку. Они помогают разработчикам избегать создания неэффективного кода, анализировать схемы и конфигурации и проверять каждый этап жизненного цикла разработки программного обеспечения в наших конвейерах.
Guardrails также преобразует необработанные данные мониторинга в полезную информацию, объясняя не только то, что пошло не так, но и как это исправить. Эта возможность необходима во всех отраслях, поскольку сложность систем будет только расти. Чтобы оставаться впереди, мы должны использовать инновационные инструменты и процессы, которые позволят нам двигаться быстрее и эффективнее.
Наблюдаемость 2.0
Традиционного мониторинга недостаточно. Нам нужны решения, ориентированные на разработчиков, которые может дать нам только Observability 2.0.
За пределами традиционного мониторинга
В сегодняшней среде разработки программного обеспечения создание передовых приложений требует пристального внимания к разработчикам, которые создают этот цифровой опыт от начала до конца; отныне современные инструменты не просто ожидаются, но и должны быть по своей сути ориентированными на разработчиков средой, способствующей эффективности и творчеству. Observability 2.0 выходит за рамки традиционных парадигм мониторинга, встраивая механизм непрерывной обратной связи непосредственно в сам жизненный цикл разработки, а не в качестве второстепенного или отдельного процесса, требуя прозрачности на каждом этапе производства программного обеспечения для постоянного поддержания работоспособности системы, гарантируя при этом качество кода и приложения. производительность строго соответствует корпоративным стандартам.
Этот современный подход требует от разработчиков работать в единой экосистеме платформы, где инструменты отладки тесно интегрированы с IDE. Этот немедленный доступ позволяет быстро выявлять, анализировать и решать проблемы непосредственно из их пространства кодирования без внешнего переключения контекста или внешней зависимости от устаревших систем, часто связанных с традиционными настройками наблюдения. Кроме того, современные решения, ориентированные на разработчиков, облегчают совместную работу в режиме реального времени посредством общих холстов, где разработчики могут визуально отслеживать состояние системы вместе с коллегами. Это не только оптимизирует процесс отладки, но также расширяет возможности обмена знаниями и коллективного решения проблем, что имеет решающее значение для разработки сложных программных систем, устойчивых к сбоям.
Телеметрия – это ключ
Observability 2.0 требует сложного уровня сбора телеметрии, где записываются метрики, связанные с производительностью (время ответа), пропускной способностью (транзакций в секунду), использованием ресурсов (использование ЦП и памяти), а также файлы журналов каждого модульного теста или этапа интеграции. с точностью. Затем эти данные обрабатываются с помощью передовых инструментов аналитики, которые обеспечивают детальное представление о состоянии системы, позволяя разработчикам заранее определить основную причину до того, как проблемы перерастут в критические сбои. Более того, эти решения не просто выявляют проблемы, когда производительность падает ниже допустимых порогов, они включают в себя методы машинного обучения для прогнозного анализа. Это означает выявление закономерностей и потенциальных будущих рисков на основе исторических данных, что, в свою очередь, позволяет разработчикам выполнять итерации, осознавая возможные проблемы масштабирования или узкие места в ресурсах.
Этот подход к наблюдаемости нового поколения также интегрируется в конвейеры непрерывной интеграции/непрерывного развертывания (CI/CD). Тем самым он определяет стратегии автоматизации сборки и развертывания, гарантируя, что только приложения с проверенными метриками перейдут на последующие этапы тестирования или выпуска. Разработчики получают дополнительные возможности благодаря информационным панелям в рамках своего рабочего процесса, которые отображают состояние работоспособности различных модулей; эти визуальные индикаторы обеспечивают четкость областей, требующих немедленного внимания, что позволяет ускорить цикл разработки, держа разработчиков в курсе событий, не отвлекая их от написания качественного кода в условиях реального времени.
Чтобы быть по-настоящему современными и ориентированными на разработчиков, решения для наблюдения должны также включать в себя надежные механизмы журналирования, позволяющие отслеживать поток выполнения. Эта детальная информация в файлах журналов становится важной при отладке сложных потоков приложений или распределенных систем, где взаимодействие компонентов может привести к неясным взаимозависимостям, вызывающим непредвиденные ошибки. Расширенные инструменты мониторинга теперь предоставляют контекстную информацию об этих журналах, находясь в среде разработчика, что не только способствует быстрому решению проблем, но и позволяет глубже понять, как элементы кода взаимодействуют на протяжении всего своего жизненного цикла. Это понимание имеет решающее значение при разработке с использованием микросервисов или бессерверных архитектур, где традиционные методы наблюдения могут не уловить тонкие нюансы межсервисного взаимодействия.
Более того, Observability 2.0 в контексте инструментов разработчика означает реализацию возможностей сквозной визуализации трассировки, чтобы разработчики могли всесторонне понимать, как их код взаимодействует с различными компонентами системы. Речь идет не только о выявлении проблем, но и о проверке выбора дизайна; например, понимание задержки между вызовами API внутри сервисной сетки или отслеживание потоков данных посредством многофазных транзакций.
Интеграция с инструментами разработчиков
Интеграция инструментов наблюдения, ориентированных на разработчиков, в повседневный рабочий процесс требует тщательного планирования и продуманной архитектуры, поддерживающей различные среды тестирования. Это может варьироваться от модульных тестов до испытаний на выносливость в производственных репликах, гарантируя, что мониторинг станет не просто второстепенным вопросом, а неотъемлемым элементом на протяжении всего процесса разработки. Когда они пишут код, это становится частью их брони; Панели визуализации встроены в интегрированные среды разработки или специальные приложения для разработчиков, что позволяет в любое время мгновенно получить представление о показателях поведения и работоспособности. Такая прозрачность укрепляет доверие между командами, создавая среду, в которой разработчики могут уверенно внедрять новые функции, не опасаясь, что ошибка, обнаруженная сегодня, может вызвать посторонние отвлекающие факторы завтра.
Современные решения также должны облегчать наблюдение в контейнерных или облачных средах, которые становятся все более распространенными. Это означает, что адаптивные инструменты могут охватывать несколько уровней инфраструктуры, будь то мониторинг контейнеров, модулей Kubernetes, бессерверных функций и т. д. — каждый уровень предлагает уникальные задачи, но в равной степени требует точного сбора телеметрии для эффективного наблюдения. Разработчики должны использовать эти современные решения не только для поддержания высокой производительности, ожидаемой сегодня конечными пользователями, но и для создания перспективных систем, которые могут быстро масштабироваться без ущерба для надежности и стабильности во время внезапных скачков трафика, сохраняя при этом свое внимание к написанию чистого и надежного кода. где разработчики получают возможность наблюдать за тем, как каждая написанная ими строка влияет на общее поведение системы.
Таким образом, современный подход к Observability 2.0, ориентированный на разработчиков, настаивает на интеграции аналитики в реальном времени в процесс разработки для поддержания работоспособности программного обеспечения. Многосторонняя стратегия включает в себя встраивание инструментов отладки в IDES, обеспечивающих немедленную обратную связь и возможности для совместной работы, которые соответствуют современным облачным рабочим процессам, включение расширенной обработки метрик в конвейеры CI/CD, внедрение комплексного журналирования для отслеживания потока выполнения через сложные структуры приложений, обеспечивая при этом сквозной подход. визуализация для полного контекстного понимания взаимодействия кода. Современная разработка программного обеспечения требует, чтобы эти решения были не просто дополнительными, а ключевыми компонентами, обеспечивающими эффективность и точность: основой, на которой разработчики создают отказоустойчивые, производительные и масштабируемые системы, сохраняющие верность корпоративным стандартам и одновременно создающие прозрачную среду для быстрого выполнения итераций, ведущую к конечная цель — предоставление высококачественного программного обеспечения.
Наблюдаемость 2.0 обязательна
В заключение, использование инструментов разработчика с учетом Observability 2.0 больше не является необязательным, а скорее обязательным элементом. Сегодня разработчикам нужны эти расширенные функции как неотъемлемая часть их повседневной практики кодирования, точно так же, как они полагаются на любой другой необходимый набор инструментов, такой как системы контроля версий или автоматизация сборки. Современные решения должны выходить за рамки общепринятых границ, становясь неотъемлемыми аспектами среды разработчика, где каждое нажатие клавиши фиксируется показателями в реальном времени, которые влияют на немедленные решения и способствуют более глубокому пониманию. Эта гармония между беглостью программирования и соблюдением требований обеспечивает не только доставку, но и устойчивость в сегодняшних постоянно меняющихся условиях.
Наблюдаемость 2.0
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все ваши вопросы.
Комментарии и отзывы экспертов
Вам может быть интересно
Двоичное квантование в векторных базах данных повышает эффективность, производительность и оптимизирует хранение данных для расширенного поиска и анализа информации.Векторные базы данных — это с...
В этой статье вы узнаете от разработчиков компании DST Global, о преимуществах, ...
Узнайте о преимуществах от разработчиков компании ...
Oracle — самая популярная база данных в мире...
Повысьте производительность и масштабируемость, ис...
В этом комплексном сравнении от разработчиков комп...
: создание эффективных практик разработки и обслуж...
В этой статье рассматривается, что такое потоковая...
Базы данных (БД) — способ хранения и организ...
В статье специалистами компании DST Global обсужда...
Новые комментарии
Еще с начала 2000-х годов, когда не существовало биометрии, хакеры пользовались ...
Как и любое технологическое достижение, наряду с захватывающими возможностями ге...
Вывод ясен: ИИ — это не просто технологический феномен, а глобальная сила, меняю...
Стоит вернуться в прошлое, чтобы понять, как мы пришли к необходимости версии 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 решает для разработчиков:
— Им нужны точные, богатые контекстом инсайты реального времени о системе, чтобы они могли полагаться на единый источник истины для понимания «неизвестных неизвестных».
— Более быстрая отладка, благодаря которой разработчики могут легко анализировать и понимать сложные системы.
Это возможно благодаря тому, что строительным блоком «наблюдаемости 2.0» являются события журналов, которые являются более мощными, практичными и экономически эффективными, чем метрики (рабочая лошадка «наблюдаемости 1.0»), поскольку они сохраняют контекст и взаимосвязи между данными.
Кроме того, «наблюдаемость 2.0» построена на открытых стандартах, таких как OpenTelemetry, что позволяет разработчикам использовать общий стандарт для трассировок, журналов и метрик.
Принятие открытого, переносимого средства сбора телеметрических данных — немаловажное новшество; я еще помню те времена, когда единственными альтернативами были две: укомплектовать штат сотрудников крупной компании для сбора телеметрических данных по всей нашей инфраструктуре или заплатить небольшое состояние поставщику за развертывание его собственных агентов для сбора этих данных.
Как Observability 2.0 изменит опыт разработчиков
Опыт разработчиков (DX) определяет восприятие инженерами своей работы, влияя на продуктивность, вовлеченность, удовлетворенность и удержание. Сильный DX способствует формированию среды, в которой команды могут работать с максимальной отдачей, эффективно и с энтузиазмом решая поставленные задачи.
В этом контексте наличие правильного инструментария для управления целостностью ПО оказывает огромное влияние на DX: недавний опрос Atlassian «State of Developer Experience Report 2024» показал, что восемь с лишним часов в неделю могут быть потеряны из-за неэффективности работы в условиях борьбы с техническим долгом, некачественной документации и недостаточного количества инструментов отладки.
Для улучшения DX — а значит, и способности команды доставлять надежное, масштабируемое и поддерживаемое ПО — было выявлено три основные области:
— Циклы обратной связи. Обеспечение непрерывного совершенствования за счет быстрого обучения и внесения корректировок.
— Управление когнитивной нагрузкой. Обеспечение точной и доступной документации.
— Оптимизация состояние потока. Минимизация прерываний для поддержания глубокой погруженности в работу.
Observability 2.0 затрагивает все три эти области, предоставляя разработчикам больше возможностей для улучшения видимости и сокращая количество ручных задач:
— Контекстная информация в реальном времени. Разработчики получают немедленную обратную связь об изменениях в системе, что помогает им быстрее и увереннее поставлять код. При использовании Observability 1.0 мне часто казалось, что отладка — это археологические раскопки: кропотливое вскрытие слоя за слоем, чтобы понять дизайн системы, архитектуру и проектные решения, прежде чем выявить первопричину проблемы. Благодаря Observability 2.0 вы получаете точную видимость в реальном времени всех компонентов и их взаимосвязей и можете легко избежать непреднамеренного архитектурного технического долга при внесении изменений.
— Сокращение ручного труда. Использование фреймворков наблюдаемости, таких как OpenTelemetry, для документирования означает, что ваша работающая система будет соответствовать документации без необходимости ее ручного обновления. Отладка также становится более эффективной благодаря богатым контекстом данным, что позволяет разработчикам диагностировать проблемы без просеивания чрезмерных объемов данных.
Практический пример: отладка с помощью Observability 2.0
Observability 2.0 открывает двери для новых сценариев использования и инструментов, которые могут решить повседневные проблемы разработчиков, сэкономить им значительное время и устранить головную боль.
Вот мой опыт относительно текущего процесса отладки и то, как, по моему мнению, он будет развиваться с появлением Observability 2.0.
— Традиционная отладка предполагает подход, основанный на поиске: вы просеиваете данные телеметрии, просматриваете бесконечные журналы и трассировки, интуитивно подбираете шаблоны и полагаетесь на опыт, обоснованные догадки и (возможно, устаревшую) ментальную модель системы.
— Вы пытаетесь воспроизвести проблему, хотя это не всегда возможно из-за нечетких и неполных отчетов — если таковые вообще предоставляются.
— Наконец, вам, возможно, приходится ориентироваться в разрозненных ресурсах — документации, диаграммах архитектуры, записях о принятых решениях, API и репозиториях — только для того, чтобы полностью понять систему.
Как я уже говорил, проблемы в сложных распределенных системах редко бывают изолированными. Чтобы понять не только то, что пошло не так, но и то, почему и как что-то пошло не так, требуется сопоставить данные на различных уровнях системы, что требует много времени и чревато человеческими ошибками.
Не говоря уже о том, что иногда на команды оказывают давление, требуя «просто устранить проблему как можно быстрее» из-за потребностей бизнеса и горящих сроков. В случае с Observability 1.0 это может привести к устранению «симптомов» проблемы, но не ее сути.
В Observability 2.0 новые инструменты для разработчиков, использующие OpenTelemetry, позволяют отлаживать работу на уровне платформы с глубоким воспроизведением сессий. Одним щелчком мыши разработчики могут захватить сессии, показывающие шаги по воспроизведению ошибки, сопровождаемые данными от экранов фронтенда до глубоких платформенных трассировок, метрик и журналов.
Получение точных данных в реальном времени и документации по реальной архитектуре системы значительно сокращает время, затрачиваемое на поиск и отладку неисправностей.
Используя «наблюдаемость 2.0» и такие фреймворки, как OpenTelemetry, организации могут получить целостное представление о своем ПО в режиме реального времени, что улучшает работу разработчиков, повышает общую продуктивность и долгосрочную устойчивость.
Теперь они не просто устраняют «симптомы» — как при постоянном приеме обезболивающих из-за головной боли, — а решают корневую проблему и предотвращают головную боль до ее возникновения.