README.md

# Вопросы про инфраструктуру и деплой

## Что такое сине-зеленый деплой(blue-green deployment)?

Сине-зеленый деплой (blue-green deployment) — это метод управления развертыванием программного обеспечения, который помогает минимизировать простои и риски при выпуске новых версий приложений. Подход предполагает наличие двух идентичных производственных сред, именуемых "синей" и "зеленой". Ниже подробно описаны ключевые аспекты и этапы сине-зеленого развертывания:

1. Две идентичные среды: На любой момент времени только одна из этих сред активно обслуживает пользователей. Допустим, активной является синяя среда, которая обслуживает текущие запросы, пока в зеленую среду развертывается новая версия приложения.

2. Подготовка новой версии: Новая версия приложения разворачивается в неактивной среде (в нашем примере это зеленая). Развертывание производится в фоновом режиме, что позволяет тщательно протестировать приложение без воздействия на активных пользователей.

3. Тестирование новой версии: Зеленая среда может быть тщательно протестирована перед переключением трафика, что позволяет выявить и исправить ошибки или производственные проблемы в безопасной среде.

4. Переключение трафика: Когда новая версия проверена и готова, сетевой трафик переключается с синей среды на зеленую. Это обычно делает с помощью изменения конфигурации маршрутизации или сетевых маршрутизаторов. Для пользователей этот переход обычно происходит прозрачно.

5. Отмена изменений (если необходимо): Если в новой версии обнаружены проблемы после переключения, процесс переключения легко обращаем. Можно просто вернуть трафик обратно на синюю среду, пока проблемы не будут решены.

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

- Минимизация простоев: Пользователи практически не замечают перехода, поскольку смена активной среды происходит быстро и без прерывания сервиса.
- Обратимость изменений: Возможность быстрого отката к предыдущей версии приложения, если обнаружены проблемы.
- Тестирование в условиях, близких к боевым: Новая версия может быть протестирована в обстановке, максимально приближенной к реальной, без влияния на текущих пользователей.

### Недостатки

- Ресурсы: Требуется поддержание двух полноценных производственных сред, что увеличивает затраты на инфраструктуру.
- Сложность управления: Управление двумя средами и переключениями между ними может быть сложным процессом, требующим строгой координации.

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

## Что такое Canary (канареечные развертывания)?

Канареечные развертывания (Canary Deployments) — это метод постепенного развертывания обновлений программного обеспечения, который позволяет внедрять изменения с минимальным риском и воздействием на пользователей. Название происходит от старинной практики использования канареек в шахтах для выявления опасных условий: если канарейка умирала, это означало, что в шахте есть ядовитые газы, и шахтёры должны были эвакуироваться. В контексте ИТ, канареечные развертывания предполагают постепенное развертывание нового кода на небольшую часть серверов или пользователей, чтобы в случае проблем можно было минимизировать их воздействие и быстро откатить изменения.

Ниже описаны ключевые аспекты канареечных развертываний:

1. Пошаговое развертывание: Вместо того чтобы полностью развернуть новую версию приложения сразу на все серверы или для всех пользователей, новая версия сначала развертывается на малую долю инфраструктуры или для небольшой группы пользователей ("канареек").

2. Мониторинг и аналитика: На этапе "канареек" происходит тщательный мониторинг производительности, ошибок и других метрик новой версии. Это помогает быстро обнаружить и устранить возможные баги или проблемы с производительностью.

3. Постепенное увеличение доли: Если новая версия успешно работает на начальной группе серверов или пользователей, её развертывание постепенно расширяется на большее количество серверов или пользователей. Это продолжается до тех пор, пока новая версия полностью не заменит старую.

4. Быстрая реакция на проблемы: Если возникают проблемы, критические ошибки или снижение производительности, процесс развертывания можно приостановить или откатить до предыдущей стабильной версии, затронув минимальное количество пользователей.

