Развертывание и масштабирование

Введение

Развёртывание — это процесс доставки новой версии программного компонента в целевую среду и её безопасного ввода в эксплуатацию.

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

В монолитной системе развёртывание часто выглядит относительно просто:

Собрать приложение
→ остановить старую версию
→ установить новую
→ запустить

В микросервисной архитектуре одновременно могут существовать:

десятки или сотни сервисов;
несколько экземпляров каждого сервиса;
разные версии;
отдельные базы данных;
очереди;
фоновые обработчики;
API Gateway;
Service Discovery;
edge-компоненты;
несколько регионов.

Поэтому развёртывание становится самостоятельной архитектурной задачей.

Необходимо обеспечить:

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

Масштабирование также нельзя сводить только к добавлению серверов.

Необходимо определить:

какой компонент является узким местом;
можно ли запускать несколько экземпляров;
где хранится состояние;
как распределяется нагрузка;
выдерживает ли база данных рост трафика;
сохраняются ли порядок и идемпотентность;
сколько ресурсов экономически оправдано.

Главный принцип:

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

1. Среды выполнения

Типичная система использует несколько сред:

Local
Development
Testing
Staging
Production

Local

Среда разработчика.

Используется для:

написания кода;
unit-тестов;
локальной отладки;
проверки интеграций через эмуляторы.

Development

Общая среда активной разработки.

Testing

Среда автоматических и ручных проверок.

Staging

Максимально приближена к Production.

Используется для:

smoke tests;
проверки миграций;
нагрузочных испытаний;
проверки конфигурации.

Production

Реальная рабочая среда.

Среды не должны различаться настолько сильно, чтобы тестирование переставало отражать производственное поведение.

2. Environment Parity

Environment Parity означает максимальное сходство сред по:

версии runtime;
образам;
конфигурационной структуре;
сети;
базе;
брокеру;
механизму аутентификации;
способу развёртывания.

Полная идентичность часто слишком дорога.

Но критические различия должны быть известны и документированы.

Плохо:

Development:
локальный файл и SQLite.

Production:
распределённая PostgreSQL, Redis и брокер.

Такая среда может не выявить:

сетевые ошибки;
конкуренцию;
транзакционные различия;
несовместимость SQL;
проблемы миграции.

3. Артефакт развёртывания

Артефакт — неизменяемый результат сборки, который доставляется в среды.

Примеры:

исполняемый файл;
архив;
пакет;
контейнерный образ;
serverless package;
Helm chart вместе с версией образа.

Хорошая практика:

Один раз собрать
→ один и тот же артефакт продвигать по средам.

Плохо пересобирать приложение отдельно для Production, потому что проверенная и рабочая версии могут различаться.

4. Immutable Artifact

Артефакт после сборки не должен изменяться.

Он получает:

уникальную версию;
checksum;
commit hash;
metadata;
подпись.

Конфигурация среды передаётся отдельно.

Это позволяет точно ответить:

какая версия работает;
из какого commit она создана;
какой pipeline её собрал;
какие проверки она прошла.

5. Конфигурация и код

Код приложения не должен содержать production-настройки.

Разделяются:

Код

Одинаковый для сред.

Конфигурация

Зависит от окружения:

адреса;
лимиты;
feature flags;
параметры подключения;
размеры пулов.

Секреты

пароли;
токены;
ключи;
сертификаты.

Секреты не должны храниться в обычных конфигурационных файлах или исходном коде.

6. Configuration as Code

Конфигурация развёртывания должна быть:

версионируемой;
проходить review;
проверяться автоматически;
воспроизводиться;
иметь историю.

К ней относятся:

deployment manifests;
маршруты;
policies;
autoscaling;
network rules;
dashboards;
alerts.

7. Infrastructure as Code

Infrastructure as Code описывает инфраструктуру декларативно или программно.

Можно управлять:

сетями;
виртуальными машинами;
кластерами;
базами;
очередями;
хранилищами;
ролями;
секретами;
DNS.

Преимущества:

повторяемость;
review;
автоматическое создание среды;
уменьшение ручных ошибок;
обнаружение drift.

8. Configuration Drift

Configuration Drift возникает, когда реальная инфраструктура отличается от описанной.

Причины:

ручные production-изменения;
неполные scripts;
аварийные исправления;
разные процедуры для сред.

Последствия:

непредсказуемое поведение;
невозможность воспроизведения;
сложное восстановление.

Ручное изменение должно либо запрещаться, либо сразу переноситься в код конфигурации.

9. Контейнеризация

Контейнер упаковывает:

приложение;
runtime;
системные зависимости;
необходимые файлы;
конфигурационную структуру.

Контейнер обеспечивает единообразный запуск в разных средах.

Схема:

Container Image
├── Application
├── Runtime
└── Libraries

Контейнер не является отдельной виртуальной машиной.

Он разделяет ядро операционной системы хоста.

10. Преимущества контейнеров

воспроизводимое окружение;
быстрый запуск;
стандартный формат поставки;
удобное масштабирование;
изоляция процессов;
простое версионирование;
совместимость с оркестраторами.

Но контейнеризация не исправляет:

неправильные границы сервисов;
плохие контракты;
ошибки согласованности;
отсутствие наблюдаемости;
небезопасный код.

11. Контейнерный образ

Образ строится слоями.

Хороший образ должен быть:

минимальным;
неизменяемым;
не запускаться от root без необходимости;
не содержать секретов;
содержать только нужные файлы;
иметь известную базовую версию;
проходить vulnerability scan.

12. Multi-Stage Build

Multi-stage build позволяет разделить:

Build Environment
→ Runtime Image

В итоговый образ не попадают:

компилятор;
исходники;
build cache;
тестовые инструменты.

Это уменьшает:

размер;
поверхность атаки;
время загрузки.

13. Image Tagging

Плохой вариант:

service:latest

Непонятно, какая версия развёрнута.

Лучше:

service:2.4.1
service:commit-a82f17

Tag может быть удобным именем, но для полной неизменяемости используют digest.

14. Registry образов

Container Registry хранит образы.

Необходимо:

разграничение доступа;
retention;
scanning;
подпись;
репликация;
журнал загрузок;
запрет подмены release-образов.

15. Software Supply Chain

Цепочка поставки включает:

Исходный код
→ зависимости
→ build system
→ артефакт
→ registry
→ deployment

Риски:

вредоносная зависимость;
подмена образа;
компрометация pipeline;
утечка ключа подписи;
небезопасный base image.

Необходимы:

dependency scanning;
SBOM;
signing;
provenance;
минимальные права pipeline.

16. SBOM

Software Bill of Materials — перечень компонентов артефакта:

библиотеки;
версии;
лицензии;
transitive dependencies.

SBOM помогает:

находить уязвимые компоненты;
выполнять аудит;
оценивать лицензии;
реагировать на инциденты.

