«Зелёный коридор» (ЗК) — проект перестроения культуры потребления ресурсов в масштабах «цифрового государства». Чтобы вы понимали масштаб инфраструктуры, которой мы управляем:
8 000 000 физических ядер;
1,2 экзабайта данных в хранилищах;
Почти 600 000 серверов, считая виртуальные машины.
Когда работаешь с такими объёмами, даже микроскопическая погрешность в 1% лишней аллокации превращается в гору «мёртвого железа», на котором можно было бы запустить ещё один банк средних размеров. В начале наше фактическое потребление ресурсов находилось в районе 27%.
Звучит как катастрофа? На самом деле это был осознанный выбор, нулевая терпимость к риску. У нас в Сбере культура выживаемости систем: нормой являются схемы 2N, 4N или Active-Active на четыре площадки (одна из которых вообще в другом регионе с огромными сетевыми задержками). Добавьте к этому логистический шок 2022 года, когда железо наконец доезжало до стойки, а инженеры резервировали его под завязку: «А вдруг завтра поставки встанут?». И кто не слышал про программы импортозамещения? Или legacy to platform (L2P) — смена платформенного ПО: кто в Сбере, тот поймёт, почему по завершению программы некоторые сотрудники неподдельно радовались и кричали «Ура!». В итоге квоты выбраны, бюджет потрачен, а процессоры недоиспользованы.
Проект такого уровня не потянет горстка людей. Да, у нас есть «ядро» в лице Вадима Татарницева, Евгения Акинчица, Анны Осиповой и Евгения Бинна. Но также у нас есть команда эксплуатации, которой руковожу я, Максим Халматов, и подразделение Алексея Нестеренко, которое тянет огромные стримы по аналитике и методологии.
Методология: почему $Среднее + 2\sigma$ — это не просто математика
«Зелёный коридор» — это методика, позволяющая с помощью единого интегрального показателя оценить эффективность использования инфраструктуры на самых детальных уровнях: от виртуальных машин до контейнерных кластеров. В первой версии наш интегральный показатель зависел от шести ключевых метрик:
Потребление процессора и памяти виртуальными машинами.
Потребление дисков виртуальными машинами.
Потребление квот OpenShift Enterprise (OSE).
Потребление лимитов OSE.
Потребление квот DropApp (DA).
Потребление лимитов DA.
Почему именно эти метрики? По ним была достаточно точная отчётность, а в инфраструктуре с десятками тысяч серверов это уже значимое преимущество. Полная точность при таких масштабах недостижима: что‑то ломается, где‑то пропадают данные. Это всё-таки инфраструктура, которая живёт и дышит.
Контейнеризация в банке занимает значительную долю инфраструктуры. В периоды активных миграций объём фактически удваивается, а команды при планировании традиционно закладывают ресурсы с запасом.
Главный вопрос: как отделить плохое потребление от хорошего? Идти классическим путём — проводить исследования и нагрузочные тесты для каждого из 50+ продуктов в режиме эксплуатации — нереально. Хотя нам всё равно пришлось этим заниматься, потому что у нас не было времени на академические исследования. Сейчас мы уже поменяли методику нагрузочного тестирования и теперь ищем не только максимумы-минимумы, но и параметры оборудования для попадания в параметры Зелёного коридора.
Мы выбрали прагматичный подход: взяли среднее значение с верхним доверительным интервалом по двум квадратичным отклонениям на периоде в 90 дней. Почему 90? Чтобы сгладить сезонность, дать время на «разогрев» сервера и отсечь разовые пики, которые не отражают реальную жизнь продукта. Если система попадает в этот расчётный «коридор», то она считается эффективной, а если нет, то мы идём к владельцу с вопросами.
Но давайте чуть подробнее. Начнём с классики — виртуальных машин. Мы считаем среднее значение с верхним доверительным интервалом по двум квадратичным отклонениям на периоде в 90 дней. CPU и RAM считаем по-отдельности, затем для группы (или одной VM) берём минимум из двух значений. Если расчёт ведём для группы, то сначала считаем средневзвешенные значения по процессору и памяти, затем берём минимум из них — это и есть потребление.
Зачем минимум? Чтобы исключить ситуацию, при которой процессор загружен полностью, а память простаивает (или наоборот), но ресурс формально считается «потреблённым».
Логика коридоров
Для каждого типа стенда (пром, тест и так далее) и класса критичности автоматизированной системы заданы собственные границы нормальности. В Сбере используются четыре класса критичности: от основных клиентских сервисов до внутренних систем, не взаимодействующих с внешними клиентами.
На уровне сущности в ITSM (фактически — для каждого продукта) мы:
Берём рассчитанные метрики потребления.
Проверяем, попадает ли конкретная VM в свой «Зелёный коридор».
Для подразделения считаем средневзвешенную долю виртуальных машин, прошедших в коридор.
Остальные метрики считаем по схожей логике, но с другим базовым показателем.
Как считаются остальные метрики
Для остальных метрик используется максимум за 90 дней по отношению «использовано/выделено». Это применительно к другим сущностям:
Диски VM: максимальное отношение использованного к выделенному за 90 дней.
Квоты OSE: максимальное отношение лимитов проекта к квоте проекта за 90 дней.
Лимиты OSE: максимальное отношение потребления процессоров и памяти в проекте к лимитам проекта за 90 дней.
Квоты DA: максимальное отношение лимитов кластера к квоте кластера за 90 дней (из квоты вычитаем неуправляемую клиентом техническую обвязку — 15% размера кластера).
Лимиты DA: максимальное отношение потребления процессоров и памяти кластера к лимитам кластера за 90 дней.
Почему для контейнеризации берём максимумы, а не средние?
На начало 2025 года скважность сбора данных по проектам и кластерам составляла 1 раз в час. При такой частоте среднее значение имеет высокую волатильность. В первом квартале мы довели частоту до одного замера в 15 минут, однако для расчёта средних с доверительными интервалами требуется частота не реже одного раза в минуту, как в виртуализации.
При этом у нас более 8 млн контейнеров, с каждого снимается до восьми сырых метрик каждую минуту. Для хранения хотя бы двух дней таких данных (на случай инцидента) требуется порядка 100 ТБ — это само по себе инфраструктурная задача.
Агрегировать всё на стороне мониторинга тоже нельзя: он перестанет выполнять свою основную функцию и превратится исключительно в «двигатель потребления». Сейчас мы нашли техническое решение этой задачи (об этом выпустим отдельную статью), но в начале 2025 года приняли прагматичное решение: для контейнеризации считать по максимумам.
Детектив на проде: сайдкары и «обогреватели» стоек
Когда мы начали оптимизировать лимиты в Kubernetes, вскрылся пласт проблем, о которых мы даже не подозревали. Сбер — это про безопасность. На каждое приложение навешивается куча «сайдкаров» (proxy, security-агенты, журналирование). Выяснилось, что эта инфраструктурная «обвязка» в некоторых проектах потребляла больше ресурсов, чем само полезное приложение! В итоге пришлось создавать отдельный инженерный стрим, пересматривать лимиты для этих сервисов и проводить кратную оптимизацию. Эффект на масштабе в 8 млн ядер был просто колоссальным.
Конечно, были и те, кто пытался «хакнуть» систему. Как только «Зелёный коридор» начал реально влиять на KPI подразделений, в журналах замелькали странные вещи. Некоторые писали скрипты, которые имитировали нагрузку на процессор («грелки») или искусственно раздували Xmx у Java-машин, чтобы не отдавать квоты по памяти.
Мы быстро разработали инструменты обнаружения таких аномалий. К чести коллег, эта «партизанская война» длилась недолго. Сейчас все понимают: проще и честнее оптимизировать архитектуру или признать необходимость масштабирования, чем оправдываться за бессмысленный обогрев серверной.
Интеграл эффективности: 80% против 27%
Самый частый вопрос, который нам задают: «Как у вас в отчётах может стоять 80% выполнения целей ЗК, если реальная загрузка железа 27%?».
Тут нет магии или подтасовки. Это двухэтапный процесс.
Этап первый (Зелёный коридор): мы заставляем клиентов эффективно использовать те квоты, которые они уже получили. Если ты взял 100 ядер, а используешь 10 — верни 90. Когда все «сдают лишнее», квоты освобождаются.
Этап второй (уплотнение): на освободившиеся «виртуальные» ресурсы мы сажаем новых клиентов или расширяем старые проекты без закупки нового железа.
В результате мы уже подняли производственное потребление с 27% до 37%. Кажется, что 10% — это мало? Но в пересчёте на сэкономленные средства это сопоставимо с годовой прибылью среднего банка.
Взгляд за горизонт: от процентов к FinOps
Мы не хотим, чтобы «метрика стала целью» (эффект Гудхарта). Поэтому «Зелёный коридор» — это лишь фундамент для перехода к полноценному FinOps.
Что мы строим сейчас:
Unit-экономику. Мы хотим точно знать Cost-to-Value — сколько ИТ-денег тратится на обслуживание одного клиента или одной транзакции. Только так можно понять реальную эффективность бизнеса.
Managed Inference Platform. Наша собственная разработка для совместного использования GPU-ресурсов. Дорогие видеокарты не должны простаивать, они должны «нарезаться» между проектами в зависимости от текущей нагрузки.
DB-as-a-Service. Мы ломаем старый подход «один сервер — одна база». Разработчику проще и быстрее получить контейнер с PostgreSQL, чем ждать развёртывания тяжёлой версии, которая наполовину будет стоять пустой.
Наш идеал — потребление не менее 50% при сохранении всех стандартов надёжности. Это амбициозно, это сложно, но это единственный путь для компании такого масштаба.
В следующих статьях мы подробнее расскажем о том, как решали проблему сбора метрик (8 млн контейнеров — это вам не шутки) и как наша BI-команда создаёт витрины, которые видят каждое ядро.
А как у вас обстоят дела с «переподпиской» и борьбой за квоты? Пишите в комментариях, обсудим.