Разработка и тестирование playbook для Ansible.

Как пережить весь этот ад разных версий зависимостей? У меня несколько раз было, что в разных проектах нужны разные версии Ansible и обвеса к нему. Однажды пришлось версии зависимостей подбирать 3 часа, чтобы и ansible работал нормально и lint, и molecule не бодалась. Не понравилось мен это. Потому я тогда решил это просто - во всех проектах зависимости одинаковых версий сделал. Но сейчас можно проще - DevContainers для VSCode. Это уже зрелое решение и вот тут ребята с ecom.tech рассказали насколько это полезно и как они применяют это в разработке с Ansible https://habr.com/ru/companies/oleg-bunin/articles/1009974/. У меня как раз такая же идея возникла, когда я месяц назад писал playbook для Ansible - использовать DevContainers. Я любитель в проект кидать Makerfile и локально все через него делать, так вот у меня Linux, а у некоторых коллег MacOS и они страдали, т.к. Makefile был заточен исключительно под Linux. DevContainers это решают.

И они выложили свой Dev Container для Ansible https://github.com/weslyg/devcontainer-ansible потому что нормального в природе не было.

P.S. если ты маковод и твой MacOS жжет тебе ноги, когда запускаешь Docker Desktop - посмотри в сторону OrbStack и будет только приятно тепло )

А где ты используешь DevContainers?

#инструменты #ansible #vscode #практики #devcontainers

Завел резервный канал в белолистном мессенджере, буду туда дублировать посты.

Выбирайте кому как удобно читать, этот канал остается основным.

Канал там приватный, читать по ссылке https://max.ru/join/TPK41mVYowJvYKvsr9Blr3ZJfYzaM5dbQqWkIe9h-TI

Защита от взрыва кардинальности метрик в OpenTelemetry

Иногда приложения могут создать метрики с лейблами в которых тысячи и сотни значений. Хороший пример, когда в лейбл кладут URL. И оказывается у вас на сайте десятки тысяч, сотни тысяч товаров, в момент когда приходит поисковый робот это все обходить - количество метрик растет в геометрической прогрессии. Чем больше у вас измерений, тем больше данных - это как разница между 2D и 3D. Если 2 измерения x и y, в которых по 10 и 20 значений, то получим 10*20=200 строк метрик. Если же мы добавили еще одну метку z (измерение) в которой 30 значений, то получим 10*20*30=6000 рядов. А теперь в моменте в z оказывается 30000 разных значений, получаем 10*20*30000=6 000 000 рядов.

Мы такое ловили у себя при подсчете метрик по логам http-сервера в vector.dev, после чего поставили трансформ для защиты tag_cardinality_limit - он как раз отбрасывает метки, если в них слишком много значений. То что он отбрасывает значения можно увидеть по внутренним метрикам vector.dev

Для OpenTelemetry часто используют свои компоненты для обработки. Коллектор OpenTelemetry отвечает за прием и обработку данных, он поддерживает разные процессоры (аналог трансформа в vector.dev) чтобы преобразовывать данные как нужно вам. С метриками тут может также случиться эта беда. Для защиты от взрыва кардинальности метрик появился https://github.com/YElayyat/otel-cardinality-processor процессор OpenTelemetry

Случались ли у вас взрывы кардинальности метрик? Как предотвращали?

#observability #metrics #cardinality #наблюдаемость #opentelemetry

Инструмент ведения личной базы знаний LogSeq разделяется на 2 проекта!

https://logseq.io/p/e3YDyX5AYr