17. Оркестрация

При большом количестве контейнеров требуется оркестратор.

Он управляет:

размещением;
перезапуском;
масштабированием;
Service Discovery;
health checks;
rolling update;
конфигурацией;
секретами;
ресурсами.

Оркестратор не понимает бизнес-правила сервиса автоматически.

Он управляет жизненным циклом процессов.

18. Kubernetes как пример оркестратора

Kubernetes использует декларативную модель желаемого состояния.

Например:

Желаемое состояние:
3 экземпляра Order Service.

Control Plane постоянно сравнивает:

Желаемое состояние
с
Фактическим состоянием.

Если экземпляр завершился, платформа создаёт новый.

19. Pod

Pod — минимальная развёртываемая единица Kubernetes.

Он может содержать:

основной контейнер;
sidecar;
init container.

Контейнеры одного Pod:

размещаются вместе;
разделяют сеть;
могут разделять volumes;
имеют общий жизненный цикл.

Обычно один Pod содержит один основной сервисный процесс.

20. Deployment

Deployment управляет stateless-приложениями.

Он определяет:

образ;
число replicas;
стратегию обновления;
resource requests;
resource limits;
health probes;
environment;
volumes.

Deployment создаёт и обновляет ReplicaSet.

21. StatefulSet

StatefulSet используется для stateful workloads.

Предоставляет:

стабильные имена;
определённый порядок;
отдельные volumes;
предсказуемую идентичность экземпляров.

Примеры:

некоторые базы;
брокеры;
stateful-кластеры.

Но managed database часто предпочтительнее самостоятельного запуска критической СУБД в оркестраторе.

22. DaemonSet

DaemonSet запускает экземпляр на каждом подходящем узле.

Применяется для:

log collectors;
monitoring agents;
network components;
storage agents;
edge adapters, привязанных к узлам.

23. Job

Job выполняет конечную задачу:

миграцию;
импорт;
batch calculation;
backfill;
одноразовую обработку.

Он считается завершённым после успешного выполнения.

24. CronJob

CronJob запускает Job по расписанию.

Примеры:

ежедневный отчёт;
очистка временных файлов;
reconciliation;
архивирование.

Нужно учитывать:

повторный запуск;
пропущенное время;
параллельные экземпляры;
идемпотентность;
часовой пояс.

25. Resource Requests

Request — ресурс, необходимый для планирования.

Например:

CPU request: 500m
Memory request: 512 MiB

Scheduler использует requests для выбора узла.

Слишком маленькие requests приводят к:

перегрузке узлов;
непредсказуемой производительности.

Слишком большие — к:

низкой утилизации;
невозможности размещения;
лишней стоимости.

26. Resource Limits

Limit ограничивает максимальный ресурс.

CPU limit может привести к throttling.

Превышение memory limit обычно приводит к завершению процесса по OOM.

Необходимо различать:

временный рост CPU;
утечку памяти;
нормальный рабочий набор;
пиковый payload.

27. OOMKilled

Если контейнер превышает memory limit, он может быть завершён.

Простой restart не устраняет причину.

Необходимо анализировать:

heap;
большие объекты;
buffer;
кэш;
параллелизм;
размер запроса;
утечку.

28. CPU Throttling

При достижении CPU limit процесс получает меньше процессорного времени.

Сервис может:

не падать;
но резко увеличить latency;
начать получать timeout;
вызвать retry storm.

Поэтому необходимо наблюдать не только ошибки, но и throttling.

29. Liveness Probe

Liveness отвечает:

Нужно ли перезапустить контейнер?

Она должна обнаруживать:

deadlock;
необратимое зависание;
неработоспособность процесса.

Не следует включать в liveness проверку всех внешних зависимостей.

Иначе временный отказ базы вызовет бесконечные перезапуски всех сервисов.

30. Readiness Probe

Readiness отвечает:

Можно ли направлять сюда новый трафик?

Сервис может быть alive, но not ready, если:

не завершена инициализация;
нет критического подключения;
выполняется draining;
экземпляр перегружен.

При not ready Pod остаётся запущенным, но исключается из маршрутизации.

31. Startup Probe

Startup Probe полезна для приложений с долгим запуском:

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

До её успеха liveness не должна преждевременно перезапускать процесс.

32. Graceful Shutdown

При завершении сервис должен:

Стать not ready.
Прекратить принимать новые запросы.
Завершить текущие операции.
Прекратить получение новых сообщений.
Подтвердить уже обработанные.
Закрыть соединения.
Сохранить нужное состояние.
Завершиться.

Принудительное завершение без draining может приводить к:

оборванным запросам;
повторным сообщениям;
частичным операциям.

33. Termination Grace Period

Оркестратор предоставляет время на graceful shutdown.

Если сервис не завершился, процесс будет остановлен принудительно.

Время должно учитывать:

максимальную длительность запроса;
batch processing;
завершение транзакции;
остановку consumer.

Но не должно быть бесконечно большим.

34. Rolling Update

Rolling Update постепенно заменяет старые экземпляры новыми.

v1 v1 v1
→
v1 v1 v2
→
v1 v2 v2
→
v2 v2 v2

Преимущества:

не требуется двойная полная среда;
ограниченный простой;
стандартная стратегия оркестраторов.

Требования:

совместимость версий;
readiness;
достаточное число экземпляров;
совместимая схема базы.

35. Max Surge и Max Unavailable

При rolling update определяются:

Max Surge

Сколько дополнительных экземпляров можно временно создать.

Max Unavailable

Сколько экземпляров может быть недоступно.

Например:

replicas = 10
maxSurge = 2
maxUnavailable = 1

Это влияет на:

скорость rollout;
стоимость;
доступность;
нагрузку на кластер.

36. Риск Rolling Update

Одновременно работают две версии.

Если новый Provider несовместим со старым Consumer или наоборот, система ломается в процессе обновления.

Необходимо соблюдать:

backward compatibility;
forward tolerance;
additive database migrations;
совместимые события.

37. Recreate Strategy

Все старые экземпляры останавливаются, затем запускаются новые.

Преимущества:

версии не работают одновременно;
проще для несовместимых локальных ресурсов.

Недостаток:

простой.

Подходит для:

некритичных внутренних инструментов;
single-instance stateful process;
систем с допустимым maintenance window.

38. Blue-Green Deployment

Существуют две полноценные среды:

Blue — текущая версия.
Green — новая версия.

Процесс:

Развернуть Green.
Выполнить проверки.
Переключить трафик.
Наблюдать.
Сохранить Blue для отката.
Позднее удалить старую среду.

39. Преимущества Blue-Green

быстрый переключатель;
простой rollback трафика;
полная проверка среды;
версии не обязательно смешиваются в обработке запросов.

Недостатки:

двойные ресурсы;
сложность stateful-компонентов;
миграции базы;
фоновые consumers могут работать одновременно.

40. Blue-Green и база данных

Даже если приложение легко переключить, обе версии часто используют одну базу.

Несовместимая миграция делает rollback невозможным.

Нужна схема:

Expand
→ deploy Green
→ migrate usage
→ observe
→ Contract later

41. Canary Deployment

Новая версия получает небольшую часть трафика:

99% → v1
1% → v2

Доля постепенно увеличивается:

5%
25%
50%
100%

На каждом этапе сравниваются:

error rate;
latency;
saturation;
бизнес-метрики;
данные;
жалобы пользователей.

42. Критерии Canary

Трафик можно выделять по:

проценту;
пользователям;
tenant;
региону;
feature flag;
типу запроса;
внутренним сотрудникам.

Canary должен иметь автоматические критерии остановки.

43. Automated Rollback Canary

Пример условия:

Если error rate новой версии
превышает базовую более чем на допустимый порог,
остановить rollout.

Дополнительно:

latency p95;
CPU;
payment success rate;
conversion;
очередь ошибок.

Технические метрики должны дополняться бизнес-метриками.

44. Shadow Deployment

Копия production-трафика направляется новой версии.

Её ответ не используется.

Преимущества:

проверка на реальных запросах;
сравнение результатов;
отсутствие влияния на клиента.

Риски:

двойная нагрузка;
утечка чувствительных данных;
побочные эффекты;
стоимость.

Shadow-версия должна быть безопасной и не выполнять реальные необратимые команды.

45. A/B Deployment

A/B используется для продуктового эксперимента.

Разные группы пользователей получают разные функции.

Это не то же самое, что Canary.

Canary проверяет техническую безопасность релиза.

A/B проверяет продуктовую гипотезу.

46. Feature Flags

Функция отделяется от deployment.

Код может быть развёрнут, но не активирован.

Преимущества:

постепенный запуск;
быстрое отключение;
тестирование по группам;
разделение release и deploy.

Риски:

ветвление;
сложность комбинаций;
мёртвые флаги;
разные состояния системы.

Каждый временный flag должен иметь владельца и дату удаления.

47. Dark Launch

Новая функция развёрнута, но скрыта от пользователей.

Можно:

прогреть кэш;
построить проекцию;
проверить производительность;
подготовить данные.

Это уменьшает риск момента включения.

48. Progressive Delivery

Progressive Delivery объединяет:

Canary;
feature flags;
automated verification;
постепенное увеличение трафика;
автоматический rollback.

Цель — уменьшить blast radius новой версии.

49. Blast Radius

Blast Radius — масштаб влияния ошибки.

Он уменьшается через:

canary;
небольшой batch deployment;
tenant-based rollout;
региональный rollout;
feature flag;
изоляцию сервисов.

Не следует сразу направлять 100% критического трафика на непроверенную версию.

50. Smoke Tests

После развёртывания выполняются минимальные проверки:

сервис отвечает;
критический endpoint работает;
база доступна;
публикация сообщения работает;
версия правильная.

Smoke test не заменяет полный набор тестов.

51. Post-Deployment Verification

После релиза проверяются:

health;
error rate;
latency;
logs;
traces;
бизнес-операции;
миграции;
backlog;
внешние интеграции.

Успешный статус pipeline не гарантирует корректность production.

52. Rollback

Rollback возвращает предыдущую версию приложения.

Он должен быть:

автоматизирован;
быстрым;
проверенным;
не требовать ручного поиска артефакта.

Но откат приложения может быть невозможен после несовместимого изменения данных.

53. Roll Forward

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

Причины:

данные уже преобразованы;
новая версия записала новый формат;
внешний контракт уже используется;
old version несовместима.

Стратегия выбирается заранее.

54. Миграции базы данных

Миграция схемы должна учитывать независимые и постепенные релизы.

Плохой процесс:

Удалить старую колонку
→ развернуть новую версию.

Если старая версия ещё работает, она сломается.

Безопасный процесс:

1. Добавить новую колонку.
2. Развернуть код, умеющий работать с обеими.
3. Выполнить backfill.
4. Переключить чтение и запись.
5. Убедиться, что старое поле не используется.
6. Удалить позднее.

55. Expand–Migrate–Contract

Expand

Добавить новую совместимую структуру.

Migrate

Перевести данные и версии приложения.

Contract

Удалить старую структуру после завершения перехода.

Эта стратегия особенно важна при rolling и canary deployment.

56. Миграция как отдельный Job

Миграции можно выполнять отдельным контролируемым процессом.

Преимущества:

один владелец выполнения;
отдельные логи;
явный статус;
предотвращение параллельного запуска;
независимые retries.

Не следует разрешать всем replicas одновременно выполнять тяжёлую migration при старте.

57. Backfill

Backfill заполняет новые данные для старых записей.

Требования:

batch;
ограничение нагрузки;
progress;
retry;
resumability;
idempotency;
reconciliation.

Большой backfill может выполняться часами или днями и должен работать рядом с production-трафиком безопасно.

58. Миграция событий

Новая версия может публиковать новый формат события.

Нужно учитывать старых Consumers.

Стратегии:

совместимое расширение;
новая версия события;
dual publishing;
upcaster;
переходный topic.

Нельзя предполагать, что все Consumers обновятся одновременно.

59. Независимый pipeline сервиса

Типичный pipeline:

Checkout
→ Restore Dependencies
→ Build
→ Unit Tests
→ Static Analysis
→ Security Scan
→ Package
→ Publish Artifact
→ Deploy
→ Smoke Tests
→ Progressive Verification

Для независимого сервиса pipeline не должен всегда ждать release всей платформы.

60. Continuous Integration

CI означает частое объединение изменений в основную ветку с автоматической проверкой.

Преимущества:

ранние конфликты;
быстрый feedback;
короткие ветки;
меньше интеграционный риск.

61. Continuous Delivery

Каждое успешное изменение потенциально готово к Production.

Production-deploy может требовать ручного одобрения.

62. Continuous Deployment

Каждая версия, прошедшая проверки, автоматически попадает в Production.

Подходит только при:

сильной автоматизации;
хорошем тестировании;
наблюдаемости;
быстром rollback;
небольших изменениях.

63. Trunk-Based Development

Разработчики работают с короткоживущими ветками или основной веткой.

Большие незавершённые функции скрываются feature flags.

Это снижает:

сложные merge;
долгую интеграцию;
расхождение версий.

64. GitOps

Желаемое состояние среды хранится в Git.

Специальный controller:

наблюдает repository;
сравнивает состояние;
применяет изменения;
восстанавливает drift.

Преимущества:

audit;
review;
rollback;
декларативность.

Секреты требуют отдельной безопасной обработки.

65. Deployment Approval

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

ручное одобрение;
change window;
four-eyes principle;
проверка compliance.

