Гоняетесь ли вы за Root cause инцидентов? Или видите как и я в этом ограничения ⛔?

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

Для меня это, как при падении с табуретки 🦵🦵🦵 трехногой причиной определить поломку одной ножки ❌. Затем посмотреть только на нее, понять что она была склеяна из 2 частей и просто починить эту ножку, усилив ее стальным стержнем 🍢.

В следующий раз вы снова падает с табуретки 🤦 и сразу идете смотреть на опоры. Они все целые 🤷, но у одной вырвало болт с резьбы. Снова инцидент тот же - вы лежите на полу потирая бок.

И это лишь табуретка, а не сложная система из десятков компонент.

#инцидент_менеджмент #обучение

Уже совсем скоро - 9 сентября в 13:00 расскажу QA на https://perfconf.ru/, как SLO может быть им полезно и про наше решение для тех кто впервые решил попробовать SLO. Приходите - буду рад.

А ваши QA знают, чем для них полезны SLO?

#доклад #конференция

Как #SRE защитить приложение от лишней нагрузки? 🤔

📜Вы наверно видели инциденты, когда все перестало работать из-за внутренней DoS атаки из-за баги в сервисе. Это когда твой сервис 🅰️ предоставляет API и другой сервис
🅱️ к тебе пришел за данными. И вот однажды сервис 🅱️ всеми силами начинает заваливать API сервиса 🅰️ запросами. Тот, бедный, пыжиться, но не может своими мощностями такое прожевать. В итоге сервис 🅱️ не получает данные, а сервис 🅰️ отказывает другим и падает. Кто виноват? 🅰️ потому что был слаб? Или 🅱️ потому что сильно налегал?

🔍Небольшой постмортем. Триггером был излишний трафик сервиса 🅱️. Но ведь и 🅰️ никак не говорил "Хватит, я на пределе". А еще оказалось, что на обращения сервиса 🅱️ вообще не рассчитывали, не ждали его как клиента в 🅰️. Это в итоге создало сбой.

Как от этого защитить приложение?

1. Аутентификация запросов по API ключу.
Зачем? Затем чтобы не было возможности нагружать сервис пока он не готов. В Amazon применяют это так: команда сервиса 🅱️ просит ключ API к сервису 🅰️, команда 🅰️ запрашивает у команды 🅱️ ожидаемую нагрузку в RPS и смотрит хватит ли мощности, если не хватит, то ключ не дают, а планируют работы по доделке сераиса 🅰️ для получения нужной производительности. Когда 🅰️ готов - для 🅱️ выдают ключ API.

2. Ограничение частоты запросов Rate-limiter.

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

Как думаете это излишние меры? Есть ли иные способы?

#практики #нагрузка #разработчику #микросервисы

Наткнулся на статью от инженеров из Mercari – японский онлайн-сервис. Они рассказывают как у них начало подгорать от количества сервисных SLI/SLO, и что по факту не все важное это покрывало.

Потому они перешли на Critical User Journey #SLO с вороха отдельных россыпей на каждый микросервис.

Интересна тут роль e2e тестов и QA. Ребята смогли скрестить SLO с e2e тестами на CUJ и получить инструмент актуализации SLO, что сократило работу по сопровождению SLO на 99%.

Стоит присмотреться https://engineering.mercari.com/en/blog/entry/20241204-keeping-user-journey-slos-up-to-date-with-e2e-testing-in-a-microservices-architecture/

#статьи #практика #slo #e2e #cuj

Завтра https://perfconf.ru/
Приглашаю на мой доклад про SLO в 13ч

Как думаете QA, должны знать про SLO?

#доклад #slo #конференция #perfconf

🎤 Выступил на 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

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