C 24 апреля 2026 проект LogSeq разделил функциональность ведения PKB (личная база знаний) на два проекта:
1. Новая версия на основе Logseq DB (https://github.com/logseq/logseq). Отдельная локальная база знаний хранимая в БД Sqlite. Это обещает упрощения синхронизации и лучшую производительность при работе.
2. Версия на основе Markdown файлов Logseq OG (https://github.com/logseq/og)

Разработчики полностью переключаются на Logseq DB, но оставляют проект Logseq OG на поддержке (будут выходить обновления безопасности, но не будет новых фич).

Почему разработчики решили уйти от файлов:
- Возможность масштабировать графы знаний без ущерба для производительности
- Редактирование в режиме реального времени
- Надежная синхронизация между устройствами и командами
- Self-hosted sync и поддержка больших графов 50k+ страниц

Logseq DB поддерживает Logseq Sync, локальное шифрование данные и передача на другие узлы синхронизации (шифрование вашим паролем).

У меня как раз Logseq на основе файлов, как она была с самого начала. У меня там около 2к статей пока. Я не замечаю каких-то проблем с производительностью.

А вы используете личные базы знаний?

AI SRE Summit 2026: выжимка из заметок

Привет, киты 🐳.

Наткнулся на пост на реддите и решил поделиться.

AI в SRE - это уже не демо, а продакшен. Вопросы сместились с "как это работает" на "кто отвечает, когда оно ломается".

Ключевые тезисы

1. Стоимость и надёжность - это одно целое
ИИ-агент, который лечит инцидент автоскейлингом, может накрутить счёт за облако на $50K. Если в ваших SLO нет бюджета - вы не контролируете надёжность.

2. Нельзя наложить ИИ на сломанную платформу
Broken platform + AI = более сложный баг, который сложнее отладить. Сначала наведите порядок в конфигурациях, логировании и деплое. Потом добавляйте агентов.

3. Observability теперь для машин
ИИ-агенту нужна структурированная, семантически богатая телеметрия. Если логи - это "text/plain с примесью надежды", агент будет гадать. Гадание в продакшене = инцидент.

4. У ИИ-агента нет владельца
Кто отвечает, когда автономный агент неправильно интерпретировал метрику или запустил неверный скрипт? Пока это серая зона. Нужны чёткие рамки: что агент делает сам, а где нужен человеческий апрув.

5. Роль SRE трансформируется
Было: тушим пожары, пишем ранбуки, дежурим.
Становится: проектируем границы автономии, пишем политики, интерпретируем решения ИИ.

Что уже сделать бы надо

- Добавьте бюджетные лимиты (деньги) в error budgets. Нет денег - нет надёжности
- Структурируйте логи под ИИ: векторизуйте, тегируйте, давайте контекст. Logfmt лучше свободного текста
- Введите режимы для агентов: автономно / с апрувом / только рекомендации. Переключайте по уровню риска
- Документируйте решения ИИ для постмортема и обучения
- Тренируйте команду на гибридных сценариях: человек + ИИ, а не "или-или"

Что я думаю

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

ИИ - усилитель процессов. Хаос ускорит хаос. База + ИИ = масштабирование надёжности.

Вопрос: если агент чинит инциденты, кто чинит агента когда он сломался?

P.s. вспоминается статья 1982 г "Иронии автоматизации", проблемы те же

The Ёп - да, ёп, че я такое в вел?!

Привет, киты 🐳!

Я чето задолбался исправлять команды в консоли, лень толкнула искать исправлялку - и я нашел thefuck. Работает оно неплохо, но fuck! FUCK это длинно и писать тоже ЛЕНЬ )

Потому, ёп - вот что звучит в голове )
И ёп - то что подходит мне и тебе 😆 Ёп - он тот же fuck, только короче 😈

Потому, ставим себе Ёп! и пишем меньше 😜

https://github.com/r3code/theep

#theep #tools #эффективность #инструмент #хулиганим

Ребят, не по теме SRE, а по теме контактов. Знакомый ищет спеца кто делает SEO продвижение в Google по России. Если у вас есть проверенные люди — прошу накидать контактов в личку @r3code.

#запрос #контакты #неформат

1:1 - это не терапия, а место, где можно по-человечески поговорить не только о работе.

Уйдем чуть-чуть от технички в более простые, но не менее важные вещи.
Раньше я воспринимал 1:1 довольно утилитарно.

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

Потом в Додо мне показали другой формат.

Оказалось, что 1:1 - это не только про задачи, перформанс и “что у тебя по проекту”. Иногда это маленький safe space, где можно сказать:
- “я устал”
- “я не вывожу”
- “меня бесит вот эта штука”
- “я не понимаю, куда дальше расти”
- “у меня сейчас сложный период вне работы”

И нормальный руководитель в этот момент не становится психологом, спасателем или мамой. Но он начинает видеть контекст.

А контекст решает.

Если руководитель видит только карточки в трекере, он управляет карточками.
Если он видит человека и контекст вокруг него, он может управлять нагрузкой, ожиданиями, ростом и рисками.

Для меня это прям поменяло отношение к 1:1. Это перестало быть встречей ради встречи и стало нормальным инструментом управления.

Что, на мой взгляд, делает 1:1 полезным:

1. Регулярность
Лучше стабильные 30 минут раз в 1-2 недели, чем “созвонимся, когда будет тема”.
Потому что “темы нет” - это тоже состояние. Иногда самое важное всплывает не в начале, а на 17-й минуте после стандартного “да вроде всё нормально”.

