Макс тут перевел статью, где объясняют разницу и общность инженеров 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

Michel The Bear с коллегами тут похоливарили "в SREду на кухне" про мониторинг и всё что с ним связано.

Приглашаю сравнить вашу точку зрения с коллегами 😉

Аудио https://music.yandex.ru/track/147188042

Видео
https://vkvideo.ru/video-152990965_456240051
https://youtu.be/WyT9ni4mGtU


#мониторинг #observability #devops #sre #подкаст

Пользуетесь ли вы Ai-ассистетнами для работы?

Я активно. Стадию принятия уже пошел.

В рабочей среде местный Qwen в Visual Studio Code через расширения Continue или Roo Code. В этот можно кормить наш код и он не уйдет в паблик.

Для личного позования у меня Qwen через расширение Lingma. И вот недавно я в первый раз оплатил доступ к модели, но это не часто слышимые ChatGPT или Claude.

Не знаю как, но вырулил я сначала на сайт z.ai - Зай, Дед Мазай :) Так вот они – китайцы 🇨🇳 – выпустили еще модель GLM-4.7 (линейная модель). По возможностям сопоставима с Claude, но стоит 6$, а не 20$ за тоже самое. Но у меня не было опыта работы с Claude, потому не с чем сравнить 😁.

Понадобилось 3 дня на адаптацию к работе. Лучше всего заработал с расширением Roo Code. Первый объект на пробу — рефакторинг чужого кода на JavaScript. С Lingma мне за 3 попытки не удалось сохранить функционал, ломалось.
С GLM-4.7 получилось. Возможно я просто накопил нужные навыки и сложилось.

Но теперь проблема — появилось еще дофига идей куда это приложить в работе ))

🧙‍♂️ Какой ваш опыт? Какие задачи вы с удовольствием смогли решить с помощью AI?

Документирование новых поделок с #AI

Удивительно хорошо зашла эта задача с Ai даже с корпоративным Qwen. Банально докидываешь выкатку с Ansible через Gitlab старому проекту, все уже отладил и вдруг... Внезапно подумал, что через полгодика может надобно быстро вспомнить "А это вообще что?".

Тут я подхожу из позиции, что будущий я не знает меня нынешнего, и лучше объяснить все важное, и что вызывало боль.
Раньше я сей README.md писал бы сам доставая из головы структуру проекта, применения, известные проблемы.
Теперь же я могу надиктовать черновик структуры и сказать как наполнить. Агент же сходит по структуре, если нужно и добавит инфы.
Остается прочитать результат и подкорректировать.

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

А как у вас? Доку вообще пишете?

Чашечка кофе за 50-100 тыс. рублей или Баночка колы за 3000рублей.

Угадайте в какой ситуации так можно попить кофе или колы? Или расскажите, как вам удалось схожим способом попить )

> Мой ответ дам в комментариях. И рабочий совет, как попить дешевле

👨‍🚒 Потянуло меня посмотреть, что в опыте пожарных настоящих есть полезного для IT-инцидентов.

Написал статью, чтобы закрепить свое виденье на этот вопрос.

И знаете, многое похоже, но кое-что прям явно хочется забрать.

Я, например, до сих пор горю, что некоторые считают тред инцидента в мессенджере равносильным протоколу / журналу инцидента.
Да возможно ваша культура общения настолько высока, что так и есть, но чаще в жизни это 40-300 сообщений, которые невозможно быстро причитать, когда зашел в инцидент.
Если у вас есть AI-бот которого можно натравить на инцидент, чтобы он сделал саммари - это круто. Но это все равно не протокол. Я считаю, что протокол должен вестись отдельно. Сейчас уже можно прикрутить к этому AI, идея - сделать бота, которому в треде указал через эмоджи сообщение и он закинул это в текущий протокол. А еще лучше сделать бота фасилитатора-инцидента, который бы подсказывал, что пора дать апдейт в таком то виде (может быть и сам бы предложил текст), рассказать какие гипотезы тестим, что делаем в ближайшие полчаса, уведомить пользователей и т.п.

Почитать https://habr.com/ru/articles/994690/

#статьи #sre #инцидент_менеджмент #habr

Это стоит перепостить!

Миша написал классный пост про TCP протокол. Мне прямо вспомнились времена работы в телекоммуникациях, когда мы неделями в Wireshark сидели, чтобы отреверсить протокол управления в железяке.

