# Жизненный цикл облачного приложения

← [Раздел](README.md) · [Главная](../README.md)

## Цель

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

## Предварительно

- [Модели облака](modeli-oblaka.md)

## Время

**3–4 часа**

---

## Этапы жизненного цикла (SDLC в облаке)

| Фаза | Вопрос | Артефакты |
|------|--------|-----------|
| 1. Идея и ценность | Зачем продукт? | One-pager, гипотезы |
| 2. Требования | Что должно делать? | User stories, NFR |
| 3. Проектирование | Из чего состоит? | C4, ADR, API-контракты |
| 4. Реализация | Как закодировать? | Репозиторий, тесты |
| 5. Сборка и CI | Как проверить автоматически? | Pipeline, артефакты |
| 6. Развёртывание | Как доставить в облако? | Образы, манифесты, IaC |
| 7. Эксплуатация | Как держать живым? | Мониторинг, алерты, runbooks |
| 8. Эволюция | Как менять без боли? | Миграции, feature flags |
| 9. Вывод (EOL) | Как безопасно закрыть? | Миграция данных, архив |

В облаке фазы 5–7 **тесно связаны**: без CI/CD и observability «эксплуатация» превращается в ручной хаос.

```mermaid
flowchart LR
  Idea[Идея] --> Req[Требования]
  Req --> Design[Проектирование]
  Design --> Dev[Разработка]
  Dev --> CI[CI/CD]
  CI --> Deploy[Деплой]
  Deploy --> Ops[Эксплуатация]
  Ops --> Evolve[Изменения]
  Evolve --> Dev
  Ops --> EOL[Вывод]
```

---

## Фаза 1–3: до первой строки кода

**Идея «Умного списка»:** семьи забывают покупки; общий список в реальном времени решает боль.

**Требования (фрагмент):**

| ID | Требование |
|----|------------|
| FR-1 | Пользователь создаёт список |
| FR-2 | Делится списком по ссылке |
| NFR-1 | Отклик API < 300 ms (p95) |
| NFR-2 | Доступность 99.5% в месяц |

**Проектирование:** Context-диаграмма — пользователь, приложение, email SaaS для приглашений. Подробнее в [разделе 03](../03-proektirovanie/README.md).

Ошибка новичка: пропустить NFR и «добавить масштаб потом».

---

## Фаза 4–5: разработка и CI

Разработчики ведут код в **git**. Каждый merge request проходит:

1. Линтер / форматтер  
2. Unit-тесты  
3. Сборка артефакта (бинарник или Docker-образ)

**CI (Continuous Integration)** — автоматическая проверка при каждом push. Без CI облачный деплой **опасен**: неизвестно, собирается ли проект вообще.

| Окружение | Назначение |
|-----------|------------|
| local | Разработка на ноутбуке |
| dev | Общая песочница команды |
| staging | Копия прода для приёмки |
| production | Реальные пользователи |

---

## Фаза 6: развёртывание

**Деплой** — выкладка новой версии в окружение. В облаке типично:

1. Собрали образ `app:1.2.3`  
2. Обновили конфиг (реплики, env)  
3. Платформа **постепенно** заменяет старые инстансы (rolling update)

Откат: вернуть образ `app:1.2.2` и те же миграции БД (если обратимы).

Тема [10 — Деплой](../10-deploy/README.md).

---

## Фаза 7: эксплуатация

После запуска начинается **эксплуатация (operations)**:

| Активность | Зачем |
|------------|-------|
| Мониторинг метрик | CPU, ошибки 5xx, latency |
| Логи | Разбор инцидентов |
| Алерты | Разбудить дежурного при SLA breach |
| Патчи безопасности | CVE в зависимостях |
| Бэкапы БД | Восстановление после сбоя |
| Дежурства (on-call) | Реакция на падение |

```mermaid
flowchart TB
  User[Пользователь] --> App[Приложение]
  App --> Metrics[Метрики]
  App --> Logs[Логи]
  Metrics --> Alert[Алерт]
  Alert --> Oncall[Дежурный]
  Oncall --> Runbook[Runbook]
  Runbook --> Fix[Исправление / откат]
```

---

## Инцидент: учебный сценарий

**02:00:** алерт «ошибки 500 на POST /lists/items».  
**02:05:** дежурный смотрит логи — `connection refused` к БД.  
**02:10:** проверка: managed PostgreSQL в maintenance (плановое окно забыли в календаре).  
**02:15:** статус-страница, ожидание; после окна — восстановление.

**Урок:** эксплуатация — не только «чинить баги», но и **календарь**, **коммуникация**, **SLA**.

---

## Фаза 8: эволюция без остановки

| Техника | Применение |
|---------|------------|
| Миграции схемы БД | Версионированные SQL / ORM migrations |
| Feature flags | Новая функция для 5% пользователей |
| Версионирование API | `/v1/` и `/v2/` параллельно |
| ADR | Зафиксировать «почему перешли на очередь» |

Связь с [ADR](../03-proektirovanie/adr-resheniya.md) и [контрактами API](../04-vzaimodeistvie/kontrakty-api.md).

---

## Фаза 9: вывод из эксплуатации (EOL)

Когда продукт закрывают:

1. Уведомить пользователей за N дней  
2. Экспорт данных (GDPR и др.)  
3. Остановить запись, read-only период  
4. Архив бэкапов по политике  
5. Удалить ресурсы в облаке (чтобы не платить)

Забытый bucket S3 или ВМ — **типичная утечка денег и данных**.

---

## Роли в жизненном цикле

| Роль | Фазы |
|------|------|
| Product / аналитик | 1–2 |
| Архитектор | 2–3, 8 |
| Разработчик | 3–5 |
| DevOps / SRE | 5–7 |
| QA | 4–6 |
| Security | 3, 5, 7 |

Один человек в стартапе может совмещать всё — но **фазы всё равно существуют**.

---

## Практика

1. Для bugfix в проде выпишите 8 шагов от тикета до закрытия.  
2. Отметьте, где нужен откат деплоя, а где — hotfix в git.  
3. Добавьте в календарь «плановое окно БД» для учебного кейса.

---

## Самопроверка

1. Чем staging отличается от production?  
2. Зачем CI, если вы деплоите «раз в месяц вручную»?  
3. Что такое runbook одним предложением?

---

## Дальше

→ [02 — Компоненты](../02-komponenty/README.md)