Это не отменяет автоматизацию самого выполнения.

Ручным должно быть решение, а не копирование файлов и ввод команд.

66. Масштабирование

Масштабирование может быть:

вертикальным;
горизонтальным;
функциональным;
географическим;
масштабированием данных.

Нельзя решать все проблемы добавлением replicas.

67. Вертикальное масштабирование

Увеличиваются ресурсы экземпляра:

CPU;
RAM;
диск;
network bandwidth.

Преимущества:

простота;
не требуется распределённость;
удобно для базы и stateful workload.

Ограничения:

физический предел;
крупный blast radius;
стоимость растёт нелинейно;
обновление может требовать restart.

68. Горизонтальное масштабирование

Добавляются экземпляры:

Service 1
Service 2
Service 3

Требования:

stateless или внешнее состояние;
load balancing;
идемпотентность;
корректная конкуренция;
общее хранилище;
distributed coordination при необходимости.

69. Stateless-сервисы

Stateless-сервис не хранит критическое состояние пользовательской операции в памяти конкретного экземпляра между запросами.

Это упрощает:

масштабирование;
failover;
restart;
rolling update;
балансировку.

Состояние хранится во внешнем durable storage или передаётся в запросе.

70. Локальный кэш и Stateless

Наличие локального кэша не обязательно делает сервис stateful в бизнес-смысле.

Если кэш можно потерять и восстановить, экземпляр остаётся заменяемым.

Необходимо, чтобы потеря кэша влияла только на производительность, а не на корректность.

71. Stateful-сервисы

Stateful workload хранит уникальное состояние, связанное с конкретным экземпляром.

Примеры:

database shard;
stream partition processor;
actor;
локальный промышленный gateway;
in-memory session engine.

Масштабирование требует:

partitioning;
replication;
leader election;
checkpoint;
state transfer.

72. Session Affinity

Sticky session направляет пользователя в один экземпляр.

Преимущества:

позволяет временно хранить session локально.

Недостатки:

неравномерная нагрузка;
сложный failover;
потеря session при завершении;
ограничение масштабирования.

Предпочтительно выносить session во внешнее хранилище или токен, если это оправдано.

73. Load Balancing

Load Balancer распределяет запросы.

Алгоритмы:

round robin;
least connections;
weighted;
random;
latency-based;
consistent hashing.

Выбор зависит от:

длительности запросов;
размера экземпляров;
state affinity;
географии;
нагрузки.

74. Autoscaling

Autoscaling автоматически меняет количество экземпляров.

Источники сигналов:

CPU;
memory;
request rate;
queue depth;
consumer lag;
latency;
custom business metric;
расписание.

CPU не всегда является правильной метрикой.

75. Horizontal Pod Autoscaler

HPA изменяет число Pod на основании метрик.

Пример:

Целевая CPU:
60%.

Минимум:
3 replicas.

Максимум:
20 replicas.

Но HPA реагирует с задержкой.

Сервис должен выдерживать нагрузку до добавления новых экземпляров.

76. Autoscaling по CPU

Подходит для CPU-bound нагрузок:

вычисления;
кодирование;
анализ;
преобразование.

Плохо отражает:

ожидание сети;
очередь;
блокировки базы;
ограничение внешнего API.

77. Autoscaling по памяти

Memory metric сложнее, потому что память часто освобождается не сразу.

Если приложение стабильно использует кэш, HPA может ошибочно масштабировать его вверх.

Memory scaling полезен, если потребление действительно связано с нагрузкой и экземпляры способны освободить память.

78. Autoscaling по Request Rate

Можно масштабировать по:

запросов в секунду на экземпляр.

Это часто лучше CPU для I/O-сервисов.

Необходимо учитывать:

сложность запросов;
разные endpoints;
latency upstream;
connection pool.

79. Autoscaling по Queue Depth

Для workers полезна длина очереди.

Пример:

1 worker обрабатывает 50 сообщений в минуту.
В очереди 5 000 сообщений.

Autoscaler добавляет consumers.

Но необходимо учитывать:

максимальную нагрузку базы;
partition count;
rate limit внешней системы;
порядок сообщений.

80. Consumer Lag

Для event stream ключевой сигнал — lag.

Latest offset - Consumer offset

Если lag растёт, обработка не успевает.

Но добавление consumers помогает только до числа partitions.

81. Scheduled Scaling

Если нагрузка предсказуема:

начало рабочего дня;
ночной batch;
ежемесячный отчёт;
маркетинговая кампания,

ресурсы можно увеличить заранее.

Это уменьшает задержку реактивного autoscaling.

82. Predictive Scaling

На основании истории прогнозируется будущая нагрузка.

Подходит для стабильных повторяющихся паттернов.

Риск:

неверный прогноз;
неожиданное событие;
лишняя стоимость.

Обычно применяется вместе с реактивным scaling.

83. Scale-to-Zero

Число экземпляров уменьшается до нуля.

Подходит для:

редко вызываемых функций;
некритичных jobs;
serverless;
тестовых сред.

Недостатки:

cold start;
первый запрос ждёт;
отсутствие постоянного consumer;
невозможность для некоторых realtime-задач.

84. Cold Start

Cold Start включает:

запуск контейнера;
загрузку runtime;
чтение конфигурации;
установку соединений;
прогрев JIT;
загрузку модели.

Для latency-sensitive сервиса нужен:

minimum replicas;
pre-warming;
быстрый startup;
readiness после завершения прогрева.

85. Scale-Up Delay

Autoscaler обнаруживает нагрузку не мгновенно.

Затем требуется:

принять решение;
запланировать Pod;
загрузить образ;
запустить;
пройти readiness.

Поэтому необходимо иметь headroom.

86. Headroom

Headroom — свободная ёмкость для внезапного роста.

Система, постоянно работающая на 100%, не успевает масштабироваться.

Запас зависит от:

скорости запуска;
вариативности нагрузки;
критичности;
стоимости.

87. Thrashing Autoscaler

Если scaling слишком чувствителен, число экземпляров постоянно меняется:

3 → 6 → 3 → 7 → 3

Это создаёт:

cold starts;
нестабильность;
лишнюю стоимость;
connection churn.

Нужны:

stabilization window;
cooldown;
усреднение метрик;
разумные пороги.

88. Vertical Pod Autoscaler

VPA может рекомендовать или менять requests/limits экземпляров.

Полезен для:

подбора размера;
сервисов с изменяющимся профилем;
уменьшения overprovisioning.

Изменение ресурсов часто требует пересоздания Pod.

VPA и HPA по CPU могут конфликтовать без правильной настройки.

89. Cluster Autoscaler

Если в кластере нет места для новых Pod, добавляются вычислительные узлы.

Цепочка:

Нагрузка
→ HPA создаёт Pod
→ Pod Pending
→ Cluster Autoscaler добавляет Node
→ Pod запускается