Когда читаешь это, думаешь, да ладно - ну вот же 21 век крутые технологии, скорости гигабитные 5G и 6G, а тут речь за какой-то "господин килобайт". Даже возмущение какое-то возникает сначала )

Но хоть технологии и ушли далеко, но база по прежнему из 1983 года (тогда повсеместно началось применение TCP-протокола).

#tcp #репост #история #база

https://t.me/jtprogru_channel/4455

Вы как относитесь к написанию кода с AI?

Я вот с этой картинкой, не согласен. При работе с AI агентом я выступаю как Product Owner - описываю результат, который удовлетворит бизнес. Когда бизнес - это вы сами, то агенты - это ваша команда.

Косячит ли команда? Всегда ли понимает задачи правильно и однозначно? Конечно нет - на себе много раз проверял. Если принял задачу с мыслю "тут все очевидно", то это скорее звоночек, что лучше спросить "а что ты имел в виду?". Это во много раз сокращает переделки.

О чем это я - о том что, всегда нужно изучать план изменений, что предложила ваша команда разработчиков. Особенно если это AI.

Можно еще научить агента спрашивать "правильно ли я понял, что".

Думаю хорошо такой набор правил собирать в отдельном репозитории, чтобы позже переиспользовать.

Вы переиспользуете промты? Или каждый раз из головы?

Не мог удержаться не запостить этот скрин.

Я недавно посмотрел Темный рыцарь. И тут он!

P.S. Из фильма "Бетман против SRE".

#fun #мониторинг #grafana #batman

👁 Увидимся на DevOpsConf 2026 на моем докладе!

Вы уже знаете, что я с 2026 года в ПК DevOpsConf, но еще осенью я подал несколько заявок на доклад. В этот раз оказался интересна тема SLO.

Доклад "Как SLO водят нас за нос" будет не о том, что это, как это реализовать, а про то, как и где можно проколоться в подсчетах, как система может сама обманывать вас, и как неправильное позиционирование и применение SLO приводит лишь к гонке за зелеными бордами, вместо реальной надежности. Конечно, просто пересказать это будет недостаточно - расскажу как можно это обходить.

📆 Встречаемся 3 апреля на
DevOpsConf 2026, Стрим: Наблюдаемость/Мониторинг инфраструктуры, Зал 6

🔖 В это году конференция на ВДНХ! Павильон № 38 Бизнес. Техноград

Про антипаттерны алертов.

Макс написал все за меня. Нет, не тот который ловит даже на парковке 😁.

Потому просто заберите себе это в практику — это реально полезно.

Я все эти антиппттерны видел в жизни, и не хочется чтобы вам пришлось будить разработчика ночью лично, только потому что он отключил телефон, а ты живешь по случайности в том же отеле и на том же этаже.

Брать тут https://t.me/youngmaxnotes/103

💫 Как у вас подгорело от "прекрасных" алертов? Расскажите в комментах

#алертинг #антипаттерны #база #репост

Тренировка по #инцидент_менеджемент

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

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

Второй раз уже случилось непонятное и пришлось копать логи, запросы и ошибки. Нашли - завели багу, и поняли, что по таким логам "так себе копать".

Освоился и с кубером и Google Cloud. Один падучий сервис будил меня 4 дня подряд в час ночи. Я на 3 день сделал себе консоль прямо на телефоне, чтобы ходить перезагружать тот сбойный под не вставая с кровати 😉 На 5 ночь я проснулся сам в 1 час ночи - но никто не позвонил. Оказалось разработчики починили 👨‍🔧 вчера.

Пока компания маленькая и растет - можно и получается учиться прямо на проде, т.к. потери не велики.

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

Тогда как тренироваться?
Вы можете попробовать сделать стенд повторяющий часть прода и там ломать и пробовать чинить - так делают ребята в Яндекс такси (рассказывали в докладе).

Другой способ – попробовать отдельные тренажёры. Вот несколько площадок для тренировок онлайн по Linux и Kubernetes:
- https://labs.iximiuz.com/challenges?author=ivan-velichko&filter=all&category=kubernetes
- https://sadservers.com/
- https://keep-alive.ru - командные траблшутинга
- https://srega.me/ - индивидуальные тренировки в формате Capture the flag

Или
- Оффлайн на своей машине https://github.com/Manoj-engineer/k8squest


А как в работу с инцидентами погружались вы? Как получали опыт troubleshooting?

#troubleshooting #личный_опыт #sre