resume/legend/LEGEND.md

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

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

Живой нарратив поверх этой таблицы (проект отдела, распорядок дня, разбор инцидента, версионирование дашбордов) — в STORY.md. Стек отдела целиком, включая инструменты без личной строки в резюме, — в DEPT_STACK.md. Есть три резюме под три направления (мониторинг, DevOps, системное администрирование) с одними и теми же фактами из этого файла, но разной расстановкой акцентов — какое резюме соответствует какому направлению и как вести себя на собеседовании в зависимости от него, см. 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 → «Бытовые детали»).

• 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).
• Ansible — автоматизация установки/настройки серверов и конфигурирования сервисов, роли и плейбуки для деплоя.
• Nginx — маршрутизация и балансировка нагрузки перед сервисами (в частности перед компонентами мониторинга и внутренними веб-интерфейсами).
• ELK (Elastic Stack) — централизованный сбор и анализ логов в дополнение к метрикам из Prometheus.
• Jira — планирование спринтов, ведение задач в Agile-процессе отдела.
• Gitea — внутренний git-хостинг для хранения Ansible-ролей, конфигов, скриптов; встроенная Wiki используется под инструкции и постмортемы инцидентов (см. 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 → «Реальный кейс: 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) показал: Kubernetes, PostgreSQL, сетевая база, Kafka и Vault спрашивают часто, но их нет в рабочем стеке ни АО ТНИИС, ни ОКБ СУХОЙ. Вместо того чтобы дописывать их в опыт компаний (что нарушило бы правило честности кейсов из ../AI_GUIDELINES.md), они выделены в отдельную честную категорию — домашнюю лабораторию, аналогично тому, как на собеседовании в ВТБ упоминание pet-проекта сработало в плюс (см. разбор в ../interview/real-interviews.md).

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

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

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

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

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

При добавлении нового кейса в stack/*/CASE.md:

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