DevOps Rules

CI/CD пайплайны

• Падай быстро: сначала запускай линтинг и юнит-тесты, а уже потом дорогие интеграционные тесты — это экономит время и ресурсы.
• Кэшируй зависимости между сборками — повторный npm install на каждом билде тратит лишние минуты.
• Фиксируй версии экшенов по SHA, а не по тегам — actions/checkout@v3 может измениться, SHA — нет.
• Секреты только в переменных окружения, никогда в коде или логах — маскируй их в выводе CI.
• Запускай независимые задачи параллельно — тесты, линтинг и сборка могут выполняться одновременно.

Стратегии деплоя

• Blue-green: новая версия работает параллельно со старой, переключение трафика происходит мгновенно — откат так же прост.
• Canary: направляй часть трафика на новую версию — выявляй проблемы до полного релиза.
• Rolling: обновляй инстансы постепенно — баланс скорости и риска.
• Всегда имей план отката перед деплоем — точно знай, как вернуть всё назад.
• Деплой один и тот же артефакт во все окружения — собирай один раз, продвигай по стадиям.

Infrastructure as Code

• Храни всю инфраструктуру в системе контроля версий — Terraform, Ansible, CloudFormation должны быть в Git.
• Никогда не применяй изменения без предварительного плана — сначала terraform plan, потом apply.
• State-файлы содержат секреты — храни их удалённо и с шифрованием, не в Git.
• Используй модули для повторного использования — не копируй конфигурации.
• Разделяй окружения — изменения в dev не должны затрагивать production.

Контейнеры

• Один процесс на контейнер — это не виртуальная машина.
• Health checks обязательны — оркестратор использует их для маршрутизации и перезапуска.
• Не запускай контейнеры от root — используй non-root пользователя.
• Иммутабельные образы: конфигурация через переменные окружения, а не внутри образа.
• Тегируй образы SHA коммита, а не просто latest.

Управление секретами

• Никогда не храни секреты в файлах, закоммиченных в Git — используй Vault, sealed secrets или CI-хранилища.
• Регулярно ротируй секреты — автоматизация упрощает этот процесс.
• Используй разные секреты для разных окружений.
• Аудируй доступ к секретам — кто, когда и что использовал.
• Держи секреты в памяти, а не на диске — временные файлы живут дольше, чем кажется.

Мониторинг и алерты

• Четыре ключевых сигнала: задержка, трафик, ошибки, насыщенность.
• Алерты должны сигнализировать о симптомах, а не причинах — «пользователи видят ошибки», а не «CPU высокий».
• Каждый алерт должен быть actionable — иначе это шум.
• Дашборд на каждый сервис с ключевыми метриками.
• Структурированные логи (JSON) — удобнее для анализа.

Надёжность

• Определи SLO до настройки мониторинга — что значит «здоровый сервис».
• Error budgets: небольшое количество ошибок допустимо — 99.9% означает ~8 часов даунтайма в год.
• Практикуй chaos engineering на staging — ломай заранее.
• Подготовь runbooks для типичных инцидентов.
• Постмортемы без поиска виноватых — фокус на системах.

Частые ошибки

• SSH в прод для фиксов — все изменения должны идти через автоматизацию.
• Отсутствие staging — «работает у меня» ≠ «работает в проде».
• Игнорирование нестабильных тестов — подрывает доверие к CI.
• Ручные шаги в деплое — рано или поздно приведут к ошибке.
• Мониторинг только «счастливых сценариев» — отслеживай ошибки и крайние случаи.

Сетевое взаимодействие

• Внутренним сервисам не нужны публичные IP — используй приватные подсети.
• TLS везде, даже внутри сети — zero trust подход.
• DNS для service discovery — IP-адреса меняются.
• Health checks балансировщика должны отличаться от проверок приложения.
• Firewall по принципу deny-by-default — разрешай только необходимое.