Управление затратами на облако

Что это такое

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

Почему это важно

Счёт — единственная обратная связь, которую облако даёт вам каждый месяц, и он отчитывается о каждом решении, принятом с прошлого раза. Команды, которые его не читают, накапливают простаивающие ресурсы, раздутые машины и забытое хранилище, пока число не становится проблемой уровня совета директоров, а ответом — поспешная и вредная волна сокращений. Команды, которые его читают, обычно обнаруживают, что несколько повторяющихся образцов — неприкреплённые диски, нетестовые окружения, работающие всю ночь, данные, пересекающие регионы без причины, — дают большую часть потерь. Это не бухгалтерское упражнение; это обзор дизайна с прикреплённым числом.

Ключевые идеи

Подбор размера начинается с измеренного использования

Инстанс оценивается по своему размеру, а не по нагрузке. Почти в любом парке есть машины, наблюдаемые процессор и память которых составляют долю от выделенного, и изменить их размер — самое дешёвое сбережение, потому что оно не требует ни обязательств, ни смены архитектуры. Метод скучен и эффективен: измерьте пиковое использование за представительный период, выберите следующий размер вниз, который всё ещё проходит его с запасом, и повторяйте. То же относится к томам хранилища, которые выделили большими и никогда не уменьшали.

выделено: 8 vCPU, 32 GB
наблюдаемый пик: 1.4 vCPU, 6 GB
действие: уменьшить размер, оставить запас на всплеск, измерить заново в следующем месяце

Обязательства меняют гибкость на цену

Провайдер даст скидку на нагрузку, чья форма предсказуема заранее: обязательство на год или три для вычислений либо заявленный уровень расходов. Экономия большая, и риск настоящий, потому что обязательство оплачивается независимо от того, нужна ли нагрузке эта мощность. Используйте обязательства для стабильного пола использования — той части, что работала бы даже в тихий день, — а всё, что выше, оставляйте на оплату по факту.

Нетестовые окружения — обычный виновник

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

Бюджеты и оповещения превращают счёт в сигнал

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

Теги — то, что делает число делимым

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

Потери часто пахнут дизайном

Простаивающая реплика базы данных, очередь без потребителя, сервис, который никто не вызывает: каждая — это строка затрат и одновременно неотвеченный вопрос дизайна. Находить их через счёт эффективно, потому что счёту нет дела до намерений. Их удаление — небольшая архитектурная уборка, которая попутно окупает себя.

Практика

Найдите крупнейшую потерю в одном аккаунте

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

Готово, когда: вы можете назвать одно конкретное изменение на строку и его примерную месячную экономию.

Поставьте нетестовое окружение на расписание

Выберите среду разработки и определите её рабочие часы. Опишите, как она будет останавливаться и запускаться автоматически и кто заметит, если запуск не удастся.

Готово, когда: расписание называет часы, владельца и запасной план, и вы можете оценить долю месяца, которую оно экономит.

Частые ошибки

Подбирать размер на глаз и никогда не пересматривать — выделенная мощность уходит далеко выше использования; исправить: измеряйте пиковое использование по расписанию и меняйте размер.
Покупать обязательства на весь парк — нагрузка меняется, а обязательство нет; исправить: покрывайте обязательством только стабильный пол, а выше платите по факту.
Оставлять нетестовое окружение работать непрерывно — оно стоит почти как продакшен, а ночью не даёт ничего; исправить: поставьте его на расписание рабочих часов.
Задавать один бюджет на весь аккаунт — ни одна команда не видит и не может действовать по своей доле; исправить: бюджет и оповещения на окружение или команду.
Создавать ресурсы без тегов владельца — затраты нельзя приписать, а потери нельзя назначить; исправить: требуйте минимальный набор тегов при создании.

Что читать дальше

AWS (06-cloud-devops/02-aws) — аккаунт и сервисы, чьё использование записывает этот счёт, поэтому читайте первым.
Идентичность и затраты (06-cloud-devops/02-aws/04-identity-and-cost) — права, решающие, кто может создавать затраты, и теги, которые их приписывают.
Terraform (06-cloud-devops/07-terraform) — описание инфраструктуры кодом, при котором потерянный ресурс виден в диффе, а не только в счёте.