Я буду выступать на конференции для QA https://perfconf.ru/ 9 сентября с докладом про SLO. Расскажу как это может быть полезно QA и про готовый набор инструментов для SLO.

Если собираетесь сами, или кто-то из знакомых QA хотел пойти, то для покупок за свой счет дают скидку 20% по промокоду

PC20

Если от компании оплачиваете – не действует, к сожалению 🤷

Но можно попросить скидку - приходите ко мне в личку, выведу на нужных людей 😘

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

Галюцинации?

В первый раз в ответе гуглового #GPT Gemini попался такой артефакт. Раньше я встречал много подобных в DeepSeek, когда окончание слова на китайском, а иногда одно слово на английском между русских.

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

Встречали подобное?

#ai

В продолжение к прошлому посту про Галлюцинации GPT. Не о них самих. А про эти 2 иероглифа.

Я их понял! По вечерам учу китайский по карточкам AnkiDroid чисто для себя, потому что интересно. Так попадалась карточка про плаванье, я не мог запомнить долго. Но вот оказывается помню. Эти 2 иероглифа вниз и течение - дословно получилось вниз+течение, т.е. дословно написано "доступны для downstream систем".

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

У вас были схожие инсайты?

Гоняетесь ли вы за 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/
В ней я рассказал, как мы шли к процессу стандартизации логов и что это дало. Сейчас мы так и живем.

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