# Рунити / Runity — вакансия CTO облачного направления (полный текст)

## Метаданные

- **Компания:** Рунити (Runity) — облачный провайдер: публичное облако + dedicated-серверы (юрлицо/бренд уточнить)
- **Вакансия:** Технический директор (CTO) облачного направления
- **Масштаб роли:** 2 команды разработки, ~50 человек, включая руководителей команд и тимлидов
- **Стек:** Python, Go, PHP, React, Vue; Kubernetes (K&S опечатка в тексте), Docker, Prometheus, MySQL, PostgreSQL
- **Формат:** удалённо; офисы/коворкинги Москва, Самара, Санкт-Петербург; ДМС с первого месяца
- **Дата отклика:** 12.09.2026 (пользователь уже откликнулся)

## О вакансии (verbatim)

> Рег. облако активно растет и сейчас нам не хватает CTO, который поможет выстроить устойчивое развитие публичного облака и dedicated-серверов: архитектуру, инженерные процессы, delivery, качество, надежность платформы и взаимодействие разработки с продуктом, коммерцией и поддержкой.

**Основные задачи:**

- Сделать измеримыми и предсказуемыми SLA и надежность платформы
- Определить степень влияния от legacy-систем на production и составить план реализации по устранению зависимости
- Управление двумя командами разработки — 50 человек, включая руководителей команд и тимлидов
- Выстроить архитектуру публичного облака и dedicated-серверов под быстрый рост числа сервисов
- Настроить инженерные процессы, delivery и контроль качества, довести накопленные технические и процессные вызовы до управляемой системы

**Необходимый опыт:**

- Опыт на позиции CTO или технического лидера в B2B, облачных технологиях, инфраструктуре или SaaS
- В прошлом практический опыт низкоуровневого программирования: виртуализация, серверная инфраструктура, работа с OpenStack на физическом уровне серверов
- Или опыт бэкенд-разработки на C++ или Go, понимание устройства процессора и памяти на уровне, достаточном для архитектурных решений
- Опыт работы на стыке разработки и эксплуатации, а не только по одну из сторон
- Навык не только принимать архитектурные решения, но и строить команды и процессы, с ответственностью за результат и SLA
- Опыт управления инженерными командами от 20 человек

**Условия:** удалёнка (опционально офисы Москва/Самара/СПб), ДМС с первого месяца, wellbeing-программа, внутреннее и внешнее обучение, корпоративные скидки.

## Наш профиль и гэпы

**Совпадает (частично):**

- **Техническое лидерство в B2B/SaaS:** Balance Platform — Lending-as-a-Service платформа (B2B SaaS, кредитная автоматизация), путь Senior Developer → Team Lead → Ruby Practice Lead; разработка стандартов, которые приняли другие команды (DDD-стандарт, code-review стандарты, Ruby competency matrix, лёгкий процесс техдолга).
- **Работа на стыке разработки и эксплуатации:** Kubernetes, Docker, Prometheus, Grafana, OpenTelemetry (распределённый трейсинг на 20 сервисов), GitLab CI/CD (пайплайны ~30 мин → ~5 мин), миграции и надёжность production. Но это — потребитель инфраструктуры, а не её владелец.
- **Legacy → управляемая система:** monolith → microservices в Balance Platform; перестройка C4-документации на ~50 сервисов и миграция инфраструктуры банка до ~80% в Raiffeisen; тележка метрик и надёжности (1000 RPS, 2000 магазинов, 10x ускорение синхронизации, 800 ГБ+ данных).
- **Go в production:** платформенный сервис на Samokat (Kafka → WebSocket, ~500 соединений / ~50 событий в сек.), высоконагруженный HTTP-краулер в SeoPult.
- **Низкоуровневая база:** образование — МАИ, «Математик, системный программист» (прикладная математика и физика). Это единственный релевантный «низкоуровневый» актив в профиле.

**Честные гэпы (критичные):**

- **Нет опыта CTO/Head of Engineering.** В треке — Team Lead, Product Team Lead, Ruby Practice Lead, Technical Lead. Управление 50 людьми двумя командами через руководителей и тимлидов не подтверждается фактурой: реальные масштабы — небольшие команды + техническое лидерство в нескольких командах.
- **Нет низкоуровневого программирования в продакшене:** ни виртуализации, ни OpenStack, ни серверной инфраструктуры на физическом уровне; нет C++, нет работы с железом. Go есть, но прикладной бэкенд, не системный уровень.
- **Нет облачно-провайдерского домена:** публичное облако, dedicated-серверы, гипервизоры, SLA платформы как продукта — этого опыта нет. K8s/Docker/Prometheus — эксплуатация поверх чужой инфраструктуры.
- **Ответственность за SLA платформы** как формальную метрику не подтверждаем — есть надёжность и производительность конкретных систем.
- **Рынок и валюта:** русскоязычная вакансия, офисы в РФ → доход, скорее всего, в рублях. Это расходится с целью проекта (валютный доход).

## Стратегические расхождения

1. **Роль — управленческая (CTO, 50 человек), а позиционирование проекта — IC-разработчик** («Ищем позицию разработчика (IC), НЕ тимлид/менеджер»). Это уже не «архитектурно-доменный трек» (SMS Aggregate), а полноценный переход в менеджмент.
2. **Целевой гэп не закрывается тюнингом резюме.** В прошлых кейсах (Runware, Fuse Energy, GitLab) гэп — это язык/фреймворк или домен, куда переносится инженерная фактура. Здесь ядро требований (OpenStack/виртуализация/железо + управление 50 людьми) в профиле отсутствует как класс.

## Оценка шансов и варианты действий

**Реалистично:** отклик — лотерейный билет. Скорее всего, отсеют на скрининге из-за опыта управления и низкоуровневой базы; вероятность разговора — низкая.

**Варианты (решение за пользователем):**

- **A. Минимальный честный отклик** (~1 час): короткое письмо/сообщение рекрутеру о переносимом — nation-scale системы (Platon, 1M+ машин), инфраструктурная миграция банка, DDD/процессы, принятые несколькими командами, Go + системное образование; честно про отсутствие low-level/облачно-провайдерского опыта. Плюс — не размываем master-резюме.
- **B. Полный tailoring резюме под Head of Engineering / CTO** (несколько часов): переупорядочить опыт под управление/процессы/SLA, дописать «команды и процессы» вперёд, ослабить IC-акценты. Минусы: противоречит позиционированию проекта и портит фокус основного резюме; лучше делать отдельной ручной версией (как `western-cv-fuse-energy.html`), а не из `cv.yaml`.
- **C. Не тратить ресурс** (0 часов): кейс зафиксирован, отклик отправлен — ждать реакции, усилия направлять в IC-Ruby/AI-трек.

**Рекомендация:** если разговор с компанией интересен сам по себе (рынок РФ, облачный домен как смена профессии) — вариант A. Если цель — валютная удалёнка IC — вариант C, а A только при появлении ответа от компании.

## Статус

- 12.09.2026 — отклик отправлен пользователем; кейс зафиксирован.
- 12.09.2026 — запущен ИИ-скрининг hh (вопросы адаптивные): 2 вопроса пройдено (роль, задачи), готов ответ по C++/Go → [`hh-screening.md`](hh-screening.md). Идёт по факту, без решения по варианту A/B/C: отвечаем честной фактурой, без размывания master-резюме.