Коротко. Облачный счёт растёт не потому, что облако дорогое, а потому, что в нём ничего не выключается само. Инфраструктура становится строкой операционных расходов, которой управляют инженеры, а объясняет её финансовый директор. Маршрут — про то, как эти двое начинают говорить на одном языке.
Зачем это бизнесу
Переход в облако меняет не только технологию, но и природу расходов: капитальные вложения раз в пять лет превращаются в ежемесячный счёт, который зависит от поведения разработчиков. Компании, которые не перестроили под это управленческий учёт, обнаруживают перерасход через год, когда отменить решения уже дорого.
Ориентир: если вы не можете разложить счёт по продуктам или командам, вы не управляете инфраструктурой — вы её оплачиваете.
Маршрут
| Ступень | Что читаем | Что забираем | Срок |
|---|---|---|---|
| 1. Основание | Книги по администрированию Linux и «Bash и кибербезопасность» | Понимание, из чего состоит сервер и что такое «нагрузка» | 3 недели |
| 2. Упаковка | «Docker. Вводный курс», «Docker без секретов» | Почему «у меня работало» перестало быть аргументом | 2 недели |
| 3. Повторяемость | «Запускаем Ansible» | Инфраструктура как описание, а не как ручная настройка | 3 недели |
| 4. Разбиение на части | «Облачные микросервисы» | Когда дробление помогает, а когда добавляет сетевых отказов | 4 недели |
| 5. Наблюдаемость | «Zabbix 7: мониторинг ИТ-инфраструктуры» | Что мерить, чтобы узнавать о сбое раньше клиента | 2 недели |
| 6. Надёжность как договор | «Настоящий SRE» | Бюджет ошибок, уровни обслуживания, дежурства | 4 недели |
Семь выводов — своими словами
- Основная часть счёта — забытое, а не работающее. Тестовые окружения, диски удалённых машин и логи, которые никто не читает, обычно дают заметную долю расходов.
- Разбиение на микросервисы — это перенос сложности, а не её устранение. Вместо сложного кода получается сложная сеть, и отлаживать её труднее.
- Стопроцентная доступность не цель, а ошибка планирования. Каждая девятка после запятой стоит кратно дороже предыдущей; разумный подход — договориться о допустимом уровне сбоев и тратить остаток на развитие.
- Мониторинг без дежурства бесполезен. Оповещение, которое некому принять в три часа ночи, — это только способ узнать утром.
- Ручная настройка не масштабируется и не восстанавливается. Сервер, собранный руками, невозможно воспроизвести после аварии — именно это, а не удобство, оправдывает автоматизацию.
- Разбор инцидентов без поиска виноватых даёт больше, чем регламенты. Команды, где разбор превращается в наказание, перестают сообщать о сбоях.
- Аренда не отменяет проектирование. Облако снимает вопрос закупки железа и не снимает вопрос, что делать при отказе зоны доступности.
Что это значит в деньгах
| Решение | Что спросить | На что смотреть в счёте |
|---|---|---|
| Переезд в облако | Какие процессы изменятся, а не какие серверы переедут | Соотношение расходов на среды разработки и на продуктив |
| Резервирование | Сколько стоит час простоя этого сервиса | Плата за резервные мощности, которые никогда не включались |
| Хранение | Кто и когда читает эти данные | Объём в горячем хранилище старше года |
| Рост команды | Кто отвечает за счёт по своему сервису | Доля расходов без владельца |
Красные флаги
- Проект переезда описан списком серверов, а не списком сервисов с требованиями к доступности.
- Нет разметки ресурсов по командам и продуктам — значит, счёт нельзя разложить.
- Микросервисы предлагаются как цель, а не как ответ на конкретное ограничение.
- В плане нет проверки восстановления: резервные копии есть, а восстановление из них никто не пробовал.
- Обсуждается доступность в процентах без указания, что считается недоступностью.
Частые вопросы
Связанное
- FinOps — управление расходами на облако
- SLI, SLO и SLA
- Наблюдаемость
- Разбор инцидентов
- Well-Architected
Книги названы как источники. KZSalesHub не распространяет файлы изданий.
Счёт растёт не от объёма, а от невыключенных ресурсов и передачи данных наружу. Разбор счёта по статьям раз в месяц окупается быстрее любой оптимизации архитектуры.
Материал обновлён 30 сентября 2026