Это значительно медленнее добавления Pod на уже свободный узел.

90. Capacity Planning

Capacity Planning определяет ресурсы для ожидаемой нагрузки.

Нужно знать:

baseline;
peak;
рост;
сезонность;
latency target;
throughput;
размер данных;
fault tolerance.

Планирование строится на измерениях и моделях, а не на предположении «добавим сервер при проблеме».

91. Throughput

Throughput — объём операций за единицу времени.

Примеры:

500 запросов в секунду.
10 000 сообщений в минуту.

Нужно измерять не только входной запрос, но и:

базу;
брокер;
внешние API;
CPU;
диски.

92. Latency Percentiles

Среднее значение может скрывать плохой пользовательский опыт.

Используются:

p50;
p95;
p99.

Например:

p50 = 100 мс.
p99 = 4 секунды.

Небольшая доля очень медленных запросов может быть критичной.

93. Saturation

Saturation показывает степень исчерпания ресурса:

очередь запросов;
занятые потоки;
connection pool;
CPU throttling;
disk queue;
broker lag.

Высокая saturation часто предшествует ошибкам.

94. Little’s Law на практическом уровне

Количество одновременно выполняемых операций связано с:

скоростью поступления;
временем обработки.

Если запросы приходят быстрее или обрабатываются дольше, растёт concurrency и очередь.

Поэтому уменьшение latency может повысить пропускную способность без добавления экземпляров.

95. Bottleneck Analysis

Узким местом может быть:

CPU сервиса;
база;
блокировка;
внешний API;
очередь;
сеть;
один partition;
connection pool.

Масштабирование не того компонента не даст результата.

Пример:

Добавили 20 экземпляров API,
но база выдерживает только 200 соединений.

96. Connection Pool

Каждый экземпляр сервиса имеет pool соединений.

При масштабировании:

20 экземпляров × 50 соединений
= до 1000 соединений к базе.

База может не выдержать.

Нужно согласовывать:

число replicas;
размер pool;
лимит базы;
proxy;
transaction duration.

97. Database Scaling

Варианты:

vertical scaling;
read replicas;
partitioning;
sharding;
caching;
query optimization;
indexes;
archival;
CQRS.

Database часто масштабируется сложнее stateless API.

98. Read Replicas

Чтение распределяется между replicas.

Подходит для:

отчётов;
списков;
некритичных запросов.

Необходимо учитывать replication lag.

После записи пользователь может не увидеть изменение сразу.

99. Write Scaling

Запись сложнее масштабировать.

Подходы:

partitioning;
sharding;
распределение по tenant;
batching;
уменьшение contention;
event log;
отдельные владельцы данных.

Нельзя просто добавить replicas для одной writable relational database без модели координации.

100. Cache Scaling

Кэш уменьшает нагрузку, но добавляет:

invalidation;
memory cost;
hot keys;
stampede;
consistency.

Масштабирование кэша требует:

partitioning;
replication;
eviction policy;
наблюдаемости.

101. Cache Stampede

Много запросов одновременно обнаруживают истёкший ключ и обращаются к базе.

Защита:

distributed lock;
request coalescing;
jitter TTL;
stale-while-revalidate;
background refresh.

102. Hot Key

Один ключ получает непропорциональную нагрузку.

Примеры:

глобальная настройка;
популярный товар;
общий счётчик.

Даже распределённый кэш может перегрузить один shard.

103. Partitioning Workers

Задачи распределяются по ключу.

Например:

MachineId
→ определённая partition.

Это сохраняет порядок по станку.

Но число параллельных consumers ограничивается числом partitions.

104. Backpressure при масштабировании

Если downstream не выдерживает нагрузку, добавление producers ухудшит ситуацию.

Необходимо:

ограничивать concurrency;
использовать bounded queues;
применять rate limits;
учитывать capacity downstream;
возвращать overload signal.

105. Load Shedding

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

Можно отклонять:

низкоприоритетные запросы;
тяжёлую аналитику;
необязательные рекомендации;
запросы сверх квоты.

Лучше быстро вернуть контролируемую ошибку, чем довести всю систему до полного отказа.

106. Priority Queues

Сообщения разделяются по приоритету.

Например:

High:
управляющие команды производства.

Normal:
обычные операции.

Low:
аналитическая обработка.

Нужно предотвращать starvation низкого приоритета.

107. Multi-Zone Deployment

Экземпляры распределяются по зонам доступности.

Цель:

пережить отказ зоны;
уменьшить общий blast radius.

Нужно учитывать:

topology spread;
anti-affinity;
database placement;
межзональный трафик;
quorum.

108. Pod Anti-Affinity

Критические replicas не должны оказаться на одном узле.

Если узел завершится, будут потеряны все экземпляры.

Anti-affinity или topology spread распределяет их.

109. Multi-Region Deployment

Система развёртывается в нескольких регионах.

Варианты:

active-passive;
active-active;
regional ownership;
geo-routing.

Сложность:

данные;
конфликты;
latency;
failover;
compliance;
стоимость.

110. Active-Passive

Один регион обслуживает трафик.

Второй готов к переключению.

Необходимо:

репликация;
регулярная проверка failover;
DNS или traffic switch;
понятные RPO/RTO.

Резервная среда, которую никогда не проверяли, не является надёжной стратегией.

111. Active-Active

Несколько регионов принимают трафик одновременно.

Преимущества:

высокая доступность;
низкая региональная latency.

Сложности:

распределённая запись;
конфликты;
global routing;
data residency;
высокая стоимость.

112. Disaster Recovery

Disaster Recovery определяет восстановление после крупного отказа.

Нужно иметь:

backup;
replicated artifacts;
IaC;
runbook;
резервный регион;
восстановление DNS;
проверенные процедуры.

113. RPO и RTO

RPO

Допустимая потеря данных.

RTO

Допустимое время восстановления.

Пример:

RPO: 5 минут.
RTO: 30 минут.

Чем строже показатели, тем выше стоимость архитектуры.

114. Chaos Testing Deployment

Проверяются сценарии:

завершение Pod;
потеря Node;
отказ Zone;
замедление базы;
недоступность Registry;
рост очереди;
неуспешный rollout.

Цель — убедиться, что механизмы восстановления действительно работают.

115. Deployment Freeze

В критические периоды может вводиться ограничение релизов:

финансовое закрытие;
производственный запуск;
сезонный пик;
праздничная нагрузка.

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

116. Наблюдаемость развёртывания

Для каждого rollout нужны:

deployment events;
version;
start/end time;
replicas ready;
failed probes;
restarts;
errors;
latency;
бизнес-метрики.

На dashboard должно быть видно, когда новая версия вошла в систему.

117. Release Marker в логах и метриках

Логи и spans должны содержать:

