А вы тоже слышали байку о том, что облако по сравнению с онпрем-инфраструктурой получается едва ли не дешевле электричества из розетки, а PAYG – справедливее коммунизма? Нет, в целом принцип и правда выглядит очень честно: сколько заказал – столько и заплати. Как в ресторане. На практике такого, конечно, чаще всего бывает. Но чего всегда бывает в избытке – так это претензий финотдела, который кого угодно сведет с ума, допытываясь, почему растут счета. А кто бы их знал? Продакшн стабилен, метрики зеленые, архитектура давно устоялась – причин для роста как будто и нет. Но компании то и дело выходят за рамки бюджетов.
«Счёт опять больше. Мы же ничего не меняли»
SRE в SaaS-компании
Налетают к нам на днях финансы с претензией по счетам. Дескать, куда дели деньги? Я, не будь дураком, открываю им консоль и тыкаю как котят: у меня все как в аптеке. Каждый сервис работает ровно так, как проектировали. Утилизация стабильная, нагрузка в пределах расчетной, всплесков нет. Инфраструктура под контролем. Все как надо. Не первый год замужем.
Успокаиваюсь. Объясняю: так и должно работать, инфраструктура динамическая, мы не можем держать фиксированное потребление. Они кивают, вроде даже соглашаются, а потом опять по новой.
Вопросы при этом задают такие, будто я сам не понимаю, чем занимаюсь:
Где именно мы начали тратить больше, если изменений не было?
Что из этого роста нормальная динамика, а что перерасход?
Кто вообще должен уметь объяснять итоговую цифру?
«Мы оптимизировали пуб��ичное облако два года. А теперь посчитайте онпрем»
Head of Infrastructure в финтехе
У нас в компании есть публичные облака и собственный дата-центр. Два года ребята работали над снижением расходов в публичке: смотрели биллинги, строили отчеты, удаляли лишнее, меняли типы ресурсов, резервировали мощности. Сложно, но понятно — цифры перед глазами.
И тут как-то раз приходит к нам молодец из CFO. Красивый такой, в пиджаке, и просит: посчитайте, мол, наше железо в деньгах. Как облако. Сравнивать будем.
Кладу под язык глицинчик и начинаю объяснять. Железо купили три года назад по CAPEX. Деньги потрачены, оборудование амортизируется. Это вообще ни разу не OPEX, это в принципе другая модель учета. Сравнивать их – как с трамвайной ручкой развлекаться. Бестолку, короче.
А ему хоть бы хны. Дай цифры и все.
А как считать-то?! Можно посчитать по остаточной стоимости — получится одна сумма. Можно по рыночной цене аналогов сейчас — будет в два раза выше. Можно по амортизации — третий вариант. И все три подхода формально корректны, но результаты дадут разные.
А главное — практический смысл этих расчетов какой? Удалишь виртуальную машину из онпрема, счет не изменится. Железо уже куплено, электричество оплачено, аренда ЦОД зафиксирована.
Причем спросят о том, ответить на что невозможно:
Зачем переводить CAPEX в OPEX, если деньги уже потрачены?
Как эти цифры потом вообще использовать?
В чем смысл экономии, если удаление ВМ не меняет счета?
Как подойти к оценке: по закупке, амортизации или рыночной цене?
Если знаем общую стоимость — как распределять ее на CPU, RAM, диски?
«Мы переехали в гибрид ради экономии. Стало сложнее»
Архитектор в крупной компании
У нас часть нагрузки крутится в облаке, а часть у себя. Сами понимаете, регуляторика, легаси, политика компании. Решение архитектурно более чем обоснованное, спорить не о чем.
Только вот теперь облако считает одна команда, а онпрем — другая. Как следствие, отчеты разные, метрики разные, все разное. По отдельности каждый кусок вроде понятен, а общей картины нет. Что выгоднее-то? А как тут сравнишь, если модели затрат вообще не сопоставимы? Вопрос риторический.
Вот и живем теперь с тремя системами учета вместо одной. А потом удивляемся, почему счета растут. Да потому что на работу людей надо брать не по объявлению!
И разговор каждый раз за пределы инженерных обсуждений выходить не будет. А то достали уже:
Как сравнивать эффективность публичного облака и онпрема?
По каким метрикам принимать решения о миграции туда или обратно?
Что считать дешевле, если модели затрат разные?
Где заканчивается инженерия и начинается экономика?
«Мы берём ресурсы с запасом. Потому что так безопаснее»
DevOps в продуктовой компании
Никто не хочет быть крайним, если продакшен упадет. Вы вот хотите? Я – нет.
Поэтому резервируем. Память, диски, ядра. Я считаю, это правильно. Надежность же важнее.
Мы понимаем, что в облаке это рост счета, а в онпреме — нехватка мощностей и заявки на закупки. Но если продакшн ляжет – отвечать-то нам, а не этим экономистам.
Финансы смотрят на утилизацию CPU 40% и спрашивают: почему не 80%? Можно же взять инстансы помельче и сэкономить.
Объясняю базовые вещи. Эти 40% — средняя утилизация. При пиковой нагрузке она поднимается до 90%. Если уберем запас, при следующем пике система начнет деградировать. Latency вырастет, часть запросов упадет по таймауту, пользователи получат ошибки.
Запас нужен не от жадности. Он нужен для обработки пиков нагрузки, для сбоев отдельных нод, для деплоев без даунтайма, для неожиданных всплесков трафика. Это инженерные требования, а не прихоть.
Вот и думай, кто должен принимать такие решения – мы, которые отвечаем за аптайм, или они, которые над каждой копейкой трясутся?
А вопросы все те же:
Где граница между надежностью и избыточностью?
Как доказать, что оптимизация не убьет производительность?
Кто вообще должен принимать такие решения — инженер или бизнес?
Можно ли управлять этим системно, а не на интуиции?
«Нам нужен прогноз. Не отчёт задним числом»
Руководитель инфраструктуры
Бюджет на следующий год обсуждается жестко. Фраза "возьмем прошлый месяц и умножим" больше не работает. Нужен детальный прогноз с обоснованиями.
Какие вам обоснования, спрашиваю? Инфраструктура масштабируется динамически. Нагрузка зависит от бизнеса, а не от календаря. Сегодня показатели одни, завтра другие, послезавтра – третьи. А запланируем выход на новый рынок – будет вообще раза в 2 больше.
Ну, или не будет, если сделка сорвется.
А мы тут при чем?
Нет, можно взять средний счет за последние три месяца, добавить 20% на рост, заложить резерв. Получится какая-то цифра. Но она о��нована на допущениях, а не на точных данных. Занизишь прогноз — в середине года придется просить дополнительные деньги. Завысишь — будут вопросы, почему запрашиваешь больше, чем тратишь.
А еще облачные провайдеры меняют цены. То скидки дают на Reserved Instances, то убирают старые типы инстансов, то вводят новые тарифы на трафик. В прошлом году цены на некоторые сервисы изменились процентов на 15. Как учитывать это в прогнозе на следующий год?
Только на основании чего, непонятно. И вопросы всегда одни:
Как прогнозировать затраты в динамической инфраструктуре?
Какие допущения вообще допустимы?
Как учитывать рост продукта, а не только инфраструктуры?
Где проходит граница ответственности между ИТ и бизнесом?
Доколе?
Что тут скажешь? Непонятно, можно ли вообще управлять всем этим системно. Или так и придется каждый месяц объяснять рост счетов, искать, где можно срезать, доказывать обоснованность каждого решения?
Что эффективнее — жесткие лимиты с автоблокировкой или выстраивание культуры осознанного потребления? И почему управление инфраструктурными затратами до сих пор выглядит как набор костылей — независимо от типа облака?
У писавших эти строки ответов на поставленные выше вопросы нет. Может, вы что посоветуете?
Следующая статья в цикле будет от противоположной стороны. Обещают даже, что с примерами и цифрами. Ну, посмотрим.
