# Легенда соискателя

Единый источник истины о том, «где и зачем» применялась каждая технология из резюме. Все кейсы и ответы на вопросы должны быть непротиворечивы этому документу. См. правила проработки кейсов в [../AI_GUIDELINES.md](../AI_GUIDELINES.md).

Живой нарратив поверх этой таблицы (проект отдела, распорядок дня, разбор инцидента, версионирование дашбордов) — в [STORY.md](STORY.md). Стек отдела целиком, включая инструменты без личной строки в резюме, — в [DEPT_STACK.md](DEPT_STACK.md). Есть три резюме под три направления (мониторинг, DevOps, системное администрирование) с одними и теми же фактами из этого файла, но разной расстановкой акцентов — какое резюме соответствует какому направлению и как вести себя на собеседовании в зависимости от него, см. [PROFILES.md](PROFILES.md).

## Таймлайн

| Период | Компания | Роль | Основной стек |
|---|---|---|---|
| Март 2022 — Сентябрь 2023 (1 г. 7 мес.) | ОКБ СУХОЙ | Инженер-тестировщик | CentOS, Selenium, GitLab, C/C++, Python |
| Сентябрь 2023 — н.в. (2 г. 11 мес.) | АО ТНИИС | Инженер по сопровождению | Astra Linux, Grafana, Prometheus, Mimir, Docker, Ansible, Nginx, ELK, Jira, Gitea, Bash, Java, SQL |

Общий опыт — 4 года 5 месяцев. Логика перехода: от тестирования встроенного ПО (проверка качества готового продукта) — к сопровождению и эксплуатации инфраструктуры (обеспечение стабильности продукта в проде). Естественное развитие: тестировщик, который глубоко разбирался в стендах и автоматизации тестов, вырос в инженера, отвечающего за автоматизацию инфраструктуры и мониторинг.

## ОКБ СУХОЙ — инженер-тестировщик (2022—2023)

Контекст роли: верификация встроенного программного обеспечения на платформе CentOS — тестовые стенды интеграционного и приёмочного тестирования. Место работы — таганрогская площадка кооперации ОАК, не головной офис в Москве (снимает вопрос о совмещении с очной магистратурой ЮФУ в Таганроге, см. [STORY.md](STORY.md) → «Бытовые детали»).

- **CentOS** — рабочая ОС тестовых стендов: развёртывание окружения, работа с сервисами и логами через консоль.
- **Selenium** — автоматизация функциональных проверок там, где у ПО был веб/UI-интерфейс для управления стендом; писал тестовые сценарии и автотесты.
- **GitLab** — хранение тестовых скриптов и сценариев, отслеживание версий тестовой документации, базовое знакомство с CI до глубокого погружения в TeamCity на следующей позиции.
- **C/C++** — контекст тестируемого встроенного ПО: чтение и понимание кода на C/C++ требовалось, чтобы грамотно ставить тестовые сценарии, писать баг-репорты с точной локализацией проблемы и общаться с разработчиками на их языке.
- **Python** — вспомогательные скрипты для автоматизации рутины тестировщика (подготовка тестовых данных, парсинг логов стендов, обвязка вокруг Selenium-тестов).

## АО ТНИИС — инженер по сопровождению (2023 — н.в.)

Контекст роли: сопровождение и эксплуатация инфраструктуры, мониторинг, автоматизация деплоя и конфигурирования.

- **Astra Linux** — базовая ОС серверного парка отдела, администрирование и сопровождение сервисов.
- **Grafana + Prometheus + Mimir** — стек мониторинга: сбор метрик (Prometheus), построение дашбордов (Grafana), масштабирование хранения метрик на несколько инстансов (Mimir).
- **Docker** — контейнеризация сервисов мониторинга и вспомогательных инструментов, локальное воспроизведение окружений; включая сборку кастомных образов под специфичные задачи CI (см. строку Gitea выше и [../stack/docker/CASE.md](../stack/docker/CASE.md)).
- **Ansible** — автоматизация установки/настройки серверов и конфигурирования сервисов, роли и плейбуки для деплоя.
- **Nginx** — маршрутизация и балансировка нагрузки перед сервисами (в частности перед компонентами мониторинга и внутренними веб-интерфейсами).
- **ELK (Elastic Stack)** — централизованный сбор и анализ логов в дополнение к метрикам из Prometheus.
- **Jira** — планирование спринтов, ведение задач в Agile-процессе отдела.
- **Gitea** — внутренний git-хостинг для хранения Ansible-ролей, конфигов, скриптов; встроенная Wiki используется под инструкции и постмортемы инцидентов (см. [STORY.md](STORY.md) → «Как решается инцидент»). Помимо хранения кода — администрирование самого инстанса (Docker Compose: Gitea + Postgres, nginx reverse proxy перед ним) и CI-раннеров Gitea Actions: основной раннер плюс отдельный **cross-builder** — кастомный Docker-образ (Debian + `arm-linux-gnueabihf-gcc` и статические armhf-библиотеки, собираемые на этапе сборки образа) под CI кросс-сборки встроенного C-кода для ARM-плат (проект отдела на базе SDR-платформы Pluto — см. [../stack/docker/CASE.md](../stack/docker/CASE.md) → «Реальный кейс: self-hosted CI-раннеры Gitea Actions»). Практический опыт: восстановление раннера из restart-loop (протухшая регистрация), маршрутизация job'ов по меткам между раннерами, проверка целевой архитектуры собранных бинарей в pipeline.
- **TeamCity + Molecule** — CI-конвейер для тестирования Ansible-ролей перед выкладкой.
- **Bash** — повседневная автоматизация на серверах: обвязка вокруг Ansible/Docker, скрипты обслуживания.
- **Java** — часть стека сопровождаемых сервисов отдела (эксплуатация/поддержка Java-приложений, чтение логов и стектрейсов при инцидентах), не основной инструмент разработки.
- **SQL** — запросы к базам данных сопровождаемых сервисов и/или к хранилищам метрик/логов при разборе инцидентов и подготовке отчётности.

