اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
Пятничный деплой
رفتن به کانال در Telegram
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://t.me/s/count0_digest
نمایش بیشتر4 721
مشترکین
+224 ساعت
-17 روز
+130 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '26
ژوئن '26
+70
در 0 کانالها
مه '26
+86
در 0 کانالها
Get PRO
آوریل '26
+114
در 0 کانالها
Get PRO
مارس '26
+127
در 8 کانالها
Get PRO
فوریه '26
+67
در 0 کانالها
Get PRO
ژانویه '26
+46
در 0 کانالها
Get PRO
دسامبر '25
+46
در 0 کانالها
Get PRO
نوامبر '25
+56
در 1 کانالها
Get PRO
اکتبر '25
+49
در 0 کانالها
Get PRO
سپتامبر '25
+44
در 1 کانالها
Get PRO
اوت '25
+55
در 0 کانالها
Get PRO
ژوئیه '25
+58
در 0 کانالها
Get PRO
ژوئن '25
+53
در 0 کانالها
Get PRO
مه '25
+48
در 0 کانالها
Get PRO
آوریل '25
+62
در 1 کانالها
Get PRO
مارس '25
+82
در 0 کانالها
Get PRO
فوریه '25
+50
در 0 کانالها
Get PRO
ژانویه '25
+88
در 1 کانالها
Get PRO
دسامبر '24
+82
در 0 کانالها
Get PRO
نوامبر '24
+126
در 4 کانالها
Get PRO
اکتبر '24
+110
در 1 کانالها
Get PRO
سپتامبر '24
+74
در 0 کانالها
Get PRO
اوت '24
+73
در 0 کانالها
Get PRO
ژوئیه '24
+87
در 0 کانالها
Get PRO
ژوئن '24
+87
در 1 کانالها
Get PRO
مه '24
+94
در 0 کانالها
Get PRO
آوریل '24
+112
در 0 کانالها
Get PRO
مارس '24
+113
در 0 کانالها
Get PRO
فوریه '24
+106
در 1 کانالها
Get PRO
ژانویه '24
+131
در 0 کانالها
Get PRO
دسامبر '23
+101
در 1 کانالها
Get PRO
نوامبر '23
+177
در 1 کانالها
Get PRO
اکتبر '23
+21
در 0 کانالها
Get PRO
سپتامبر '23
+45
در 0 کانالها
Get PRO
اوت '23
+42
در 0 کانالها
Get PRO
ژوئیه '23
+50
در 0 کانالها
Get PRO
ژوئن '23
+44
در 0 کانالها
Get PRO
مه '23
+32
در 0 کانالها
Get PRO
آوریل '23
+24
در 0 کانالها
Get PRO
مارس '23
+32
در 0 کانالها
Get PRO
فوریه '23
+29
در 0 کانالها
Get PRO
ژانویه '23
+27
در 0 کانالها
Get PRO
دسامبر '22
+31
در 0 کانالها
Get PRO
نوامبر '22
+30
در 0 کانالها
Get PRO
اکتبر '22
+32
در 0 کانالها
Get PRO
سپتامبر '22
+42
در 0 کانالها
Get PRO
اوت '22
+53
در 0 کانالها
Get PRO
ژوئیه '22
+39
در 0 کانالها
Get PRO
ژوئن '22
+46
در 0 کانالها
Get PRO
مه '22
+37
در 0 کانالها
Get PRO
آوریل '22
+35
در 0 کانالها
Get PRO
مارس '22
+24
در 0 کانالها
Get PRO
فوریه '22
+32
در 0 کانالها
Get PRO
ژانویه '22
+55
در 0 کانالها
Get PRO
دسامبر '21
+55
در 0 کانالها
Get PRO
نوامبر '21
+71
در 0 کانالها
Get PRO
اکتبر '21
+59
در 0 کانالها
Get PRO
سپتامبر '21
+71
در 0 کانالها
Get PRO
اوت '21
+75
در 0 کانالها
Get PRO
ژوئیه '21
+44
در 0 کانالها
Get PRO
ژوئن '21
+78
در 0 کانالها
Get PRO
مه '21
+32
در 0 کانالها
Get PRO
آوریل '21
+91
در 0 کانالها
Get PRO
مارس '21
+66
در 0 کانالها
Get PRO
فوریه '21
+82
در 0 کانالها
Get PRO
ژانویه '21
+67
در 0 کانالها
Get PRO
دسامبر '20
+2 821
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 26 ژوئن | +3 | |||
| 25 ژوئن | 0 | |||
| 24 ژوئن | +2 | |||
| 23 ژوئن | +5 | |||
| 22 ژوئن | +2 | |||
| 21 ژوئن | +1 | |||
| 20 ژوئن | +1 | |||
| 19 ژوئن | +2 | |||
| 18 ژوئن | +4 | |||
| 17 ژوئن | +1 | |||
| 16 ژوئن | +3 | |||
| 15 ژوئن | +6 | |||
| 14 ژوئن | 0 | |||
| 13 ژوئن | +3 | |||
| 12 ژوئن | +3 | |||
| 11 ژوئن | 0 | |||
| 10 ژوئن | +5 | |||
| 09 ژوئن | 0 | |||
| 08 ژوئن | +1 | |||
| 07 ژوئن | +2 | |||
| 06 ژوئن | +2 | |||
| 05 ژوئن | +1 | |||
| 04 ژوئن | +7 | |||
| 03 ژوئن | +4 | |||
| 02 ژوئن | +3 | |||
| 01 ژوئن | +9 |
پستهای کانال
Repost from Мониторим ИТ
Когда метрики сходят с ума: автоматическая детекция аномалий во временных рядах в Yandex Monium
А вот Яндекс пишет как они решали задачу поиска аномалий на своем внутреннем контуре Monium. Когда-нибудь обещают это это же самое реализовать и для внешних пользователей.
📱 Telegram | 📲 MAX
| 2 |  Если в вашей работе регулярно всплывают GitLab Runner, Kubernetes, ArgoCD или CDN, возможно, этот митап стоит добавить в календарь.
10 июля команда Спортса" проводит Infrastructure & Reliability Meetup
📍 Москва + онлайн
В программе четыре доклада:
• как защитить GitLab Runner;
• как устроена CDN и что важно при миграции инфраструктуры;
• опыт внедрения ArgoCD и GitOps;
• запуск GPU-задач в Kubernetes на нестандартном железе.
Выступать будут инженеры из Спортса", Wildberries & Russ и 2ГИС. После докладов обещают просмотр матча 1/4 финала ЧМ-2026 ⚽️
Подробная программа и регистрация по ссылке: https://sprts.cc/deploy | 696 |
| 3 | 📎 Пусть main делает реальную работу
«Просто свяжи всё в main, логику вынеси в пакеты, держи main.go в двадцать строк». Так советуют.
Совет не то чтобы неверный, но ведёт к конкретной поломке. Вы получаете папку cmd/ из пакетов, которые вызываются ровно из одного места, и main.go на двадцать строк вида «вызвать функцию бутстрапа в internal/app». Вы добавили лишний слой, но не добавили абстракции.
➡️ Что делать вместо
Пусть main делает настоящую работу. Читает конфиг, инициализирует пул базы, связывает зависимости, поднимает gRPC сервер и регистрирует обработчик остановки.
Если ваш main.go на двести строк, но каждая строка это честная проводка без бизнес логики и без условий по фичефлагам, это нормально:
func main() {
ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
defer stop()
cfg := config.MustLoad() // паникует на плохом конфиге, намеренно на старте
pool, err := pgxpool.New(ctx, cfg.DatabaseURL)
if err != nil {
log.Fatal("failed to initialize database pool", zap.Error(err))
}
defer pool.Close()
queries := db.New(pool)
memberSvc := members.NewService(queries)
srv := grpc.NewServer(grpc.ChainUnaryInterceptor(
logging.UnaryServerInterceptor(logger),
recovery.UnaryServerInterceptor(),
))
memberspb.RegisterMembersServiceServer(srv, memberSvc)
go func() {
if err := srv.Serve(lis); err != nil {
log.Fatal("server exited", zap.Error(err))
}
}()
<-ctx.Done()
srv.GracefulStop()
}
Это читаемо, и это реальная топология приложения, видная в одном файле. Тонкий main оправдан, только когда стартовая логика действительно сложная и заслуживает отдельного пакета. В остальных случаях честная проводка прямо в main понятнее.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека Go-разработчика
#GoToProduction | 1 180 |
| 4 | herdr
agent multiplexer that lives in your terminal.
https://github.com/ogulcancelik/herdr | 918 |
| 5 |  4 MCP-сервера, о которых стоит знать каждому DevOps-инженеру
1. Kubernetes MCP
- расследовать pod’ы в CrashLoopBackOff;
- дебажить неудачные деплои;
- анализировать состояние кластера.
Repo:
https://github.com/Flux159/mcp-server-kubernetes
2. AWS MCP
- разбирать резкие скачки расходов в AWS;
- находить неиспользуемые ресурсы;
- troubleshooting облачной инфраструктуры.
Repo:
https://github.com/awslabs/mcp
3. Terraform MCP
- проверять Terraform-планы;
- находить drift в инфраструктуре;
- объяснять изменения в инфраструктуре.
Repo:
https://github.com/hashicorp/terraform-mcp-server
4. Grafana + Prometheus MCP
- расследовать скачки latency;
- анализировать production-инциденты;
- объяснять alert storms.
Repos:
https://github.com/grafana/mcp-grafana
https://github.com/pab1it0/prometheus-mcp-server
ИИ может получать доступ к вашей инфраструктуре, понимать, что реально происходит, и помогать разбирать проблемы на основе настоящих данных, а не догадок. | 1 192 |
| 6 |  📖 Как использовать Temporal
Меня зовут Миша Иглицкий, я бэкенд‑разработчик в платформе Яндекс Еды. Наш процессинг заказов уже почти год работает целиком на Temporal. Я уже рассказывал, как эта функция безболезненно решает привычную проблему распределённой бизнес-логики. А сегодня хочу поделиться советами миграции на Temporal, которые мы вывели из нашего опыта.
❇️ Не поддавайтесь иллюзии чистой архитектуры
Бизнес-логика в Temporal Workflow выглядит очень соблазнительно. Но её изоляция от ввода-вывода (I/O) сама по себе не гарантирует хорошую архитектуру. В идеале ваша доменная область вообще ничего не должна знать о Temporal — только предоставлять нужные вам интерфейсы.
Наши грабли: первая версия Workflow была просто «простынёй» вызовов Activity в правильном порядке. Одну часть бойлерплейта для юнит-тестов мы копипастили, а вторую — адаптировали. В итоге сложность нашей системы разрослась до неподдерживаемой и пришлось менять подход.
❇️ Как надо делать:
🟢 Тестируйте бизнес-логику небольшими блоками, изолированно от Temporal SDK
🟢 Используйте интерцепторы для метрик, retry policy и кастомного логирования
🟢 На Go обязательно пользуйтесь кодогенератором для вызовов Activity
💹 Сохраняйте всё, что способно повлиять на работу бизнес-логики
Она должна всегда приводить к одному и тому же результату на одинаковой истории событий — это суть детерминистического подхода в Temporal, который обеспечивает такую надёжность.
Какие инструменты могут помочь:
🟢 SideEffect. Фиксирует в истории результат недетерминированного вычисления и не оформляет его как отдельную Activity. При повторных проигрываниях Temporal просто достаёт сохранённое значение
🟢 Версионирование. Позволяет старым Workflow работать по-старому, новым — по-новому. Полезно именно там, где бизнес-логика обновляется без возможности отката
🟢 Feature Flags. Хотя технически они реализуются через LocalActivity или SideEffect, эта парадигма гораздо гибче простого версионирования и позволяет переключить поведение только у части Workflow. Это особенно полезно для постепенного внедрения изменений с возможностью откатиться
➖ Неочевидный совет: лучший способ не выстрелить себе в ногу с версионированием — это копипаст. Весь старый код оборачивается в if version == oldVersion, а новый просто пишется рядом уже с улучшениями. Когда старых Workflow не остаётся, ветвление удаляется. Да, это временное нарушение DRY, но код всё равно скоро исчезнет. Главное — действительно потом его удалить 🤫
🔶 Читайте все подробности в статье на Хабре. Там я рассказал, что именно нам помогло обеспечить плавность перехода на Temporal и какие тесты мы используем для защиты от случайного недетерминизма. А также объяснил, что делать, если в Workflow слишком много действий, и поделился другими разными полезностями для работы с Temporal.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 1 100 |
| 7 | cardamon | 1 |
| 8 | О бенчмаркинге, часть 2
(первая часть тут)
Производительности в вакууме не бывает
Состояние одной и той же системы от запуска к запуску бенчмарков всегда разное. Даже если зафиксированы все статические параметры (настройки OS и рантайма, CPU affinity, etc), то температура процессоров, состояние кешей, layout кода в памяти всё равно плавают. Что уж говорить про внешне схожие окружения - там различий может быть еще больше.
Следовательно результаты на выходе всегда различаются.
Так какой из них нам взять за основу?
———
Помогает формулировка от Ben Sigelman: «Performance is a shape, not a number».
Производительность это всегда распределение, а не одно конкретное число. Не существует одного единственного, правильного значения.
И каждый отдельный прогон бенчмарка это просто один сэмпл из всего распределения, полученный при конкретных условиях.
Если углубить, то и внутри одного запуска мы всегда получаем распределение:
$ funclatency-bpfcc __sys_sendto -d 10 -u
usecs : count distribution
0 -> 1 : 12433 |************ |
2 -> 3 : 20394 |******************* |
4 -> 7 : 20540 |********************|
8 -> 15 : 1962 |** |
16 -> 31 : 237 | |
32 -> 63 : 19 | |
64 -> 127 : 8500 |******** |
128 -> 255 : 12 | |
256 -> 511 : 0 | |
512 -> 1023 : 4 | |
1024 -> 2047 : 5 | |
2048 -> 4095 : 1 | |
4096 -> 8191 : 2 | |
———
Задача перформанс-инженера сводится к двум вещам:
1. сужать это распределение
2. объяснять, почему оно именно такое
На ширину распределения влияет шум: переключение контекста, прерывания, соседи, и т.д. И чем шум больше, тем шире хвосты распределения.
Важный момент: шум может быть случайным, а может быть систематическим. Бороться с ними нужно по-разному.
———
Случайный шум (random noise) это то, что возникает непредсказуемо, без видимой системы. Например, фоновый процесс случайно попал на наше ядро в одних прогонах и не попал в других. Или соседнее ядро внезапно дало всплеск нагрузки на общий L3.
Лечится количеством прогонов: чем их больше, тем сильнее усредняем случайные отклонения, и тем точнее итоговая оценка.
Систематический шум (systematic bias), уже другое явление. Какой-то фактор стабильно сдвигает измерения в одну и туже сторону. Например IRQ, прибитый к нашему ядру, просыпается через равные промежутки. Такой тип шумов (или отклонений) не лечится количеством прогонов, из раза в раз будем получать искаженный результат.
В "Producing Wrong Data Without Doing Anything Obviously Wrong", авторы показали, что даже размер переменных окружения может вносить существенные искажения в итоговый результат.
С систематическим шумом борются наблюдением и рандомизацией факторов, см. Stabilizer.
———
Это объясняет, почему Passive Benchmarking плох, даже при тысяче прогонов: он не отличает один тип шума от другого. Active Benchmarking, помимо прочего, как раз про то, чтобы такие смещения находить.
Ранее мы говорили о цикле в Active Benchmarking: запустил → пронаблюдал → сформулировал гипотезу → проверил → повторил.
Это как раз про то, что борьба с шумом процесс бесконечный: зафиксировали частоту, получили распределение уже, в следующем прогоне в топ выходят прерывания, вынесли их с ядра, получили еще более стабильный результат.
Далее поднимают голову соседи по L3 кешу...
По своей природе это похоже на дрейфующее бутылочное горлышко в производительности: всегда что-то будет в топ-1.
Следующим возникает естественный вопрос: "где и когда остановиться?" To be continued.
———
Выводы
- Производительность это распределение, а не число
- Шум есть всегда, и работать с ним нужно исходя из его типа
- Борьба с шумом бесконечный процесс - главное знать, где остановиться.
———
Поставить лайк на Linkedin | 851 |
| 9 | Контроль доступа в Kubernetes
🔐Всем DevOps! Собрали для вас подборку статей с LearnKube, которая поможет разобраться, кто может подключаться к серверу API, что именно ему разрешено и как это контролировать в Kubernetes.
⏺В первой статье Гулькан Топку и Артур Чиао сосредоточились на аутентификации. На примерах поймете, как действуют ограничения к серверу HTTP API и ни слова про kubectl.
⏺Следующий этап – авторизация и RBAC. Всё о том, как ограничить доступ, чтобы у каждого пользователя и сервиса были только нужные права.
⏺И наконец, практическая модель адаптации аутентификации под свою инфраструктуру, например через LDAP.
Желаем приятного чтения и продуктивной недели!
#девопс #kubernetes #безопасность | 1 070 |
| 10 | Антиконференция Summer Merge — летняя перезагрузка для ИТ, которую нельзя пропускать 🔥
Устали от одинаковых событий и рабочей рутины? Присоединяйтесь к Summer Merge! Это по-настоящему летний формат ИТ-ивента. Программа события готова и уже на сайте.
— 3 дня на природе, без офисов и дедлайнов;
— Живые дискуссии под открытым небом вместо лекций в аудиториях;
— Soft skills, карьера и реальные боли индустрии;
— Нетворкинг, который действительно работает;
— Спорт, вечерние посиделки у костра и десятки видов активностей.
🤝 За 4 года антиконференция объединила тысячи IT-специалистов: разработчиков, менеджеров, аналитиков, владельцев бизнеса и маркетологов. Summer Merge – сообщество, в котором легко находить единомышленников, деловых партнеров, новые карьерные возможности и даже вторую половинку.
⛺ Формат палаточного лагеря и дружеская открытая атмосфера помогают перезагрузиться, посмотреть на работу по-новому и уехать с новыми идеями и вдохновением на весь год.
Спешите приобрести билет до повышения цен со скидкой 15% по промокоду «ПЯТНИЧНЫЙДЕПЛОЙ»!
Купить билеты на сайте. | 1 126 |
| 11 | 📖100 Go Mistakes and How to Avoid Them
🖋Harsanyi Teiva | 2022
Книга «100 ошибок в Go и как их избежать» показывает, как заменить распространенные проблемы в программировании на Go идиоматичным и выразительным кодом. Вы изучите десятки интересных примеров и кейсов и научитесь выявлять ошибки, которые могут возникнуть в ваших собственных приложениях. Автор книги Тейва Харсаньи систематизирует методы предотвращения ошибок по удобным категориям — от типов данных и строк до параллелизма и тестирования.
💾 Скачать книгу
Clean Code | #книги #Go & Мах | 1 086 |
| 12 | OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana.
Версия 1.37.0 (Базовая)
- HTTP:
- Метрики: http.server.request.duration, http.client.request.duration
- Единица измерения: Секунды (s)
- Атрибуты: http.request.method, url.scheme, http.response.status_code и др.
- RPC (включая gRPC и JSON-RPC):
- Метрики: rpc.server.duration, rpc.client.duration
- Единица измерения: Миллисекунды (ms)
- Атрибуты: rpc.system, rpc.service, rpc.method
Версия 1.38.0
- HTTP:
- Единица измерения: Окончательно закреплена в секундах (s). В более ранних черновиках и некоторых реализациях использовались миллисекунды, но в 1.38.0 стандарт окончательно перешел на секунды для всех duration метрик.
- RPC:
- Начало перехода от rpc.server.duration к rpc.server.call.duration.
Версия 1.39.0
- RPC:
- Переименование метрик: Метрики rpc.server.duration и rpc.client.duration начинают заменяться на rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Переход с миллисекунд (ms) на секунды (s) для новых метрик call.duration.
- gRPC/JSON-RPC:
- Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды.
Версия 1.40.0
- RPC:
- Стабилизация: rpc.server.call.duration и rpc.client.call.duration становятся основными и рекомендуемыми метриками.
- Атрибуты: Уточнены требования к атрибутам rpc.system (например, grpc, jsonrpc), rpc.service и rpc.method.
- HTTP:
- Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries).
Версия 1.41.0
- RPC:
- Финализация: Старые метрики rpc.server.duration и rpc.client.duration официально помечены как устаревшие (deprecated) или удалены из основных рекомендаций в пользу rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Строго секунды (s) для всех call.duration метрик.
- gRPC/JSON-RPC:
- Значения атрибута rpc.system стандартизированы: grpc для gRPC, jsonrpc для JSON-RPC.
Версия 1.42.0
- HTTP:
- Уточнения в атрибутах http.request.method (например, добавление поддержки нестандартных методов или уточнение регистра).
- RPC:
- Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например, error.type).
Версия 1.43.0
- RPC:
- Продолжение работы над согласованностью атрибутов между различными RPC-системами.
- Уточнения в документации по использованию rpc.service и rpc.method для gRPC и JSON-RPC.
- HTTP:
- Незначительные корректировки в семантике атрибутов server.address и server.port.
Резюме ключевых изменений:
- Единицы измерения: Повсеместный переход с миллисекунд (ms) на секунды (s) для всех метрик duration.
- Имена метрик RPC: Переход от rpc.*.duration к rpc.*.call.duration.
- Атрибуты: Стандартизация значений для rpc.system (grpc, jsonrpc) и уточнение набора обязательных атрибутов.
А как вы решаете вопрос с именами метрик и изменениями в OTEL?
#opentelemetry #observability #changelog #otel | 594 |
| 13 | nfraDev Community приглашает на InfraDev Meetup #4: про AI и не только
Прямо сейчас мы наблюдаем как AI в SDLC меняет процесс разработки — об удачных примерах и кейсах поговорим в этот раз. Обсудим, как разрабатывать инфраструктурные сервисы с помощью AI и как построить MLOps-платформу для обучения моделей. И не только: пока AI не перестроил DevOps-цикл, классические вызовы сборки образов для виртуальных машин остаются актуальными.
Спикеры
▫️Кирилл Фролов, эксперт-разработчик в отделе разработки базовых сервисов, VK Cloud, VK Tech
▫️Павел Шипилов, Старший разработчик ML Платформы в Avito
▫️Александр Александров, системный архитектор в направлении разработки и управления инфраструктурой, VK Cloud, VK Tech
Подробнее о докладах читайте на странице мероприятия.
Когда: 10 июня, с 18:00 до 23:59
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.
Зарегистрироваться. | 1 265 |
| 14 | OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana.
Версия 1.37.0 (Базовая)
- HTTP:
- Метрики: http.server.request.duration, http.client.request.duration
- Единица измерения: Секунды (s)
- Атрибуты: http.request.method, url.scheme, http.response.status_code и др.
- RPC (включая gRPC и JSON-RPC):
- Метрики: rpc.server.duration, rpc.client.duration
- Единица измерения: Миллисекунды (ms)
- Атрибуты: rpc.system, rpc.service, rpc.method
Версия 1.38.0
- HTTP:
- Единица измерения: Окончательно закреплена в секундах (s). В более ранних черновиках и некоторых реализациях использовались миллисекунды, но в 1.38.0 стандарт окончательно перешел на секунды для всех duration метрик.
- RPC:
- Начало перехода от rpc.server.duration к rpc.server.call.duration.
Версия 1.39.0
- RPC:
- Переименование метрик: Метрики rpc.server.duration и rpc.client.duration начинают заменяться на rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Переход с миллисекунд (ms) на секунды (s) для новых метрик call.duration.
- gRPC/JSON-RPC:
- Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды.
Версия 1.40.0
- RPC:
- Стабилизация: rpc.server.call.duration и rpc.client.call.duration становятся основными и рекомендуемыми метриками.
- Атрибуты: Уточнены требования к атрибутам rpc.system (например, grpc, jsonrpc), rpc.service и rpc.method.
- HTTP:
- Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries).
Версия 1.41.0
- RPC:
- Финализация: Старые метрики rpc.server.duration и rpc.client.duration официально помечены как устаревшие (deprecated) или удалены из основных рекомендаций в пользу rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Строго секунды (s) для всех call.duration метрик.
- gRPC/JSON-RPC:
- Значения атрибута rpc.system стандартизированы: grpc для gRPC, jsonrpc для JSON-RPC.
Версия 1.42.0
- HTTP:
- Уточнения в атрибутах http.request.method (например, добавление поддержки нестандартных методов или уточнение регистра).
- RPC:
- Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например, error.type).
Версия 1.43.0
- RPC:
- Продолжение работы над согласованностью атрибутов между различными RPC-системами.
- Уточнения в документации по использованию rpc.service и rpc.method для gRPC и JSON-RPC.
- HTTP:
- Незначительные корректировки в семантике атрибутов server.address и server.port.
Резюме ключевых изменений:
- Единицы измерения: Повсеместный переход с миллисекунд (ms) на секунды (s) для всех метрик duration.
- Имена метрик RPC: Переход от rpc.*.duration к rpc.*.call.duration.
- Атрибуты: Стандартизация значений для rpc.system (grpc, jsonrpc) и уточнение набора обязательных атрибутов.
А как вы решаете вопрос с именами метрик и изменениями в OTEL?
#opentelemetry #observability #changelog #otel | 978 |
| 15 |  Загадка ядра Linux: почему на 36 vCPU Cilium падает, а на 32 — нет
Автор оригинальной статьи, Пьер Мане, рассказывает, как его команда столкнулась с на первый взгляд необъяснимым поведением Cilium и как поиск решения привёл его к конфигурации ядра Linux.
Отладка сродни археологии: ты пробираешься сквозь слои абстракций, пока не доберёшься до коренной породы — ядра. Это история о том, как скрытая в коде Linux логика работы со степенями двойки приводила к случайным и загадочным падениям Cilium, из-за чего мы не могли выкатиться в production.
Подробности в статье на Хабре.
@usr_bin_linux | 1 222 |
| 16 |  Материалы и слайды своего мастер-класса на CodeFest выложил на GitHub (продублирую в комменты)
Open source на страже Kubernetes Runtime Security
https://github.com/rusdacent/codefest-2026 | 1 210 |
| 17 |  В эфире DevOps FM с первой летней подборкой новостей!
⏺ Стало известно о масштабном инциденте провайдера MIRhosting. Платформа nLighten без предупреждения отключила оборудование, и часть инфраструктуры компаний в европейских ДЦ стала недоступна.
На момент публикации остановлена работа серверов в Германии и Нидерландах. Также недоступны THE.Hosting, UFO.Hosting, Alexhost.com, Vdsina.com и другие. Накануне инцидента MIRhosting подвергся проверкам регуляторов, были предъявлены обвинения в обходе санкций.
⏺ Codex обнаружил новую уязвимость. HTTP/2 Bomb позволяет провести удалённую DoS-атаку на серверы с включённым HTTP/2. Проблема затрагивает NGINX, Apache HTTPD, Microsoft IIS, Envoy и Cloudflare Pingora в конфигурации по умолчанию.
Атака сочетает две известные техники:
• Первая использует особенности HPACK, сжатия HTTP-заголовков в HTTP/2, из-за которого расходуется больше памяти сервера.
• Вторая техника работает на задержке через flow control, из-за которого ресурсы не освобождаются.
Весь PoC – здесь, а список затронутых серверов и рекомендации – тут.
⏺ Шон Вэбб отчитался о прогрессе HardenedBSD за апрель и май 2026.
Основная часть усилий ушла на миграцию с GitLab на Radicle. Ключевые репозитории уже перенесены, хотя Вэбб сообщил, что часть интеграций ещё дорабатывается вручную. За два месяца вышло несколько рекомендаций по безопасности для FreeBSD и новые сборки FreeBSD 16, FreeBSD 15.
⏺Вслед за обзором инцидентов атак ИИ-агентов блоге Docker вышло 2 практических гайда по безопасности в песочнице.
В первой Шрини Секаран разбирает набор из 5-ти практик обеспечения безопасности: ограничение процессов, контроль сети, лимиты ресурсов и постоянный мониторинг поведения во время выполнения.
Во второй части даёт схему внедрения принципов в жизненный цикл работы ИИ-агента и оставляет подробный чек-лист для проверки.
⏺ В блоге CNCF вышел подробный разбор архитектуры платформы разработки на базе Kubernetes. Автор показывает, как объединить принципы нативных облачных технологи, IaC, GitOps и практики безопасности цепочки поставок. Логика построена на работе трёх уровней – архитектуры, платформы и приложения.
⏺ На Medium рассказали о сетях Kubernetes, от базовых принципов до практических сценариев. В статье описали логику работы pod IP, роль CNI-плагинов и особенности ClusterIP, NodePort и LoadBalancer. Отдельно вынесли частые вопросы и сценарии отладки проверок селекторов Service, бесконечным <pending> и проблемами в работе CNI.
#новостная_подборка #девопс #Docker #Kubernetes #HardenedBSD | 1 505 |
| 18 | 5 слоев кэширования в веб-приложениях: Полное руководство для Python-разработчиков #habr
https://habr.com/ru/articles/1031748/
Tags: кэширование, http-заголовки, cdn, local storage
Author: artemshumeiko | 1 365 |
| 19 | Поздравляю всех подписчиков с началом лета! И вручаю вам тёплый летний подарок: методичку по харденингу Ubuntu 24.04 на русском.
Методичка - моего авторства (@bykva)
Долгие и нудные часы чтения 1000-страничного CIS и публичной ansible роли зародили во мне идею - вот бы была готовая выжимка, по которой можно было бы настроить автоматизацию, при этом понимать что именно она выполняет. и сделать это за 1 день, а не за несколько недель.
В итоге родилась она - сжатая выжимка тысячестраничного CIS Benchmark: по каждому пункту коротко - что и зачем настраивать, с выделенными нюансами и ссылками на источники.
Внутри - более подробное описание что это и зачем.
З.Ы. саммаризация была сделана полностью без ИИ, но вот цветовое оформление, фактчекинг и правки орфографии и пунктуации я уже делал с помощью него, поэтому что-то могло поехать. Буду благодарен за ОС. | 1 010 |
| 20 | Choosing a Python Logging Library in 2026
Python использует стандартную библиотеку logging, что означает, что большая часть существующего кода на Python уже использует её на том или ином уровне, и каждая альтернатива от сторонних разработчиков строится на её основе, оборачивает его или намеренно заменяет её.
В этой статье рассматриваются следующие вопросы: какие библиотеки существуют, как они соотносятся друг с другом, где они пересекаются со стандартной библиотекой и когда каждая из них имеет смысл.
📱 Telegram | 📲 MAX | 1 339 |
