😡 Да назови ты это однообразно! Убей в себе художника-индивидуалиста.

Это крик SR-инженера встретившего много разнообразно названных метрик, которые несут в себе одни и те же данные.

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

Короче имена сервисов в названии метрик — это лютый #антипаттерн и боль.

🧐Как-то можно сделать правильно и хорошо?

Сотни людей старались и сделали #OpenTelemetry - используйте это как стандарт. Тут уже и имена придуманы и правила!

Вот ребята излили эту боль подробно в блоге у себя
https://opentelemetry.io/blog/2025/how-to-name-your-metrics/

🗣А вам удалось убедить команды в необходимости стандартизации метрик?

#практики #стандартизация

Кто куда, а я на Стачку!

Мой доклад про SLO в 14:50 2 октября на ИТ-конференции Стачка.
Которая пройдет в Санкт-Петербурге в конференц-центр гостиницы Космос Прибалтийская.

Приглашаю Вас посетить мероприятии и увидеться там!

🤩🤩🤩
У меня есть +1 один оплаченный билет 🎟, если вы в Санкт-Петербурге, то напишите в коммент - "хочу на Стачку". Если написавший будет только один, то отдам ему, иначе одного получателя выберет рандом из написавших ответ.
🤩🤩🤩

Для остальных есть промокод на 10% - используйте при заказе билета Стачка10

https://vk.com/nastachku

#конференция #стачка #бонус

😈 Хочу выступать с PDF!

Вот что я бы сказал, если бы мне предложили все слайды презентации переделать из Google слайдов в PowerPoint и потом доводить до прежнего вида (ну нету его у меня и не хочу).

Вы скажете - это же неудобно! Да есть неудобства, держишь все в голове.

Однако я задался вопросом, неужели нет софта, который бы показал PDF также в режиме докладчика. Оказалось есть!

👁 PymPress (https://github.com/Cimbali/pympress) - кросплатформенный и бесплатный! Его можно дать организаторам конференций. Туда даже можно подсовывать аннотации слайдам и сохранить.

А еще эта штука - тренажер для спикера 👅. В ней можно задать время ⏳ выступления, как только начинаешь листать - время начинает обратный ход.
📜 И там даже есть журнал переходов - сколько на каждом слайде времени ушло. Классно же!

И вишенки: умеет играть встроенные GIF, видео и аудио (нужен еще vlc или gstreamer)

🤔 А вы стали бы выступать с PDF с таким инструментом?

#спикеру #инструменты #конференция

🙈- Хрень какая-то невообразимая универсальная
🚃- Локомотив тяговый маневровый
🗄- Шкаф платяной двухстворчатый

Замечали, что в официальных названиях изделий у нас чаще всего есть определенный порядок слов, ну прям как английском.

Но у нас он проще — в наименование изделия ставят существительное (ГОСТ), чтобы ты сначала понял что это такое.

Это небольшие флешбеки из прошлого, когда я разрабатывал систему управления телекоммуникационным оборудованием на Delphi 7. Когда приходила переводная документация на иностранную аппаратуру, то по наименованию сразу можно было определить был ли переводчик с знанием предметной области или просто переводил текст. Она выделялась по прилагательным в начале, что-то вроде: Электростатический токонепроводящий сейсмостойкий корпус. Т.е. только в конце, как в сериале узнаешь самое интересное )

Я заметил за собой, что статьи в совей базе знаний стараюсь так и назвать — и сайдэффект в том, что это потом помогает при поиске позже. Cтандартизация помогает.

#документация #гост

Скоро осень, а осень тоже время несения добра позитива 🍁 под шелест желтой листвы.
А я снова буду шелестеть про SLI/SLO и дарить наш опыт на конференции #merge https://baltic2025.mergeconf.ru/ 17-19 октября 2025.

Для тех кто хочет посетить конференции MERGE (Светлогорск, Москва, Иннополис) у меня есть персональный промокод на скидку в 20%!
Кто хочет получить промокод - пишите в комментарии "Хочу на Merge"

P.S> для дочитавших до конца. 👨‍🏫 Есть один бесплатный билет - кто первый напишет в комментарий "Хочу бесплатно", тот первый получит.