2. Это не статус-митинг
1:1 - это не место, куда надо переносить весь таск-трекер.
Статусы должны жить в таск-трекере, стендапах, PR, документах - где угодно, но не съедать весь 1:1.
Задачи можно обсуждать, но обычно за ними должна быть настоящая тема: блокер, конфликт, перегруз, непонятные ожидания, потеря мотивации.

Если весь 1:1 - это “ну что там по тикету?”, то поздравляю, вы изобрели плохой дейлик на двоих.

3. Повестка должна быть с двух сторон

Хорошо, когда и руководитель, и человек заранее накидывают темы.

Если повестку всегда приносит только руководитель, встреча быстро превращается в “начальник что-то хотел”. А 1:1 всё-таки должен быть местом, где человек тоже может принести то, что ему важно.

4. Safe space создаётся поведением, а не словами

Недостаточно сказать “у нас тут безопасное пространство”.
Безопасность появляется, когда тебя не перебивают, не обесценивают, не используют личное против тебя через месяц и не превращают каждую честную фразу в performance issue.

Доверие строится медленно, а ломается очень быстро. Классика, ничего нового.

5. Личное можно обсуждать, но аккуратно

1:1 - не исповедь и не терапия. Руководитель не должен лезть человеку в душу.

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

Где-то это пересборка нагрузки. Где-то отпуск. Где-то более чёткие ожидания. Где-то просто “окей, я понял, давай в ближайшие пару недель не будем накидывать сверху”.

6. Нужны follow-up’ы

Если на 1:1 договорились что-то сделать - это надо потом вспомнить.
“Я поговорю с командой”, “посмотрю промо-план”, “помогу разгрузить”, “вернусь с ответом” - это не декоративные фразы, а action items.

Нет follow-up’а - нет доверия. Всё очень просто и очень больно.

Хороший 1:1 после себя оставляет чуть больше ясности, спокойствия или движения вперёд.

Для человека - это место, где его слышат не только как исполнителя задач.
Для руководителя - это ранний мониторинг состояния команды.
Только вместо CPU, latency и error rate у тебя мотивация, усталость, ясность, доверие и рост.

И если после 1:1 ничего не меняется ни в голове, ни в действиях, ни в отношениях - возможно, это был просто ещё один календарный алерт без runbook’а.

А у вас 1:1 больше про задачи, про людей или “ну надо же иногда созваниваться”?

#sre #teamhealth #onetoone #leadership

Читал тут LinkedIn.

Многие пишут про AI и риск, что разработчики отвыкнут и разучатся, а если доступ к Ai отключат, то они не сумеют сделать ничего.

Ai тут непричем - это иронии любой автоматизации. Я как-то брал сноуборд на Красной поляне в прокат и у них заглючил сайт, знаете через сколько они в помнили о "древнем" раьочем обходном решении - можно договор на бумаге прямо тут подписать.? Через час. а через 70 минут сайт подняли.

Как можно было сообразить раньше?
Только тренировать этот отказ.

Но тут есть одно но - иногда информационная система настолько сильно встроена в процесс, что дешевле час недоступности, чем перекладка из бумаги потом.

Как понять когда использовать обходные решения? Когда это не станет дороже простоя?!

#SRE #иронии #эффективность

17 лет назад HTML и CSS был суров и был еще в ходу ужасный Internet Explorer 6

Я тогда увлекался экспериментами с ними, даже сайт помню css-trics был. Сейчас на CSS без js можно делать мультики!

А тогда я заморочился сделать разметку аккордов для гитары, было интересно.

Оно до сих пор работает 😎 https://www.r3code.ru/projects/accord-v2/accord.html

А чего я это вспомнил? Мне от хабра пришло письмо, что то кто-то меня упомянул в статье от 2010 года! Археолог не иначе, подумал я и пошел проверить, но комментов от 2026 свежих не нашел - видать глюк. Ну что ж спасибо ему - поностальгировал )

Как соблюдать баланс работы и жизни

Привет, киты 🐳!

Смотрите есть хороший курс от Yale "The Science of Well-Being" (с материалами на русском даже), на Coursera он стоит 44 евры. Хотелось его почитать, посмотреть да ещё бы и за бесплатно. Он всего 7ч занимает.

Пошел искать - нашёл пост выжимку https://www.reddit.com/r/DecidingToBeBetter/comments/ghrgz5/summary_of_yales_famous_science_of_wellbeing/

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

Пришлось в этот раз запла... не пришлось 😂 И торренты тут не причем!

