🔥The Last of 9s🔥 Последние девятки, которых всегда не хватает - живут тут :)

О чем это вообще? Про все вокруг SRE.

А если подробнее!? А если подробнее то про:

1. Надежность, отказоустойчивость и доступность. Как их достичь от систем дизайна до нефункциональных требований.

2. Перформанс. Ускорять будем все от линукса до jvm.

3. Наблюдаемость. Как быстро находить узкие места и проблемы на проде.

Все в формате техно текстов, без водички и с максимальной пользой! Ловушки, хаки, кулстори - будет всё.

А кто говорит? Автор - руководитель направлений SRE, Performance и Observability в крупной e-commerce компании. Раньше много выступал и активно участвовал в мире performance инженерии, сейчас хочу делится опытом в более широком контексте! Тем более его накопилось очень много. Вдруг зайдет? :)

🔥 Всем 99,99🔥

#performance #perfops #factory

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

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

решение:
придумали относительно новый формат встраивания в процесс, делаем сервисную команду с максимальной экспертизой а в продуктовые команды внедряем собственный фреймворк на базе java-jmeter-dsl. фреймворк позволяет писать тесты похоже по смыслу и на том же языке (котлин), что и пишутся автотесты в командах. на входе в прод прикрутили валидатор тестов - quality gate. по необходимости продукты приходят в центр экспертизы, который назвали модным словом perfops.

взлетело?
да, но без реактивной тяги, до сих пор ускоряем этот взлет и надеюсь скоро заопенсорсим наше решение!

ссылочки:
про это я выступал как-то на хайлоаде:
https://youtu.be/iDFBWczQVcg?si=MQZGyEKTRnyMGfQB
это полная версия, кому нужны подробности и нравится текстовый формат на хабре:
https://habr.com/ru/companies/oleg-bunin/articles/682746/
а это, чтоб вообще никого не обидеть, на английском эта же статейка:
https://medium.com/@login40000/perfops-faster-and-cheaper-through-a-service-oriented-approach-in-performance-testing-5689b3747014
а еще, если тема интересна, у нас очень ламповое коммьюнити про перформанс на 7 тыщ человек: t.iss.one/qa_load

#performance #perfops #stands 

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

проблема:
наши перформанс стенды, на которых мы катали нагрузку уничтожали time to market.
- время разливки дампов на них было больше 12 часов, могло закончится фейлом. 
- данные были обрезаны и обфусцированы. соответственно о релевантности результатов нагрузочных испытаний можно забыть
- из плюсов можно было наливать туда синтетикой и ходить на бд под своей учеткой любому тестеру

решение: 
- мы выделили отдельный сетевой сегмент машин, куда начали отливать дампы прям с прода без изменений. доступ к ним был 1 в 1 как на проде.
- на этих стендах выбрали файловую систему с поддержкой Copy on Write (у нас  была XFS)
- в момент создания динамического стенда (aka kubernetes namespace) триггерится создание, например, постгрес контейнера, в котором initContainer выполняет простой .sh скрипт:

