Как проходит рабочий день на последнем месте работы

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

Утро (с 9:00 до 10:30):

1. Первым делом — проверка дашбордов в Grafana (состояние кластера Kubernetes, метрики приложений) и алертов в PagerDuty. Если ночью были инциденты — изучаю логи в Loki и трассировку в Jaeger, чтобы понять root cause.
2. Daily stand-up (10:00) — 15-минутный созвон с командой разработки и QA. Я кратко докладываю о состоянии инфраструктуры, планируемых деплоях и обсуждаю блокеры, связанные с окружениями.

Основная работа (до 17:00):

• Автоматизация и инфраструктура как код: Пишу или обновляю конфигурации Terraform для AWS (VPC, RDS, S3) и Helm-чарты для деплоя микросервисов. Например, на прошлой неделе я автоматизировал создание staging-окружения для новой команды:

  # terraform/modules/eks/main.tf
  module "eks" {
    source = "terraform-aws-modules/eks/aws"
    cluster_name = "staging-${var.team_name}"
    ...
  }

• CI/CD пайплайны: Работаю над улучшением GitLab CI пайплайнов — добавляю этапы security scanning (Trivy для образов, Checkov для Terraform), оптимизирую кэширование, чтобы сборка из 15 минут укладывалась в 7.
• Инженерная работа: Расследование инцидентов. Был случай, когда поды в Kubernetes теряли связь с БД из-за проблем с Calico CNI. Пришлось анализировать kubectl describe pod, логи CNI-плагина и настраивать Network Policies.
• Планирование и документация: Участие в планировании спринта, где мы оцениваем инфраструктурные задачи (например, миграция на новую версию Istio). Обновляю runbooks в Confluence — четкие инструкции по реагированию на частые инциденты.

Вечер (после 17:00):

• Код-ревью инфраструктурных PR от коллег.
• Обучение: Выделяю время на изучение новых инструментов. Сейчас разбираюсь с ArgoCD для GitOps, чтобы уйти от ручных kubectl apply.
• On-call ротация: Раз в три недели я в on-call смене. В это время всегда на связи, готовый реагировать на критичные алерты (например, SLO по доступности сервиса упал ниже 99.9%).

График гибкий, но основное правило — изменения в production не вносим после 16:00 в пятницу.