> For the complete documentation index, see [llms.txt](https://rema.gitbook.io/it-business-system-analyst/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rema.gitbook.io/it-business-system-analyst/systems_analyst/devops-ci-cd.md). # DevOps культура и CI/CD | Грейд | Роль | | --------- | ------ | | 🟠 Senior | 🅰️ SA | > DevOps и CI/CD кардинально изменяют требования к поставке и архитектуре. Аналитику важно понимать эти практики для корректной формулирования требований к производительности, надежности и откатываемости. ## Что такое DevOps **DevOps** — это культура, практики и инструменты, которые объединяют разработку (Development) и операции (Operations) в единую команду. Вместо того, чтобы разработчики "бросали" код операционникам, они вместе отвечают за полный жизненный цикл системы. Основные принципы: * **Автоматизация** — минимум ручных операций * **Измерение** — всё должно быть видимо и измеримо * **Обмен знаниями** — инженеры разных направлений учат друг друга ## Что такое CI/CD **Continuous Integration (CI)** — практика, при которой разработчики несколько раз в день интегрируют свой код в общий репозиторий. Каждая интеграция проходит автоматические тесты. **Continuous Delivery (CD)** — расширение CI. Код упаковывается в готовый артефакт и может быть развернут в production нажатием кнопки. **Continuous Deployment** — полная автоматизация: каждый коммит, прошедший тесты, автоматически попадает в production. ### Типичный CI/CD pipeline ``` Разработчик пушит код ↓ (git push) Git repository ↓ (webhook) CI/CD система (Jenkins, GitLab CI, GitHub Actions) ↓ (триггер) Этап 1: Сборка - Скомпилировать код - Запустить unit-тесты - Анализ кода (SonarQube) ↓ (если успешно) Этап 2: Интеграционные тесты - Запустить интеграционные тесты - Развернуть на тестовой среде ↓ (если успешно) Этап 3: Build артефакта - Создать Docker image - Загрузить в реестр ↓ (если успешно) Этап 4: Deploy на staging - Развернуть на staging-сервере - Smoke-тесты ↓ (ручное решение или автоматическое) Этап 5: Deploy в production - Развернуть в production - Мониторинг и алерты ↓ Система работает, метрики собираются ``` ## CI/CD для аналитика: почему это важно ### Требования меняются с CI/CD **Без CI/CD (квартальные релизы):** * Большие изменения раз в квартал * Долгий процесс тестирования (две недели) * Высокий риск при релизе * Откат сложный **С CI/CD (ежедневные релизы):** * Маленькие изменения несколько раз в день * Автоматическое тестирование (минуты) * Низкий риск (маленькие изменения легче отследить) * Откат простой (вернуть предыдущий коммит) ### Требования должны быть маленькими и независимыми При CI/CD требование "Полностью переписать систему авторизации" не пройдет — слишком сложно развертывать, тестировать и откатывать. Правильное требование: "Добавить поддержку MFA для SMS". ### Feature flags для управления релизами **Feature flag** — это переключатель, который позволяет включать/отключать функцию без переразворачивания кода. ``` // Код if (featureFlags.isEnabled('new_checkout_flow')) { // Новый процесс checkout return newCheckout(); } else { // Старый процесс return legacyCheckout(); } ``` **Для аналитика:** требование должно включать описание feature flag: * Кто может включать флаг (только admins)? * Как постепенно включать (сначала для 5% пользователей, потом 50%, потом 100%)? * Как отключать, если что-то пошло не так (rollback на 0%)? ## Среды разработки и требования ### Типичные среды | Среда | Назначение | Требования от аналитика | | -------------- | --------------------------------------------- | --------------------------------------------------------------- | | **Dev** | Разработчик тестирует свой код | Может быть нестабильна, данные могут быть тестовыми | | **Staging** | Полная копия Production | Должна быть стабильна, данные максимально приближены к продовым | | **Production** | Работающая система с реальными пользователями | Максимальная надежность, безопасность, производительность | **Типичная ошибка:** требование формулируется для production (99.99% uptime), но staging требует другого. Правильно: ``` Production: Uptime 99.9%, Response time P95 < 200ms Staging: Uptime 95%, Response time < 500ms (допускается) Dev: Может быть любым ``` ## Observability: логирование, мониторинг, трейсинг ### Логирование (Logs) Логи — это события, которые произошли в системе: ``` 2026-04-09 14:23:15 [INFO] Order created: order_id=12345, customer_id=789, amount=500 2026-04-09 14:23:16 [ERROR] Payment failed: order_id=12345, error="Card declined", provider="Stripe" 2026-04-09 14:23:17 [INFO] Order cancelled: order_id=12345, reason="payment_failed" ``` **Требования аналитика к логированию:** * Какие события должны логироваться? * На каком уровне (DEBUG, INFO, WARNING, ERROR)? * Какую информацию включить (user\_id, request\_id, duration)? ### Мониторинг (Metrics) Метрики — это числовые показатели: ``` requests_per_second: 150 req/sec response_time_p95: 180ms error_rate: 0.5% cpu_usage: 45% memory_usage: 2.3 GB / 4 GB database_connections: 45 / 50 ``` **RED метрики для сервиса:** * **Rate** — сколько запросов в секунду? * **Error rate** — сколько ошибок? * **Duration** — как долго обработка? **Требования аналитика к мониторингу:** ``` Метрики для отслеживания: - orders_created_total (counter) - order_processing_duration_seconds (histogram) - payment_errors_total (counter) Алерты: - Если error_rate > 1% на 5 минут → Page on-call инженера - Если response_time_p95 > 500ms → Warning в Slack - Если database_connections > 80% → Warning в Slack ``` ### Трейсинг (Traces) Трейс следует один запрос через несколько сервисов: ``` trace_id: abc123 Запрос: POST /api/orders ├─ API Gateway (10ms) │ └─ Authorization (5ms) ├─ Order Service (50ms) │ ├─ Validate request (5ms) │ ├─ Save to DB (30ms) │ └─ Publish event (15ms) ├─ Inventory Service (40ms) │ ├─ Check stock (20ms) │ └─ Reserve items (20ms) └─ Notification Service (20ms) └─ Send email (20ms) Total: 120ms ``` ## Infrastructure as Code (IaC) **Infrastructure as Code** — это подход, при котором вся инфраструктура описывается в виде кода. Пример Terraform (описание инфраструктуры): ```hcl resource "aws_rds_instance" "postgres" { identifier = "production-db" allocated_storage = 100 instance_class = "db.t3.medium" engine = "postgres" engine_version = "14.7" parameter_group_name = "default.postgres14" skip_final_snapshot = false tags = { Name = "production-db" } } ``` **Преимущества для аналитика:** * Инфраструктура версионируется (история изменений) * Можно легко создать одинаковую инфраструктуру для dev/staging/prod * Изменения проходят code review перед применением ## Типичные требования, которые учитывают CI/CD ### Требование 1: Откатываемость ``` Функция: Обновление цен товаров Требование: - Если после развертывания обнаружена ошибка, должна быть возможность вернуться к предыдущей версии за < 5 минут - Откат должен быть автоматическим нажатием кнопки в UI или команде - Откат не должен приводить к потере данных (БД миграции должны быть обратимы) ``` ### Требование 2: Monitoring готовность ``` Функция: Новый алгоритм рекомендаций товаров Требование: - До запуска определить метрики: * recommendation_click_through_rate * recommendation_conversion_rate * recommendation_latency_ms - Установить алерты: * Если CTR упала > 10% от baseline → откатиться * Если latency > 200ms → откатиться - Постепенное включение (canary deployment): 1. Включить для 1% пользователей на 1 час 2. Если метрики в норме → 10% пользователей 3. Если метрики в норме → 100% пользователей ``` ### Требование 3: Backward compatibility ``` API эндпоинт: GET /api/v2/products/{id} Текущий ответ: { "id": 123, "name": "Товар", "price": 500, "category": "electronics" } Новый ответ (с новым полем): { "id": 123, "name": "Товар", "price": 500, "category": "electronics", "discount_percentage": 10 // НОВОЕ ПОЛЕ } Требование: - Старый клиент, не ожидающий discount_percentage, должен продолжить работать - Новые клиенты должны уметь использовать новое поле - Внутри функции проверка: if (client_supports_discounts) { include discount } ``` ## Практические рекомендации ### При написании требований * **Думайте о릴업** — каждое требование должно быть развертываемо * **Требуйте откатываемость** — система должна вернуться в предыдущее состояние * **Определяйте метрики** — какие показатели будут отслеживать успех? * **Планируйте мониторинг** — на какие алерты должна реагировать ops-команда? * **Готовьтесь к отказам** — что происходит, если внешний сервис недоступен? ### При взаимодействии с DevOps-командой * **Обсудите требования к инфраструктуре** — сколько БД, кэшей, сервисов? * **Уточните лимиты облачного провайдера** — есть ли ограничения на request size, timeout? * **Согласуйте требования к доступности** — что такое acceptable downtime? * **Документируйте процессы** — как откатываться, как обновляться? ## 📚 Ресурсы для изучения * [DevOps Roadmap](https://roadmap.sh/devops) — полная карта DevOps-инженера * [Docker Documentation](https://docs.docker.com/) — контейнеризация * [Kubernetes Documentation](https://kubernetes.io/docs/) — оркестрация контейнеров * [The Phoenix Project](https://www.oreilly.com/library/view/the-phoenix-project/9781457191435/) — книга про DevOps культуру * [Site Reliability Engineering](https://sre.google/) — материалы от Google про SRE