👉 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

Не тот open API. Когда вы не управляете клиентами.

Очередной раз вижу в чате клич "Ребята, отзовитесь, кто пользуется API нашего сервиса X?".

Кажется, что за ерунда? Это же все наши внутренние сервисы -- посмотри по логам, по трейсам откуда запросы идут...
Но там может этого не быть. Например, ваши же сервисы не отправляют User-Agent со своим именем и версией в вызове, или нет трейсов. Всё - у вас просто куча логов об обращении на какой то endpoint вашего API.

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

О чем я говорю - о способе который видел впервые у Amazon.
Как это работает:
1) Вы даете доступ в API только по индивидуальным ApiKey, каждому потребителю свой
2) Каждый потребитель запрашивает у вас ApiKey и обязан принести сразу число - сколько нагрузки он будет вам давать (rps, ops)
3) Вы смотрите в показатели своего сервиса и принимаете решение. Если хватает мощности, то сразу выдаете ApiKey, иначе вы можете сказать "Ребята, у нас не хватит производительности вас обслужить - берем задачу на подумать как повысить производительность", и когда повысили - выдаем ApiKey.
4) Конечно хоршо бы вести базу какой ApiKey на какой сервис выдали, чтобы найти ответственных если что.
5) И также по ApiKey вы можете легко выставлять Rate-Limit, что позволит не завалить весь сервис, если один из клиентов сошел с ума.

А у вас пользуется подобными способами?
Встроено это в процесс подключения новых потребителей API?

Проверка инфраструктуры кодом - иногда и двух пар глаз 👀👀 недостаточно

Бывало у вас так: два инженера посмотрели в пулл-реквест, кивнули, мерджнули, а потом - бац!
Инцидент из-за кривой настройки безопасности или ресурса, улетевшего в продакшн без лимитов?
У нас бывало. И это не вопрос компетенции. Это вопрос того, что человек просто не может держать в голове все 750+ правил безопасной конфигурации.

Тут на помощь приходят инструменты статического анализа для Infrastructure as Code (IaC). Например, попался мне на глаза Checkov - https://www.checkov.io/

Что умеет:
- сканирует Terraform, CloudFormation, ARM, Helm, Kubernetes, Dockerfile и Serverless Framework
- проверяет на 750+ предустановленных политик - от открытых портов до отсутствия шифрования
- позволяет писать свои политики, если у вас специфичные требования
- интегрируется в CI/CD, чтобы ловить проблемы до мерджа

Почему это важно для SRE и DevOps:
- снижает когнитивную нагрузку на ревьюверов
- формализует знания о лучших практиках
- превращает "мы так не делаем" в автоматический чек
- дает артефакт для аудита и постмортема

Альтернативы, которые тоже стоит посмотреть:
- tfsec - легковесный, фокус на Terraform
- Terrascan - поддерживает несколько провайдеров, хорош для политик как код
- KICS от Checkmarx - открытый, с акцентом на безопасность

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

А вы используете статический анализ для IaC? Какой инструмент выбрали и почему? Сталкивались с инцидентами, которые можно было предотвратить автоматической проверкой?

#SRE #IaC #SAST #Security #DevSecOps #DevOps