«Зелёный коридор» (ЗК) — проект перестроения культуры потребления ресурсов в масштабах «цифрового государства». Чтобы вы понимали масштаб инфраструктуры, которой мы управляем:
-
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-команда создаёт витрины, которые видят каждое ядро.
А как у вас обстоят дела с «переподпиской» и борьбой за квоты? Пишите в комментариях, обсудим.
ссылка на оригинал статьи https://habr.com/ru/articles/1043194/