DevOps и инфраструктура

На этапе проектирования архитектуры продукта DevOps-инженер подключается и участвует в продумывании инфраструктуры под необходимости компании.
Код на окружениях работает за счет конвейеров CI/CD. DevOps-инженеры выстраивают такие конвейеры, используя специализированные инструменты и подходы – Azure DevOps Server, Gitlab CI, BitBucket, Jenkins, Github Actions и др.

Для старта разработки DevOps-инженеры создают «обвязку» решения:

1. Базы данных (MSSQL/PgSQL/Scylla/Cassandra)
2. Очереди/шины данных (RabbitMQ/Kafka)
3. Отказоустойчивые кэши (Redis/Hazelcast)
4. Балансировщики (HaProxy/Nginx)
5. Хранилище секретов (Vault/LockBox)
6. Хранилище BLOB (MongoDB/Minio/S3)
7. Провайдеры авторизации (ADFS/Keycloak/WSO2)
8. Логирование (ELK/Splunk)
9. Мониторинги (Zabbix/Prometheus/VictoriaMetriks/Grafana)

Разворачивается обвязка либо вручную, либо через конфигураторы, такие, как Ansible, ArgoCD, Terraform.

Во время выкладки кода DevOps-инженеры проверяют код на соответствие Best Practices и Cloud Native требованиям.
Примеры наших Best Practices:

1. корректная работа команды разработки с ветками по TBD
2. проверка, где и каким образом хранятся ключи, сертификаты, конфиги
3. проверка кода на безопасность
4. наличие мониторинга/алертинга
   И многие другие проверки

Перед выводом в промышленную эксплуатацию настраиваем мониторинги и алертинги.

1. Системный. Это мониторинг, который отслеживает работоспособность инфраструктуры на уровне виртуальных машин и сервисов.
2. Технический. Это инфраструктурные метрики продукта внутри кластера – как и метрики самого кластера, так и отдельно продукта.
3. Технологический. В этом случае мы отслеживаем процессы и сервисы. По сути, это выполнение разработанной системой SLA по его продуктовым метрикам. 
Для примера – время выполнения запросов.
4. Бизнесовый. Это KPI, т.е. главная панель, которую активно смотрит бизнес-заказчик.

Мы внедрили и провели первоначальную настройку, теперь наступает момент тонкого тюнинга и шлифовки. Инженеры подключаются к следующим видам работ:

• Траблшутинг – поиск и устранение неявных ошибок и неточностей.

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

• Дополнительные требования со стороны заказчика - подключаются специалисты на стороне заказчика и формируют дополнительные требования. Перед стартом эксплуатации продукта мы дополнительно фокусируемся на безопасности – например, заворачиваем трафик на Web Application Firewall (WAF), настраиваем лимиты на ресурсы и подключения.

• Дежурства. В случае возникновения проблем срабатывает алертинг и приходит звонок на телефон дежурного инженера. В зависимости от сложности проблемы разбираются сами или подключаются инженеры заказчика и наша команда разработки.

• Обработка обращений и инцидентов. С вопросами, просьбами и проблемами по конвейерам, окружениям и всем остальным обращаются к DevOps-инженерам.

Также DevOps-инженеры занимаются сопровождением инфраструктуры для разработки. Среди них:

1. Кластера Kubernetes
2. Системы CI/CD - Azure DevOps Server, Gitlab CI
3. Blob storage - Minio, MongoDB
4. Базы данных – PgSQL, MSSQL
5. Системы информационной безопасности - SonarQube, Dependency Track, GitLeaks
6. Раннеры для сборки как для Linux, так и для Windows
7. Системы мониторинга – Grafana, Prometheus, VictoriaMetrics, Zabbix
8. Системы авторизации – ADFS, KeyCloak, WSO2
9. Очереди, Кэши

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

В зависимости от задачи это может быть оценка того:

1. как устанавливается и как обновляется,
2. чем обеспечивается консистентность данных,
3. надежность,
4. производительность системы,
5. какие есть способы переключения,
6. каким образом влияет таймаут переключение,
7. какие ошибки выдаются и как решение их обрабатывает,
8. как ведутся и как должны вестись операции по обслуживанию инфраструктуры и кластера, к примеру, перестраивание индексов либо отключение/подключение новой ноды.

Создать решение – одно дело. Другое – сделать его отказоустойчивым и всегда иметь «план Б» восстановления на случай критических ситуаций.

Disaster and recovery plan – это отработанная и протестированная процедура, нацеленная на восстановление работоспособности решения с нуля в четкие целевые сроки (кусочек SLA по предоставлению сервиса). В зависимости от требований DRP может включать в себя различные инструменты, обучение и тренировку специалистов заказчика, регулярные автоматические или ручные процедуры и т.д.

Если у вас уже есть инфраструктура, но вы сомневаетесь в уровне безопасности, современности кода или просто хотите сделать всю инфраструктуру единообразной и стандартизованной, то мы поможем навести порядок в соответствии с best practices.

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

Поддержка комплекса продуктов на приватных или публичных сервисах, как Yandex Cloud и SberCloud.