Намедни прочитал "Чёрную книгу менеджера" от Славы Панкратова

Основные тезисы кратко:
0. О проблемах и задержках нужно сообщать сразу, а не надеяться, что они исчезнут сами
1. Менеджера оценивают по результату, а не по оправданиям.
2. Настоящий руководитель берёт ответственность на себя, а не ищет виноватых.
3. Важно понимать, как бизнес зарабатывает деньги, и связывать работу команды с пользой для компании и клиента.
4. Главная задача менеджера - работа с людьми, их развитие, мотивация и организация команды.
6. Если сотрудник не справляется, сначала нужно выяснить: не понял, не умеет, не может или не хочет.
7. Основа управления - уважение к сотрудникам, коллегам и заказчикам.

9 из 10 стоматологов менеджеров в IT строго игнорирую все это :( Если вы ПМ или тимлид - строго рекомендасьен к чтению. Книжечка очень короткая, можно прочитать буквально за полчаса

Сверху можно еще шлифануть моим материалом про говорение ртом :)

Пришел, почистил, положил или как сбросить кэш и не уронить бэкенд

Базовая ситуация - фронт кэширует отрендеренные страницы в Redis. Катим новый релиз, поменялся контент, по хорошему кэш надо инвалидировать.

Не медля ни секунды, полный газ

redis.flushdb()

НО независимо от того, удаляет Redis ключи синхронно или асинхронно, с точки зрения приложения ключи исчезают одновременно (почти). Значит тысячи запросов одновременно промахиваются мимо кэша и отправляются прямиком на бэкенд. В общем (и целом) случае это cache stampede. Накладывает на союзника пик нагрузки на БД.

Прежде чем чинить, давайте решим какие конкретно проблемы мы решаем:
1. Массовый cache miss после flushdb = все ключи протухают в одну секунду. Лечится это "размазыванием" инвалидации во времени.
2. Реальный Stampede на одном горячем ключе, то есть проблема когда именно один популярный ключ протухает, и N одновременных запросов все попадают (🤡) в miss и все бегут перегенерировать одно и то же. Тут нужно что-то типо single-flight или stale-while-revalidate.


Размазываем протухание во времени

В данном случае не просто delete, а expire с разными короткими TTL, чтобы промахи размазывались по окну, а не ударили разом.

Окну?

Хорошей идеей кажется взять что-нибудь типо log(n), но реальное ограничение - не размер кэша, а сколько страниц в секунду способен снова отрендерить бэкенд.

Эмпирически неплохой считается стартовая оценка n / rebuild_rate, где rebuild_rate это пропускная способность бэкенда по перерендеру страниц. В реальности пропускная способность бэкенда плавающая. Она зависит от текущей нагрузки на БД, лунных суток и сложности рендеринга конкретной страницы. В идеале rebuild_rate сделать адптивным. Брать его из метрик (утилизация connection pool базы, p95 latency эндпоинта рендера).

Размазываем

def stagger_expiry(
    redis,
    pattern="malutka-frontend:*",
    window_seconds=None,
    rebuild_rate=200, 
    batch_size=2000,
):
    keys = list({k for k in redis.scan_iter(pattern, count=1000)})
    n = len(keys)
    if n == 0:
        return 0 

    if window_seconds is None:
        window_seconds = max(1, math.ceil(n / rebuild_rate))

   random.shuffle(keys)

    pipe = redis.pipeline(transaction=False)
    for i, key in enumerate(keys, start=1):
        ttl = max(1, math.ceil(i / n * window_seconds))
        pipe.expire(key, ttl, lt=True)

        if i % batch_size == 0:
            pipe.execute()
            pipe = redis.pipeline(transaction=False)

    pipe.execute()
    return n

Хитрость в том, что ключам ставится короткий TTL, промахи размазываются по окну без единоразового дропа. shuffle - гарантирует, что распределение TTL не зависит от порядка обхода.

А что по stampede на горячем ключе?

Размазывание выше лечит только массовый синхронный промах. Один горячий ключ всё равно протухнет в свой момент, и в эту секунду по нему прилетит столько промахов, сколько было одновременных запросов.

Это отдельная задача и решать ее надо отдельно:
1. через single-flight / лок на регенераци - когда N одновременных промахов по одному ключу схлопываются в один перерендер, остальные ждут результат.
2. stale-while-revalidate - отдаём устаревший контент, пока один воркер под локом строит свежий. По сути компромис между актуальностью и эффективностью, но на практике один из самых разумных способов убрать stampede.
3. probabilistic early expiration (XFetch) - это алгоритм перестраивает ключ вероятностно, тем чаще, чем ближе TTL и чем дороже пересчёт. Тоже достаточно популярный способ, но со своими нюансами.

Так тривиальная на первый взгляд задача по сбросу кеша (с ростом RPS на проекте) превращается в увлекательное расследование и инженерную задачу. И здорово когда ты "на глаз" и заранее сможешь это заметить 🙂

12 лет в университете

Так уже вышло, что 12 лет назад я поступил в университет в моем городе. Успел и поучиться, и попреподавать, и пописать диссертацию по техническим наукам. Поэтому тема образования не дает мне оставаться равнодушным.

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

Я не буду говорить нужно ли получать образование в ВУЗе или нет. Это тема для бесконечного холивара. Просто я попытаюсь управлять вашими ожиданиями, если вы уже приняли решение поступить в университет или только раздумываете об этом. Я бы очень хотел, чтобы этот материал попался раньше мне и всем моим студентам, но рад, что он попался вам и, надеюсь, чем-то помог🙂

https://habr.com/ru/articles/703290/

Новый выпуск философских-айти размышлений. Сегодня я расскажу про 4 столпа выживания в айти индустрии (и не только в ней). Вашему вниманию представляется - 4 ПРАВИЛА ЛЕСА

https://habr.com/ru/articles/1052108/

Сегодня у нас в гостях Александр Кондратьев - Senior Software Engineer, Open-Source enthusiast, Django evangelist и просто разнорабочий в мире IT. Погорим про то, какое осознание приходит после нескольких лет карьеры в Айти. Ну ШТОЖ поехали

https://www.youtube.com/watch?v=6IWyUz4iWkg

На просторах заблокированных в GTA RP социальных сетей наткнулся на django-nova

Typed, unified, and async-first toolkit for Django 5+

https://github.com/Artem7898/django-nova

Мнение?

Впитываем МУДРОСТЬ СТО

https://www.youtube.com/watch?v=F6syfmQtT2E

ЧТО?! НЕайтишный гость которого интересно послушать?

@metodkina - Алина Кинаревская - методолог, экс-юрист ЦБ и владелица школы танцев. Поговорили о том, почему эксперты саботируют собственный успех, как искать ту самую боль клиента, почему "дошел до финала" не всегда главная метрика обучения, а также почему анализ ЦА ключевой фактор успешного продукта

https://www.youtube.com/watch?v=Ts5GQZQBjyk