---
title: "Облако и его счёт: инфраструктура глазами финансов"
url: "https://kzsaleshub.com/marshrut-oblako-i-schet/"
type: "knowledge_article"
category: "Библиотека"
language: "ru"
source: "KZSalesHub"
published: "2026-08-15"
last_updated: "2026-09-30"
---

# Облако и его счёт: инфраструктура глазами финансов

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

## Зачем это бизнесу

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

Ориентир: если вы не можете разложить счёт по продуктам или командам, вы не управляете инфраструктурой — вы её оплачиваете.

## Маршрут

| Ступень | Что читаем | Что забираем | Срок |
| --- | --- | --- | --- |
| 1. Основание | Книги по администрированию Linux и «Bash и кибербезопасность» | Понимание, из чего состоит сервер и что такое «нагрузка» | 3 недели |
| 2. Упаковка | «Docker. Вводный курс», «Docker без секретов» | Почему «у меня работало» перестало быть аргументом | 2 недели |
| 3. Повторяемость | «Запускаем Ansible» | Инфраструктура как описание, а не как ручная настройка | 3 недели |
| 4. Разбиение на части | «Облачные микросервисы» | Когда дробление помогает, а когда добавляет сетевых отказов | 4 недели |
| 5. Наблюдаемость | «Zabbix 7: мониторинг ИТ-инфраструктуры» | Что мерить, чтобы узнавать о сбое раньше клиента | 2 недели |
| 6. Надёжность как договор | «Настоящий SRE» | Бюджет ошибок, уровни обслуживания, дежурства | 4 недели |

## Семь выводов — своими словами

1. **Основная часть счёта — забытое, а не работающее.** Тестовые окружения, диски удалённых машин и логи, которые никто не читает, обычно дают заметную долю расходов.
2. **Разбиение на микросервисы — это перенос сложности, а не её устранение.** Вместо сложного кода получается сложная сеть, и отлаживать её труднее.
3. **Стопроцентная доступность не цель, а ошибка планирования.** Каждая девятка после запятой стоит кратно дороже предыдущей; разумный подход — договориться о допустимом уровне сбоев и тратить остаток на развитие.
4. **Мониторинг без дежурства бесполезен.** Оповещение, которое некому принять в три часа ночи, — это только способ узнать утром.
5. **Ручная настройка не масштабируется и не восстанавливается.** Сервер, собранный руками, невозможно воспроизвести после аварии — именно это, а не удобство, оправдывает автоматизацию.
6. **Разбор инцидентов без поиска виноватых даёт больше, чем регламенты.** Команды, где разбор превращается в наказание, перестают сообщать о сбоях.
7. **Аренда не отменяет проектирование.** Облако снимает вопрос закупки железа и не снимает вопрос, что делать при отказе зоны доступности.

## Что это значит в деньгах

| Решение | Что спросить | На что смотреть в счёте |
| --- | --- | --- |
| Переезд в облако | Какие процессы изменятся, а не какие серверы переедут | Соотношение расходов на среды разработки и на продуктив |
| Резервирование | Сколько стоит час простоя этого сервиса | Плата за резервные мощности, которые никогда не включались |
| Хранение | Кто и когда читает эти данные | Объём в горячем хранилище старше года |
| Рост команды | Кто отвечает за счёт по своему сервису | Доля расходов без владельца |

## Красные флаги

- Проект переезда описан списком серверов, а не списком сервисов с требованиями к доступности.
- Нет разметки ресурсов по командам и продуктам — значит, счёт нельзя разложить.
- Микросервисы предлагаются как цель, а не как ответ на конкретное ограничение.
- В плане нет проверки восстановления: резервные копии есть, а восстановление из них никто не пробовал.
- Обсуждается доступность в процентах без указания, что считается недоступностью.

## Частые вопросы

**Облако дешевле своего оборудования**

Не само по себе. Оно дешевле при неравномерной нагрузке и дороже при ровной и предсказуемой. Считать нужно на горизонте трёх лет и вместе с людьми.

**С чего начать сокращение счёта**

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

**Нужен ли отдельный человек под инфраструктуру**

Начиная примерно с десяти инженеров — да. До этого роль совмещается, но ответственность всё равно должна быть названа.

## Связанное

- [FinOps](https://kzsaleshub.com/framework/finops/) — управление расходами на облако
- [SLI, SLO и SLA](https://kzsaleshub.com/framework/sli-slo-sla/)
- [Наблюдаемость](https://kzsaleshub.com/framework/observability-three-pillars/)
- [Разбор инцидентов](https://kzsaleshub.com/framework/incident-postmortem/)
- [Well-Architected](https://kzsaleshub.com/framework/well-architected/)

*Книги названы как источники. KZSalesHub не распространяет файлы изданий.*

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

---
Источник: https://kzsaleshub.com/marshrut-oblako-i-schet/