😃 Еду 🚃🚃🚃🚃 4 декабря 2025 слушать доклады в ➡️ Сколково на Первую Kuber Conf, что организована в рамках проекта "Ассоциация облачно-ориентированных технологий"
https://aot-kuberconf.ru/

Если кто-то тоже там будет, напишите в комментариях — встретимся.

#конференция #k8s

Никогда не встречался с этой особенностью коротких ссылок #Grafana https://t.me/livePercentile/6

У нас как-то давно слетели настройки в Grafana и эти короткие ссылки стали при создании указывать на localhost. С тех пор проверяю каждый раз ссылку после сосздания 🛠️, туда ли ведет.

#особенности #мониторинг #хитрости

Привет, %usernsme%! Я с неделю как член ПК новой крутой независимой конференции по мониторингу — 🔭 Observability Conf.

🗓 Пройдёт она 19 марта 2026 года в Москве (место уточняется).

1️⃣ Это первая конференция нового комьюнити, которое призвано развивать технологии мониторинга в РФ, поэтому единственным ограничением по темам будет — всё вокруг мониторинга, наблюдаемости, метрик, логов и т.д. То есть рассказать можно и о своём решении, но минимизировать открытый pr компании и продукта, добавив полезности от внедрения, описание кейсов и эффекта.

🆓 Сама конференция будет бесплатная, регистрация скоро откроется, поэтому прийти может стать любой зарегистрировавшийся.

🏃На конференции будет 2 трека:
1. 🧭🙎‍♂️ про бизнес, процессы и эффект от внедрения или оптимизации систем мониторинга
2. 🛠🧠 хардкорный — про технику, задачи, реализацию.
❓ Допускаются доклады, которые уже читались, главное их немного освежить и скорректировать название с тезисами.

➡️ Приглашаю тебя стать частью этого события в формате спикера конференции.

🥎🥎🥎 Заполняй информацию о докладе в документе и пиши мне @r3code. Приложи расшаренную ссылку или PDF заявки.🥎🥎🥎

🧙‍♂️ Если остались вопросы, задавай — отвечу. Также можете писать Александру Крылову (@darkbenladan).

P.S. Если это интересно, следующим твоим шагом будет предоставление темы/названия доклада и тезисов.
Доклады утверждаются программным комитетом (состав ПК скоро будет опубликован на новом сайте конференции).

О 4 золотых сигналах:

https://t.me/sre_community/310

🔍 А как вы меряете Saturation? Это не всегда очевидно...

#sre #основы

🤔 Как в реальной жизни люди применяют rate-limiter?

Наши уважаемые индусы из Мумбаи очень озаботились культурой поведения на дороге. А водители там очень эмоциональные и начинают бибикать, как только включают красный светофор. И гул этот растет неимоверно.

Посмотрите на видео это решение. Какую реализацию rate-limiter напоминает?

#смешная_суббота #надежность #sre #fun #жизнено

🤖Проблем хез старьиу хай спу он нодэ диэмикс-сиэйч-дев-ноль-один. Плс реакт асап ит майт бы сериос.

Или

🙋 Диман, тут на проде ошибок под 50% сыпать начало на сайте, можешь подключиться?

Так могут звучать разные озвучки алертов дежурного SRE. Какой вариант в 2 часа ночи лучше сработает, думается, что конечно второй 🥈. Но оказывается и все немного сложнее с нами человеками. Коллега по цеху Кирилл Борисов рассказал о всех перепетиях в докладе 🌱Как жить, когда у тебя N тысяч алертов в секунду на DevOpsConf 2025 — рекомендую к просмотру, жизненно.
— VkVideo

🥸 А как вы называете того кто звонит про алерты инциденты в дежурстве?

#sre #инциденты #oncall #доклад #devopsconf

Вышли результаты исследования DevCrowd: Исследование SRE-специалистов 2025, в которых многие из нас приняли участие https://t.me/devcrowd_official/40

#исследование #sre #результаты

Как повышать свою устойчивость архитектурно.

Кирилл Юрков - член команды VictoriaMetrics описал самые популярные подходы повышения устойчивости от стартапов до гипермасштабных ентерпрайзов в контексте victoriametrics инсталляции.

Вас ждут не только факты, но и трейдофы, ловушки которые могут поджидать на каждом уровне масштабирования.

Посмотрим на опыт коллег:
https://docs.victoriametrics.com/guides/vm-architectures

#sre #статьи #колллеги

Ребята тут пошли холиварить за SRE / DevOPS. Попкорн 🍿 и поехали посмотрим 😏 https://t.me/jtprogru_channel/4427

В Google нет например DevOPS инженеров, там все SRE, т.к. они называют SRE реализацией DevOPS

