#Лонгрид. О базах знаний

В определенный момент год назад я понял, что ёмкости мозга хоть и безграничны, но искать в них становиться труднее, так как информации меньше не становится.
Тогда же несколько раз попадались статьи о Second brain, цетелькастен. Не зацепило. Раньше скидывал иногда в Livejournal (олдсукулы свело кому?😁) и стати писал на Хабр. Но в первом тяжко искать, во втором готовить. В итоге решился попробовать что-то типа локальной wikipedia.

Одно время использовал Workflowy - аутлайнер, где все пишешь списками. Его советовал Кирилл Анастасин https://t.me/komikaki для заметок при подготовке доклада, чтобы быстро фиксировать мысли где бы они вас не застигли.

Нашел упоминания про Obsidian и Logseq.

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

Logseq хранит все просто в markdown файлах. Есть возможность все это скинуть через GitHub репозиторий приватный.

Но я что-то пошел путем со своими граблями: Яндекс диск и синхронизация с ним. Тут нет никакого умного улаживания конфликтов в файлах, просто стараюсь писать на одном устройстве в одну статью синкать и если надо дописывать на другом. В общем у меня 3 копии моих баз знаний.

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

Твоя база знаний - твоя сила! У твоей бабушки была поваренная книга с рецептами и еще не поздно завести свою )

Спасибо, что дочитал до конца - улыбнись 😇

Я же говорил, что один человек посчитал сколько в #ansible мест, где можно определить переменные. Так вот его #статья https://www.adaltas.com/en/2022/03/15/ansible-variables/ В ней он дает ответ, что таких места 22, а также рассказывает как правильно подобрать место для переменной.

Я буду выступать на конференции для 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!
🧙‍♂️Иногда интересно посмотреть по сторонам и найти новые связи, как ты думал, в хорошо известных тебе темах.

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