🔥Выгорание? Нет. Это меня ВЫЖИГАЮТ 🥵
Все вокруг говорят про выгорание. Как будто это какая-то мистическая болезнь, которая сама по себе накатывает на айтишника.
Но давайте начистоту: выгорание — это не болезнь. Это симптом. Симптом того, что на работе тебя систематически ВЫЖИГАЮТ.
Это не ты «не справляешься», а с тобой и вокруг тебя происходит что-то, что методично высасывает всю энергию, мотивацию и веру в себя.
Давайте сменим оптику. Не «я выгорел», а «меня выжгли». И вот эти вот «выжигатели», мы их все знаем. Узнаёте? 👇
Признаки среды, которая тебя выжигает:
1️⃣ Токсичный перфекционизм. Когда «сделано хорошо» — недостаточно. Когда код возвращают на пятнадцатый раз из-за мелочи, не влияющей на результат. Когда процесс доведения до идеала убивает саму идею.
2️⃣ Перманентный аврал. Деадлайны — это норма. «Срочно!» — это стандартный приоритет. Ощущение, что ты не работаешь, а постоянно тушишь пожар, который кто-то устроил.
3️⃣ Микроменеджмент и отсутствие доверия. Каждый твой шаг под прицелом. Ты не специалист, а исполнитель. У тебя отбирают право на собственную экспертизу и решение.
4️⃣ Бессмысленные задачи. Когда ты тратишь неделю на фичу, которую закроют через месяц. Когда от твоей работы нет видимого результата или ценности. Ощущение бега в колесе.
4️⃣ Вечный «информационный шум». Бесконечные митапы, которые можно было заменить сообщением в чате. Десятки чатов, где @all используют по любому поводу. Невозможно сосредоточиться на 2 часа подряд.
6️⃣ Размытая ответственность и политика. Когда непонятно, кто за что отвечает. Когда решения принимаются не по здравому смыслу, а по тому, кто громче крикнул или у кого больше полномочий.
Это не твоя личная слабость. Это — ядовитая среда.
А вы что замечали? 📍
Какой из этих пунктов бьёт больнее всего? Что ваш главный «выжигатель».
Давайте называть вещи своими именами. Может, тогда мы сможем что-то изменить. Или хотя бы понять, когда пора уносить ноги.
#выгорание #антиwork #it #работа #токсичнаяработа #mentalhealth #letitkit
Все вокруг говорят про выгорание. Как будто это какая-то мистическая болезнь, которая сама по себе накатывает на айтишника.
Но давайте начистоту: выгорание — это не болезнь. Это симптом. Симптом того, что на работе тебя систематически ВЫЖИГАЮТ.
Это не ты «не справляешься», а с тобой и вокруг тебя происходит что-то, что методично высасывает всю энергию, мотивацию и веру в себя.
Давайте сменим оптику. Не «я выгорел», а «меня выжгли». И вот эти вот «выжигатели», мы их все знаем. Узнаёте? 👇
Признаки среды, которая тебя выжигает:
1️⃣ Токсичный перфекционизм. Когда «сделано хорошо» — недостаточно. Когда код возвращают на пятнадцатый раз из-за мелочи, не влияющей на результат. Когда процесс доведения до идеала убивает саму идею.
2️⃣ Перманентный аврал. Деадлайны — это норма. «Срочно!» — это стандартный приоритет. Ощущение, что ты не работаешь, а постоянно тушишь пожар, который кто-то устроил.
3️⃣ Микроменеджмент и отсутствие доверия. Каждый твой шаг под прицелом. Ты не специалист, а исполнитель. У тебя отбирают право на собственную экспертизу и решение.
4️⃣ Бессмысленные задачи. Когда ты тратишь неделю на фичу, которую закроют через месяц. Когда от твоей работы нет видимого результата или ценности. Ощущение бега в колесе.
4️⃣ Вечный «информационный шум». Бесконечные митапы, которые можно было заменить сообщением в чате. Десятки чатов, где @all используют по любому поводу. Невозможно сосредоточиться на 2 часа подряд.
6️⃣ Размытая ответственность и политика. Когда непонятно, кто за что отвечает. Когда решения принимаются не по здравому смыслу, а по тому, кто громче крикнул или у кого больше полномочий.
Это не твоя личная слабость. Это — ядовитая среда.
А вы что замечали? 📍
Какой из этих пунктов бьёт больнее всего? Что ваш главный «выжигатель».
Давайте называть вещи своими именами. Может, тогда мы сможем что-то изменить. Или хотя бы понять, когда пора уносить ноги.
#выгорание #антиwork #it #работа #токсичнаяработа #mentalhealth #letitkit
👍4
🥸 Знакомы ли вам эти сокращения из DevOps/SRE?
o11ty, k8s, r8y
По-английский 8 - это eight, 11 - eleven, они любят так сокращать через созвучное.
Но тут что-то не звучит, как знакомые:
#Observability, #Kubernetes, #Reliability
Вы знали, что значат числа в этих известных сам названиях на самом деле?
Какие варианты?
o11ty, k8s, r8y
По-английский 8 - это eight, 11 - eleven, они любят так сокращать через созвучное.
Но тут что-то не звучит, как знакомые:
#Observability, #Kubernetes, #Reliability
Вы знали, что значат числа в этих известных сам названиях на самом деле?
Какие варианты?
❤1
😃 Еду 🚃🚃🚃🚃 4 декабря 2025 слушать доклады в ➡️ Сколково на Первую Kuber Conf, что организована в рамках проекта "Ассоциация облачно-ориентированных технологий"
https://aot-kuberconf.ru/
Если кто-то тоже там будет, напишите в комментариях — встретимся.
#конференция #k8s
https://aot-kuberconf.ru/
Если кто-то тоже там будет, напишите в комментариях — встретимся.
#конференция #k8s
Никогда не встречался с этой особенностью коротких ссылок #Grafana https://t.me/livePercentile/6
У нас как-то давно слетели настройки в Grafana и эти короткие ссылки стали при создании указывать на localhost. С тех пор проверяю каждый раз ссылку после сосздания 🛠️, туда ли ведет.
#особенности #мониторинг #хитрости
У нас как-то давно слетели настройки в Grafana и эти короткие ссылки стали при создании указывать на localhost. С тех пор проверяю каждый раз ссылку после сосздания 🛠️, туда ли ведет.
#особенности #мониторинг #хитрости
Привет, %usernsme%! Я с неделю как член ПК новой крутой независимой конференции по мониторингу — 🔭 Observability Conf.
🗓 Пройдёт она 19 марта 2026 года в Москве (место уточняется).
1️⃣ Это первая конференция нового комьюнити, которое призвано развивать технологии мониторинга в РФ, поэтому единственным ограничением по темам будет — всё вокруг мониторинга, наблюдаемости, метрик, логов и т.д. То есть рассказать можно и о своём решении, но минимизировать открытый pr компании и продукта, добавив полезности от внедрения, описание кейсов и эффекта.
🆓 Сама конференция будет бесплатная, регистрация скоро откроется, поэтому прийти может стать любой зарегистрировавшийся.
🏃На конференции будет 2 трека:
1. 🧭🙎♂️ про бизнес, процессы и эффект от внедрения или оптимизации систем мониторинга
2. 🛠🧠 хардкорный — про технику, задачи, реализацию.
❓ Допускаются доклады, которые уже читались, главное их немного освежить и скорректировать название с тезисами.
➡️ Приглашаю тебя стать частью этого события в формате спикера конференции.
🥎🥎🥎 Заполняй информацию о докладе в документе и пиши мне @r3code. Приложи расшаренную ссылку или PDF заявки.🥎🥎🥎
🧙♂️ Если остались вопросы, задавай — отвечу. Также можете писать Александру Крылову (@darkbenladan).
P.S. Если это интересно, следующим твоим шагом будет предоставление темы/названия доклада и тезисов.
Доклады утверждаются программным комитетом (состав ПК скоро будет опубликован на новом сайте конференции).
🗓 Пройдёт она 19 марта 2026 года в Москве (место уточняется).
1️⃣ Это первая конференция нового комьюнити, которое призвано развивать технологии мониторинга в РФ, поэтому единственным ограничением по темам будет — всё вокруг мониторинга, наблюдаемости, метрик, логов и т.д. То есть рассказать можно и о своём решении, но минимизировать открытый pr компании и продукта, добавив полезности от внедрения, описание кейсов и эффекта.
🆓 Сама конференция будет бесплатная, регистрация скоро откроется, поэтому прийти может стать любой зарегистрировавшийся.
🏃На конференции будет 2 трека:
1. 🧭🙎♂️ про бизнес, процессы и эффект от внедрения или оптимизации систем мониторинга
2. 🛠🧠 хардкорный — про технику, задачи, реализацию.
❓ Допускаются доклады, которые уже читались, главное их немного освежить и скорректировать название с тезисами.
➡️ Приглашаю тебя стать частью этого события в формате спикера конференции.
🥎🥎🥎 Заполняй информацию о докладе в документе и пиши мне @r3code. Приложи расшаренную ссылку или PDF заявки.🥎🥎🥎
🧙♂️ Если остались вопросы, задавай — отвечу. Также можете писать Александру Крылову (@darkbenladan).
P.S. Если это интересно, следующим твоим шагом будет предоставление темы/названия доклада и тезисов.
Доклады утверждаются программным комитетом (состав ПК скоро будет опубликован на новом сайте конференции).
Google Docs
Заявка на доклад Observability Conf 2026
Заявка на доклад Observability Conf 2026 Москва Сделайте копию документа, заполните и отправьте ссылку / PDF-документ вашему куратору от программного комитета. Докладчик Будет показано публично на сайте конференции Фамилия: Имя: Отчество: Компания: Должность:…
🔥4🤔1
О 4 золотых сигналах:
https://t.me/sre_community/310
🔍 А как вы меряете Saturation? Это не всегда очевидно...
#sre #основы
https://t.me/sre_community/310
🔍 А как вы меряете Saturation? Это не всегда очевидно...
#sre #основы
Telegram
Путь SRE
Golden signals SRE: зачем и что мониторить
Привет, друзья! Сегодня поговорим про золотой стандарт мониторинга в SRE - Golden signals. Это четыре основные метрики, на которых строится практически вся современная наблюдаемость систем. Вот что они значат и…
Привет, друзья! Сегодня поговорим про золотой стандарт мониторинга в SRE - Golden signals. Это четыре основные метрики, на которых строится практически вся современная наблюдаемость систем. Вот что они значат и…
👍2
Media is too big
VIEW IN TELEGRAM
🤔 Как в реальной жизни люди применяют rate-limiter?
Наши уважаемые индусы из Мумбаи очень озаботились культурой поведения на дороге. А водители там очень эмоциональные и начинают бибикать, как только включают красный светофор. И гул этот растет неимоверно.
Посмотрите на видео это решение. Какую реализацию rate-limiter напоминает?
#смешная_суббота #надежность #sre #fun #жизнено
Наши уважаемые индусы из Мумбаи очень озаботились культурой поведения на дороге. А водители там очень эмоциональные и начинают бибикать, как только включают красный светофор. И гул этот растет неимоверно.
Посмотрите на видео это решение. Какую реализацию rate-limiter напоминает?
#смешная_суббота #надежность #sre #fun #жизнено
🤣2
🤖Проблем хез старьиу хай спу он нодэ диэмикс-сиэйч-дев-ноль-один. Плс реакт асап ит майт бы сериос.
Или
🙋 Диман, тут на проде ошибок под 50% сыпать начало на сайте, можешь подключиться?
Так могут звучать разные озвучки алертов дежурного SRE. Какой вариант в 2 часа ночи лучше сработает, думается, что конечно второй 🥈. Но оказывается и все немного сложнее с нами человеками. Коллега по цеху Кирилл Борисов рассказал о всех перепетиях в докладе 🌱Как жить, когда у тебя N тысяч алертов в секунду на DevOpsConf 2025 — рекомендую к просмотру, жизненно.
— VkVideo
🥸 А как вы называете того кто звонит про алерты инциденты в дежурстве?
#sre #инциденты #oncall #доклад #devopsconf
Или
🙋 Диман, тут на проде ошибок под 50% сыпать начало на сайте, можешь подключиться?
Так могут звучать разные озвучки алертов дежурного SRE. Какой вариант в 2 часа ночи лучше сработает, думается, что конечно второй 🥈. Но оказывается и все немного сложнее с нами человеками. Коллега по цеху Кирилл Борисов рассказал о всех перепетиях в докладе 🌱Как жить, когда у тебя N тысяч алертов в секунду на DevOpsConf 2025 — рекомендую к просмотру, жизненно.
— VkVideo
🥸 А как вы называете того кто звонит про алерты инциденты в дежурстве?
#sre #инциденты #oncall #доклад #devopsconf
❤1👍1
Вышли результаты исследования DevCrowd: Исследование SRE-специалистов 2025, в которых многие из нас приняли участие https://t.me/devcrowd_official/40
#исследование #sre #результаты
#исследование #sre #результаты
Telegram
DevCrowd - недушные рисерчи IT-отрасли
Готово: исследование SRE-специалистов 2025 💥
Мы опросили 273 инженера, которые отвечают за стабильность сервисов, и собрали честную картину того, как на самом деле устроены SRE-команды в российском IT.
Вот несколько ключевых наблюдений:
- 51% компаний…
Мы опросили 273 инженера, которые отвечают за стабильность сервисов, и собрали честную картину того, как на самом деле устроены SRE-команды в российском IT.
Вот несколько ключевых наблюдений:
- 51% компаний…
Как повышать свою устойчивость архитектурно.
Кирилл Юрков - член команды VictoriaMetrics описал самые популярные подходы повышения устойчивости от стартапов до гипермасштабных ентерпрайзов в контексте victoriametrics инсталляции.
Вас ждут не только факты, но и трейдофы, ловушки которые могут поджидать на каждом уровне масштабирования.
Посмотрим на опыт коллег:
https://docs.victoriametrics.com/guides/vm-architectures
#sre #статьи #колллеги
Кирилл Юрков - член команды VictoriaMetrics описал самые популярные подходы повышения устойчивости от стартапов до гипермасштабных ентерпрайзов в контексте victoriametrics инсталляции.
Вас ждут не только факты, но и трейдофы, ловушки которые могут поджидать на каждом уровне масштабирования.
Посмотрим на опыт коллег:
https://docs.victoriametrics.com/guides/vm-architectures
#sre #статьи #колллеги
Victoriametrics
Guides: VictoriaMetrics topologies
Documentation for VictoriaMetrics, VictoriaLogs, Operator, Managed VictoriaMetrics and vmanomaly
❤🔥1
Ребята тут пошли холиварить за SRE / DevOPS. Попкорн 🍿 и поехали посмотрим 😏 https://t.me/jtprogru_channel/4427
В Google нет например DevOPS инженеров, там все SRE, т.к. они называют SRE реализацией DevOPS
А вы делите SRE и DevOPS инженеров?
В Google нет например DevOPS инженеров, там все SRE, т.к. они называют SRE реализацией DevOPS
А вы делите SRE и DevOPS инженеров?
Telegram
Мишка на сервере
Вечером в SREду... Стоп! Это из другой вселенной! В SREду на кухне! Вот правильно!
УРА! Это было сложно, но мы это сделали! Первый выпуск подкаста В SREду на кухне про "границу между DevOps и SRE" мы наконец-то зарелизили!
Кто был в первом выпуске:
- Михаил…
УРА! Это было сложно, но мы это сделали! Первый выпуск подкаста В SREду на кухне про "границу между DevOps и SRE" мы наконец-то зарелизили!
Кто был в первом выпуске:
- Михаил…
🔥2
🔳 Он не защитит вас от шумных соседей — и это не участковый, а #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?
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 #грабли
Про возможные вечные блокировки пайплайнов даже при валидных сообщениях. Про важные настройки.
И конечно по пути родились несколько вопросов, надеюсь поможете с ответами
https://habr.com/ru/articles/977412/
#статья #логи #vectordev #грабли
Хабр
Vector.dev: отравленные события — как всё сломать тихо и надолго
Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. Мы в своей компании давно используем vector.dev для обработки логов, о чем я рассказывал в предыдущих статьях (раз...
👍4🔥3
💫 Стартую рубрику "Видео моих докладов".
Первое мое выступление на конференциях — DevOpsConf 2024. Готовился полгода, было очень интересно услышать мнение других инженеров о нашей работе.
#Доклад на DevOpsConf 2024
Логи: как EFK нас довел... до Vector и Clickhouse
И серия статей на Habr по докладу
-> Презентация и материалы к докладу
📺 #Видео
——————
- YouTube
Интересно видно ли будет на последующих видео какой-то прогресс меня как спикера, я не сравнивал 😆
А вы выступали? Помните как это было впервые?
#видео #доклад #devopsconf #vector #логи #спикер
Первое мое выступление на конференциях — DevOpsConf 2024. Готовился полгода, было очень интересно услышать мнение других инженеров о нашей работе.
#Доклад на DevOpsConf 2024
Логи: как EFK нас довел... до Vector и Clickhouse
И серия статей на Habr по докладу
-> Презентация и материалы к докладу
📺 #Видео
——————
- YouTube
Интересно видно ли будет на последующих видео какой-то прогресс меня как спикера, я не сравнивал 😆
А вы выступали? Помните как это было впервые?
#видео #доклад #devopsconf #vector #логи #спикер
🔥2👍1
💫 Опубликовал новую статью по #sre, на которую навели меня читатели канала.
Длины поста тут бы мне точно не хватило, потому публикую на Habr.
Это статья не для самих SRE, а для тех людей и компаний, которые думают "У нас нет SRE" – не значит "у нас нет надёжности". Даже без SRE-инженера ваша команда уже что-то делает для надёжности. В статье покажу, как увидеть уже существующие у вас практики и понять, куда двигаться дальше.
https://habr.com/ru/articles/979686/
#статья #инструмент #практики #habr
Длины поста тут бы мне точно не хватило, потому публикую на Habr.
Это статья не для самих SRE, а для тех людей и компаний, которые думают "У нас нет SRE" – не значит "у нас нет надёжности". Даже без SRE-инженера ваша команда уже что-то делает для надёжности. В статье покажу, как увидеть уже существующие у вас практики и понять, куда двигаться дальше.
https://habr.com/ru/articles/979686/
#статья #инструмент #практики #habr
Хабр
Вы уже занимаетесь SRE. Просто не знаете об этом
Вы уже занимаетесь SRE. Просто не знаете об этом Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру . В этот раз я решил помочь вам посмотреть на свою работу в...
⚡2
Летит кит и улбается.jpg
200.4 KB
Вот это да! Друзья — нас уже 100.
Благодарен вам за то, что читаете меня и делитесь опытом в комментариях.
Благодарен вам за то, что читаете меня и делитесь опытом в комментариях.
👏6
Макс тут перевел статью, где объясняют разницу и общность инженеров DevOps, SRE, Cloud, Platform. Не могу не поделиться
https://t.me/youngmaxnotes/101
#sre #статья #перевод #различия #devops
https://t.me/youngmaxnotes/101
#sre #статья #перевод #различия #devops
Telegram
A young Max’s notebook
Очень часто слышу споры и вопросы - а в чем разница между SRE/DevOps/Cloud Engineer/Platform Engineer?
Нашел тут статью на эту тему, которая мне очень понравилась, перевел ее для вас, оригинал по ссылке в конце :)
В современном мире технологий границы между…
Нашел тут статью на эту тему, которая мне очень понравилась, перевел ее для вас, оригинал по ссылке в конце :)
В современном мире технологий границы между…
❤🔥4
Всех с Новым годом 🎄!
Желаю всем продвинуться ближе к своим целям и достичь их.
Важно сохранить все хорошее, что дал 2025 и нести с собой.
Не забывайте живых людей - хоть технологии дают прямую связь, быть с догоргими вам людьми вместе не сравнимо с сеансом видеосвязи.
Желаю всем продвинуться ближе к своим целям и достичь их.
Важно сохранить все хорошее, что дал 2025 и нести с собой.
Не забывайте живых людей - хоть технологии дают прямую связь, быть с догоргими вам людьми вместе не сравнимо с сеансом видеосвязи.
🎉5
Рубрика "Видео моих докладов".
В прошлом году второй раз выступил на конференции DevOpsConf. Готовился уже не полгода, но слайдов было под 200. Да - я люблю диафильмы с ясным развитием сюжета покадрово 🎦. И в этот раз я тоже рассказывал про развитие нашей системы логов и было что рассказать.
#Доклад на DevOpsConf 2025
🏋🏻♂️Укрощение хаоса логов с помощью модели OpenTelemetry, Vector и ClickHouse. Итоги за два года
-> Презентация и материалы к докладу
📺 #Видео
——————
* RuTube
* VkVideo
* YouTube
🤓 Угадайте что на фото и зачем?
#видео #доклад #devopsconf #vector #opentelemetry #спикер
В прошлом году второй раз выступил на конференции DevOpsConf. Готовился уже не полгода, но слайдов было под 200. Да - я люблю диафильмы с ясным развитием сюжета покадрово 🎦. И в этот раз я тоже рассказывал про развитие нашей системы логов и было что рассказать.
#Доклад на DevOpsConf 2025
🏋🏻♂️Укрощение хаоса логов с помощью модели OpenTelemetry, Vector и ClickHouse. Итоги за два года
-> Презентация и материалы к докладу
📺 #Видео
——————
* RuTube
* VkVideo
* YouTube
🤓 Угадайте что на фото и зачем?
#видео #доклад #devopsconf #vector #opentelemetry #спикер
🔥1
🙀 Что на самом деле имел в виду Google под «SRE implements DevOps»?
Из книги Google SRE:
Это не значит, что
Как мы знаем из программирования, у одного абстрактного класса может быть множество реализаций — и каждая решает общую задачу своим способом. При этом реализация ≠ наследование.
DevOps — это философия: культура, автоматизация, измеримость, совместная ответственность.
SRE — это конкретная роль, которая реализует эту философию через инженерные практики:
- SLO/SLI как договор о надёжности,
- автоматизация рутины (toil reduction),
- управление рисками через бюджет ошибок,
- отказ от «100% uptime» в пользу баланса скорости и стабильности.
SRE не заменяет DevOps — он инструмент для его воплощения.
🤌🏼 А что с SR-инженерами? 🔭⚙️
Мы кто? Мы реализация или наследование от DevOps инженера? Тут также
Поэтому я считаю, что
Для меня #SRE — это инженер с T-образной экспертизой:
- горизонталь — общее понимание стека (от сети до бизнес-логики),
- вертикаль — глубокая специализация в одной области (экспертиза).
В Google, например:
- Один SRE может быть экспертом по распределённым системам,
- Другой — по масштабируемой автоматизации,
- Третий — по надёжности ML-пайплайнов.
Никто не ожидает, что один SRE будет знать всё на уровне DevOps + DBA + Security + Network Engineer.
Ожидается, что он умеет диагностировать и координировать, а не заменять.
Замечу, что в маленькой компании или стартапе с 5-10 микросервисами и небольшим набором технологий ты еще можешь "закрыть все сам" (скорее всего ты разработчик или даже cto в роли sre) - щупалец хватит, но с ростом компании — у тебя щупалец не добавится.
В моём случае "вертикаль" — это observability и #SLO. Я не заменяю #DevOps или DBA, но умею диагностировать инцидент, сформулировать гипотезу и привлечь нужного эксперта — и именно в этом, на мой взгляд, суть надёжности как инженерной дисциплины. Инженерное мышление + системное видение, а не универсальная экспертиза.
🐳 А что думаете вы?
Из книги 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, но умею диагностировать инцидент, сформулировать гипотезу и привлечь нужного эксперта — и именно в этом, на мой взгляд, суть надёжности как инженерной дисциплины. Инженерное мышление + системное видение, а не универсальная экспертиза.
🐳 А что думаете вы?
👍7
Новость-новость ℹ️
С этой недели я член программного коммитета DevOpsConf (Онтико).
👉 Буду помогать ПК в отборе докладов и спикерам с подготовкой докладов.
🧙♂️ Это мне сейчас интересно, потому что позволяет, как специалисту, еще шире взглянуть на нашу область работы в ИТ, познакомится с новыми людьми.
🗣️ С докладчиками же хочется делится своим опытом докладчика, передавать им его, чтобы их материал раскрывался и приносил пользу слушателям.
————————————————
И сразу объявление 📣
Пока ты читал, возможно, у тебя дозрела идея классного доклада и ты захотел подать его на 🔥DevOpsConf 2026.
Правда срок приема докладов уже вышел 😐. Но тебе везет! — Вот тот самый последний вагон в который можно запрыгнуть с докладом!
🗓 Зарегистрируйся сейчас и приходи на 🎤 Онлайн-встречау с ПК DevOpsConf во вторник, 27 января, 18:00 — после нее ты получишь секретную ссылку для подачи заявки на доклад до 1 февраля 2026 💫
#devopsconf #конференции #пк #новость
С этой недели я член программного коммитета DevOpsConf (Онтико).
👉 Буду помогать ПК в отборе докладов и спикерам с подготовкой докладов.
🧙♂️ Это мне сейчас интересно, потому что позволяет, как специалисту, еще шире взглянуть на нашу область работы в ИТ, познакомится с новыми людьми.
🗣️ С докладчиками же хочется делится своим опытом докладчика, передавать им его, чтобы их материал раскрывался и приносил пользу слушателям.
————————————————
И сразу объявление 📣
Пока ты читал, возможно, у тебя дозрела идея классного доклада и ты захотел подать его на 🔥DevOpsConf 2026.
Правда срок приема докладов уже вышел 😐. Но тебе везет! — Вот тот самый последний вагон в который можно запрыгнуть с докладом!
🗓 Зарегистрируйся сейчас и приходи на 🎤 Онлайн-встречау с ПК DevOpsConf во вторник, 27 января, 18:00 — после нее ты получишь секретную ссылку для подачи заявки на доклад до 1 февраля 2026 💫
#devopsconf #конференции #пк #новость
👍1🔥1