cp -r --reflink=always /data/base/active_base /data/dynamic-data/test-stand/pgdata
`

- далее мы имеем мгновенно поднятый постгрес хоть на терабайты, издеваемся над этими данными как хотим (меняем как угодно)
- потом просто убиваем контейнер и запускаем механизм очистки теневой копии файловой системы, которая осталась после нашей нагрузки
- следующий запуск динамического стенда даст нам снова исходное состояние базы и новый форк файловой системы

матчасть с примерами рефлинков:
https://blogs.oracle.com/linux/post/xfs-data-block-sharing-reflink#:~:text=Copy%20on%20write%20is%20used,in%20use%20to%20combat%20fragmentation.

а за подробностями всех приглашаю в комменты!
з.ы: "как там в облаках?")

#slo #errorbudget #grafanamaniac #SRE

заждались!? в прошлых сериях я кидал пример квери как сделать для себя расчет метрики бюджета.

теперь заворачиваем с собой полную версию дашборда бюджета ошибок. 
фичи:
1. возможность сделать часы обслуживания, в дашборде бюджет расходуется только после 4 утра по МСК.
2. общий бюджет разделяется по разным видам клиентов и по продуктам
3. есть ключевые бёрн рейты, которые помогут вам сделать алерты и реагирование на просадки
4. есть конвертация в временной эквивалент, оставшиеся часы и общее время исходя из вашего SLO
5. сейчас в дашборде 99.2 целевой SLO - меняя его, будет изменятся поведение расчета времени
6. дашборду накрутил вокруг рандомайзера, подставляйте по аналогии свои метрики и будет счастье. сейчас адаптации под promql нет, только victoriametrics, но адаптация лёгкая, могу помочь в комментах - заходите. 

https://youtu.be/zup78o3R_cE?si=0UNjW3MjlH2SKvXC - демка!
https://github.com/kirillyu/error-budget - github (ридми дополню обязательно, но по сути импорт дашборда в графане и в путь) 

всем девяток :)

#reliability #deployment #containerawareness #JVM

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

проблема:
запускаем JVM в контейнере с cpu requests = 2, и memory limits = 1 Gb. а потом выясняется что JVM себя чувствует не очень, пытается скушать 128 cpu с сервера и постоянно убивается OOMKiller.
копаем глубже и видим:
1.forkjoinpool запускает 128 потоков
2.gc берёт 64+ тредов
3.direct memory не ограничен → oom вне heap
4.metaspace, compressed class space — без лимитов
5.итог: jvm выжирает всё, что может, и умирает в адском троттлинге

разбираемся:
сначала надо зафиксировать что JVM у вас пригодная для описанного ниже конфига, а именно будет полезно знать, что:
- до jdk 10 jvm вообще не видела cgroups, а значит брала все с сервера как есть, если не задано иное
- с jdk 10+ и 11+ — начала видеть, но если не хочешь лимитировать cpu своему критичному сервису то надо включать флаги
- -XX:ActiveProcessorCount=1 как раз нужный флаг, но и он до недавнего времени не работал. при значении в 1 без лимитов все равно показывал все ядра

чиним:
опции для минимально жизнеспособной варианта без лимитов

-XX:ActiveProcessorCount=2
-XX:MaxRAMPercentage=70
-XX:MaxMetaspaceSize=128m
-XX:MaxDirectMemorySize=128m

как рассчитать сколько надо памяти?
RSS JVM =~ Xmx + MaxMetaspaceSize + MaxDirectMemorySize + CompressedClassSpace + (N_THREADS * Xss) + jit

в прикрепе подробная картинка для данного кейса. на очереди golang :)

упомянули эту тему, когда с коллегой писали статью на хабр - как бороться с овербукингом https://habr.com/ru/companies/ecom_tech/articles/735638/

#postgres #observability #pgwatch

как мы сделали postgres наблюдаемым, не расширяя стек и не убивая прометеус кардинальностью от query_id.

и по традиции демо:
https://pgwatch.dblab.dev
лог/пас (да простит нас мировое ИБ): demo/demo

исходная проблема:
1. стандартный postgres_exporter метрики собирает, даже в разрезе query_id, но глубины не хватает и не хватает точности
2. метрики очень кардинальные за счет айдишника каждой квери в лейбле
3. смотреть в базе pg_activity или pg_stat не вариант - баз больше тысячи

как решили:
1. нашли тогда еще не очень зрелое решение, которое не расширяло наш технологический стек ни на грамм - pgwatch (рекомендуем именно https://gitlab.com/postgres-ai/pgwatch2 не https://github.com/cybertec-postgresql/pgwatch)
2. просто подняли рядом отдельный postgres-инстанс только под метрики
3. туда начали сливать pg_stat_activity, pg_stat_statements и другие системные таблицы
4. взяли дашборды, которые идут в комплекте с pgwatch и чуть-чуть докрутили

что получили:
1. дашборды с drill-down вплоть от кластера до конкретного запроса.
2. графики с планами выполнения (через плагины)
3. видно кривые настройки, autovacuum, недоиндексы из коробки без танцев с бубном
4. все это существенно на пониженной нагрузке в сравнении с экспортером для прометеуса

почему postgres-ai а не cybertec:
1. первое и главное - баги
2. второе не супер важное, в cybertec своя графана в инсталляции и не очень полезный UI (может вам будет полезен)
3. появляется поддержка кастомных метрик, что дает большую гибкость

и подтверждаю слова авторов форка от postgres-ai, действительно:
- Improved dashboards for fast troubleshooting
- Custom metrics and configs
- Support of pg_wait_sampling and pg_stat_kcache
- Used YAML based setup
- Metrics storage DB: PostgreSQL with timescaledb extension (by default)

что дальше:
посматриваем в сторону coroot - умеет вытаскивать медленные запросы через eBPF без агентов и с недавних пор еще и с нормальной поддержкой секретов.
проверим, может ли заменить наше решение

#reliability #deployment #containerawareness #JVM #Memory

продолжаем серию постов про то, как готовить апликейшн для запуска в контейнере! прошлый пост тут https://t.iss.one/r9yo11yp9e/14

проблема:
стартуем свой идеальный код на JVM в проде и клянемся, что у нас нет утечек памяти (код же идеальный!). внезапно видим со всех сторон алерты и кровавокрасные логи, которые кишат OOM Kill/OutOfMemoryError.
при этом на машине у нас 8 Gi оперативы и в контейнере лимиты 8 Gi.

садимся дебажить:
1. сначала узнаем, что из-за какого-то легаси-кода у нас стоит опция -Xmx на HeapSize 9Gi. почему вообще приложение запустилось?
2. ну конечно, мы потом с этим разберемся, а пока поставим -Xmx 7 Gi и в продашн.
3. спустя 10 минут снова логи красные, и всё сломалось, и при этом OOM Kill прилетает даже когда память вообще-то в достатке.

разбираемся:
1. вначале узнаем, что такое поведение может происходить, когда в Linux включен оверкоммит (vm.overcommit_memory=1 или 0).
2. тогда на все запросы коммита памяти (malloc и mmap) Linux всегда говорит "да", даже когда такого количества виртуальной памяти у него нет. и только тогда, когда мы фактически обращаемся к этой памяти (пишем/читаем), ОС выдает нам кусочек физической памяти.
3. и у нас в случае, когда мы поставили HeapSize > limits, мы просто вышли им за пределы физической памяти, доступной контейнеру.
4. а вот случай, когда HeapSize < limits, интереснее. в рамках этого кейса мы могли напороться на две проблемы:
- первая простая — метаспейс, нейтив-мемори или память тредов выросла и вышла за пределы оставшегося 1 Gi, и всё умерло,
- а вторая проблема могла случиться из-за конкуренции за физическую память, когда метаспейс и хип пытались получить одну и ту же область, а может, с ними это пытался сделать ещё какой-то процесс на хосте.

что делать?
1. прописывайте все пространства памяти руками:

-XX:MaxRAMPercentage=70
-XX:MaxMetaspaceSize=128m
-XX:MaxDirectMemorySize=128m

2. делайте так, чтобы их сумма не превышала лимиты контейнера.
3. и на уровне ОС отрубайте это поделие дьявола — выставляйте vm.overcommit_memory = 2 (хорошо протестировав). в комментариях уже подсказали что с оверкоммитом можно жить используя флаг -XX:+AlwaysPreTouch, сам не пользовался, но для полноты картины добавил в пост :)

в прикреп закинул шпаргалку :)

#reliability #containerawareness #runtimes #дайджест

продолжаем серию про то, как рантаймы/языки ведут себя в контейнерах. ниже рейтинг всех рассмотренных мной рантаймов и моя оценка. надеюсь, будет холиварно и оценка претерпит изменения :)

что оцениваем:
ca (container awareness): насколько рантайм "видит" лимиты контейнера (cpu, memory) и умеет подстраиваться (gc, heap, потоки).
pc (прозрачность масштабирования): насколько легко управлять масштабированием (потоки, процессы, ресурсы) без ловушек.
tm (прозрачность потоков): насколько видно, что реально делают потоки внутри, легко ли дебажить параллельность.

контейнерная осознанность языков и рантаймов:

JVM 11+ (Java, Kotlin)
ca: ⭐️⭐️⭐️⭐️⭐️
pc: ⭐️⭐️⭐️⭐️☆
tm: ⭐️⭐️☆☆☆

ca: читает лимиты cpu/memory через cgroups v2/v1, gc адаптивно подстраивается, heap через MaxRAMPercentage и другие опции памяти в наличии.
pc: ActiveProcessorCount корректно ограничивает количество потоков. ловушка - дефолтные/системные потоки (Compiler Thread или потоки сервера, типа Jetty).
tm: без jstack и подобных инструментов не видно, чем заняты треды - профилирование обязательно.

Golang
ca: ⭐️⭐️⭐️☆☆
pc: ⭐️⭐️⭐️⭐️⭐️
tm: ⭐️⭐️⭐️⭐️⭐️

ca: с go 1.17+ в целом умеет читать cgroups v2, но automaxprocs ломается без лимитов - большая ловушка для тех, кто борется с троттлингом.
pc: GOMAXPROCS можно задавать руками, прозрачное масштабирование.
tm: модель M:N полностью прозрачна, видно каждую горутину и нагрузку.

.NET Core 5.0+ (C#)
ca: ⭐️⭐️⭐️⭐️⭐️
pc: ⭐️⭐️⭐️⭐️☆
tm: ⭐️⭐️⭐️⭐️☆

ca: читает лимиты cpu/memory через cgroups v2/v1. heap GC автоматически подстраивается под доступную память контейнера без необходимости ручных настроек
pc: ThreadPool адаптивный, поведение потоков понятное.
tm: task/threadpool прозрачны через метрики, иногда скрытая активность, но прозрачнее, чем в JVM.

Node.js
ca: ⭐️⭐️⭐️☆☆
pc: ⭐️⭐️☆☆☆
tm: ⭐️⭐️☆☆☆

ca: с node 20.4+ поддержка cgroups v2 через libuv, старые версии всё ещё страдают.
pc: UV_THREADPOOL_SIZE надо тюнить вручную.
tm: event loop прозрачен, но worker_threads добавляют хаос - и теряются все преимущества.

Python (gunicorn)
ca: ⭐️⭐️☆☆☆
pc: ⭐️⭐️☆☆☆
tm: ⭐️⭐️⭐️☆☆

ca: os.cpu_count() всегда про хост, контейнерные лимиты не видит, хотя есть фреймворки, которые awareness выше
pc: масштабирование только через процессы.
tm: через fork видно процессы/треды, но GIL ломает параллельность.

Ruby (MRI)
ca: ⭐️⭐️☆☆☆
pc: ⭐️⭐️☆☆☆
tm: ⭐️☆☆☆☆

ca: etc.nprocessors всегда возвращает cpu хоста, контейнеров не видит.
pc: только форки через puma/unicorn. falcon работает лучше.
tm: из-за GIL потоков нет, только процессы.

PHP-FPM
ca: ⭐️☆☆☆☆
pc: ⭐️⭐️☆☆☆
tm: ⭐️⭐️⭐️⭐️⭐️

ca: cpu лимиты не видит, живёт как на хосте.
pc: управляется количеством процессов через pm.max_children.
tm: процессы полностью прозрачны — сколько воркеров поднято, столько и работает.

резюме:
jvm — топ по контейнерам, но требует разбираться в потоках.
golang — идеальный баланс контейнеризации и прозрачности.
.net — разделяет пьедестал с golang - минимум ловушек.
nodejs — стало лучше в новых версиях, но по-прежнему видеть nodejs с кучей worker_threads в проде не хочется.
python, ruby, php — можно настроить, но придётся попотеть.

все пункты буду разбирать в постах дальше, по аналогии с JVM тут и тут .

#туловина #troubleshooting #observability

пока я готовлю для вас бесчисленное количество забористого контента предлагаю вместе посмотреть на одну интересную репу, которая попалась мне на просторах гитхаба:
https://github.com/iopsystems/rezolus

проект с небольшим количеством звезд, но уникальный по своей пользе на мой взгляд. его форкнули и допиливают те же ребята, которые когда-то давно пилили его в твиттере (щас это Х) - https://github.com/twitter/rezolus

чем интересен:
1. первое - это частота сбора телеметрии, она очень высокая. на основе собранных данных строятся качественные агрегаты: персентили и бакетные метрики. но есть и жемчужина - можно получить raw данные в Hindsight mode - что невероятно ценно в микроперформансе или высокочастотном дебаге.
2. разработчики не распыляются, при этом метрик достаточно, чтобы ответить на вопрос "почему приложение работает медленно?".
3. есть метрики даже gpu, это сейчас актуально! https://github.com/iopsystems/rezolus/blob/main/docs/metrics.md#gpu

то есть эта штука почти полноценный профайлер в мире метрик. конечно, конкретный сискол не покажет, но это гораздо лучше чем кадвизор исходя из описания (даже с включенными tcp метриками). что скажете? берем на потестить? :)

если затащим к себе - с меня по классике дашборда под него.

#кулстори #problemreport #postmortem #jvm

делюсь кейсом из опыта, до сих пор не знаю всех вариантов как это лечить, но парочку есть :)

хронология событий:

1. представим что у нас есть шлюз гейтвей, он отдает толстому клиенту кэш со всем чем только можно. например целиком отдает каталог интернет-магазина клиентам.

2. гейтвей написан на Java, поэтому когда-то решили что кэш идеально делать на технологии hazelcast. прекрасная технология, кэш быстрый, все супер.

3. внезапно каталог наш стал большим, и быстро начал расти. видео, 100500 карточек товара, ИИ подборки... некромантия. наш шлюз под хипом имеет 25 Гб.

---день Х---
4. в этот день с утра пели птички, мы проснулись от того что рассвет был слишком красивым чтобы его пропустить... звонок, инцидент - шлюз умер.

5. вот мы уже сидим в звонке. с ходу понимаем что памяти не хватает. GC очень агрессивно чистит. приехало много контента в кэш.

6. ну дураку понятно - надо скейлить. накидываем 15 Гб. чтоб наверняка.

7. запускается роллинг апдейт (см. гифку) и ни один под не может отдать пробу. jetty пулы забиты. подняться не можем.

8. гасим входящий трафик, поднимаемся с гигантским трудом. и вынуждены ещё докинуть ресурсов и при роллинге снова полная недоступность

руткоз:
рост объема объектов в кэше.

сопутствующие проблемы:
1. когда хип выходит за 32Гб размер указателей увеличивается вдвое до 64 бит. плотность объектов уменьшается из-за отключения CompressedOops (ссылка)

2. хейзелкаст и роллинг апдейт не подружки (ссылка):
- при появлении нового инстанса его надо налить и сделать репликой, наливка замедляет работу кэша
- убийство старого пода может запускать лидер элекшн. это глобальный лок на весь кластер кэша.
10 подов и роллинг апдейт с долгой пробой. это веселые 10+ мин даунтайма.

экшн айтемы:
1. пробуем митигировать переездом на стейтфулсет. (пока сомнительно звучит)
2. вынос кэша во вне: keydb/redis, hazelcast standalone и тд.
3. учимся контролировать рост контента в кэше
4. место для вашего экшн айтема!)

#GrafanaManiac #coroot

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

https://github.com/kirillyu/coroot-grafana-dashboards - ссылочка тут.

что поменялось:
1. на таблицах с общей статой теперь есть разделение IN/OUT для латенси и процента ошибок, они означают то какое латенси или ошибки отдает контейнер и какие получает.
2. фильтры по кубернетес кластерам
3. появился полноценный граф и динамические панельки для дата слоя - кафки, монги, постгресы, теперь все видно

регайтесь на конфу, щупайте корут, поднимайте свою девяточность🔥
скоро принесу еще годноты на тему систем дизайна :)

#firstnine #perfguide #sre #observability


анонс, который в будущем можно юзать как пост для навигации по контенту.
длительное время я собирал "The First Nine Guide" - огромный excalidraw документ, с 9 (символично!?) блоками про базовые вещи, которые необходимы для достижения многодевяток, другими словами вот первая девятка. он начинается от software инженерии плавно переходя в системные слои. я его долго собирал на основе своих граблей, чужих граблей и просто исследований. цикл статей по нему, будет одной из главных веток в канале. далее хочу перейти к систем дизайну среднего масштаба и гиганского :)

1. function: the atomic unit of code (сложность функции, типы функции и что такое call stack)
[классификация функций и О-нотации]
2. runtime models (как эти функции запускаются, когда их много, кто ими управляет и как выбрать рантайм)
[виды рантаймов и особенности]
3. typical application inner-architecture (из чего состоит любой бэкенд, базовые блоки, которые могут создавать ботлнек)
[архитектурная повесть о царстве веб-сервисном]
4. ideal app to container (когда вы написали совершенный код, как его положить в контейнер, чтоб в проде не рвануло)
[тут готовили JVM и тут сводная табличка по рантаймам и их контейнерности]
5. os threads and binding (любой рантайм общается с OS, через универсальный мостик - os thread и как понять куда утекает время)
6. parallelism and concurrency (как конкурентность и параллелизм приземляются на процессор)
[ был пост про JVM память с оверкоммитом - утащил его сюда]
7. network processing parallelism (сетевые ботлнеки, irq, softirq, epoll, где смотреть и как не упереться в один vcpu)
8. container 2 container (наш контейнер и код идеальны, где может быть ловушка в общении с соседом)
9. memory & storage (общаемся с памятью без боли и разбираемся что ж там происходит)

#firstnine #bigO #sre

формат телеграма слишком тесный для большинства тем, которые я хочу осветить, поэтому я буду пробовать разные варианты - сегодня это instant view через посты в telegra.ph

поговорим мы про один из самых фундаментальных блоков наших любимых сервисов - функцию. очень часто во время траблшутинга до них руки не доходят, это оправдано потому как понимание узких мест кода - это трудоемкая задачка. но бывают вынужденные ситуации, когда проблема 100% в логике кода и сейчас век ллмок - они вам помогут сказать, чтож там происходит если стало тяжело (но я в нас верю!). в свою очередь я хочу дать более менее универсальный подход оценки функции

https://telegra.ph/Function-the-atomic-unit-of-code-06-12

#firstnine #runtimes #sre

да, сегодня снова душная теория - обещаю, что буду разбавлять чем-то приземленным :)

предыдущих сериях разбирались с функцией, теперь пришло время понять как запускать эти все функции. запускать много и желательно сразу!

https://telegra.ph/Runtime-models---kak-zapuskat-tysyachi-funkcij-odnovremenno-06-22

#sre #ratelimits #кулстори

представьте, сидите вы как всегда никого не трогаете, и тут инцидент - все горит, пришла слишком большая нагрузка на систему. каким-то образом удается потушить и сразу переносимся на стадию разбора инцидента. идет брейшторм по тому как выстраивать защиту от таких бед и тут какой чрезвычайно опытный и достопочтенный инженер говорит: "да давайте просто рейтлимиты бахнем и сё!?".

ну а мы с вами давайте разбираться, есть ли у нас причины не бахнуть рейтлимитов то?
а они есть:
1. если рейтлимитить запросы в лоб - например 1000 рпс, то вы рискуете разрушить пользовательскую сессию в абсолютно неудачном месте. представим что 1001 запрос всегда будет авторизацией, все работает а она нет, во чудеса.
2. хорошо, а может как-то per IP сделаем? плохая идея - большие кампусные сети, где тысячи сотрудников за одним айпи вас удивят и ботов в ботнете делают так много, чтоб рейтлимит их не видел.
3. тогда по умному прокинем сессию юзера во все сервисы, и не будем пускать новых пользователей если системы перегружены? ну вот это уже не дурно, но это уже целый admission control и все равно есть еще ряд проблем.
4. текущие рейты надо где-то хранить, а еще проверять на каждый запрос иначе вы при каждом горизонтальном масштабировании ваших реплик апигейтвея или балансировщика будете повышать суммарные лимиты.
5. ну и если вы их храните и проверяете на каждый запрос, будьте готовы что ваши стейтлес сервисы станут очень зависимы от базы данных/кэша в которых рейты будут жить и этот поход добавит латенси вашим пользователям и станет потенциальным узким местом.
6. финальная проблема - за рейт лимитами надо следить, адаптировать и менять с течением времени и внезапно приходящая легитимная нагрузка, которая упоролась в забытый рейтлимит это крайне распространенный кейс.

как готовить рейтлимиты? (спойлер: не просто)
1. адаптивный троттлинг (лимиты на основе p99 latency/CPU usage) - забываем статические лимиты, не забываем вкручивать еще burst лимиты и скользящее окно
2. контекстные рейтлимиты по юзер сценарию (авторизованные и неавторизованные, на странице платежки или только проходят онбординг)
3. все обмазываем метриками и алертами
4. а лучше использовать такие практики как:
tarpit/backpressure с повышением латенси вместо дропов, circuit breaker, deadline propagation, fail fast на гейтвеях, graceful degradation и retry budget. про них будет в следующих сериях!

давайте ответим достопочтенному инженеру, что мы серьезно подумаем над его предложением и с ходу не будем пока ничего бахать :)
а на досуге почитать:
https://developers.google.com/speed/protocols/trickle_tech_report.pdf
https://aws.amazon.com/ru/blogs/architecture/rate-limiting-strategies-for-serverless-applications/

#slo #errorbudget #sre #загадкивселенной #туловина

ранее я коротко упоминал о том как мы считаем SLO и бюджеты ошибок, на примере дашборда. совсем недавно классное коммьюнити ALL SLO создало гитхаб репо с форком эпически популярного sloth, который планируем развивать силами коммьюнити.

прямо сейчас, я со своей командой как раз занимаюсь селекшном какого-то чудодейственного тулинга, который:
1. позволит держать децентрализовано ямлы, в которых как-то не слишком сложно описаны sli, slo, метрики и все необходимое для расчета
2. отрендерит это в Recording Rule с унификацией и возможностью докинуть лейблов
3. постоит прозрачно error budget за заданный период (с привязкой к календарю или скользящим окном), даст отдельно метрику берн рейта и будет считать текущий показатель доступности

мы посмотрели много раз на sloth, у него явно есть проблемы с error budget, но главное - методика расчета доступности в моменте очень непрозрачная, объяснить разработке почему показатель не 99.9, а 99.7 довольно нетривиальная задачка.
еще мы протестировали Pyrra, который как будто по описанию нам идеально подходил, но обнаружили интересную ситуацию, где при скользящем окне еррор баджета в 2 недели бюджет восполнялся внутри этого периода!
сейчас мы смотрим на Google SLO Generator и пытаемся обложить его костылями, чтобы закрыть наши потребности.

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

#firstnine #architecture #systemdesign #sre

привет всем! мы продолжаем строить первую девяточку. и это будет последняя абстрактная часть в рамках цикла статей The First Nine!

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

это навело меня на мысль, что нужен какой-то более менее оформленный подход или фреймворк для общения в ситуациях, когда "нет времени объяснять таймаут в горутинах, которые копятся ожидая пул к БД". плюс ко всему в дальнейшем буду часто делать отсылки к этим объектам, поэтому будем считать, что это в том числе и некий глоссарий.

https://telegra.ph/Typical-web-application-inner-architecture-07-13

#slo #techtalk #podcast

собрались мы тут значит и решили пообщаться на тему SLO под запись и с камерами - ну вдруг это кому-то будет интересно! :)

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

посмотреть можно вот тут:
- YouTube
- ВК Видео
- RuTube

записывались на площадке @avitotech - за монтаж отдельный лайк ребятам. моими соподкастерами были Паша и Дима - с ними было очень интересно и теперь надеюсь на продолжение!