С чем не хочешь работать на новом проекте

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

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

Вот ключевые анти-паттерны и ситуации, с которыми я не хотел бы работать на новом проекте:

1. С полным отрицанием инженерной культуры и автоматизации

Это основа основ. Я не вижу себя в среде, где:

• "Ручные" продакшн-деплои через RDP/SSH считаются нормой. Это не только риск, но и прямая дорога к "синдрому единственного хранителя" (Bus Factor = 1).
• Инфраструктура как код (IaC) воспринимается как "лишняя сложность", а не как обязательный стандарт. Желание нарисовать диаграмму в Visio, а затем вручную накликивать 50 серверов — это антипаттерн 2010-х годов.
• Конфигурационный дрифт считается приемлемым. Если состояние сервера — это загадка, которую можно решить только личным вмешательством, система неуправляема.

# Пример "сценария кошмара" - деплой руками
$ scp build.tar.gz user@prod-server-01:/tmp/
$ ssh user@prod-server-01 "tar -xzf /tmp/build.tar.gz -C /var/www && sudo systemctl restart nginx"
# А теперь повторить это для prod-server-02...prod-server-20, молясь, чтобы нигде не было отличий.

Так работать нельзя. Современная альтернатива — это pipeline в GitLab CI/CD / GitHub Actions / ArgoCD, разворачивающий приложение через Terraform / Ansible и Helm / Kubernetes manifests.

2. С токсичным отношением к ответственности и "культуре блейминга"

DevOps — это прежде всего культура совместной ответственности за весь жизненный цикл приложения. Я буду крайне насторожен, если:

• Существует жесткий, непроницаемый барьер между "разработчиками" и "админами", где первые "сваливают" код, а вторые "тушат пожары".
• Постмортемы (Post-Mortem / Blameless Retrospective) превращаются в поиск виноватого, а не в анализ системных причин сбоя. Фразы "чья это была очередь деплоить?" или "это Петя сломал прод" — красный флаг.
• Нет понятия Service Level Objectives (SLO) и Error Budgets. Вместо этого есть только максималистское и невыполнимое требование "100% аптайма", ведущее к страху вносить любые изменения.

3. С архаичной, "монолитной" и непрозрачной инфраструктурой без плана эволюции

Я готов работать с legacy, но только если есть четкое понимание и дорожная карта по его модернизации. Тревогу вызовет:

• Критическая бизнес-логика в виде "черного ящика" на физических серверах или старых гипервизорах без документации, возможности контейнеризации или хотя бы эффективного мониторинга.
• Отказ от облачных или cloud-native практик (даже в рамках приватного облака) по идеологическим, а не техническим или экономическим причинам ("мы всегда так делали").
• Отсутствие централизованного логирования, мониторинга и алертинга (стек типа ELK / Loki + Prometheus + Grafana). Когда для расследования инцидента нужно собирать данные с десятков машин вручную — это потеря времени и нервов.

4. С полным игнорированием безопасности (Security)

DevSecOps — не просто модное слово. Я не могу эффективно работать, если:

• Secrets management строится на .env-файлах в репозиториях или, что хуже, на жестко зашитых паролях в коде.
• Нет практик статического (SAST) и динамического (DAST) анализа кода на уязвимости в пайплайне.
• Обновления безопасности для ОС и зависимостей не встроены в процесс, а выполняются "когда будет время".
• Доступы к продакшену не разделены по принципу наименьших привилегий, а есть один "супер-пароль на всех".

# ПЛОХО: секрет в открытом виде в манифесте (даже пример так делать нельзя!)
apiVersion: v1
kind: Secret
metadata:
  name: terrible-secret
data:
  password: cm9vdDpzZWNyZXRQYXNzd29yZCAgICAgICMgУжас!

5. С хроническим "технологическим долгом" и отсутствием инженерного тайм-бокса

Понимаю, что бизнес-задачи в приоритете. Но если никогда нет времени на улучшение платформы, это путь в пропасть. Отказ от:

• Выделения, например, 20% времени на tech debt reduction, документирование, автоматизацию рутины.
• Планомерного обновления версий ключевого ПО (Kubernetes, базы данных, инструменты CI/CD).

Заключение

Я не требую идеального greenfield-проекта на последнем стеке. Готов работать со сложным legacy, учиться новому и вносить изменения. Однако мой опыт показывает, что успех DevOps-трансформации на 80% зависит от культуры, процессов и здравого смысла, и только на 20% — от конкретных инструментов. Поэтому я ищу проекты, где есть осознание этих принципов и воля к их постепенному внедрению, даже если сегодня не все идеально. Работа же в условиях, где эти основы отрицаются, ведет к профессиональному выгоранию и не приносит реальной ценности бизнесу.