КОНЦЕПЦИЯ УПРАВЛЕНИЯ ИНФРАСТРУКТУРОЙ

Уровень: У0 (Концепция)
Версия: 1.0.0

ФИЛОСОФИЯ

Инфраструктура существует для одной цели: обеспечить непрерывную работу бизнеса.

Всё остальное — производные этой цели.

ФУНДАМЕНТАЛЬНОЕ ПРОТИВОРЕЧИЕ

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   СКОРОСТЬ  ←─────────────────────────→  НАДЁЖНОСТЬ        │
│                                                             │
│   Быстрый доступ                         Сохранность        │
│   Горячие данные                         Резервирование     │
│   Дорого                                 Дёшево             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Невозможно иметь одновременно максимальную скорость и максимальную надёжность в одном месте за разумные деньги.

Решение: Разделение на два слоя.

ДВА СЛОЯ ХРАНЕНИЯ

Слой исполнения (Сервер)

Назначение: Здесь программы работают прямо сейчас.

Характеристики:
- Скорость критична
- Объём ограничен
- Потеря данных = остановка работы
- Стоимость высокая

Принцип: Минимум данных, максимум кода.

Слой сохранности (Hub)

Назначение: Здесь данные живут вечно.

Характеристики:
- Скорость вторична
- Объём безлимитный
- Потеря данных = потеря истории
- Стоимость низкая

Принцип: Максимум данных, ноль исполнения.

ГЛАВНОЕ ПРАВИЛО

╔═════════════════════════════════════════════════════════════╗
║                                                             ║
║   На сервере только то, что НУЖНО ПРЯМО СЕЙЧАС             ║
║                                                             ║
║   Всё остальное — в хабе                                   ║
║                                                             ║
╚═════════════════════════════════════════════════════════════╝

Тест: Если файл не использовался 7 дней — ему не место на сервере.

ПРИРОДА ДАННЫХ

Данные имеют температуру:

Пример:
- Горячие: работающий код, активная БД
- Тёплые: вчерашние логи, недавние экспорты
- Холодные: прошлогодние отчёты
- Замороженные: архив версий, старые бэкапы

ПРИНЦИП ВОССТАНОВИМОСТИ

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   Сервер можно ПОЛНОСТЬЮ восстановить из Hub               │
│                                                             │
│   Hub НЕЛЬЗЯ восстановить из сервера                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Следствия:
1. Сервер — расходный материал
2. Hub — единственный источник правды для данных
3. Git — единственный источник правды для кода
4. Потеря сервера = часы на восстановление
5. Потеря Hub = катастрофа

ТРИ КАТЕГОРИИ РЕСУРСОВ

1. Код (восстановим из Git)

• Исходники программ
• Конфигурации
• Скрипты

Потеря: Неприятно, но восстановимо.

2. Состояние (восстановимо из бэкапов)

• Базы данных
• Сессии пользователей
• Кеши

Потеря: Откат на последний бэкап.

3. Данные (невосстановимы)

• Загруженные файлы
• Документы пользователей
• История операций

Потеря: Необратима. Защищать максимально.

ПРИНЦИП ЭФЕМЕРНОСТИ

Сервер = временная сущность

Следствия:
- Нельзя хранить на сервере то, что жалко потерять
- Сервер должен быть воспроизводим за 1 час
- Никаких уникальных данных только на сервере

ПРИНЦИП ЕДИНОГО ОКРУЖЕНИЯ

Один сервер = одно окружение = один venv

Почему:
- Меньше конфликтов зависимостей
- Проще обновление
- Экономия места
- Единая точка управления

Исключение: Docker-контейнеры имеют изолированные окружения.

ЖИЗНЕННЫЙ ЦИКЛ ДАННЫХ

СОЗДАНИЕ → ИСПОЛЬЗОВАНИЕ → СТАРЕНИЕ → АРХИВАЦИЯ → УДАЛЕНИЕ
    ↓            ↓             ↓           ↓           ↓
  Сервер      Сервер       Миграция      Hub       Hub/Delete
                            в Hub

Данные движутся в одном направлении: от горячего к холодному.

БЭКАПЫ: ФИЛОСОФИЯ

Зачем бэкапы

Не для "на всякий случай". А для гарантированного восстановления.

Что определяет стратегию

1. RPO (Recovery Point Objective) — сколько данных можно потерять?
   - 1 час? Бэкап каждый час
   - 1 день? Бэкап раз в день

2. RTO (Recovery Time Objective) — как быстро нужно восстановиться?
   - 1 час? Бэкапы под рукой
   - 1 день? Можно в облаке

Правило 3-2-1

• 3 копии данных
• 2 разных типа носителей
• 1 копия offsite (вне сервера)

МОНИТОРИНГ: ФИЛОСОФИЯ

Цель мониторинга

Не "видеть красивые графики". А узнать о проблеме раньше пользователя.

Три уровня

1. Доступность — работает или нет?
2. Производительность — работает быстро или медленно?
3. Ёмкость — когда закончится место/память?

АВТОМАТИЗАЦИЯ: ФИЛОСОФИЯ

Если делаешь что-то второй раз — автоматизируй

Почему:
- Человек забудет
- Человек ошибётся
- Машина не забудет и не ошибётся

Исключение: Разовые операции.

БЕЗОПАСНОСТЬ: ФИЛОСОФИЯ

Принцип минимальных привилегий

Каждый компонент имеет только те права, которые ему необходимы.

Принцип защиты в глубину

Несколько слоёв защиты. Пробив один — встретишь следующий.

Принцип "assume breach"

Предполагай, что тебя уже взломали. Что тогда?

СВЯЗЬ С БИЗНЕСОМ

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   Инфраструктура — это не цель, а средство                 │
│                                                             │
│   Бизнес-ценность > Техническое совершенство               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Вопрос перед любым решением:
"Как это поможет бизнесу зарабатывать деньги?"

ИТОГО: КЛЮЧЕВЫЕ ПРИНЦИПЫ

1. Разделяй горячее и холодное — сервер для работы, hub для хранения
2. Сервер эфемерен — всё восстановимо из hub + git
3. Данные движутся к холоду — от сервера к hub
4. Бэкапы для восстановления — не для галочки
5. Автоматизируй повторяющееся — человек ошибётся
6. Бизнес первичен — техника вторична

СВЯЗАННЫЕ ДОКУМЕНТЫ

Статус: Концепция
Следующий review: При изменении философии