5. Автоматизация: Канареечные развертывания часто автоматизируются с использованием инструментов оркестрации и мониторинга, таких как Kubernetes, Jenkins, Prometheus и других. Автоматизация позволяет более надежно и эффективно управлять процессом развертывания.

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

- Минимизация риска: Развертывание новой версии сначала на малой доле снижает риск глобальных перебоев в работе.
- Сбор реальных данных: Канареечные развертывания позволяют собирать данные о новой версии в реальных условиях эксплуатации, что помогает выявить проблемы, которые могут остаться незамеченными в тестовой среде.
- Плавное обновление: Постепенное внедрение изменений вызывает меньшее недовольство пользователей и делает обновление менее заметным для них.

### Недостатки

- Сложность конфигурации: Требуется сложная настройка инфраструктуры для управления различными версиями приложения и маршрутизации трафика между ними. 
- Ресурсы и время: Процесс мониторинга и постепенного развертывания может занимать больше времени и ресурсов по сравнению с другими методами.

Канареечные развертывания широко используются в крупномасштабных системах, облачных платформах и веб-приложениях, где стабильность и непрерывность работы критично важны. Этот метод помогает организациям внедрять новые функции и обновления с минимальным риском для пользователей.

## Что такое Dark (скрытые) или А/В-развертывания?

Скрытые развертывания (Dark Deployments) и А/В-развертывания (A/B Deployments) — это две разные стратегии развертывания программного обеспечения, каждая из которых преследует свои цели и имеет свои особенности.

### Dark Deployments (Скрытые развертывания)

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

Ключевые аспекты скрытых развертываний:

1. Параллельное развертывание: Новая версия или функция развертывается параллельно с действующей версией, но изменения остаются "выключенными" или недоступными для пользователей.

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

3. Минимизация риска: Поскольку изменения не видны пользователям, риски, связанные с потенциальными проблемами новой версии, минимальны.

4. Подготовка к включению: После того как скрытая версия протестирована и проверена, её можно "включить" для пользователей с минимальными задержками.

5. Использование фич-флагов: Часто реализуется с помощью механизмов фич-флагов (feature flags), которые позволяют включать и выключать функции по мере необходимости.

### A/B Deployments (А/В-развертывания)

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

Ключевые аспекты A/B-развертываний:

1. Паралельное развертывание: Две версии (например, старая версия A и новая версия B) одновременно развертываются в производственной среде для разных групп пользователей.

2. Сбор данных: Каждая группа пользователей видит только одну из версий, и собираются данные о взаимодействиях пользователей с каждой версией. Это позволяет оценить, какая версия обеспечивает лучшие результаты.

3. Целевые метрики: Может измеряться множество метрик, таких как скорость загрузки, коэффициент конверсии, пользовательская вовлеченность и удовлетворенность.

4. Принятие решений: На основе анализа собранных данных компании могут решить, какую версию сохранить или какие изменения внести для оптимизации пользовательского опыта.

5. Безопасность: А/В-развертывания позволяют проводить эксперименты в реальных условиях с минимальным риском, так как изменения тестируются только на части аудиторий.

### Сравнение и различия

- Цель: Скрытые развертывания направлены на тестирование системы без влияния на пользователей, тогда как A/B-развертывания нацелены на сравнительный анализ версий для оптимизации пользовательского опыта.
- Влияние на пользователей: В скрытых развертываниях влияния на пользователей нет до момента "включения" функции. В A/B-развертываниях разным пользователям одновременно доступны разные версии.
- Использование фич-флагов: Оба подхода могут использовать фич-флаги, но для разных целей — скрытые развертывания используют их для полного сокрытия функций, а A/B-развертывания могут использовать их для динамического переключения версий.

## Что такое SLA, SLO, SLI?

SLA (Service Level Agreement), SLO (Service Level Objective) и SLI (Service Level Indicator) — это ключевые концепции в управлении уровнем обслуживания информационных систем и сервисов, используемые для обеспечения и управления качеством предоставляемых услуг. Давайте разберем каждую из этих терминов более подробно:

### SLA (Service Level Agreement)
  
SLA — это соглашение об уровне обслуживания, представляющее собой формальный договор между поставщиком услуг и клиентом, определяющий ожидаемые уровни производительности и доступности услуг.

Ключевые особенности SLA:

1. Формализация: Документ содержит юридически обязывающие условия и часто является частью контрактов между клиентом и поставщиком услуг.
  
2. Элементы SLA:
   - Описание услуг: Определяет, какие именно услуги предоставляются.
   - Показатели производительности: Включает метрики, которые будут использоваться для измерения качества услуг (например, доступность, время отклика).
   - Уровни обслуживания: Определяет конкретные, измеримые цели для показателей производительности (например, 99.9% время доступности).
   - Обязанности и ответственность: Распределяет обязанности между клиентом и поставщиком услуг.
   - Ответные меры: Обозначает действия, которые будут предприняты в случае несоответствия уровня обслуживания установленным целям (например, штрафы или право на расторжение договора).

3. Цель: Основная цель SLA — установить четкие ожидания и обязательства обеих сторон, обеспечивая прозрачность и контроль уровня обслуживания.

### SLO (Service Level Objective)

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

Ключевые особенности SLO:

1. Определение целей: Конкретные и измеримые показатели, установленные для мониторинга и оценки уровня обслуживания.
  
2. Фокус на метрики: Каждое SLO связано с конкретной метрикой, как, например, среднее время отклика, пропускная способность, уровень доступности.

3. Временные рамки: SLO обычно определяются за определенный период времени, например, 99.9% времени доступности за месяц или год.

4. Важность SLO: SLO помогают руководству и командам, предоставляющим услуги, сосредоточиться на ключевых аспектах качества обслуживания и управлять ожиданиями клиентов.

### SLI (Service Level Indicator)

SLI — это показатель уровня обслуживания, представляющий собой конкретную метрику, используемую для измерения фактического уровня обслуживания.

Ключевые особенности SLI:

1. Измерение реальности: SLI — это фактические показатели, такие как среднее время отклика или процент успешных запросов, которые используются для оценки уровня обслуживания.

2. Подходы к измерению: SLIs часто собираются с помощью мониторинговых систем и аналитических инструментов, таких как метрики серверов, клиентские данные и журналы.

3. Выравнивание с SLO: SLI показывают, насколько текущие показатели соответствуют целям, определенных в SLO.

4. Пример SLI: Если SLO устанавливает цель 99.9% доступности в течение месяца, то SLI — это фактические данные о доступности за этот период, которые могут составлять, например, 99.7%.

### Связь между SLA, SLO и SLI

- SLA: Это общий договор, который включает в себя множество SLO.
- SLO: Является частью SLA и определяет конкретные цели качества обслуживания.
- SLI: Это фактические метрики, использованные для измерения достигнутого уровня обслуживания и оценки соответствия этим целям.

### Пример взаимодействия

Представьте, что вы подписали SLA с облачным провайдером. В вашем соглашении может быть указано следующее:

- SLA: Ваш договор гласит, что облачный провайдер обязуется обеспечивать доступность сервиса на уровне 99.9% времени в течение месяца. В случае нарушения обязательств провайдер уплачивает штраф или предоставляет вам определенные льготы.
  
- SLO: Внутри SLA указано, что целевым уровнем (SLO) является 99.9% доступности сервиса за месяц.

- SLI: В течение месяца команда мониторинга собирает данные о фактической доступности сервиса. На конец месяца SLI показывает, например, 99.85%, что означает небольшой недочет по сравнению с установленной целью.

В результате, SLA, SLO и SLI работают вместе, чтобы обеспечить управление и мониторинг уровня обслуживания, установленного между клиентами и поставщиками услуг, упрощая процесс контроля и поддержания качества предоставляемых услуг.

## Какие инструменты CI/CD вам известны?

### Jenkins

Описание: Jenkins – один из самых популярных инструментов для автоматизации CI/CD процессов.

