Green SRE: можно ли быть зеленым и надежным¶

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

А теперь добавьте к этому новую переменную: энергию. Ваши серверы ее просто едят. Ваши базы данных ее едят. Ваши бесконечные тестовые окружения, которые кто-то забыл выключить полгода назад, тоже ее едят. И за все это кто-то платит.

Раньше мы называли это "оптимизацией затрат" и гордились собой. Теперь это называют "Green SRE" и иногда добавляют слово "устойчивость". Но суть не меняется: меньше ресурсов == меньше денег. А если при этом планета становится чуть здоровее - ну, приятный бонус, как кэшбэк, о котором вы не просили, но который приятно получить.

Вопрос, который мучает многих: "А не придется ли мне жертвовать надежностью, чтобы быть зеленым?" Спойлер: нет. Или почти нет. Или да, но вы об этом узнаете осознанно, а не в 3 часа ночи во время сбоя.

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

В 2026 году ситуация изменилась. И вот почему.

Первое: деньги стали ощутимее.

Если вы работаете в облаке, вы знаете этот момент. Вы открываете биллинг за месяц и видите строку "Compute". И думаете: "Мы что, крипту майнили?!" Нет, это просто ваши QA-окружения, которые разработчики забыли выключить, и десяток инстансов, которые работают на 5% загрузке, потому что когда-то кто-то заложил запас "на всякий случай".

По данным Flexera за 2025 год, треть облачных расходов уходят впустую. Треть! Это как купить три стейка и один выбросить. Только стейков тут на миллионы рублей.

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

Второе: регуляторика пришла и к нам.

Европейский CSRD (Corporate Sustainability Reporting Directive) уже заставляет компании, работающие с Европой, отчитываться об углеродном следе. Американские требования SEC то же самое. Российские компании, которые выходят на международные рынки или работают с глобальными партнерами, уже сталкиваются с вопросами: "А какой у вас углеродный след? А какие у вас показатели энергоэффективности?"

Даже если вы чисто внутренний российский бизнес, крупные заказчики (госкомпании, ритейлеры, банки) все чаще включают экологические требования в тендеры. Не потому, что они вдруг стали экоактивистами, а потому что у них самих такие требования сверху.

Третье: ресурсы не бесконечны.

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

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

Так что Green SRE это не про "спасем планету". Это про "спасем бюджет и не упремся в потолок мощностей". Экологическая составляющая приятное дополнение, как иконка "эко" на стиральной машине, которая экономит воду и электричество, а заодно и планету.

Миф: устойчивость убивает надежность¶

Самый популярный аргумент, который я слышу от коллег: "Вы хотите, чтобы я отключил резервные мощности ради экономии? А если все упадет? Вы тогда придете планете помогать?"

Это справедливый вопрос. И ответ на него: нет, мы не предлагаем отключать резервы. Мы предлагаем перестать держать резервы, которые никогда не использовались, и перестать запускать инстансы, которые ничего не делают.

Вот вам пример из жизни российского ритейлера (назовем его "Очень Большой Магазин"). У них было правило: каждый микросервис должен работать в трех зонах доступности с запасом мощности 200% от пиковой нагрузки. Звучит надежно. Звучит как "мы никогда не упадем".

Проблема была в том, что пиковая нагрузка случалась раз в месяц, в день распродажи. Остальные 29 дней 60% инстансов работали с загрузкой CPU 3-7%. Они потребляли энергию, занимали места в стойках, генерировали тепло, которое требовало охлаждения, и тихо съедали бюджет.

Когда команда SRE посчитала, сколько денег уходит на эти "спящие" инстансы, у финдира случился легкий когнитивный диссонанс. Сумма за год равнялась стоимости новой команды разработки.

Что они сделали? Они не отключили резервы. Они внедрили умное масштабирование. Теперь в обычные дни работает минимально необходимая мощность. За час до распродажи система начинает поднимать дополнительные инстансы. После распродажи аккуратно убирать.

Надежность не упала. SLO остались теми же. А счет за облако уменьшился на 28%. И энергии стало уходить на треть меньше.

Это не история про жертвы. Это история про то, что избыточность, которая не управляется, это не надежность. Это просто расточительство.

Как измерить, насколько вы зелены (и не в смысле цвета вашего дашборда)¶

Вы не можете управлять тем, что не измеряете. Это золотое правило SRE работает и здесь.

На уровне инфраструктуры есть три основные метрики, которые стоит знать.

PUE (Power Usage Effectiveness)

Это отношение всей энергии, потребляемой дата-центром, к энергии, которая уходит непосредственно на IT-оборудование. Остальное уходит на охлаждение, освещение, потери.

Идеальный PUE равен 1,0. Реальный от 1,2 до 2,0. В крупных коммерческих дата-центрах Москвы и Санкт-Петербурга хороший показатель 1,3-1,5.