service version;
build ID;
deployment ID;
environment.

Это позволяет сравнивать:

Ошибки появились только после версии 2.4.1.

118. SLO-Aware Deployment

Если error budget почти исчерпан, автоматическая политика может:

остановить рискованные релизы;
уменьшить скорость rollout;
потребовать approval;
переключить команду на надёжность.

119. Стоимость масштабирования

Больше replicas означает:

вычислительные ресурсы;
соединения;
логи;
tracing;
межзональный трафик;
лицензии;
storage.

Масштабирование должно учитывать не только SLA, но и стоимость.

120. Overprovisioning

Слишком большой запас ресурсов:

увеличивает стоимость;
скрывает неэффективность;
снижает плотность кластера.

Но некоторое overprovisioning необходимо для:

пиков;
отказа узла;
быстрого scaling;
rollout.

121. Underprovisioning

Недостаточные ресурсы приводят к:

throttling;
OOM;
timeout;
очередям;
нестабильному autoscaling;
каскадным сбоям.

Экономия может оказаться дороже инцидентов.

122. Rightsizing

Rightsizing — подбор разумных requests и limits на основании фактических метрик.

Необходимо анализировать:

p95 CPU;
p95 memory;
пиковую нагрузку;
burst;
startup;
GC;
ограничения downstream.

123. FinOps

FinOps связывает архитектуру, команды и стоимость.

Полезные показатели:

стоимость сервиса;
стоимость запроса;
стоимость tenant;
стоимость хранения;
idle resources;
стоимость логов.

Команда должна видеть экономический результат масштабирования.

124. Cost Allocation

Ресурсы маркируются:

service;
team;
environment;
tenant;
project.

Это помогает определить владельца расходов и оптимизировать их осознанно.

125. Непродуктивные среды

Development и Staging могут потреблять значительную часть бюджета.

Возможные меры:

scale-to-zero;
расписание выключения;
ephemeral environments;
shared managed dependencies;
уменьшенные datasets.

Но тестовая среда должна оставаться достаточно похожей на Production.

126. Ephemeral Environment

Для branch или pull request создаётся временная среда.

Преимущества:

изолированное тестирование;
удобный review;
параллельная разработка.

Недостатки:

стоимость;
длительное создание;
миграции;
тестовые данные;
ограниченные внешние интеграции.

127. Preview Environment

Preview environment может содержать:

изменяемый сервис;
shared dependencies;
mocks других сервисов.

Не всегда необходимо копировать всю платформу.

128. Stateful Deployment

Развёртывание stateful-компонента требует:

backup;
replication;
quorum;
ordered rollout;
data compatibility;
leader transfer;
partition safety.

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

129. Quorum

Распределённому хранилищу требуется достаточное число участников.

При обновлении нельзя уменьшить доступное число ниже quorum.

Например, для трёх узлов потеря двух делает cluster недоступным.

130. Pod Disruption Budget

PDB ограничивает число экземпляров, которые могут быть добровольно недоступны одновременно.

Он помогает при:

обновлении узлов;
autoscaling cluster;
maintenance.

Но не защищает от аварийного отказа.

131. Node Maintenance

Перед обслуживанием узел:

cordon;
drain;
перенос workloads;
завершение stateful components по правилам.

Нужно учитывать PDB и локальные volumes.

132. Локальные volumes

Данные на локальном диске узла усложняют:

перенос;
failover;
autoscaling;
восстановление.

Для временных данных это допустимо.

Для критических данных требуется durable storage и стратегия восстановления.

133. Deployment фоновых Consumers

Consumer должен корректно обрабатывать:

остановку;
ack;
retry;
partition rebalance;
повторное сообщение.

При rollout старые и новые версии могут одновременно читать очередь.

Схема сообщения должна быть совместимой.

134. Consumer Rebalance

При изменении числа consumers partitions перераспределяются.

На время rebalance обработка может задерживаться.

Долгие операции должны:

поддерживать checkpoint;
корректно завершаться;
не терять Ack;
быть идемпотентными.

135. Масштабирование Consumer Group

Максимальный параллелизм ограничен числом partitions.

3 partitions
→ эффективно не более 3 активных consumers группы.

Добавление десяти consumers не увеличит throughput после этого предела.

136. Масштабирование Work Queue

В обычной очереди можно увеличивать workers, пока downstream выдерживает.

Но возможны ограничения:

rate limit внешнего API;
connection pool базы;
lock contention;
общий файл;
сериализация по ключу.

137. Singleton Jobs

Если scheduler запущен в каждом replica, одна задача может выполниться несколько раз.

Решения:

отдельный Job;
leader election;
distributed lock;
queue;
platform scheduler.

Сама задача всё равно должна быть идемпотентной.

138. Edge Deployment

Edge-сервисы работают рядом с оборудованием или локальной площадкой.

Особенности:

ограниченные ресурсы;
нестабильная связь;
удалённое обновление;
физическая безопасность;
offline mode;
разные версии оборудования.

139. Обновление Edge

Стратегии:

по площадкам;
небольшими группами;
с локальным rollback;
с проверкой совместимости;
с сохранением старого образа.

Нельзя одновременно обновлять все производственные площадки без возможности восстановления.

140. Offline Rollback

Edge-устройство должно иметь возможность вернуться к предыдущей версии без постоянного доступа к центру.

Варианты:

A/B partitions;
сохранённый образ;
локальный watchdog;
подписанные пакеты.

141. Производственная безопасность

Развёртывание сервиса, управляющего оборудованием, требует более строгих мер:

maintenance window;
подтверждение оператора;
совместимость с firmware;
безопасное состояние при сбое;
запрет опасных команд;
ручной fallback;
полный аудит.

Обычная стратегия «автоматически выкатывать каждую версию» может быть неприемлема.

142. Deployment AI-сервиса

AI-компонент может зависеть от:

модели;
GPU;
quantization;
tokenizer;
prompts;
safety policy.

Версия должна включать не только код, но и:

model version;
configuration;
prompt version;
index version;
runtime.

143. Масштабирование AI Workload

Ограничения:

GPU memory;
model loading;
batch size;
token throughput;
queue;
cold start;
context length.

CPU-based autoscaling часто недостаточен.

Используются:

queue depth;
active sequences;
token rate;
GPU utilization;
memory.

144. Model Warm-Up

Новый AI-instance может долго загружать модель.

Он не должен считаться ready до:

загрузки весов;
подготовки runtime;
пробного inference;
загрузки tokenizer.

145. Масштабирование 3D/инженерных расчётов

Для тяжёлых геометрических или расчётных задач подходит очередь jobs.

SubmitJob
→ Queue
→ Compute Workers
→ Result Storage

Workers масштабируются по queue depth.

Синхронный API возвращает Operation ID.

146. Развёртывание desktop-приложения

Desktop-система развёртывается иначе, чем серверный сервис.