Нашёл на сайте Yele описание этого курса и там написано, что он Free если без сертификата и ссылка дана. Переходишь по ней и курс в Courcera выдается бесплатно!

Как получить: идем на сайт https://online.yale.edu/courses/science-well-being, крутим до (FREE) Coursera - Full course, no certificate и жмем. В ваш акк на Coursera добавится это курс 🧙‍♂

🏮А как вы поддерживаете баланс между работой и жизнью?

#работа #психология #курс #бесплатно #Coursera #work_life_balance

OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)

Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana.

Версия 1.37.0 (Базовая)

- HTTP:
- Метрики: http.server.request.duration, http.client.request.duration
- Единица измерения: Секунды (s)
- Атрибуты: http.request.method, url.scheme, http.response.status_code и др.
- RPC (включая gRPC и JSON-RPC):
- Метрики: rpc.server.duration, rpc.client.duration
- Единица измерения: Миллисекунды (ms)
- Атрибуты: rpc.system, rpc.service, rpc.method

Версия 1.38.0

- HTTP:
- Единица измерения: Окончательно закреплена в секундах (s). В более ранних черновиках и некоторых реализациях использовались миллисекунды, но в 1.38.0 стандарт окончательно перешел на секунды для всех duration метрик.
- RPC:
- Начало перехода от rpc.server.duration к rpc.server.call.duration.

Версия 1.39.0

- RPC:
- Переименование метрик: Метрики rpc.server.duration и rpc.client.duration начинают заменяться на rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Переход с миллисекунд (ms) на секунды (s) для новых метрик call.duration.
- gRPC/JSON-RPC:
- Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды.

Версия 1.40.0

- RPC:
- Стабилизация: rpc.server.call.duration и rpc.client.call.duration становятся основными и рекомендуемыми метриками.
- Атрибуты: Уточнены требования к атрибутам rpc.system (например, grpc, jsonrpc), rpc.service и rpc.method.
- HTTP:
- Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries).

Версия 1.41.0

- RPC:
- Финализация: Старые метрики rpc.server.duration и rpc.client.duration официально помечены как устаревшие (deprecated) или удалены из основных рекомендаций в пользу rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Строго секунды (s) для всех call.duration метрик.
- gRPC/JSON-RPC:
- Значения атрибута rpc.system стандартизированы: grpc для gRPC, jsonrpc для JSON-RPC.

Версия 1.42.0

- HTTP:
- Уточнения в атрибутах http.request.method (например, добавление поддержки нестандартных методов или уточнение регистра).
- RPC:
- Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например, error.type).

Версия 1.43.0

- RPC:
- Продолжение работы над согласованностью атрибутов между различными RPC-системами.
- Уточнения в документации по использованию rpc.service и rpc.method для gRPC и JSON-RPC.
- HTTP:
- Незначительные корректировки в семантике атрибутов server.address и server.port.

Резюме ключевых изменений:

- Единицы измерения: Повсеместный переход с миллисекунд (ms) на секунды (s) для всех метрик duration.
- Имена метрик RPC: Переход от rpc.*.duration к rpc.*.call.duration.
- Атрибуты: Стандартизация значений для rpc.system (grpc, jsonrpc) и уточнение набора обязательных атрибутов.

А как вы решаете вопрос с именами метрик и изменениями в OTEL?

#opentelemetry #observability #changelog #otel

Капец, МММ живее всех живых

Увидел на визитке QR код Vilavi, подумал что это какой-то турецкий мессенджер. Слышал, что люди какой-то используют.

Зашел я по нему и почуял что-то странное. Проверил основной сайт. На первый взгляд безобидно, но я полез почитать о компании и увидел там адрес на Кипре, при этом сама страница заявляет про какой-то продукт из Сибири и что они успешно растущая компания с 2009 года 🤔.

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

Вот если их файлик с условиями вознаграждения и с сайта раздел Бизнес дать на анализ нейросети, с вопросом "У меня подозрение на схему понзи, пирамидку. Проверь вот эти материалы" - ой там портянка будет...

Жаль, что не все люди это осознают и могут проверить.

А вы когда сомневаетесь, как проверяете подобное ?

#скам #пирамида #нейросети #неработа #финграмотность

Привет киты 🐳 . А нафиг вам оно надо?

Именно об этом позволят задуматься сей инструмент https://github.com/dominikhei/cardamon - он подключается к вашему хранилищу метрик Prometheus и определяет какие метрики вообще не запрашиваются и просто лежат без пользы засоряя диски.