Что вам с этим делать? Если вы арендуете стойки в коммерческом дата-центре, вы мало можете повлиять на PUE. Но вы можете выбирать провайдера с лучшими показателями. И, поверьте, крупные дата-центры уже соревнуются в PUE, потому что для них это конкурентное преимущество.

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

CUE (Carbon Usage Effectiveness)

Это метрика углеродного следа. Она учитывает не только сколько энергии вы съели, но и то, насколько эта энергия была "грязной" с точки зрения выбросов.

В России структура генерации разная в разных регионах. Если ваш дата-центр стоит в Сибири, где много гидроэнергии, ваш CUE будет лучше, чем если он стоит в регионе, где энергия производится на угле или газе.

Некоторые облачные провайдеры уже позволяют выбирать регионы с более "зеленой" энергией. Яндекс.Облако, например, публикует данные об энергоэффективности своих дата-центров. VK Cloud тоже. И если для вас это важно (а для отчетности перед европейскими партнерами может быть важно), вы можете сделать выбор осознанно.

Carbon Intensity per Request

А вот это уже ваша метрика. Метрика уровня сервиса.

Carbon Intensity per Request = (общее потребление энергии сервисом) / (количество обработанных запросов)

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

Как? Те же методы, что и для оптимизации latency и cost. Оптимизация кода, эффективное кэширование, правильный выбор типов инстансов, избавление от лишних операций.

И здесь появляется интересная закономерность: то, что делает ваш сервис быстрее и дешевле, обычно делает его и "зеленее". Потому что меньше вычислений на запрос = меньше энергии = меньше latency = меньше денег.

Waste Ratio

Это процент ресурсов, которые вы оплачиваете, но не используете.

Спящие инстансы, переразмеренные виртуальные машины, неиспользуемые диски, старые снапшоты, QA-окружения, которые разработчики забыли выключить, все это попадает в Waste Ratio.

Хороший Waste Ratio меньше 10%. В среднем по отрасли, как мы помним, 32%. То есть большинство компаний платят треть от своего облачного счета просто так.

Практики Green SRE¶

Теперь к конкретике. Вот что можно сделать прямо завтра, не рискуя доступностью и не просыпаясь от алертов в три часа ночи.

Resource right-sizing

Золотое правило: не держите инстансы "на всякий случай". Автоскейлинг придумали именно для этого.

Посмотрите на свои сервисы. Какова их обычная нагрузка? Какова пиковая? Есть ли разумный сценарий, при котором нагрузка вырастет внезапно, без возможности предварительно поднять мощности?

В большинстве случаев пики можно предсказать. Черная пятница, распродажи, начало учебного года, новогодние праздники - вы знаете эти даты. Система может готовиться к ним заранее, поднимая мощности за час-два до события.

В остальное время работайте на минимально необходимой конфигурации.

Spot-инстансы для некритичных нагрузок

Spot-инстансы - это виртуальные машины, которые облачные провайдеры продают со скидкой 60-90%, но с условием: в любой момент, когда эти мощности понадобятся кому-то, кто готов платить полную цену, вашу машину могут выключить.

Звучит страшно. Но для многих задач это идеальное решение.

Что можно запускать на spot-инстансах? Фоновые задачи, batch-обработку, CI/CD, тестовые окружения, dev-среды. Все то, что если упадет, никто не заметит или это можно будет перезапустить через 5 минут без последствий.

А что нельзя? Критичные онлайн-сервисы, базы данных, системы, от которых зависит жизнь пользователей.

В российских облаках (Яндекс.Облако, VK Cloud и других) spot-инстансы уже есть. И экономия на них вполне реальная.

Выбор регионов

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

В России, например, дата-центры в Сибири часто имеют лучший PUE, чем в Москве, потому что холодный климат позволяет использовать свободное охлаждение большую часть года.

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

И да, иногда такие регионы еще и дешевле. Потому что энергия там стоит меньше.

Оптимизация кода

Это звучит как "напишите код лучше", что, конечно, легко сказать, но сложно сделать.

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

APM-инструменты (Application Performance Monitoring) помогают находить такие места. Посмотрите на свои самые медленные эндпоинты. Оптимизируйте их. Вы получите меньше latency, меньше нагрузки на инфраструктуру, меньше счетов и меньше энергии.

Утилизация ресурсов

Загрузка CPU 5% в течение 30 дней это не запас надежности. Это инстанс, который можно или заменить на более дешевый, или объединить с другим, или просто выключить.

Автоматизируйте поиск таких ресурсов. Настройте политики: если инстанс работает с загрузкой ниже X% в течение Y дней, он получает тег "кандидат на оптимизацию". А дальше инженер принимает решение.

То же самое с дисками. Неподключенные (unattached) диски, старые снапшоты, неиспользуемые балансировщики - все это тратит деньги и энергию.

Когда надежность требует энергии (и это нормально)¶

Давайте будем честными. Иногда надежность действительно требует энергии. И это нормально.

Геораспределение

