🎤 Выступил на Perfconf 11 с докладом про SLO

Аудитория была внимательная, слушали и вопросы задавали. Все отведенное время потратили.

👉 При подготовке этого доклада я открыл для себя насколько QA связаны с SRE и как QA могут помочь SRE!
🧙‍♂️Иногда интересно посмотреть по сторонам и найти новые связи, как ты думал, в хорошо известных тебе темах.

🙋 А вы какие инсайты ловили, после общения с коллегами из смежных сфер работы?

🎤 Начинающему #спикеру конференций

Два года назад в 2023 я решил подать доклад на DevOpsConf 2024. Мой первый доклад 📑. Тогда мне очень помог наш DevRel Олег Бусель. У него был просто шикарный бланк для подготовки заявки доклада. Он помог сделать заявку качественно 👍.

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

Мое первое выступление было на конференции организованной Онтико, потому информация ниже относится к их конференциям.

Мысли после выступления:
* Работа с тренерами при подготовке доклада дала огромный толчок в развитии навыков: выступать, как отвечать на каверзные вопросы, как волнение перед выходом преобразовать в топливо для уверенности.
* Понравилось, какое классное чувство возникает, когда кураторы + тренеры по структуре помогают вот эту разухабистую тропинку из твоих мыслей превратить в четкий маршрут для слушателя с важными знаками и понятной траекторией
* После первого выступления я получил большое количество единомышленников и друзей, причем даже не по основной теме доклада! Итогом стало создание сообщества ALLSLO, которое выросло за 2 года с 5 до 200 человек!

Что советую при подаче доклада в первый раз:
* Используйте при подаче заявок форму CFP как опору, даже отвечая на эти казалось бы несложные вопросы вы уже формируете структуру
* Заведите себе аутлайнер или просто записываете в телеграмм кружочки себе, когда вам пришла мысль к докладу - иногда инсайт может настигнуть где угодно и важно его поймать
* Посмотрите какие темы актуальны для конференции в этом году и проведите брейншторм, иногда кажется, что твоя тема не подходит, но если смотреть на нее с другой стороны, то оказывается вот оно - то что надо!
* Лайфхак! Если у вас две темы и вы думаете, что одна точно не подойдет, то все равно отправьте обе! Лично у меня так было, выстрелила вторая, которая казалась мне менее интересной.
* Боишься! Бойся потерять возможность проверить свою идею и не рассказать о ней! Люди могут помочь тебе найти новое решение узнав о твоем, не упускай шанс расширить свой опыт и найти единомышленников.

👉 Особый пункт - пройдите тему "Синдром самозванца" с Романом Поборчим и Полиной Лето. Он снимает многие оковы спикера.

P.S. DevOpsConf уже открыла прием докладов https://cfp.devopsconf.io

#конференция

В прошлом году написал статью https://habr.com/ru/companies/vitech/articles/854424/
В ней я рассказал, как мы шли к процессу стандартизации логов и что это дало. Сейчас мы так и живем.

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

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

Это крик 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

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

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

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

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

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