Телеграм канал «DevOps&SRE Library»

Setting Up OpenTelemetry on the Frontend Because I Hate Myself Frontend developers deserve so much better from OpenTelemetry, especially since they stand to benefit so much. https://thenewstack.io/setting-up-opentelemetry-on-the-frontend-because-i-hate-myself

Choosing the right OpenTelemetry Collector distribution https://www.datadoghq.com/blog/otel-collector-distributions

Why I recommend native Prometheus instrumentation over OpenTelemetry https://promlabs.com/blog/2025/07/17/why-i-recommend-native-prometheus-instrumentation-over-opentelemetry

Запустите карьеру инженера на оплачиваемой программе развития МТС ПРО и работайте с самыми востребованными технологиями! Почему это крутой старт? — Зарплата 115 000 рублей (до вычета налогов), за классные результаты работы ее могут повысить в течение программы. — Гибридный график: три дня в офисе и два — удаленно. — Практический опыт на реальных проектах. — Наставничество опытных менторов и поддержка команды. Открыты направления: — Аппаратный разработчик — Радиоинженер — Сетевой инженер-разработчик — Инженер IP/MPLS, ЦОД — Архитектор облака — DevOps-инженер — Инженер SRE Начинайте карьеру с МТС ПРО — выбирайте трек и поднимайте свой экспертный уровень вместе с лучшими! Регистрируйтесь: https://u.to/EdlVIg

Flame Charts: The Time-Aware Sibling of Flame Graphs https://www.polarsignals.com/blog/posts/2025/05/28/flamecharts-the-time-aware-sibling-of-flame-graphs

Синтаксис Python освоили, а что дальше? Работа с БД, парсинг и собственные пет‑проекты В новом бесплатном курсе от Selectel собраны обучающие материалы для первых шагов в мире реального программирования. Меньше теории — больше практики. После прохождения курса вы научитесь: ▪️работать с базами данных и брокерами сообщений, ▪️создавать приложения с графическим интерфейсом, ▪️автоматизировать получение данных. Начните курс в Академии Selectel: https://slc.tl/m4ixl Реклама. АО «Селектел», ИНН 7810962785, ERID: 2Vtzqw5L42v

6 Reasons You Don't Need an SRE Team The model of large SRE teams covering many services in a vague and nebulous way that's open to repeated re-interpretation is mostly a side-effect of (a) cargo-culting the building of these large groups, or (b) retrofitting SRE/DevOps onto existing groups without the company-wide reliability focus required (or the fortitude to decide you didn't need such a large group to do SRE). https://log.andvari.net/6reasons.html