🧙‍♂️Готовился как-то я к вебинару по паттернам надежности SRE и нашел классный сборник
Resilience and Reliability Patterns
https://jurf.github.io/daap/resilience-and-reliability-patterns/
Хорошо структурировано.

✒️Хочу заметить, что паттерны надежности - это не серебряная пуля 🎯, все равно могут быть сайд-эффекты о которых следует узнать заранее. Тот же паттерн Retries может вам организовать DoS атаку (пример в https://habr.com/ru/companies/tbank/articles/858602/)

3 месяца назад Neil Murphy, один из авторов SRE Book опубликовал анонс, что они пишут 2 редакцию! И спрашивал, а чего бы вы там хотели видеть?! 👁

Первой ответила от нас @kaleturina, затем и я добавил.

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

Мой коммент:

> I'd like to propose developing and describing a model of SLI/SLO maturity. As I see in real practice many companies can only support the very first level - define some SLOs and just watching them, because they still do not understand why they need it. The second level - do SLO based decisions based on error budget levels, if EB exhausted - dig and try to fix it. At this level I also see a lack of motivation at the teams level, so companies handle it by including a service SLO in team's KPI (I think this is a bad idea leading to "workarounds" to fit the SLIs to the KPI target). The third - a rapid reaction to SLIs drops by Multi Window Multi Burn Rate alerts, any fast burn rate alert declared as an incident (this helps with a better reaction), teams trying to fix issues before the budget exhausted, no slow burn alerts analytics, no feature freezes. The fourth is the third plus slow burn alerts analytics and decisions, analytics accepted by a company, error budget policy with feature freezers and an unfreeze tax.
I've never seen the 4th level ) Especially a real feature freezing practice.
And another one. Do we need to compensate an Error budget that was spent by service A due to failure in the underlying service B?
What if the B service is our Kubernetrs cluster or our network and all our services spent their budgets because of this falure? Should we do a feature freeze for all affected services?

Коммент Марины:

There are several topics I would personally love to see covered. It won't fit in one message, so I will split it :)

1. On-call compensation packages
Many companies expect engineers to work overtime, including handling incidents outside regular working hours, without offering any additional compensation. This approach not only leads to burnout among engineers, but also creates unrealistic expectations in upper management regarding operational costs. Both of these factors negatively impact long-term system reliability.

2. Improving the "burn rate" metric
The current concept of a "burn rate of 4" is unclear to many engineers and therefore rarely used in practice. It might be more helpful to reframe this concept—perhaps by alerting teams when they are projected to exhaust their error budget within a certain timeframe. Making the metric more intuitive could significantly improve its adoption and usefulness.

#sre #slo #allslo

🤦”Вот, что за херня!? Не видно же ничего.“

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

🗣️Потому ровно такая мысль звучит в голове у слушателей вашего доклада, когда они видят слайды с таким дизайном в вашей презентации.

Это я к чему. #Спикеру важно знать как будет выглядеть место #выступлениия. Если организатор не показывает сам, то попросите фото из зала. Это позволит вам адаптировать презентацию под это место, а люди увидят все, что должны были.

👉 Приходилось ли так вот всматриваться сквозь лес голов в интересный доклад?

🧙‍♂️👉Удивительное рядом. Вы встречали ситуацию, когда вам надо спасать сервис от нагрузки?

Варианты проблем:
А) долгие запросы в БД
Б) Сервис просто сам не вытягивает производительностью, а надо хоть как-то да пережить это.

Как это решить?

🧠Логичный мозг скажет:
По А) - дело ясное, сами натворили, сами найдут запрос и оптимизируют.
По Б) - кешироварие давайте, или отмасштабировать ещё больше


👨‍🔧Практика говорит:
По А) часто дешевле это сейчас залить ресурсами и искать спокойно проблему, чем тратить время, инженеров на оптимизацию
По Б) если этот сервис участвует в запросах с фронтенда (веб), то вам повезло – тут ограничения можно сделать прямо в веб приложении, например, сделать отложенную загрузку по кнопке (пока пользователь не нажал, запросов к нашему страдальцу нет).


🫴Какие у вас были необычные решения для снижения нагрузки?

#sre #практика