Требуются:

installer;
version check;
automatic update;
rollback;
совместимость локальной базы;
подпись пакета;
staged rollout.

Обновление может выполняться по группам пользователей.

147. Desktop и backend compatibility

Desktop-клиенты обновляются не одновременно.

Backend должен некоторое время поддерживать несколько версий API.

Нельзя предполагать, что все пользователи установили новую версию в день релиза.

148. Database Migration локального клиента

Локальная база должна мигрироваться безопасно:

backup;
transaction;
version;
rollback или forward repair;
проверка свободного места;
совместимость installer.

149. Масштабирование API Gateway

Gateway масштабируется горизонтально.

Необходимо учитывать:

TLS;
WebSocket;
connection count;
rate limiting state;
aggregation;
streaming.

Stateful rate limiting может требовать общего распределённого storage.

150. Масштабирование Service Discovery

Registry и DNS должны быть высокодоступными.

Но клиент не должен обращаться в Registry при каждом запросе.

Используются:

кэш;
watch;
server-side routing;
platform Service.

151. Масштабирование брокера

Брокер масштабируется через:

partitions;
queues;
replicas;
consumers;
storage;
throughput limits.

Нужно учитывать:

порядок;
replication factor;
retention;
disk;
network.

152. Масштабирование логирования

Каждый новый replica создаёт больше логов.

Если логировать payload каждого запроса, наблюдаемость может стать:

дорогой;
медленной;
небезопасной.

Используются:

уровни;
sampling;
retention;
structured fields;
исключение чувствительных данных.

153. Trace Sampling

При большом трафике хранить все traces дорого.

Стратегии:

head-based sampling;
tail-based sampling;
error sampling;
latency sampling;
adaptive sampling.

Ошибочные и медленные traces следует сохранять с большим приоритетом.

154. Deployment Metrics

Полезные показатели:

deployment frequency;
lead time;
change failure rate;
time to rollback;
rollout duration;
failed deployments;
percentage automated;
incidents by version.

155. DORA Metrics

Основные показатели:

Deployment Frequency;
Lead Time for Changes;
Change Failure Rate;
Mean Time to Restore.

Они оценивают способность команды безопасно доставлять изменения.

156. Change Failure Rate

Доля релизов, которые приводят к:

rollback;
incident;
hotfix;
деградации.

Высокая частота релизов полезна только при низком риске отказа.

157. Mean Time to Restore

MTTR измеряет время восстановления после проблемы.

Уменьшается через:

наблюдаемость;
быстрый rollback;
runbook;
canary;
feature flags;
автоматизацию;
ясное ownership.

158. Runbook развёртывания

Runbook должен описывать:

запуск rollout;
критерии успеха;
остановку;
rollback;
миграции;
проверку данных;
контакты;
аварийные действия.

159. Антипаттерн: ручное развёртывание

Признаки:

копирование файлов по SSH;
ручное редактирование config;
выполнение SQL без журнала;
неизвестная версия;
отсутствие rollback.

Ручные процедуры плохо масштабируются и трудно воспроизводятся.

160. Антипаттерн: Latest Tag

Production использует:

image: latest

Невозможно точно определить или вернуть версию.

Следует использовать immutable version или digest.

161. Антипаттерн: секреты в образе

Секрет, добавленный при build, остаётся в слоях образа даже после удаления из финального файла.

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

162. Антипаттерн: миграция при каждом старте

Все replicas одновременно пытаются изменить базу.

Это создаёт:

race;
lock;
долгий startup;
неясный статус.

163. Антипаттерн: Liveness зависит от базы

База временно недоступна.

Все Pods перезапускаются.

После восстановления база получает storm соединений.

Следует разделять состояние процесса и готовность обслуживать запросы.

164. Антипаттерн: отсутствие Readiness

Новый экземпляр сразу получает трафик до завершения инициализации.

Результат:

ошибки;
высокая latency;
неготовый кэш;
неустановленные соединения.

165. Антипаттерн: мгновенный rollout на 100%

Новая версия сразу обслуживает всех пользователей.

Blast radius максимален.

Для критичных систем лучше progressive delivery.

166. Антипаттерн: Rollback без учёта данных

Команда откатывает приложение, но старая версия не понимает новую схему.

Rollback должен проектироваться совместно с migration strategy.

167. Антипаттерн: Autoscaling только по CPU

Сервис ожидает медленную базу, CPU низкий, очередь растёт.

HPA не масштабирует.

Нужно выбирать метрики, отражающие реальную работу.

168. Антипаттерн: неограниченный Autoscaling

Autoscaler создаёт сотни экземпляров, которые перегружают базу или внешний API.

Нужны:

max replicas;
downstream capacity;
rate limits;
load shedding;
cost limits.

169. Антипаттерн: Memory Leak лечится scaling

Добавление экземпляров временно скрывает утечку, но каждый новый экземпляр позже завершится.

Нужно исправлять причину.

170. Антипаттерн: слишком маленькие resource requests

Планировщик размещает много Pod на узле.

При реальной нагрузке узел перегружается.

Возникают:

eviction;
throttling;
OOM;
noisy neighbor.

171. Антипаттерн: слишком большие requests

Кластер простаивает, но новые Pod не помещаются.

Стоимость растёт.

Нужно выполнять rightsizing.

172. Антипаттерн: Scaling без нагрузочного теста

Планируется:

1000 запросов в секунду

но система никогда не проверялась при такой нагрузке.

Нагрузочный тест должен охватывать:

сервис;
базу;
сеть;
брокер;
внешние лимиты.

173. Антипаттерн: HPA и очередь без лимитов

Workers масштабируются медленно, а очередь растёт бесконечно.

Нужны:

backpressure;
retention;
priority;
DLQ;
alert по возрасту сообщений.

174. Антипаттерн: один экземпляр критического Gateway

Все сервисы имеют по три replicas, но Gateway один.

Фактическая доступность определяется самым слабым обязательным компонентом.

175. Антипаттерн: все replicas на одном Node

Формально сервис масштабирован, но отказ узла уничтожает все экземпляры.

Нужно topology spread.

176. Антипаттерн: Active-Active без модели конфликтов

Два региона одновременно меняют одни данные.

Не определено:

кто владелец;
как разрешать конфликт;
какой порядок;
что делать при partition.

Active-active требует предметной модели согласования.

177. Антипаттерн: Kubernetes ради Kubernetes

Небольшая система из двух сервисов получает сложный кластер, который команда не умеет поддерживать.

Оркестратор оправдан, если его преимущества превышают операционную стоимость.

178. Когда Kubernetes может быть избыточен

небольшое число сервисов;
стабильная нагрузка;
одна машина или простые VM;
отсутствует platform team;
managed platform решает задачу проще;
высокая цена сложности.

Возможны альтернативы:

managed container platform;
serverless;
VM + systemd;
PaaS;
Docker Compose для ограниченного контура.

179. Выбор платформы развёртывания

Критерии:

число сервисов;
нагрузка;
требования доступности;
multi-region;
компетенции;
безопасность;
стоимость;
vendor lock-in;
edge;
stateful workloads.

180. Пример системы заказов

Компоненты:

API Gateway: 3 replicas.
Order Service: 6 replicas.
Payment Service: 4 replicas.
Inventory Service: 5 replicas.
Notification Workers: autoscaling 2–30.

Order Service масштабируется по request rate.

Notification Workers — по queue depth.

Payment Service имеет ограничение по rate внешнего провайдера, поэтому max replicas не должен превышать безопасную общую нагрузку.

181. Пример canary для Payment Service

Этапы:

Развернуть v2 с одним экземпляром.
Проверить readiness.
Отправить внутренние тестовые платежи.
Направить 1% допустимого трафика.
Сравнить:
- успешность;
- latency;
- повторные операции;
- ответы провайдера.
Увеличить до 10%.
Завершить rollout.
Сохранить v1 для быстрого возврата на ограниченный период.

182. Пример производственной платформы

Возможная модель:

Central Services
├── Planning
├── Inventory
├── Tool Management
└── Reporting

Site Edge
├── Site Gateway
├── Machine Adapters
└── Local Queue

Central Services масштабируются в серверном кластере.

Edge-компоненты развёртываются по площадкам и должны работать при потере центральной связи.

183. Обновление Machine Adapter

Процесс:

Проверить совместимость модели станка.
Вывести Adapter из readiness.
Завершить текущие команды.
Остановить старую версию.
Установить подписанный пакет.
Выполнить handshake.
Проверить read-only операции.
Разрешить управляющие команды.
Сохранить возможность локального rollback.

184. Масштабирование телеметрии

Вместо масштабирования одного API используются:

partitioning по MachineId;
несколько collectors;
edge buffering;
streaming broker;
time-series storage;
downsampling.

Основной сигнал autoscaling — ingress rate и consumer lag.

185. Пример Tool Selection Service

Он может иметь два режима:

Синхронный быстрый подбор
→ stateless API replicas.

Тяжёлый анализ
→ job queue + compute workers.

API масштабируется по request rate.

Workers — по queue depth и длительности задачи.

186. Пример AI-сервиса

Маршрутизатор принимает запрос.

Inference workers могут быть:

GPU;
CPU;
разные модели.

Масштабирование учитывает:

queue wait;
active sequences;
tokens per second;
GPU memory;
latency SLO.

187. Чек-лист развёртывания

Артефакт неизменяем?
Версия однозначна?
Секреты передаются безопасно?
Есть CI/CD?
Настроены probes?
Поддерживается graceful shutdown?
Версии совместимы?
Миграция базы обратимо или эволюционна?
Есть smoke tests?
Есть rollback или roll forward?
Наблюдаются бизнес-метрики?
Ограничен blast radius?

188. Чек-лист масштабирования

Что является узким местом?
Нагрузка CPU-bound или I/O-bound?
Сервис stateless?
Как хранится session?
Выдерживает ли база рост replicas?
Каков размер connection pool?
Какая метрика управляет scaling?
Какова скорость запуска экземпляра?
Есть ли headroom?
Как ограничен max scale?
Что происходит с downstream?
Какова стоимость масштабирования?

189. Чек-лист autoscaling workers

Как измеряется queue depth?
Каков возраст старейшего сообщения?
Какова скорость обработки worker?
Есть ли partition limit?
Идемпотентны ли задачи?
Что происходит при shutdown?
Есть ли DLQ?
Ограничивает ли downstream throughput?
Как предотвращается thrashing?
Каков максимальный backlog?

190. Чек-лист production readiness

Определён владелец сервиса?
Есть dashboard?
Настроены alerts?
Определены SLO?
Есть runbook?
Проверен backup?
Проверен restore?
Проверен отказ экземпляра?
Проверен rolling update?
Выполнялся нагрузочный тест?
Известен предел capacity?
Проверены секреты и права?

191. Практические рекомендации

Правило 1

Собирайте артефакт один раз и продвигайте его между средами.

Правило 2

Храните конфигурацию отдельно, а секреты — в защищённом хранилище.

Правило 3

Автоматизируйте deployment и rollback.

Правило 4

Используйте readiness, liveness и graceful shutdown по их реальному назначению.

Правило 5

Выполняйте эволюционные совместимые миграции данных.

Правило 6

Снижайте blast radius через canary и progressive delivery.

Правило 7

Масштабируйте по метрике, отражающей реальную нагрузку.

Правило 8

Учитывайте capacity баз, брокеров и внешних сервисов.

Правило 9

Распределяйте replicas по узлам и зонам.

Правило 10

Связывайте техническую масштабируемость с наблюдаемостью и стоимостью.

192. Контрольные вопросы

После изучения урока обучающийся должен уметь ответить:

Что называется развёртыванием?
Что означает immutable artifact?
Зачем отделять конфигурацию от кода?
Какие преимущества даёт контейнеризация?
Что делает оркестратор?
Чем readiness отличается от liveness?
Для чего нужна startup probe?
Что происходит при rolling update?
Чем Blue-Green отличается от Canary?
Что такое Progressive Delivery?
Почему rollback может быть невозможен после миграции данных?
Для чего используется Expand–Migrate–Contract?
Чем горизонтальное масштабирование отличается от вертикального?
Что требуется для масштабирования stateless-сервиса?
Какие метрики можно использовать для autoscaling?
Почему CPU не всегда является правильным сигналом?
Что такое consumer lag?
Почему добавление replicas может перегрузить базу?
Что такое headroom?
Какие риски имеет active-active deployment?

193. Итоги урока

Развёртывание микросервисов должно быть:

автоматическим;
повторяемым;
наблюдаемым;
безопасным;
постепенно контролируемым;
совместимым с откатом или исправлением вперёд.

Основные стратегии:

Rolling Update
Blue-Green
Canary
Shadow
Feature Flags
Progressive Delivery

Выбор стратегии зависит от:

критичности;
совместимости версий;
стоимости ресурсов;
состояния данных;
допустимого blast radius.

Масштабирование может быть:

Vertical
Horizontal
Scheduled
Reactive
Predictive
Geographical

Но добавление экземпляров эффективно только тогда, когда остальные компоненты пути также выдерживают рост нагрузки.

Необходимо учитывать:

базу данных;
брокер;
connection pools;
partitions;
внешние rate limits;
состояние;
стоимость.

Для управляемого scaling нужны:

корректные resource requests;
подходящие метрики;
headroom;
stabilization;
max limits;
backpressure;
нагрузочные тесты.

Главный принцип можно сформулировать следующим образом:

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