56 lines
8.0 KiB
Markdown
56 lines
8.0 KiB
Markdown
# Технический стек отдела
|
||
|
||
Опорный документ для ответа на вопрос «расскажите про стек отдела» — по образцу чужой легенды (список стека + короткий аргумент, почему каждый инструмент здесь). В отличие от [LEGEND.md](LEGEND.md), где технология привязана к личной строке резюме, этот файл описывает **окружение целиком**, как его увидел бы инженер отдела — включая инструменты, с которыми не работал напрямую, но которые логично стоят рядом (см. [LEGEND.md](LEGEND.md) → «Инструменты отдела без личной строки в резюме»). Правило на такие инструменты то же, что в примере легенды: минимум 2-3 предложения по каждому, без «мы с этим не работали».
|
||
|
||
## Язык бэкенда
|
||
|
||
- **Java** — сопровождаемые сервисы внутреннего контура (детали продукта закрыты режимом, см. [STORY.md](STORY.md) → «Проект отдела»). Работа с этим слоем — эксплуатация и диагностика (логи, стектрейсы, health-эндпоинты), не разработка.
|
||
|
||
## ОС
|
||
|
||
- **Astra Linux SE** — основная серверная ОС парка отдела: сертифицированный дистрибутив для контуров с гособоронзаказом, естественный выбор для режимного предприятия.
|
||
- **Debian** — DEV-песочница для обкатки конфигов и ролей перед прод-контуром на Astra: логично, потому что Astra построена на базе Debian, и навыки/пакеты в основном переносимы 1:1.
|
||
|
||
## Серверы и балансировка
|
||
|
||
- **Nginx** — маршрутизация и балансировка нагрузки перед сервисами и компонентами мониторинга (кейс — балансировка x3 Mimir round-robin, см. [STORY.md](STORY.md)).
|
||
- **Kubernetes** — в рабочем стеке отдела нет (закрытый статичный парк VM не требует оркестрации, IaC-слой закрыт Ansible). Личный опыт с K8s — честный pet-кластер, см. [LEGEND.md](LEGEND.md) → «Домашняя лаборатория» и [../stack/kubernetes/CASE.md](../stack/kubernetes/CASE.md).
|
||
|
||
## Хранилище и артефакты
|
||
|
||
- **MinIO** — S3-совместимое объектное хранилище, служит бэкендом для блоков Mimir (Mimir архитектурно требует объектное хранилище под долгосрочные данные метрик — без него горизонтальное масштабирование не работает). Настраивали и администрировали в связке с админами, я — потребитель как часть стека мониторинга.
|
||
- **Nexus** — внутренний менеджер артефактов/бинарей в закрытом контуре без выхода вовне: то же хранилище, откуда я брал архив бинаря Node Exporter при установке (см. [STORY.md](STORY.md) → «Простая задача»).
|
||
|
||
## Контроль версий
|
||
|
||
- **Git** — система контроля версий.
|
||
- **Gitea** — внутренний git-хостинг: репозитории Ansible-ролей, конфигов, JSON дашбордов Grafana; встроенная **Wiki** — инструкции и постмортемы (см. [STORY.md](STORY.md)).
|
||
|
||
## Мониторинг
|
||
|
||
- **Grafana** — визуализация метрик, дашборды (50 в резюме).
|
||
- **Prometheus** — сбор метрик по pull-модели.
|
||
- **Mimir** — горизонтально масштабируемое хранилище метрик поверх Prometheus (remote_write), решение проблемы производительности одной федерации.
|
||
- **Alertmanager** — маршрутизация и группировка алертов из Prometheus (куда идут уведомления, кто дежурит) — часть связки, встроен в архитектуру, отдельно не настраивал с нуля, но понимаю, зачем он между Prometheus и получателем алерта.
|
||
- **Node Exporter** — метрики хоста (CPU/RAM/диск) — личный кейс установки, см. [STORY.md](STORY.md).
|
||
- **Blackbox Exporter** — проверка доступности эндпоинтов (HTTP/TCP/ICMP), в частности контроль сроков TLS-сертификатов.
|
||
- **Nginx Exporter** — метрики самого Nginx как балансировщика.
|
||
- **Process Exporter** — метрики отдельных процессов на VM.
|
||
- **Postgres Exporter** — метрики состояния БД, которые ведут разработчики/администраторы БД; я — потребитель метрик со стороны мониторинга, не администратор самой БД (администрирование PostgreSQL — честный pet, см. [../stack/databases/CASE.md](../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 выше.
|