- Возможности:
  - Поддержка множества плагинов для интеграции с различными системами.
  - Возможность параллельного выполнения задач.
  - Расширяемость через Groovy скрипты.
- Применение: Подходит для проектов любой сложности и на любых языках программирования.

### GitLab CI/CD

Описание: Интегрированный с GitLab репозиториями, предоставляет возможности CI/CD из коробки.

- Возможности:
  - Поддержка контейнеров и Kubernetes.
  - Продвинутая система управления доступом и конфигурации.
  - Встроенная поддержка пайплайнов на основе YAML.
- Применение: Идеален для проектов, размещенных в GitLab.

### CircleCI

Описание: Инструмент для CI/CD, который концентрируется на легкости использования и масштабируемости.

- Возможности:
  - Интеграция с GitHub и Bitbucket.
  - Поддержка контейнеров Docker и конфигурируемых пайплайнов.
  - Быстрая настройка и высокое время безотказной работы.
- Применение: Хорош для стартапов и компаний, уже использующих облачные системы управления исходным кодом.

### Travis CI

Описание: Облачный CI/CD сервис, популярный среди проектов с открытым исходным кодом.

- Возможности:
  - Простая конфигурация через .travis.yml.
  - Бесшовная интеграция с GitHub.
  - Поддержка различных языков программирования.
- Применение: Подходит для небольших команд и проектов с открытым исходным кодом.

### Bamboo

Описание: Коммерческий инструмент CI/CD от Atlassian, разработчика Jira.

- Возможности:
  - Тесная интеграция с другими продуктами Atlassian (Jira, Bitbucket).
  - Поддержка непрерывного тестирования и деплоя.
  - Интеграция с Docker и AWS.
- Применение: Подходит для компаний, уже использующих экосистему Atlassian.

### TeamCity

Описание: Инструмент CI/CD от JetBrains, известного своими IDE.

- Возможности:
  - Интеллектуальные управляемые пайплайны.
  - Поддержка множества языков программирования и систем сборки.
  - Широкие возможности для параллельных сборок.
- Применение: Для команд, предпочитающих высоко настроенные, гибкие и мощные решения.

### GitHub Actions

Описание: Интегрированная система CI/CD, предлагающая автоматизацию прямо в GitHub.

- Возможности:
  - Конфигурация через YAML файлы.
  - Управление событиями, происходящими в репозитории (push, pull request, issue).
  - Безупречная интеграция с экосистемой GitHub.
- Применение: Идеально для разработки, полностью размещенной в GitHub.

### AWS CodePipeline

Описание: CI/CD сервис от Amazon, полностью интегрированный с AWS.

- Возможности:
  - Управление пайплайнами через AWS Management Console.
  - Интеграция с другими сервисами AWS (S3, CodeDeploy, ECS).
  - Автоматизация всего жизненного цикла разработки.
- Применение: Для проектов, полностью размещенных и работающих в AWS.

### Azure DevOps

Описание: Набор инструментов от Microsoft для управления всей цепочкой поставки ПО.

- Возможности:
  - Глубокая интеграция с Azure.
  - Поддержка множественных языков и фреймворков.
  - Удобная система управления пайплайнами через YAML.
- Применение: Для разработки и деплоя в Azure.

### Google Cloud Build

Описание: CI/CD сервис от Google, частью Google Cloud Platform.

- Возможности:
  - Поддержка пошаговых сборок через конфигурационные файлы.
  - Полная интеграция с GCP сервисами.
  - Мощные инструменты аналитики и мониторинга.
- Применение: Для компаний, использующих инфраструктуру GCP.

### Argo CD

Описание: Современный инструмент CD, специализированный для Kubernetes.

- Возможности:
  - Поддержка GitOps подхода.
  - Управление Kubernetes приложениями посредством Git репозиториев.
  - Мониторинг состояния приложений в реальном времени.
- Применение: Для организаций, активно использующих Kubernetes для деплоя.

### Tekton