А вы делите SRE и DevOPS инженеров?

🔳 Он не защитит вас от шумных соседей — и это не участковый, а #Kubernetes

Kubernetes умеет ограничивать CPU и память на уровне контейнера. Но вот других критически важных ресурсов — сети (in/out, пропускная способность и rate пакетов) и дискового I/O (пропускная способность и IOPS для persistent volumes) — он не умеет ограничивать.

Результат — классические проблемы "шумных соседей" (noisy neighbour), которые почти невозможно предсказать, быстро диагностировать и уж тем более предотвратить.

Например:
- Один под сожрал весь сетевой канал на ноде → остальные поды начинают валиться с таймаутами, retry штормы.
- Другой под устроил диск-бомбардировку -> соседи получают latency в десятки и сотни миллисекунд при работе с PV, потому что SSD исчерпал IOPS-бюджет.

🤔 Можно, конечно, вручную рассовывать поды по нодам в зависимости от их I/O-профиля. Но это — хрупкий, ручной и трудоёмкий процесс наподобие балансировки нагрузки в эпоху Bash-скриптов и SSH-хостов.

Иногда кажется, проще начать старинке разносить сервисы по хостам вручную, без абстракций. Хотя бы понятно, кто с кем делит диск и сеть.

🧙‍♂️А зачем тогда Kubernetes?

Он решает другие, но не менее важные задачи:
- Оркестрация жизненного цикла подов (запуск, рестарт, graceful shutdown).
- Самовосстановление: падающий под поднимется автоматически.
- Декларативное управление инфраструктурой: "я хочу три реплики и мне пофиг, где они"
- Service discovery и балансировка трафика между подами
- Rolling updates без простоя
- Упрощённое управление секретами и конфигами.

Но изоляция по I/O-ресурсам — не по адресу . Это нужно решать на других уровнях: CNI-плагинами, eBPF, storage-классами с QoS, либо просто проектировать архитектуру так, чтобы «тяжёлые» и «чувствительные» нагрузки не оказывались на одной ноде.

K8s решает определенный набор проблем, но вводит и свои собственные. Главное — понимать, где заканчивается его зона ответственности.

🙋 А у вас были похожие проблемы в K8s?

Только опубликовал новую статью про vector.dev.
Про возможные вечные блокировки пайплайнов даже при валидных сообщениях. Про важные настройки.

И конечно по пути родились несколько вопросов, надеюсь поможете с ответами

https://habr.com/ru/articles/977412/

#статья #логи #vectordev #грабли

💫 Стартую рубрику "Видео моих докладов".

Первое мое выступление на конференциях — DevOpsConf 2024. Готовился полгода, было очень интересно услышать мнение других инженеров о нашей работе.

#Доклад на DevOpsConf 2024
Логи: как EFK нас довел... до Vector и Clickhouse

И серия статей на Habr по докладу

-> Презентация и материалы к докладу

📺 #Видео
——————
- YouTube

Интересно видно ли будет на последующих видео какой-то прогресс меня как спикера, я не сравнивал 😆

А вы выступали? Помните как это было впервые?

#видео #доклад #devopsconf #vector #логи #спикер

💫 Опубликовал новую статью по #sre, на которую навели меня читатели канала.
Длины поста тут бы мне точно не хватило, потому публикую на Habr.

Это статья не для самих SRE, а для тех людей и компаний, которые думают "У нас нет SRE" – не значит "у нас нет надёжности". Даже без SRE-инженера ваша команда уже что-то делает для надёжности. В статье покажу, как увидеть уже существующие у вас практики и понять, куда двигаться дальше.

https://habr.com/ru/articles/979686/

#статья #инструмент #практики #habr

Вот это да! Друзья — нас уже 100.

Благодарен вам за то, что читаете меня и делитесь опытом в комментариях.

Макс тут перевел статью, где объясняют разницу и общность инженеров DevOps, SRE, Cloud, Platform. Не могу не поделиться
https://t.me/youngmaxnotes/101

#sre #статья #перевод #различия #devops

Всех с Новым годом 🎄!

Желаю всем продвинуться ближе к своим целям и достичь их.

Важно сохранить все хорошее, что дал 2025 и нести с собой.

Не забывайте живых людей - хоть технологии дают прямую связь, быть с догоргими вам людьми вместе не сравнимо с сеансом видеосвязи.

Рубрика "Видео моих докладов".

В прошлом году второй раз выступил на конференции DevOpsConf. Готовился уже не полгода, но слайдов было под 200. Да - я люблю диафильмы с ясным развитием сюжета покадрово 🎦. И в этот раз я тоже рассказывал про развитие нашей системы логов и было что рассказать.

