58 lines
12 KiB
Markdown
58 lines
12 KiB
Markdown
# Профили позиционирования: три резюме, одна легенда
|
||
|
||
Резюме теперь три — [../RESUME.md](../RESUME.md) (мониторинг), [../RESUME_DEVOPS.md](../RESUME_DEVOPS.md) (DevOps), [../RESUME_SYSADMIN.md](../RESUME_SYSADMIN.md) (системное администрирование). Причина разделения: одно резюме, заточенное под мониторинг, снижало проходимость на скрининге по двум другим направлениям — конкретное название желаемой должности и релевантная подача первых пунктов сильно влияют на отклик (см. [../RESUME_RULES.md](../RESUME_RULES.md) → «Точное название желаемой должности»).
|
||
|
||
**Главное правило: факты одни на все три профиля, различаются только акценты.** Компании, даты, должности в блоках опыта, цифры (50 дашбордов, 15 Ansible-скриптов), образование — идентичны во всех трёх файлах. [LEGEND.md](LEGEND.md) остаётся единственным источником истины о том, где и зачем применялась каждая технология; этот файл — только надстройка про то, как расставлять акценты и вести себя на собеседовании в зависимости от того, с какого резюме пришёл отклик. HR одной компании технически может увидеть все три резюме соискателя на hh.ru — противоречий в фактах между ними быть не должно, иначе это разрушает доверие мгновенно.
|
||
|
||
## Как определить, какой профиль держать
|
||
|
||
Перед звонком/собеседованием смотреть, на какую вакансию и через какое резюме был отклик — это определяет, какой профиль ниже держать в разговоре. Если непонятно (рекрутёр не уточнил) — по умолчанию профиль «Мониторинг», как основной и наиболее проработанный.
|
||
|
||
## Профиль 1 — Мониторинг
|
||
|
||
**Резюме:** [../RESUME.md](../RESUME.md), должность «Инженер по сопровождению».
|
||
|
||
**Питч на 30 секунд:** «4 года 5 месяцев в инфраструктуре и эксплуатации, последние почти 3 года — инженер по сопровождению в АО ТНИИС, где мониторинг был основной зоной ответственности: настроил и веду 50 дашбордов Grafana, интегрировал Prometheus, внедрил Mimir для горизонтального масштабирования хранения метрик. Автоматизацию вокруг мониторинга и деплоя закрываю Ansible и Docker».
|
||
|
||
**Что вести первым:** связка Grafana + Prometheus + Mimir, кейс с балансировкой Nginx под 3 инстанса Mimir ([STORY.md](STORY.md) → «Сложная задача»), разбор инцидента по стандартной формуле ([STORY.md](STORY.md) → «Как решается инцидент»), версионирование дашбордов через Gitea + TeamCity.
|
||
|
||
**Что держать фоном:** Ansible/Docker — упоминать как инструменты, обслуживающие мониторинг, не выводить в центр рассказа.
|
||
|
||
**Pet-кейсы под руку:** [stack/monitoring](../stack/monitoring/CASE.md) уже покрыт основным опытом; из pet — не требуется, разве что Kafka, если спросят про очереди/потоковую передачу метрик.
|
||
|
||
**Уже полностью покрыто действующими документами** — этот профиль не новый, все `stack/monitoring/QUESTIONS.md` и текущая структура резюме уже заточены под него.
|
||
|
||
## Профиль 2 — DevOps
|
||
|
||
**Резюме:** [../RESUME_DEVOPS.md](../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](../stack/docker/CASE.md)), реальный кейс с Gitea CI-раннерами (restart-loop, cross-builder, маршрутизация по меткам — [stack/docker/CASE.md](../stack/docker/CASE.md) → раздел 9), pet Kubernetes ([stack/kubernetes/CASE.md](../stack/kubernetes/CASE.md)).
|
||
|
||
**Что держать фоном:** Grafana-дашборды — упоминать как результат, не углубляться так же подробно, как в профиле «Мониторинг».
|
||
|
||
**Типовой риск направления и честный ответ:** «Kubernetes в проде?» → прямо и честно, по формуле из [LEGEND.md](LEGEND.md) → «Домашняя лаборатория»: «В рабочем стеке этого не было — закрытый статичный парк VM, оркестрация была не нужна, весь IaC-слой закрывал Ansible. Мне стало интересно, поэтому поднял себе дома кластер (kind, 1 control-plane + 2 worker) и прошёл его от установки до собственного Helm-чарта — могу подробно рассказать про Pod/Deployment/Service/Ingress и что видел вживую». Не выдавать pet-практику за продовый опыт.
|
||
|
||
**Pet-кейсы под руку:** [stack/kubernetes/CASE.md](../stack/kubernetes/CASE.md), [stack/vault/CASE.md](../stack/vault/CASE.md) (если спросят про секреты — ansible-vault в проде, Vault — pet), [stack/kafka/CASE.md](../stack/kafka/CASE.md).
|
||
|
||
## Профиль 3 — Системное администрирование
|
||
|
||
**Резюме:** [../RESUME_SYSADMIN.md](../RESUME_SYSADMIN.md), должность «Системный администратор».
|
||
|
||
**Питч на 30 секунд:** «4 года 5 месяцев в эксплуатации серверной инфраструктуры. В АО ТНИИС сопровождаю парк серверов на Astra Linux — диагностика через логи и консоль, Nginx для маршрутизации и балансировки нагрузки, централизованный сбор логов через ELK, автоматизация рутинных операций через Ansible-роли и Bash. До этого в ОКБ СУХОЙ разворачивал и сопровождал тестовые стенды на CentOS. Образование — «Инфокоммуникационные технологии и системы связи», профильное для сетевой и серверной части».
|
||
|
||
**Что вести первым:** администрирование Astra Linux/CentOS (сервисы, логи, systemd — формула диагностики из [STORY.md](STORY.md) → «Как решается инцидент», шаги 4-5 про `systemctl status`/`journalctl`), Nginx как балансировщик, автоматизация через Ansible/Bash, сетевая диагностика (dig/traceroute/curl/ss — [stack/networking/CASE.md](../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/networking/CASE.md) (основной для этого профиля), [stack/databases/CASE.md](../stack/databases/CASE.md) (PostgreSQL — если спросят про администрирование БД сверх роли потребителя метрик из Postgres Exporter, см. [DEPT_STACK.md](DEPT_STACK.md)).
|
||
|
||
## Общее для всех трёх профилей
|
||
|
||
- Причина ухода, распорядок дня, состав отдела, разбор инцидента — общий нарратив из [STORY.md](STORY.md), не меняется между профилями.
|
||
- Цифры нагрузки — только по правилам [CAPACITY.md](CAPACITY.md), независимо от того, какое резюме привело к диалогу.
|
||
- Если на собеседовании всплывает факт из другого профиля (например, интервьюер по DevOps-вакансии спрашивает про сетевую диагностику) — отвечать честно из общей легенды, профили не создают барьеров в знаниях, только определяют, что рассказывать первым по умолчанию.
|