Культура, экономика и масштаб performance

Вице-президент по разработке принимает орг с p99 800 мс и LCP 3,5 с. Каждый квартал — два-три SLO-burning инцидента, каждый потребляет 20–40 инженерных дней. У неё 6 месяцев и $500k. Вопрос не в том, как исправить текущие инциденты — а в том, как сделать производительность свойством org, пережившим её срок полномочий.

Error budgets: операционный трейдофф

SRE-книга Google формализовала производительность и надёжность как непрерывный трейдофф через error budgets.

SLO задаёт цель: “99,9% запросов /checkout менее 200 мс за 30 дней.” Error budget — допустимый shortfall: 0,1% = примерно 43 минуты в месяц. Когда бюджет здоровый, команда может быстрее доставлять фичи (больше допустимого риска). Когда бюджет исчерпан, команда должна сосредоточиться на производительности и надёжности до его восстановления.

Это превращает спор “оптимизировать или доставлять фичи?” в количественный трейдофф. Каждый релиз выпускается с предсказанным влиянием на error budget. Релизы, которые сожгут более установленного процента оставшегося бюджета, требуют явного принятия риска.

Лестница бюджетов: SLO на уровне сервиса — наверху. Route-level бюджеты (размер бандла на маршрут, query count на endpoint, allocation rate на сервис) — посередине. Feature-level бюджеты — внизу. Каждый PR несёт ответственность перед ближайшим к нему бюджетом. Когда per-route и per-feature бюджеты соблюдены, headline SLO соблюдён. Когда sub-бюджеты дрейфуют, SLO страдает первым.

Экономика производительности

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

Инфраструктурная стоимость: сервис с 2x лучшим throughput требует вдвое меньше инфраструктуры при той же нагрузке. Счёт AWS масштабируется с vCPU, памятью и пропускной способностью. Конкретные примеры:

• Переписывание структурного логгера Discord снизило per-request аллокации на 90%, опустив накладные расходы GC с 20% до менее 2%. Инфраструктурная стоимость сервиса чата снижена на 40%.
• Оптимизация LCP storefront Shopify на мобильных устройствах (bundle audit + lazy-load) восстановила LCP с 4,5 с до 1,9 с. Показатель отказов снизился на 12%, напрямую связанный со скоростью страницы.
• Программа profile-first на стороне сервера Stripe возвращает оценочно $5–10 в сэкономленных инфраструктурных затратах на каждый инженерный час.

Инженерная velocity: команды со зрелой дисциплиной производительности тратят 5–10% инженерного времени на неё как постоянное обслуживание. Команды без неё — 20–40% в кризисном режиме. Разница — 15–30 процентных пунктов инженерной ёмкости, постоянно освобождённой для продуктовой работы.

Найм и удержание: быстрое ПО — конкурентный дифференциатор. Инженеры, присоединяющиеся к командам с зрелой дисциплиной производительности, задерживаются дольше и производят больше.

Снижение toil: превращение пожаротушения в инфраструктуру

SRE-фреймворк снижения toil спрашивает: какая ручная работа повторяется, автоматизируема и растёт с масштабом? Пожаротушение производительности — классический toil: алерт в 3 часа ночи, ручная диагностика, исправление, повторение через три месяца. Цикл превращает toil в инфраструктуру.

Здоровая команда удерживает toil ниже 50% инженерного времени по SRE-руководству. Многие команды сидят на 70–80% до дисциплины и 20–30% после. Инвестиция в observability, gates и runbook окупается не только снижением инцидентов, но и восстановлением инженерного времени, постоянно перенаправляемого на продуктовую работу.

Измеряйте: отслеживайте количество performance-инцидентов в квартал и средние инженерные часы на инцидент. В Q1 зрелой программы они падают на 50–70% от базового уровня. После 12 месяцев стабилизируются около нуля для известных классов отказов.

Распределённое владение: избегание bottleneck

Антипаттерн: централизовать всю работу по производительности в одну “команду производительности”. Эта команда становится bottleneck — каждая продуктовая команда ждёт её, каждая регрессия становится “чужой проблемой” до кризиса.

Паттерн, масштабирующийся:

• Frontend-инженеры: фрагменты 02 + 07 (hot paths + bundle budgets). Владеют per-route CWV.
• Backend-инженеры: фрагменты 02 + 04 + 05 + 06 (hot paths + GC + N+1 + batching). Владеют per-endpoint latency и query budgets.
• SRE / DevOps: фрагмент 01 (profile-first инфраструктура, непрерывное профилирование). Строят и поддерживают CI gates.
• Platform-инженеры: фрагмент 03 (cache vs big-O — фундаментальные паттерны). Поддерживают общий observability-стек.

Платформенная команда строит инфраструктуру, которая позволяет каждой команде владеть своей производительностью. Без распределения производительность незаметно деградирует по мере доставки фич продуктовыми командами без подотчётности. С ним каждый PR проверяется против бюджетов, каждая команда разбирает регрессии ретроспективно, а платформенная команда ускоряет, а не блокирует.

Культурные механизмы, обеспечивающие устойчивость

Три практики строят прочную культуру:

1. Производительность в каждом PR-ревью, а не отдельной фазе. PR-шаблон включает пункт чеклиста: “влияние на производительность рассмотрено.” Код-ревьюеры обучены замечать семисигнальные паттерны (lazy loading пропущен, N+1 введён, лишние аллокации) и спрашивать. Ежеквартальные инженерные опросы спрашивают “ваш ревьюер обращал внимание на производительность?” — измеряет приживаемость культуры.

2. OKR инженерного менеджера включают производительность. OKR EM включают “поддерживать или улучшать route SLOs” наряду с delivery-метриками. Критерии продвижения senior-инженера включают “демонстрированные улучшения производительности систем в зоне владения”. Без этого инженеры рационально депrioritизируют производительность в пользу видимой работы над фичами. С ним рациональный выбор совпадает с здоровьем команды.

3. Blameless retro после каждого performance-инцидента, всегда заканчивающееся новым gate. Структура ретро: что был симптом, что была первопричина, какой gate поймал бы раньше, кто владеет добавлением gate. Накопленные CI gates и записи runbook становятся институциональной памятью команды; новые инженеры наследуют её с первого дня.