#Доклад на DevOpsConf 2025
🏋🏻‍♂️Укрощение хаоса логов с помощью модели OpenTelemetry, Vector и ClickHouse. Итоги за два года

-> Презентация и материалы к докладу

📺 #Видео
——————
* RuTube
* VkVideo
* YouTube

🤓 Угадайте что на фото и зачем?

#видео #доклад #devopsconf #vector #opentelemetry #спикер

🙀 Что на самом деле имел в виду Google под «SRE implements DevOps»?

Из книги Google SRE:

"SRE is what happens when you ask a software engineer to design an operations function."
"SRE is one implementation of DevOps."

Это не значит, что SRE = DevOps × 2.

Как мы знаем из программирования, у одного абстрактного класса может быть множество реализаций — и каждая решает общую задачу своим способом. При этом реализация ≠ наследование.

DevOps — это философия: культура, автоматизация, измеримость, совместная ответственность.
SRE — это конкретная роль, которая реализует эту философию через инженерные практики:
- SLO/SLI как договор о надёжности,
- автоматизация рутины (toil reduction),
- управление рисками через бюджет ошибок,
- отказ от «100% uptime» в пользу баланса скорости и стабильности.

SRE не заменяет DevOps — он инструмент для его воплощения.

🤌🏼 А что с SR-инженерами? 🔭⚙️

Мы кто? Мы реализация или наследование от DevOps инженера? Тут также реализация ≠ наследование.
Поэтому я считаю, что SRE != "DevOps на стероидах". SRE может вырасти хоть из инженера поддержки первой линии. Лично я — реализация из backend-разработчика.

Для меня #SRE — это инженер с T-образной экспертизой:
- горизонталь — общее понимание стека (от сети до бизнес-логики),
- вертикаль — глубокая специализация в одной области (экспертиза).

В Google, например:

- Один SRE может быть экспертом по распределённым системам,
- Другой — по масштабируемой автоматизации,
- Третий — по надёжности ML-пайплайнов.
Никто не ожидает, что один SRE будет знать всё на уровне DevOps + DBA + Security + Network Engineer.
Ожидается, что он умеет диагностировать и координировать, а не заменять.

Замечу, что в маленькой компании или стартапе с 5-10 микросервисами и небольшим набором технологий ты еще можешь "закрыть все сам" (скорее всего ты разработчик или даже cto в роли sre) - щупалец хватит, но с ростом компании — у тебя щупалец не добавится.

В моём случае "вертикаль" — это observability и #SLO. Я не заменяю #DevOps или DBA, но умею диагностировать инцидент, сформулировать гипотезу и привлечь нужного эксперта — и именно в этом, на мой взгляд, суть надёжности как инженерной дисциплины. Инженерное мышление + системное видение, а не универсальная экспертиза.

🐳 А что думаете вы?

Новость-новость ℹ️

С этой недели я член программного коммитета DevOpsConf (Онтико).

👉 Буду помогать ПК в отборе докладов и спикерам с подготовкой докладов.
🧙‍♂️ Это мне сейчас интересно, потому что позволяет, как специалисту, еще шире взглянуть на нашу область работы в ИТ, познакомится с новыми людьми.

🗣️ С докладчиками же хочется делится своим опытом докладчика, передавать им его, чтобы их материал раскрывался и приносил пользу слушателям.

————————————————
И сразу объявление 📣

Пока ты читал, возможно, у тебя дозрела идея классного доклада и ты захотел подать его на 🔥DevOpsConf 2026.

Правда срок приема докладов уже вышел 😐. Но тебе везет! — Вот тот самый последний вагон в который можно запрыгнуть с докладом!

🗓 Зарегистрируйся сейчас и приходи на 🎤 Онлайн-встречау с ПК DevOpsConf во вторник, 27 января, 18:00 — после нее ты получишь секретную ссылку для подачи заявки на доклад до 1 февраля 2026 💫

#devopsconf #конференции #пк #новость

🔥 Ухты! Observability Conf обзавелась своим сайтом!

🔭 https://observability-conf.ru

✏️ Регистрируйся и приходи послушать.
- Оффлайн:
г. Москва, м. Бауманская, F-Loft 19 марта 2026
- или онлайн (ссылка позже после регистрации)

#observabilityconf #конференция #анонс #регистрация

👉 Observability Conf приглашает к подаче заявок на доклады.

🎯 Кто не приносил доклад мне лично, но хочет рассказать про мониторинг и observability, или знаете того кто имеет интересный доклад ?!
🫴 Приглашаем подать заявку до 27 февраля 2026.

Я знаю многие сомневаются нужно ли вообще - нужно. Нужно. Особенно если вы были в ограниченных условиях, в маленькой или средней компании.

👉 Ждем твою заявку тут https://observability-conf.ru