Кроме того из него же можно сразу создать правила для drop-а таких метрик сразу.

Напомню, лишние метрики - это не только 2-3 килограмма лишних дисков, это еще и повышение нагрузки на CPU при выборке, и необходимость иметь больше CPU. Когда метрик много при выборке приходится обходить но гораздо больше данных и это замедляет работу с метриками, работу досок. И еще увеличивает вероятность сделать слишком общий запрос и забить нагрузкой поиска и выборки данных эти сервера.

Так зачем хранить, то что не требуется от вас хранить ни по закону, ни по здравому смыслу?

P.S. буду пробовать его на совместимость с Victoria Backham Metrics

#наблюдаемость #observability #инструментарий #метрики #оптимизация

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

Менее года назад впервые отобрался с докладом на HighLoad в Санкт-Петербурге. Это было нечто новое, ведь раньше я тут был только зрителем.

#Доклад на Saint HighLoad 2025
Как добыть SLO: источники и инструменты гномов SREдней полосы

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

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

🤓 Угадайте сколько гномов было в докладе?

P.S. кому интересна тема SLO — вас уже ждут тут https://tg-me.sbs/allslo_ru

#видео #доклад #devopsconf #sre #slo #спикер

Привет, киты 🐳🐳. Встречаемся в Петербурге!

Ребята. Буду в Петербурге с 20 по 23 июня 2026г.
22-23 на SaintHighLoad 2026.

Пишите в личку. Если будет желание пересечься и поговорить вживую - знаю отличное место с вкусной рыбой 🐟.

#sainthighload #петербуг

Завтра буду выступать на Gmonit Observability Day 2026 с небольшим докладом про развитие нашего стека наблюдаемости.

Если будете там, заходите поговорить и на доклад.

Пройдет по адресу:  Москва, ул Мясницкая 13, с20, лофт Quattro Space
с 10 до 21ч.

https://gmonit.ru/event/observabilityday2026

#конференция #выступление #доклад #наблюдаемость #gmonit

Работа с агентами в командах: AI-а-а-а-а-а генты и возвращение Джуна

Привет киты 🐳 !
Попалась интересная статья "Я уволил джуна, нанял AI-агента, через месяц нанял джуна обратно“


Сжато: Взяли джуна Антона - работал среде, продукт знал . Потом вкусили AI-агентов и Антона уволили - он дороже.

1–2 неднли: кайф. Модуль за 3 часа вместо 3 дней, 14 задач вместо 7, тесты +13% к покрытию .

Неделя 3: первые косяки. Агент применил скидку + промокод дважды - не знал негласного правила. Сломал retry-логику: rate-limit был описан только в Confluence.

Неделя 4: математика сломалась. На ревью трачу больше, чем экономлю. Агент не помнит контекст, два агента устроили конфликт в utils.py.

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

Вернул джуна Антона. Не потому что провалились - потому что выросли.

Итог: это эволюция, не замена. Формула: джун × AI = мидл. Антон пишет промпты, знает контекст, агенты — для шаблонов и тестов. Скорость ×2, качество — человеческое. Контекст продукта — всегда за человеком.

#ai #ai_агенты #практика #разработка #команды

🐋 Друзья, киты! Этим летом приму участие в Summer Merge и приглашаю вас присоединиться.

С 3 по 5 июля на берегу Волги, в эко-парке «Русский Берег» (Ульяновск), пройдёт Summer Merge — это не классическая конференция, а скорее большое летнее приключение для взрослых. Проживание в палаточном лагере, живое общение и насыщенная программа без формальных условностей.

Я впервые буду в новой роли, не докладчик как обычно, а амбассадор рисования набросков ✏️ - это мое хобби.
Будем отключать мозг и быстро рисовать, выхватывать детали за 5, 3, 1, 7 минут. Вам не нужно уметь рисовать - это как исследование себя. Оценок ставить никто не будет. В итоге у нас будет за 1ч около 10 набросков. Если вы в первый раз это делаете - вы удивитесь и себе и ощущениям после. Это очень интересный опыт.

Summer Merge объединяет тех, кто настроен на профессиональный рост, осмысленный нетворкинг и здоровую перезагрузку. Здесь можно не только послушать коллег, но и обсудить волнующие вопросы в неформальной обстановке, у костра или за чашкой кофе.

Буду рад всем!

Билеты и программа на сайте: summermerge.ru

По моему промокоду SINYAVSKY действует скидка 20%.

#конференция #merge #промокод #наброски #хобби