Initial commit: interview prep repo (resume, legend, stack cases, Kubernetes course)

legend/LEGEND.md

@@ -0,0 +1,76 @@
+# Легенда соискателя
+
+Единый источник истины о том, «где и зачем» применялась каждая технология из резюме. Все кейсы и ответы на вопросы должны быть непротиворечивы этому документу. См. правила проработки кейсов в [../AI_GUIDELINES.md](../AI_GUIDELINES.md).
+
+Живой нарратив поверх этой таблицы (проект отдела, распорядок дня, разбор инцидента, версионирование дашбордов) — в [STORY.md](STORY.md). Стек отдела целиком, включая инструменты без личной строки в резюме, — в [DEPT_STACK.md](DEPT_STACK.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** — контейнеризация сервисов мониторинга и вспомогательных инструментов, локальное воспроизведение окружений.
+- **Ansible** — автоматизация установки/настройки серверов и конфигурирования сервисов, роли и плейбуки для деплоя.
+- **Nginx** — маршрутизация и балансировка нагрузки перед сервисами (в частности перед компонентами мониторинга и внутренними веб-интерфейсами).
+- **ELK (Elastic Stack)** — централизованный сбор и анализ логов в дополнение к метрикам из Prometheus.
+- **Jira** — планирование спринтов, ведение задач в Agile-процессе отдела.
+- **Gitea** — внутренний git-хостинг для хранения Ansible-ролей, конфигов, скриптов; встроенная Wiki используется под инструкции и постмортемы инцидентов (см. [STORY.md](STORY.md) → «Как решается инцидент»).
+- **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), ни в этом файле.
+4. Pet-технологии (раздел выше) никогда не переносятся в блоки опыта компаний — только в раздел «Навыки» резюме и в раздел «Домашняя лаборатория» здесь.
+5. Новые истории и детали быта/процессов сверять с [STORY.md](STORY.md), стек отдела — с [DEPT_STACK.md](DEPT_STACK.md), чтобы не появлялось противоречий между документами.