В вакансиях всё чаще пишут SRE, SLO, error budget, оптимизация TCO в облаке. Для кого то эти слова новые, но на деле это простая управленческая логика: сервис должен работать предсказуемо, а стоить ровно столько, сколько нужно, а не сколько получилось.

SRE это не админы помоложе SRE родился из идеи Google: надёжность сервиса можно строить как продукт, а не как вечный пожарный режим. Классическая эксплуатация часто живёт так: упало починили, снова упало снова починили. Герои есть, системы нет. SRE спрашивает иначе. Что для нас значит сервис живой. Как мы это измеряем. Сколько сбоев мы готовы терпеть. Что делаем, когда терпение кончилось.

Три слова, которые реально надо понимать. SLI это показатель. Например доля успешных запросов, время ответа, процент оформленных заказов. SLO это цель по этому показателю. Например 99.9 процентов успешных запросов за месяц. Error budget это допустимый запас на поломки. Если цель 99.9 процентов, то 0.1 процента ошибок ещё в бюджете. Бюджет есть можно быстрее катить фичи. Бюджет почти сгорел сначала чиним надёжность, потом красоту. Это и есть мост между бизнесом и разработкой. Не давайте всё зафризим на месяц, а по цифре видно: сейчас риск выше пользы от новой фичи. Ещё из практики, без которой SRE не взлетает. Понятный on-call, а не кто ответил в чате. Разборы инцидентов без поиска виноватых, с конкретными действиями. Алерты по симптомам для пользователя, а не диск на 87 процентов в три ночи без последствий. Автоматизация восстановления там, где человек уже надоел чинить одно и то же. Если коротко: SRE это дисциплина, которая делает нестабильность управляемой.

TCO это не сколько стоит сервер TCO это полная стоимость владения. Не прайс инстанса в облаке, а всё, что вы платите за то, чтобы решение жило. В TCO обычно сидит железо или облако, лицензии и внешние сервисы, люди разработка поддержка дежурства, инциденты и простой, миграции обучение техдолг. Поэтому фраза давайте в облако там дешевле сама по себе ничего не значит. Иногда облако дешевле на старте и дороже через год. Иногда наоборот. Смотреть надо на сумму владения, а не на одну строку в счёте. Оптимизация TCO это не срезать бюджет любой ценой. Это снизить стоимость без убийства скорости и надёжности. Иначе вы сэкономите на инфраструктуре и заплатите падениями, ночными дежурствами и потерей выручки. Это ложная экономия. Облачный TCO: где обычно утекают деньги В облаке редко внезапно дорого. Обычно дорого незаметно. Типовые рычаги, которые реально работают. Первое. Rightsizing. Платите за размер, который нужен, а не за с запасом на всякий случай. Второе. Reserved и commitment. Скидка за обязательство, если нагрузка предсказуема. Третье. Выключение простоя. Ночные и тестовые контуры не обязаны жить круглосуточно как прод. Четвёртое. Хранилище. Старые логи и бэкапы не обязаны лежать на самом дорогом тарифе. Пятое. Трафик и логи. То, что никто не смотрит, тоже приходит в счёте. Шестое. Плотность. Меньше пустых машин, выше утилизация. Седьмое. Make vs buy. Иногда купить сервис дешевле, чем содержать свою команду вокруг самописного. Хороший вопрос для команды не как нам экономить, а какая стоимость у каждого критичного продукта и что мы получаем за эти деньги.

Как SRE и TCO связаны Их часто разводят по разным слайдам. В жизни это одна история. Если режете стоимость и ломаете SLO, вы не оптимизировали TCO. Вы переложили риск на бизнес. Если держите идеальную надёжность ценой огромного простоя мощностей и ночных героев, вы тоже платите лишнее. Нормальная рамка звучит так. Договорились о уровне сервиса. Видим стоимость владения. Двигаем фичи, пока error budget позволяет. Экономим там, где не бьём по пользователю и выручке. Для руководителя отдела это уже не технарские буквы, а язык управления: приоритеты, риск, деньги, скорость.