Если вы хотите, чтобы ваш сервис пережил отказ целого дата-центра, вы держите ресурсы в нескольких регионах. Это больше серверов, больше энергии, больше денег.

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

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

Active-active vs active-passive

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

Но active-passive имеет свой минус: переключение занимает время. Если для вас RPO и RTO измеряются секундами, active-active ваш выбор. Если вы можете пережить пару минут простоя, active-passive сэкономит вам кучу энергии и денег.

Реальный пример из российской практики¶

Возьмем условный банк, который мы назовем "Большой Банк".

У них была проблема: QA-окружения. Десять команд разработки, у каждой по 3-4 окружения (dev, test, staging, pre-prod). Все окружения работали 24/7. На них крутились инстансы, базы данных, очереди, кэши. Вся эта красота потребляла энергию и стоила около 2,5 млн рублей в месяц.

SRE-команда сделала несколько вещей.

Во-первых, внедрили политику: окружения живут только в рабочее время. С 22:00 до 09:00 они автоматически выключаются. В выходные тоже.

Возражение разработчиков: "А если я хочу поработать вечером из дома?" Решение: можно запросить продление вручную через чат-бота. Бот включает окружение на 4 часа. Потом снова выключает.

Во-вторых, для dev-окружений начали использовать spot-инстансы. Dev-окружению не нужна надежность 99.99%. Если оно упадет, разработчик просто перезапустит задачу.

В-третьих, внедрили автоматический поиск "зомби". Инстансы, которые работают больше 30 дней без перезапуска, с загрузкой CPU ниже 10%, автоматически получают уведомление владельца: "Если через 7 дней вы не подтвердите необходимость, инстанс будет остановлен". 70% таких инстансов оказывались забытыми.

Результат за год: сокращение облачных расходов на QA-окружения на 42%. Снижение энергопотребления на 38%. При этом ни один критичный сервис не пострадал, ни одно SLO не было нарушено.

А разработчики? Они привыкли. И даже полюбили. Потому что теперь утром в понедельник они не ждут, пока окружение поднимется вручную, оно уже готово к 9:00. А вечером пятницы оно выключается само, и никто не забывает.

Как внедрять Green SRE без боли¶

Если вы решили, что хотите попробовать:

Шаг 1. Начните с измерения.

Нельзя улучшить то, что вы не измеряете. Начните считать Waste Ratio. Посмотрите, сколько у вас ресурсов работает с загрузкой ниже 10%. Сколько "спящих" инстансов. Сколько QA-окружений, которые никто не использует. Посмотрите просто на числа. Без осуждения. Числа не врут.

Шаг 2. Найдите легкие победы.

QA-окружения, dev-среды, неиспользуемые диски это то, где результат будет быстрым и безболезненным. Начните с этого. Покажите руководству первые цифры экономии. Это создаст аппетит и доверие.

Шаг 3. Автоматизируйте, а не запрещайте.

Никто не любит запреты. "Нельзя создавать инстансы больше X" - это путь к тому, что инженеры начнут вас ненавидеть и обходить правила.

Вместо этого сделайте так, чтобы правильное поведение было удобным. "Хочешь поднять dev-окружение? Вот кнопка. Оно поднимется через 2 минуты и будет работать 8 часов, потом выключится само. Хочешь дольше? Нажми "продлить".

Шаг 4. Сделайте энергоэффективность видимой.

Добавьте в дашборды SRE показатели энергопотребления и Waste Ratio. Чтобы инженеры видели, как их решения влияют не только на latency и SLO, но и на то, сколько энергии съедает их сервис.

Конкуренция между командами мощная штука. Когда команда А видит, что у команды Б Waste Ratio 5%, а у них 25%, у них появляется здоровая мотивация.

Шаг 5. Не трогайте критичные сервисы в первую очередь.

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

Когда это не работает¶

Признаюсь честно: есть ситуации, где Green SRE это не про вас.

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

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

Green SRE это не религия. Это подход. Он работает там, где есть возможность оптимизации без потери надежности. А там, где такой возможности нет, вы просто платите за надежность. И это осознанный выбор.

Green SRE это вообще не про какие-нибудь жертвы во имя планеты. Это про то, чтобы перестать жечь деньги и энергию на то, что не приносит бизнесу пользы и не делает системы надежнее.

Большинство компаний могут сократить энергопотребление и облачные расходы на 20-30% без нарушения SLO. Просто потому, что у них есть куча ресурсов, которые работают впустую.

Начните с измерения Waste Ratio. Найдите легкие победы в QA-окружениях и dev-средах. Автоматизируйте, а не запрещайте. Сделайте энергоэффективность видимой в дашбордах. И помните: то, что делает ваш сервис быстрее и дешевле, почти всегда делает его и "зеленее".

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

И только если собеседник окажется сочувствующим, добавьте: "Ну и планете, кстати, тоже немного легче". Как бонус.

Как кэшбэк. Который вы не ждали, но который приятно получить.