Ответ
На моей предыдущей позиции DevOps-инженера в продуктовой компании были следующие сильные и слабые стороны:
Плюсы:
- Автоматизация процессов: Удалось внедрить полноценный CI/CD пайплайн на GitLab CI, что сократило время развертывания с нескольких часов до 15-20 минут.
- Инфраструктура как код: Перевели всю инфраструктуру в AWS на Terraform, что позволило легко создавать идентичные staging-окружения для тестирования.
- Культура метрик: Внедрили стек мониторинга на основе Prometheus, Grafana и Alertmanager, что дало прозрачность по здоровью сервисов.
- Тесная работа с разработкой: Регулярные совместные инцидент-ретро и работа над улучшением Docker-образов приложений.
Минусы:
- Legacy-системы: Часть сервисов все еще работала на физических серверах с ручным деплоем через bash-скрипты, что создавало «долг» и риски.
- Фрагментированная документация: Конфигурации и процессы часто описывались в разных wiki-системах и даже личных заметках, что замедляло онбординг новых членов команды.
- Бюджетные ограничения: Пришлось обходиться open-source решением для логов (ELK stack вместо коммерческого Splunk), что требовало больше времени на поддержку и тонкую настройку.
Пример одного из таких legacy-скриптов, который мы в итоге переписали на Ansible:
#!/bin/bash
# Скрипт для деплоя на прод. Нет idempotency, хардкод, слабая обработка ошибок.
scp /build/app.jar user@prod-server-01:/opt/app/
ssh user@prod-server-01 "systemctl restart myapp"
# А что если сервер prod-server-02? А если копия не удалась?