Пятничный деплой
Open in Telegram
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://t.me/s/count0_digest
Show more4 807
Subscribers
-324 hours
+27 days
+5730 days
Loading data
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
October '26Oct '26
October '26
+97
in 0 channels
September '26
+50
in 0 channels
Get PRO
August '26
+55
in 0 channels
Get PRO
July '26
+57
in 0 channels
Get PRO
June '26
+78
in 0 channels
Get PRO
May '26
+86
in 0 channels
Get PRO
April '26
+114
in 0 channels
Get PRO
March '26
+127
in 9 channels
Get PRO
February '26
+67
in 0 channels
Get PRO
January '26
+46
in 0 channels
Get PRO
December '25
+46
in 0 channels
Get PRO
November '25
+56
in 1 channels
Get PRO
October '25
+49
in 0 channels
Get PRO
September '25
+44
in 1 channels
Get PRO
August '25
+55
in 0 channels
Get PRO
July '25
+58
in 0 channels
Get PRO
June '25
+53
in 0 channels
Get PRO
May '25
+48
in 0 channels
Get PRO
April '25
+62
in 1 channels
Get PRO
March '25
+82
in 0 channels
Get PRO
February '25
+50
in 0 channels
Get PRO
January '25
+88
in 1 channels
Get PRO
December '24
+82
in 0 channels
Get PRO
November '24
+126
in 4 channels
Get PRO
October '24
+110
in 1 channels
Get PRO
September '24
+74
in 0 channels
Get PRO
August '24
+73
in 0 channels
Get PRO
July '24
+87
in 0 channels
Get PRO
June '24
+87
in 1 channels
Get PRO
May '24
+94
in 0 channels
Get PRO
April '24
+112
in 0 channels
Get PRO
March '24
+113
in 0 channels
Get PRO
February '24
+106
in 1 channels
Get PRO
January '24
+131
in 0 channels
Get PRO
December '23
+101
in 1 channels
Get PRO
November '23
+177
in 1 channels
Get PRO
October '23
+21
in 0 channels
Get PRO
September '23
+45
in 0 channels
Get PRO
August '23
+42
in 0 channels
Get PRO
July '23
+50
in 0 channels
Get PRO
June '23
+44
in 0 channels
Get PRO
May '23
+32
in 0 channels
Get PRO
April '23
+24
in 0 channels
Get PRO
March '23
+32
in 0 channels
Get PRO
February '23
+29
in 0 channels
Get PRO
January '23
+27
in 0 channels
Get PRO
December '22
+31
in 0 channels
Get PRO
November '22
+30
in 0 channels
Get PRO
October '22
+32
in 0 channels
Get PRO
September '22
+42
in 0 channels
Get PRO
August '22
+53
in 0 channels
Get PRO
July '22
+39
in 0 channels
Get PRO
June '22
+46
in 0 channels
Get PRO
May '22
+37
in 0 channels
Get PRO
April '22
+35
in 0 channels
Get PRO
March '22
+24
in 0 channels
Get PRO
February '22
+32
in 0 channels
Get PRO
January '22
+55
in 0 channels
Get PRO
December '21
+55
in 0 channels
Get PRO
November '21
+71
in 0 channels
Get PRO
October '21
+59
in 0 channels
Get PRO
September '21
+71
in 0 channels
Get PRO
August '21
+75
in 0 channels
Get PRO
July '21
+44
in 0 channels
Get PRO
June '21
+78
in 0 channels
Get PRO
May '21
+32
in 0 channels
Get PRO
April '21
+91
in 0 channels
Get PRO
March '21
+66
in 0 channels
Get PRO
February '21
+82
in 0 channels
Get PRO
January '21
+67
in 0 channels
Get PRO
December '20
+2 821
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 30 October | 0 | |||
| 29 October | +1 | |||
| 28 October | +3 | |||
| 27 October | +3 | |||
| 26 October | +1 | |||
| 25 October | +4 | |||
| 24 October | 0 | |||
| 23 October | +2 | |||
| 22 October | 0 | |||
| 21 October | +2 | |||
| 20 October | +4 | |||
| 19 October | 0 | |||
| 18 October | +2 | |||
| 17 October | +4 | |||
| 16 October | +1 | |||
| 15 October | +1 | |||
| 14 October | +2 | |||
| 13 October | +5 | |||
| 12 October | +12 | |||
| 11 October | +19 | |||
| 10 October | +5 | |||
| 09 October | +4 | |||
| 08 October | +13 | |||
| 07 October | +1 | |||
| 06 October | 0 | |||
| 05 October | 0 | |||
| 04 October | +3 | |||
| 03 October | +2 | |||
| 02 October | +1 | |||
| 01 October | +2 |
Channel Posts
⚡️ Онлайн-митап IT_ONE: Между кодом и продом
Три прикладных доклада для тех, кто отвечает за стабильность инфраструктуры. Обсудим на встрече защиту Helm-чартов
от некорректных данных, научим писать надежные проверки
на helm-unittest и разберем развертывание собственной LLM-модели без лимитов на токены.
12 ноября
18:00 (мск), онлайн
Регистрация: по ссылке
Приглашаем разработчиков, DevOps-, QA- и SRE-инженеров, тимлидов и архитекторов.
В программе митапа — три выступления:
1️⃣ Персональный ИИ своими руками. Руслан Кашафутдинов расскажет, как развернуть свою ИИ-модель и работать без квот облачных сервисов. 2️⃣ Helm-чарты: когда они действительно нужны. Виталий Перваков разберет защиту от некорректных данных и сравнит инструменты проверки конфигураций. 3️⃣ Стабильные unit-тесты для Helm-чартов. Андрей Слатимов покажет, как с помощью helm-unittest находить ошибки шаблонизации и проверять обратную совместимость.Приходи со своими рабочими вопросами — можно будет обсудить их с экспертами. Авторы лучших вопросов получат мерч IT_ONE: футболку, стикеры и плед. 📎 Всем зарегистрированным участникам после митапа отправим презентации спикеров и другие полезные материалы. Регистрируйся до 11 ноября, 23:59 (мск)
| 2 |  Команда DevCrowd* запустила второе исследование инженеров, которые отвечают за надёжность: SRE, DevOps, платформенных инженеров и всех, кто держит прод в строю.
В этом году главный сюжет — как меняется роль в эпоху AI. Смотрят на то, что уже автоматизируется, а что, наоборот, дорожает: пускают ли AI действовать в проде и где проходит граница доверия, добавляет ли сгенерированный код новых инцидентов, и что остается исключительно работой человека, когда рутину забирает машина. Отдельный блок про soft skills: какие навыки SRE-специалисты считают важными, в каких проседают и что не заменит AI.
Не обошли и человеческую цену надежности: сколько стоят дежурства по времени, деньгам и здоровью и на ком в команде реально концентрируется нагрузка.
Часть вопросов повторяет прошлогодний опрос, так что по грейдам, зонам ответственности и рынку будет видна динамика, а не разовый срез.
Опрос анонимный на 12 минут. Отчет обещают уже декабре.
🌐 Принять участие: https://survey.devcrowd.ru/sre-2026
*DevCrowd — независи | 486 |
| 3 | No text... | 434 |
| 4 | whiteboard
Whiteboard is an open-source desktop app where humans and agents can architect software together in a common workspace.
https://github.com/devdotfast/whiteboard | 539 |
| 5 |  Какие доклады вы хотите услышать на DevOpsConf 2027?
Мы начали собирать программу и первым делом хотим узнать, что сейчас болит сильнее: AI-агенты с доступом к проду, переезды между облаками и аварийное восстановление или растущая нагрузка на команду?
От ваших ответов зависит, каким темам мы дадим больше места и каких спикеров пойдем искать. Поэтому будем рады любому мнению, даже если вы еще не решили, поедете ли на DevOpsConf.
Опрос займет около 5 минут. В благодарность откроем вам записи Saint HighLoad++ 2026 в личном кабинете — будет что посмотреть вечером.
Пройти опрос 👈 | 606 |
| 6 |  Как VictoriaLogs хранит логи в колоночной структуре
А вот добрые люди опубликовали перевод оригинальной статьи, о которой я публиковал пост пару дней назад.
В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go.
Читать на Хабре
📱 Telegram | 📲 MAX | 681 |
| 7 | Алерты, которые не бесят
Привет, %username%! Тут Антон Быстров из Cloud.ru написал на Хабре толковый текст про alert fatigue — ту стадию, когда в дежурном чате сотни непрочитанных и ты просто убираешь телефон. С этого момента мониторинг уже не работает, даже если правила формально срабатывают.
Полезное из статьи:
- Готовые наборы вроде Awesome Prometheus Alerts — нормальный старт, но не финал. Автор правил не знает, как устроен твой сервис.
- Будить человека стоит, только если проблема реальна, важна, срочна и требует действия (тест Роба Эвашука). «CPU 90%» без контекста его не проходит.
- Алертим на пользовательские симптомы («не создаётся ресурс в проде, зона А»), а не на причины. Исключение — когда до отказа осталось меньше времени, чем нужно на фикс.
- Пороги — через SLO и burn rate на двух окнах, длинном и коротком, а не «10 пятисоток за час».
- Перед включением прогоняем выражение по истории и известным инцидентам. И помним ловушку с up == 0: пустой результат значит и «всё ок», и «данных нет».
- Группировка и подавление в Alertmanager: один инцидент — одно сообщение, остальное — контекст.
- В уведомлении: что сломалось, масштаб, что ещё сработало, с чего начать, кто реагирует. Плюс ссылки на дашборд и runbook.
- Регулярно разбираем срабатывания: оставить, поправить, перевести в задачу, оставить для диагностики или удалить.
Отдельно плюсую мысль, что ещё один чат «для несрочных алертов» — не решение, а та же свалка в другом месте.
https://habr.com/ru/companies/cloud_ru/articles/1099844/
#SRE #Monitoring #Alerting #Prometheus #AlertManager #SLO #OnCall #Observability #Habr
Мишка на сервере — про надёжность, инциденты и инженерную практику | 687 |
| 8 | Перенос Docker-контейнера между двумя Linux-хостами
При смене Docker-хостов мы часто думаем: «Я копирую, перезапускаю — и всё». Но Docker-сервис — это не только образ: есть ещё тома, переменные окружения, порты, иногда база данных… и именно здесь всё ломается, если действовать слишком быстро.
В статье описано как убедиться в том, что все правильно перенесено →
@usr_bin_linux | 806 |
| 9 |  Kube API не отвечает, LoadBalancer не пропускает трафик, DNS не резолвит, исходящие запросы не уходят. Причина обычно кроется на стыке облачной сети и кластера, и найти её без понимания всей цепочки сложно.
3 ноября в 12:00 Роман Ерема, разработчик в команде Managed Kubernetes MWS Cloud Platform, на практике покажет:
⏺️как взаимодействуют сеть облака, CNI и сеть Kubernetes
⏺️как работают SNAT и Source IP
⏺️когда нужен externalTrafficPolicy: Local и почему при нём может не проходить health check
⏺️как диагностировать проблемы на реальных кейсах (live-demo)
Все участники получат чек-лист для проверки доступности.
Полезно инженерам, разработчикам и специалистам по сетям и облачной инфраструктуре.
🗓 3 ноября в 12:00
Регистрируйтесь по ссылке | 857 |
| 10 |  Пятничный деплой, который можно запланировать заранее
30 октября Ozon Tech проведёт Platform Meetup — поговорят о том, как устроена платформа большого бигтеха и какие инженерные решения стоят за её развитием.
В программе:
— архитектура платформы, CI/CD, стандарты разработки и сетевая инфраструктура;
— высвобождение 7000+ CPU и оптимизация архитектуры через сокращение микросервисов;
— новый инструмент платформенной аналитики и работа с большими данными.
Три доклада по 20 минут — а дальше весь вечер на вопросы, технические дискуссии и обмен опытом с руководителями платформенных команд Ozon Tech.
Когда: 30 октября, 19:00 мск
Где: Москва, лофт Casa Picassa
Регистрация: ozon.tech | 1 239 |
| 11 |  Четверг, а значит время проектов от подписчиков! 🌝
Тем, кто пропустил, что такое четверговые проекты от подписчиков, можно прочитать тут - https://t.me/tech_b0lt_Genona/4983
Сегодня у нас редкий гость рубрики - подкаст! Тимура знаю уже достаточно давно, пусть и виртуально. Тимур прекрасен!
Слово автору @tym83
---
Всем привет!
Месяц назад вместе с Артемом, Юлей и Сергеем мы запустили Kubernetes Community Podcast. В нем мы рассуждаем о будущем оркестратора, приглашаем интересных гостей, разбираем глубокие технические вопросы, связь софта и железа, методы дебага проблем, интересные и неожиданные кейсы из практики.
Например, как белка устроила гнездо в коаксиальном кабеле, поломав спутниковую связь, почему 5G это скорее маркетинг, чем реальность, и когда выгоднее вложиться в яблочный ПК, чем покупать сервер с зелеными GPU.
На сегодня вышло уже четыре выпуска:
🌟👽 Микроволновка против спутника, в DevOps в 34 и бельчата с Александром Крючковым
📡 K8s внутри 5G, edge без BMC, любовь к VMware и KubeVirt с Иваном Екимовым
📉 Что не так с AI: $200 подписка, 72 млн стойка, ноль прибыли с Эдгаром Сипкой
☸️ Каким бы стал Kubernetes, если бы его разработали сегодня
Ведущие:
Артем Горячев, Kubestronaut
Юлия Брунер, DevOps-инженер и автор канала @devops413
Сергей Фролов, DevOps-инженер и Open Source-контрибьютор
Тимур Тукаев, по вечерам трогает Cozystack
Подкаст делается полностью на энтузиазме и не преследует никаких коммерческих целей:)
Послушать и посмотреть:
- Apple Podcast
- Mave
- Яндекс Музыка
- YouTube
- Spotify
--- | 1 417 |
| 12 | Семь привычек Linux-инженера, которые спасают прод
Внутри — семь разборов сбоев: от прав на домашнюю директорию до деградации производительности после обновления ядра.
Интересный кейс про бэкапы между дата-центрами. Скорость упиралась примерно в 1 Гбит/с, и ровная полка на графике выглядела как сетевое ограничение. Но отдельный тест показал, что канал спокойно отдаёт свои 5 Гбит/с. Дальше выяснилось, что rsync поверх SSH упирался в производительность одного ядра, а сжатие и дедупликация добавляли дополнительную нагрузку.
Читать дальше на Хабре →
@usr_bin_linux | 1 253 |
| 13 |  20 октября в 12:00 (мск) пройдёт бесплатный вебинар «Мониторинг событий безопасности в MWS Cloud Platform».
Разработчики сервиса:
✅ Расскажут про возможности сервиса аудитных логов в облаке MWS Cloud Platform
Покажут в прямом эфире, как экспортировать их в SIEM-системы
✅ Вебинар будет полезен CISO, ИБ-специалистам, DevOps-инженерам и SOC-специалистам. Регистрируйтесь, подключайтесь к прямому эфиру и задавайте вопросы в чате.
🗓 20 октября в 12:00
Зарегистрироваться | 1 254 |
| 14 | Building a Custom Metrics Exporter for Kubernetes
Kubernetes поставляется со встроенной функцией отслеживания загрузки CPU и использования памяти, но большинство решений по масштабированию в реальных условиях зависят от сигналов, которые находятся за пределами этого узкого диапазона: сколько сообщений ожидает в очереди, сколько времени заняла последняя пакетная задача, сколько активных WebSocket-соединений поддерживает под. Когда встроенных метрик недостаточно, экспортер метрик восполняет этот пробел.
В этой статье подробно описано, как создать такой контейнер с нуля, упаковать его в подобие контейнера и подключить к кластеру, чтобы Prometheus — и в конечном итоге HorizontalPodAutoscaler — могли его использовать.
Статья в блоге Kubernetes
📱 Telegram | 📲 MAX | 1 117 |
| 15 | Сбор метрик или отправка метрик - разница, которая может искривлять данные
Привет, киты 🐳!
Если вы думаете, что сбор метрик по pull-модели и отправка через push это примерно одно и то же, то я вас разочарую. Это не так. В push-модели есть особенности, которые заставят ваши данные выглядеть совсем не так, как вы ожидаете. А иногда разработчики пытаются писать метрики в VictoriaMetrics Remote-write эндпоинт в том же формате, что и для Prometheus PushGateway, а потом искренне удивляются, почему метрики не появляются. Многообразие форматов действительно может породить путаницу.
Зачем вообще отправлять метрики напрямую, вместо обычного вытягивания из эндпоинта /metrics?
Для короткоживущих приложений интервал сбора при pull-модели может оказаться больше времени работы самого приложения. Сборщик просто не придет. Частый пример: cron-задачи или PHP-приложения, которые живут только на время обработки запроса. Тут push метрик спасает. Хотя нет, вру, можно придумать свое костыльное хранилище на Redis и выставить их для сбора на /metrics. Но по факту это просто изобретение PushGateway, которое тащит лишнюю зависимость.
Кстати, для cron-задач, которые выполняются более 3-5 минут, я рекомендую выставлять отдельный /metrics эндпоинт и настраивать обычный pull-сбор. Это оправдано, когда вы хотите следить за прогрессом задачи в реальном времени, а не только получить данные о факте ее начала и окончания.
Но вернемся к граблям. Вот кусочек из кода модуля для отправки метрик в Prometheus PushGateway, с которым мы столкнулись:
return &Pusher{
inner: push.New(endpoint, serviceName). // выставить в метрике job=serviceName
Gatherer(gatherer).
Grouping("k8s_cluster_name", cfg.clusterName).
Grouping("k8s_namespace_name", cfg.namespace).
Grouping("k8s_pod_name", cfg.podName).
Grouping("k8s_cronjob_name", cfg.cronjobName).
Grouping("k8s_job_name", cfg.jobName)
}
Вы можете по ошибке решить, что здесь добавляются лейблы в метрику. Но это не так (хотя Prometheus и увидит их как лейблы при сборе). Для самого PushGateway Grouping это как адрес книги в библиотеке (ряд, полка, раздел). Он отвечает за физическое хранение переданной в него группы метрик в памяти шлюза.
В PushGateway есть два поведения: перезаписывать (Push) и добавлять (Add). Для cron-задач подходит перезапись, так как нам важны данные о последнем запуске. Но в примере выше Grouping неверный. Если засунуть динамические значения (например имя пода) в Grouping, для каждого запуска cron или каждого пода создается новый адрес хранения. В итоге вы не видите полной картины по одной задаче. Хуже того, старые ячейки с метриками мертвых подов останутся в PushGateway навсегда. Он не удаляет метрики сам по TTL, поэтому они будут копиться как мусор, пока их не очистят через API. Это классическая утечка памяти.
Как это чинить?
Grouping key должен быть стабильным. Для cron-задач оставить в grouping только job (имя сервиса) и instance (имя самого крона). Всё остальное (namespace, pod_name и прочее) перенести в обычные лейблы метрик. Это решит проблему с мусором и некорректными графиками.
А вы используете PushGateway в своих проектах или стараетесь избегать его любой ценой, перестраивая архитектуру под pull? И сталкивались ли с проблемой вечных метрик в PushGateway после смерти подов?
#SRE #prometheus #PushGateway #observability #метрики #DevOps #ЛетитКит | 1 274 |
| 16 | Вот вроде очевидно, но нет | 1 137 |
| 17 |  +2Обновляем гитлабчики 💅💅💅
CVE-2026-97229 - Integer Overflow issue in CI/CD Regular Expression Compiler impacts GitLab CE/EE
GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation.
Impacted Versions: GitLab CE/EE: all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2
CVSS 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Thanks joaxcar for reporting this vulnerability through our HackerOne bug bounty program.
GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/
В этот раз Critcal один (хоть и на 10-ку), но в целом список приличный. | 1 317 |
| 18 |  Выложили доклады с DevOops 2025
YT: https://www.youtube.com/playlist?list=PL-ety8gh7rTqGi8ulve-IUZ9O5tpUo0dX
VK: https://vkvideo.ru/playlist/-149053226_21
Программа
https://devoops.ru/archive/2025/schedule/table/ | 1 295 |
| 19 | Когда мы слышим Redis, обычно первое, что приходит на ум - это кэш.
Но Redis удивительно простая и при этом универсальная технология, которую можно применять для широкого круга задач.
В новом видео за 36 минут кратко разобрали все что нужно знать про Redis для System Design: https://www.youtube.com/watch?v=mlIB7AOG-GU
Рассмотрели 7 различных сценариев Redis:
• cache
• rate limiter
• leaderboards / priority queues
• geosearch
• distributed locks
• Streams
• Pub/Sub | 1 967 |
| 20 |  Netronome — self-hosted-мониторинг качества сети и интернет-каналов
Если Speedtest Tracker, который я упоминал одном из прошлых постов, в первую очередь собирает историю тестов скорости, то Netronome идёт дальше: объединяет проверку пропускной способности, диагностику маршрутов и мониторинг удалённых серверов.
Что умеет Netronome:
— запускать тесты через Speedtest.net, LibreSpeed и iperf3;
— выполнять проверки автоматически по расписанию;
— сохранять историю скорости, задержки и других показателей;
— непрерывно контролировать потерю пакетов через ICMP;
— анализировать маршрут с помощью traceroute и MTR;
— показывать статистику потерь отдельно по каждому узлу маршрута;
— контролировать DNS-запросы;
— собирать с удалённых серверов загрузку CPU, память, диски, температуру и сетевой трафик;
— отправлять уведомления в Telegram, Discord, email и другие сервисы через Shoutrrr.
Для распределённого мониторинга используются легковесные агенты. Их можно установить на домашних серверах или удалённых площадках, а результаты свести в один веб-интерфейс. Есть интеграция с Tailscale и автоматическое обнаружение агентов внутри tailnet — удобно, если не хочется публиковать служебные порты в интернете.
Netronome потенциально может подойти в сценариях:
— контроля качества домашнего или офисного интернет-канала;
— сравнения фактической скорости с тарифом провайдера;
— мониторинга связи между филиалами через iperf3;
— поиска участка маршрута, на котором начинаются потери;
— наблюдения за серверами без развёртывания полноценного стека Prometheus;
— контроля трафика VPN-контейнеров, например Gluetun.
Само приложение написано на Go, а интерфейс — на React и TypeScript. Frontend и backend упакованы в один исполняемый файл. По данным разработчиков, типичное потребление памяти составляет около 35 МБ. Для хранения можно использовать SQLite или PostgreSQL.
Развернуть Netronome можно готовым бинарником либо в Docker. В контейнерный образ уже включены iperf3, LibreSpeed CLI, traceroute, MTR и vnstat. Есть встроенная авторизация, OIDC и ограничение доступа по IP.
Из нюансов: тесты скорости создают реальную нагрузку на канал, поэтому расписание нужно выбирать аккуратно. Для полноценной работы MTR потребуются дополнительные привилегии, а некоторые функции при установке без Docker зависят от внешних утилит.
Основная функциональность распространяется на бесплатной основе, но разрабы отдельно предлагают платный набор дополнительных тем интерфейса.
Репыч на GitHub
@usr_bin_linux | 2 108 |