Описание: Открытый фреймворк для создания CI/CD систем на Kubernetes.

- Возможности:
  - Модульная архитектура.
  - Возможность создания сложных пайплайнов.
  - Интеграция с Kubernetes и Red Hat OpenShift.
- Применение: Для разработки и развертывания Kubernetes-native приложений.

## Как обеспечить непрерывность и стабильность деплоя приложения?

### Автоматизация процессов

- CI/CD (Continuous Integration/Continuous Deployment): Настройка и использование CI/CD инструментов, таких как Jenkins, GitLab CI, CircleCI, или GitHub Actions, позволяет автоматически тестировать и деплоить изменения в приложении.
- Инфраструктура как код (IaC): Использование инструментов для автоматизации инфраструктуры, таких как Terraform, Ansible или CloudFormation, позволяет управлять конфигурацией серверов и других ресурсов повторяемо и детерминированно.

### Контроль версий кода

- Использование систем контроля версий: Репозиторий кода должен быть организован так, чтобы изменения легко отслеживались и восстанавливались. Для этого подходят системы контроля версий, такие как Git.
- Code Reviews: Обязательные ревью кода обеспечивают качество изменений и уменьшают вероятность багов.

### Тестирование

- Юнит-тесты и интеграционные тесты: Регулярное написание и выполнение тестов позволяет выявлять проблемы на ранних стадиях разработки.
- Автоматизированные тесты: Настройка автоматического выполнения тестов при любом изменении кода помогает поддерживать стабильность приложения.

### Мониторинг и логирование

- Мониторинг производительности: Использование инструментов мониторинга, таких как Prometheus, Grafana или New Relic, помогает следить за состоянием приложения в реальном времени.
- Centralized Logging: Инструменты типа ELK Stack (Elasticsearch, Logstash, Kibana) или Splunk позволяют централизованно управлять логами и быстро находить ошибки.

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

- Canary Releases: Внедрение изменений только на небольшой части серверов или пользователей для проверки стабильности.
- Blue-Green Deployment: Создание двух идентичных сред (синей и зеленой) и переключение трафика между ними для минимизации простоя.
- Rolling Updates: Пошаговое обновление сервера, чтобы избежать одновременного выключения всех экземпляров приложения.

### Резервное копирование и восстановление

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

### Документация и обучение команды

- Техническая документация: Подробное описание автоматизированных процессов, конфигураций инфраструктуры и стратегий деплоя.
- Обучение команды: Регулярное обучение сотрудников новейшим практикам и инструментам повышает общую компетенцию команды.

## С какими проблемами при деплое продукта вы сталкивались, как митигировали?

### Проблемы совместимости

Иногда код, который отлично работает в локальной среде, может не поддерживаться на сервере продакшн. Это может быть вызвано разной версией ОС, различных библиотек или зависимостей.

Митигирование:

- Контейнеризация: Использование Docker для создание изолированных и предсказуемых окружений.
- CI/CD: Настройка непрерывной интеграции и развертывания для автоматического тестирования и размещения кода в условиях, максимально схожих с продом.

### Неоптимизированный код или инфраструктура

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

Митигирование:

- Профилирование и оптимизация: Использование инструментов профилирования для выявления узких мест в коде и оптимизации производительности.
- Скалируемая инфраструктура: Настройка масштабируемой инфраструктуры (например, использование Kubernetes для оркестрации контейнера).

### Кэширование и конфликты конфигураций

Конфликтующие переменные окружения или сохранённые данные в кэше могут вызвать неожиданные ошибки.

Митигирование:

- Чистка кэша: Регулярная очистка кэша и модернизация стратегий управления кэшем.
- Четкая конфигурация: Использование инструментов для управления конфигурациями.

### Проблемы безопасности

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

Митигирование:

- Penetration Testing: Регулярное проведение тестов на проникновение для выявления и закрытия уязвимостей.
- Безопасное кэширование и управление секретами: Использование хранилищ секретов и шифрования данных.