resume/legend/DEPT_STACK.md

Технический стек отдела

Опорный документ для ответа на вопрос «расскажите про стек отдела» — по образцу чужой легенды (список стека + короткий аргумент, почему каждый инструмент здесь). В отличие от LEGEND.md, где технология привязана к личной строке резюме, этот файл описывает окружение целиком, как его увидел бы инженер отдела — включая инструменты, с которыми не работал напрямую, но которые логично стоят рядом (см. LEGEND.md → «Инструменты отдела без личной строки в резюме»). Правило на такие инструменты то же, что в примере легенды: минимум 2-3 предложения по каждому, без «мы с этим не работали».

Язык бэкенда

• Java — сопровождаемые сервисы внутреннего контура (детали продукта закрыты режимом, см. STORY.md → «Проект отдела»). Работа с этим слоем — эксплуатация и диагностика (логи, стектрейсы, health-эндпоинты), не разработка.

ОС

• Astra Linux SE — основная серверная ОС парка отдела: сертифицированный дистрибутив для контуров с гособоронзаказом, естественный выбор для режимного предприятия.
• Debian — DEV-песочница для обкатки конфигов и ролей перед прод-контуром на Astra: логично, потому что Astra построена на базе Debian, и навыки/пакеты в основном переносимы 1:1.

Серверы и балансировка

• Nginx — маршрутизация и балансировка нагрузки перед сервисами и компонентами мониторинга (кейс — балансировка x3 Mimir round-robin, см. STORY.md).
• Kubernetes — в рабочем стеке отдела нет (закрытый статичный парк VM не требует оркестрации, IaC-слой закрыт Ansible). Личный опыт с K8s — честный pet-кластер, см. LEGEND.md → «Домашняя лаборатория» и ../stack/kubernetes/CASE.md.

Хранилище и артефакты

• MinIO — S3-совместимое объектное хранилище, служит бэкендом для блоков Mimir (Mimir архитектурно требует объектное хранилище под долгосрочные данные метрик — без него горизонтальное масштабирование не работает). Настраивали и администрировали в связке с админами, я — потребитель как часть стека мониторинга.
• Nexus — внутренний менеджер артефактов/бинарей в закрытом контуре без выхода вовне: то же хранилище, откуда я брал архив бинаря Node Exporter при установке (см. STORY.md → «Простая задача»).

Контроль версий

• Git — система контроля версий.
• Gitea — внутренний git-хостинг: репозитории Ansible-ролей, конфигов, JSON дашбордов Grafana; встроенная Wiki — инструкции и постмортемы (см. STORY.md).

Мониторинг

• Grafana — визуализация метрик, дашборды (50 в резюме).
• Prometheus — сбор метрик по pull-модели.
• Mimir — горизонтально масштабируемое хранилище метрик поверх Prometheus (remote_write), решение проблемы производительности одной федерации.
• Alertmanager — маршрутизация и группировка алертов из Prometheus (куда идут уведомления, кто дежурит) — часть связки, встроен в архитектуру, отдельно не настраивал с нуля, но понимаю, зачем он между Prometheus и получателем алерта.
• Node Exporter — метрики хоста (CPU/RAM/диск) — личный кейс установки, см. STORY.md.
• Blackbox Exporter — проверка доступности эндпоинтов (HTTP/TCP/ICMP), в частности контроль сроков TLS-сертификатов.
• Nginx Exporter — метрики самого Nginx как балансировщика.
• Process Exporter — метрики отдельных процессов на VM.
• Postgres Exporter — метрики состояния БД, которые ведут разработчики/администраторы БД; я — потребитель метрик со стороны мониторинга, не администратор самой БД (администрирование PostgreSQL — честный pet, см. ../stack/databases/CASE.md).

Логи

• Elastic Stack (ELK) — Elasticsearch (хранение/поиск), Logstash (обработка/парсинг), Kibana (дашборды и разбор логов при инциденте), Filebeat — лёгкий агент, доставляющий логи Java-сервисов с VM в Elasticsearch.

CI/CD и автоматизация

• TeamCity + Molecule — CI-конвейер тестирования Ansible-ролей и раскатки конфигов/дашбордов.
• Ansible — управление конфигурацией: роли и плейбуки на установку/настройку серверов и сервисов.
• Docker — контейнеризация сервисов мониторинга и вспомогательных инструментов.
• Terraform — в рабочем стеке отдела нет: инфраструктура статична (фиксированный парк VM без облачного API для программного провижининга), поэтому весь IaC-слой закрыт конфигурационным управлением через Ansible, отдельный инструмент под провижининг не требовался.
• Bash — повседневная автоматизация и обвязка вокруг Ansible/Docker.

Как этим пользоваться на собеседовании

Если спрашивают конкретно про MinIO/Nexus/Alertmanager/Postgres Exporter/Filebeat — ответ по формуле: «для чего инструмент нужен в нашей связке» + «кто именно его настраивал» + «как я с ним соприкасался» (правил конфиг / читал метрики / знаю архитектурную роль). Не выдавать это за уровень «настраивал с нуля самостоятельно», но и не говорить «не работал» — честная middle-позиция, как и с Terraform/Kubernetes выше.