## Технологии без прямого кейса в опыте работы

Указаны в разделе «Навыки» резюме, в легенду вписаны как сквозные инструменты внутри уже описанных задач (не отдельная линия опыта):

- **Python** — автоматизация в обеих ролях (см. выше).
- **SQL** — работа с данными сопровождаемых сервисов в АО ТНИИС (см. выше).
- **C/C++** — чтение кода тестируемого ПО в ОКБ СУХОЙ (см. выше).

## Домашняя лаборатория / pet-проект

Разбор реальных собеседований ([../interview/real-interviews.md](../interview/real-interviews.md)) показал: Kubernetes, PostgreSQL, сетевая база, Kafka и Vault спрашивают часто, но их **нет** в рабочем стеке ни АО ТНИИС, ни ОКБ СУХОЙ. Вместо того чтобы дописывать их в опыт компаний (что нарушило бы правило честности кейсов из [../AI_GUIDELINES.md](../AI_GUIDELINES.md)), они выделены в отдельную честную категорию — домашнюю лабораторию, аналогично тому, как на собеседовании в ВТБ упоминание pet-проекта сработало в плюс (см. разбор в [../interview/real-interviews.md](../interview/real-interviews.md)).

| Технология | Кейс | Статус |
|---|---|---|
| Kubernetes | [../stack/kubernetes/CASE.md](../stack/kubernetes/CASE.md) | pet, поверх рабочего Docker/Ansible |
| PostgreSQL | [../stack/databases/CASE.md](../stack/databases/CASE.md) | pet, поверх рабочего SQL |
| Сети | [../stack/networking/CASE.md](../stack/networking/CASE.md) | pet, поверх рабочего Linux-администрирования |
| Kafka | [../stack/kafka/CASE.md](../stack/kafka/CASE.md) | pet, самостоятельно |
| Vault | [../stack/vault/CASE.md](../stack/vault/CASE.md) | pet, поверх рабочего ansible-vault |

**Как это позиционируется на собеседовании:** честно и прямо — «в рабочем стеке этого не было, но интересно было разобраться, поэтому поднял себе дома». Не выдаётся за продовый опыт, не привязывается к конкретным задачам АО ТНИИС/ОКБ СУХОЙ. Цифры нагрузки для pet-кейсов — только лабные замеры и публичные ориентиры, без утверждений о продовых масштабах (правило и таблица цифр — [../legend/CAPACITY.md](../legend/CAPACITY.md)).

## Инструменты отдела без личной строки в резюме

Полный стек отдела АО ТНИИС — в [DEPT_STACK.md](DEPT_STACK.md). Часть инструментов туда попадает по логике окружения (то, чем пользуется отдел или что стоит рядом с моими задачами), но в резюме отдельной строкой не идёт, потому что я с ними не работал напрямую как с основным инструментом — только на уровне «знаю, зачем стоит, могу поддержать разговор»: **MinIO** (объектное хранилище под блоки Mimir), **Nexus** (внутреннее хранилище артефактов/бинарей), **Alertmanager** (маршрутизация алертов из Prometheus), **Postgres Exporter** (снимает метрики с БД, которые ведут разработчики/администраторы БД), **Filebeat** (агент доставки логов в ELK). При вопросе про них на собеседовании — честный формат из [../AI_GUIDELINES.md](../AI_GUIDELINES.md): рассказываю, для чего инструмент нужен и как он встроен в наш стек, не выдавая это за уровень «настраивал сам с нуля».

## Правило непротиворечивости

При добавлении нового кейса в `stack/*/CASE.md`:
1. Сверить, что компания/период/стек совпадают с таблицей выше.
2. Если кейс раскрывает технологию по-новому — обновить соответствующий пункт здесь же.
3. Не добавлять технологии, которых нет ни в одном из трёх резюме ([../RESUME.md](../RESUME.md), [../RESUME_DEVOPS.md](../RESUME_DEVOPS.md), [../RESUME_SYSADMIN.md](../RESUME_SYSADMIN.md)), ни в этом файле.
4. Pet-технологии (раздел выше) никогда не переносятся в блоки опыта компаний — только в раздел «Навыки» резюме и в раздел «Домашняя лаборатория» здесь.
5. Новые истории и детали быта/процессов сверять с [STORY.md](STORY.md), стек отдела — с [DEPT_STACK.md](DEPT_STACK.md), чтобы не появлялось противоречий между документами.
6. Факты (компании, даты, должности в опыте, цифры) должны быть идентичны во всех трёх резюме — различаться может только расстановка акцентов и порядок подачи, см. [PROFILES.md](PROFILES.md).