OpenTelemetry получил статус Graduation в CNCF. Это высший уровень зрелости проекта в экосистеме фонда. Обычно до Graduation доходят проекты, которые уже массово используются в проде и не зависят от одного вендора или команды. Рынок давно принял OpenTelemetry как стандарт. Graduation — скорее формальность, чем сюрприз. Раньше каждый вендор тащил собственных агентов, SDK и форматы данных. Хочешь перейти с одной платформы на другую? – Удачи! Это был тот ещё квест) С OpenTelemetry приложения могут отдавать телеметрию единообразно. А backend для анализа, хранения и визуализации выбирается отдельно. В результате конкуренция сместилась выше по стеку. Вендоры всё меньше конкурируют агентами и закрытыми форматами, а всё больше — качеством аналитики, удобством работы, снижением шума и дополнительными возможностями платформ. Сейчас об OpenTelemetry всё чаще говорят уже не только в контексте классической observability. С ростом ИИ-систем выясняется, что без качественной телеметрии там тоже далеко не уедешь. По сути это те же распределённые системы, только с новыми слоями сложности: агентами, моделями, внешними инструментами, промптами и длинными цепочками вызовов. И если для микросервисов нам важно понимать, где сломался запрос, то для ИИ-платформ нужно ещё больше подробностей: какой агент что вызвал, какая модель ответила, где выросла задержка и сколько всё это стоило. Так что OpenTelemetry перестал быть “перспективной технологией” и стал инфраструктурным стандартом для наблюдаемости. По сути, это общий язык, на котором приложения, платформы и observability-системы договариваются о метриках, логах и трейсах.
DeDevOps Deflope News
КатегорияTechnologyЯзыкRUДобавлен06 июл. 2026 г.КачествоПроверен
Подписчики3.8K
Сред. просмотры4K
ERR105.3%
Цена-- RUB
Цена / подписчик--
Цена / просмотр--
Метрики обновлены: 06 июл. 2026 г.
Последние посты
Linux Foundation с помощью CNCF выпустил два бесплатных курса про документацию. • LFC111 — Open Source Technical Documentation Essentials Тут основы. Как структурировать, писать и поддерживать техническую документацию в Open Source-проектах. • LFC112 — Creating Effective Documentation for Developers А здесь уже больше практики. Документация API, туториалы, гайды, всё, что мы пишем регулярно. Оба курса рассчитаны на разработчиков, инженеров, PM’ов и технических писателей с базовым пониманием разработки. Обучение занимает 3-4 часа, можно проходить уроки в своём темпе. Нас с вами, коллеги, особо никто не учил писать документацию, а жаль. Конечно, эти курсы не заменят практику и живые задачи. Но они могут дать хорошую базу, чтобы вашей документацией действительно пользовались. Бесплатно, без подписок и смс. Круто же)
Дочитал «Настоящий SRE» Дэвида Бланк-Эдельмана. Это третий пост из серии, я Алексей Крылов, менеджер продукта. Итоговые впечатления. Главная фишка книги — иерархия надёжности Дикерсона. Пирамида, построенная по той же логике, что и пирамида Маслоу. В основании лежат мониторинг и наблюдаемость. Дальше идут реагирование на инциденты, разбор последствий без поиска виноватых, тестирование и релизы, планирование ресурсов, разработка. На самом верху — проектирование продукта с учётом надёжности с самого начала. Нельзя перейти на следующий уровень, не отстроив предыдущий. Для тех, кто только начинает, это честная дорожная карта. Важный нюанс в том, что движение по этой пирамиде нелинейное. Команда может быть на высоком уровне зрелости и внезапно вернуться в режим «пожарных» из-за крупного инцидента. Это нормально, и книга честно об этом предупреждает. Книга отвечает на вопрос «с чего начать», а не просто описывает, как всё устроено в Google. Структура позволяет читать нелинейно: первая часть про менталитет обязательна, а дальше можно выбирать — вторая часть про личный карьерный путь, третья про внедрение в организацию. Автор так и говорит, выберите своё приключение. Он собрал опыт множества практиков, добавил реальные истории, здоровый юмор и неожиданно много внимания уделил человеческому фактору: этике, эмпатии, выгоранию. Для технической книги редкость. Из слабых мест: иерархия Дикерсона при всей полезности неполна, и сам автор это признаёт. В ней нет места для роли SRE-инженера в проектировании архитектуры на ранних стадиях и нет борьбы с рутиной как отдельного уровня. Местами книга перегружена сносками, а центральная метафора с дайвингом к концу, по словам самого автора, становится «всё более громоздкой». Но есть кое-что интереснее формальных недостатков книги. Ловушка самого подхода. Если система работает слишком хорошо и никогда не падает, все вокруг расслабляются и перестают готовиться к сбоям. Когда инцидент всё же случается — последствия непропорционально тяжёлые, потому что никто не ждал. Книга об этом честно предупреждает. Кому рекомендую: инженерам, которые хотят взглянуть на свою работу с точки зрения влияния на компанию. Тем, кто чувствует, что просто тушит пожары, но хочет понять, как выстроить систему, в которой пожаров становится меньше. P.S. Редакция канала благодарит издательство Питер за предоставленную физическую версию книги :)
Все внедрили ИИ. Все давно в облаке, все Cloud Native, все успешны. Так выглядит любая конференция. А что на самом деле? Наши коллеги из Ассоциации облачно-ориентированных технологий решили выяснить и запустили исследование состояния Cloud Native в России 2026, которое выросло из всем знакомого State of DevOps Russia. Как всегда, опрос подробный, а отчёт с выводами будет открытым для всех. Чем больше людей пройдут опрос, тем точнее будет отчёт и тем интереснее будет сверить себя с рынком. Может, окажется, что всё не так плохо. А может — наоборот)) И это тоже полезно знать. Пройти опрос →
Broadcom передала Velero в CNCF. Velero — это инструмент для бэкапа и восстановления Kubernetes-кластеров. Бэкапит не диски, а объекты: деплойменты, права доступа, тома, то есть, всё, что нужно, чтобы поднять приложение заново или перенести его в другой кластер. У проекта длинная история: он начинался как Heptio Ark, затем после покупки Heptio стал частью VMware, а после сделки VMware/Broadcom оказался в зоне влияния Broadcom. При этом Velero давно используется в проде многими командами и сейчас имеет около 10 тысяч звёзд на GitHub. Несмотря на популярность, вокруг Velero оставался вопрос лицензии и регулирования. После резких изменений в VMware-лицензировании часть рынка стала осторожнее относиться ко всему, что находится под контролем Broadcom. Для Open Source это особенно чувствительно. Сегодня вендор активно развивает проект, завтра меняет стратегию, и пользователям приходится жить с последствиями. Переход в CNCF этот аргумент снимает, и теперь ни один вендор не может в одностороннем порядке закрыть проект или резко сменить направление. Релизы, состав мейнтейнеров, роадмапы — всё это теперь решается коллегиально, по правилам CNCF Важно не путать. Переход в CNCF не упрощает эксплуатацию. Object storage, IAM-учётки, живой целевой кластер никуда не делись, это по-прежнему требует инженерного внимания. Изменилось только то, кто принимает решения по проекту. В общем, этот анонс — хороший повод снова посмотреть на Velero тем, кто давно не смотрел. Один весомый аргумент против теперь снят.