resume/legend/PROFILES.md

Профили позиционирования: три резюме, одна легенда

Резюме теперь три — ../RESUME.md (мониторинг), ../RESUME_DEVOPS.md (DevOps), ../RESUME_SYSADMIN.md (системное администрирование). Причина разделения: одно резюме, заточенное под мониторинг, снижало проходимость на скрининге по двум другим направлениям — конкретное название желаемой должности и релевантная подача первых пунктов сильно влияют на отклик (см. ../RESUME_RULES.md → «Точное название желаемой должности»).

Главное правило: факты одни на все три профиля, различаются только акценты. Компании, даты, должности в блоках опыта, цифры (50 дашбордов, 15 Ansible-скриптов), образование — идентичны во всех трёх файлах. LEGEND.md остаётся единственным источником истины о том, где и зачем применялась каждая технология; этот файл — только надстройка про то, как расставлять акценты и вести себя на собеседовании в зависимости от того, с какого резюме пришёл отклик. HR одной компании технически может увидеть все три резюме соискателя на hh.ru — противоречий в фактах между ними быть не должно, иначе это разрушает доверие мгновенно.

Как определить, какой профиль держать

Перед звонком/собеседованием смотреть, на какую вакансию и через какое резюме был отклик — это определяет, какой профиль ниже держать в разговоре. Если непонятно (рекрутёр не уточнил) — по умолчанию профиль «Мониторинг», как основной и наиболее проработанный.

Профиль 1 — Мониторинг

Резюме: ../RESUME.md, должность «Инженер по сопровождению».

Питч на 30 секунд: «4 года 5 месяцев в инфраструктуре и эксплуатации, последние почти 3 года — инженер по сопровождению в АО ТНИИС, где мониторинг был основной зоной ответственности: настроил и веду 50 дашбордов Grafana, интегрировал Prometheus, внедрил Mimir для горизонтального масштабирования хранения метрик. Автоматизацию вокруг мониторинга и деплоя закрываю Ansible и Docker».

Что вести первым: связка Grafana + Prometheus + Mimir, кейс с балансировкой Nginx под 3 инстанса Mimir (STORY.md → «Сложная задача»), разбор инцидента по стандартной формуле (STORY.md → «Как решается инцидент»), версионирование дашбордов через Gitea + TeamCity.

Что держать фоном: Ansible/Docker — упоминать как инструменты, обслуживающие мониторинг, не выводить в центр рассказа.

Pet-кейсы под руку: stack/monitoring уже покрыт основным опытом; из pet — не требуется, разве что Kafka, если спросят про очереди/потоковую передачу метрик.

Уже полностью покрыто действующими документами — этот профиль не новый, все stack/monitoring/QUESTIONS.md и текущая структура резюме уже заточены под него.

Профиль 2 — DevOps

Резюме: ../RESUME_DEVOPS.md, должность «DevOps-инженер».

Питч на 30 секунд: «4 года 5 месяцев в эксплуатации и автоматизации инфраструктуры. В АО ТНИИС автоматизировал конфигурирование и деплой через Ansible (15 ролей, тестирование через Molecule, раскатка через TeamCity), контейнеризировал сервисы в Docker, администрирую self-hosted CI на Gitea Actions — включая кастомный cross-builder под ARM для другого проекта отдела. Мониторинг (Grafana/Prometheus/Mimir) веду как часть той же инфраструктуры. Дополнительно дома поднял Kubernetes-кластер и прошёл его вживую по компонентам — в проде на текущем месте оркестрации не было (закрытый статичный парк VM), хочется расти в эту сторону».

Что вести первым: Ansible-автоматизация (роли/плейбуки/Molecule/TeamCity), Docker (multi-stage build, сети, диагностика — stack/docker/CASE.md), реальный кейс с Gitea CI-раннерами (restart-loop, cross-builder, маршрутизация по меткам — stack/docker/CASE.md → раздел 9), pet Kubernetes (stack/kubernetes/CASE.md).

Что держать фоном: Grafana-дашборды — упоминать как результат, не углубляться так же подробно, как в профиле «Мониторинг».

Типовой риск направления и честный ответ: «Kubernetes в проде?» → прямо и честно, по формуле из LEGEND.md → «Домашняя лаборатория»: «В рабочем стеке этого не было — закрытый статичный парк VM, оркестрация была не нужна, весь IaC-слой закрывал Ansible. Мне стало интересно, поэтому поднял себе дома кластер (kind, 1 control-plane + 2 worker) и прошёл его от установки до собственного Helm-чарта — могу подробно рассказать про Pod/Deployment/Service/Ingress и что видел вживую». Не выдавать pet-практику за продовый опыт.

Pet-кейсы под руку: stack/kubernetes/CASE.md, stack/vault/CASE.md (если спросят про секреты — ansible-vault в проде, Vault — pet), stack/kafka/CASE.md.

Профиль 3 — Системное администрирование

Резюме: ../RESUME_SYSADMIN.md, должность «Системный администратор».

Питч на 30 секунд: «4 года 5 месяцев в эксплуатации серверной инфраструктуры. В АО ТНИИС сопровождаю парк серверов на Astra Linux — диагностика через логи и консоль, Nginx для маршрутизации и балансировки нагрузки, централизованный сбор логов через ELK, автоматизация рутинных операций через Ansible-роли и Bash. До этого в ОКБ СУХОЙ разворачивал и сопровождал тестовые стенды на CentOS. Образование — «Инфокоммуникационные технологии и системы связи», профильное для сетевой и серверной части».

Что вести первым: администрирование Astra Linux/CentOS (сервисы, логи, systemd — формула диагностики из STORY.md → «Как решается инцидент», шаги 4-5 про systemctl status/journalctl), Nginx как балансировщик, автоматизация через Ansible/Bash, сетевая диагностика (dig/traceroute/curl/ss — stack/networking/CASE.md).

Что держать фоном: Grafana/Prometheus — упоминать как инструмент диагностики администратора («смотрю на дашборд, вижу аномалию, иду разбираться»), не как отдельную специализацию.

Типовой риск направления и честный ответ: «Опыт с сетевым железом — коммутаторы, VLAN, маршрутизаторы?» → честно: «Железных сетей (коммутаторы, VLAN на оборудовании) в опыте нет — весь опыт на уровне Linux-серверов: балансировка и маршрутизация через Nginx, диагностика сети (DNS-резолвинг, TCP/IP, HTTP/TLS-хендшейк, traceroute/ss/curl -v) systematизирована отдельно как домашняя практика поверх повседневного администрирования серверов». Не пытаться выдать это за опыт сетевого инженера с железом — это прямой путь к провалу на первом же уточняющем вопросе.

Pet-кейсы под руку: stack/networking/CASE.md (основной для этого профиля), stack/databases/CASE.md (PostgreSQL — если спросят про администрирование БД сверх роли потребителя метрик из Postgres Exporter, см. DEPT_STACK.md).

Общее для всех трёх профилей

• Причина ухода, распорядок дня, состав отдела, разбор инцидента — общий нарратив из STORY.md, не меняется между профилями.
• Цифры нагрузки — только по правилам CAPACITY.md, независимо от того, какое резюме привело к диалогу.
• Если на собеседовании всплывает факт из другого профиля (например, интервьюер по DevOps-вакансии спрашивает про сетевую диагностику) — отвечать честно из общей легенды, профили не создают барьеров в знаниях, только определяют, что рассказывать первым по умолчанию.