Вопросы на собеседовании: Инженер автоматизации

Я бы построил тонкий control plane и версионируемые SDK, а не заставлял каждый репозиторий использовать один фреймворк.

• Репозитории публикуют стандартный тестовый манифест с типом набора, владельцем, классом ресурсов, тайм-аутом и ожидаемой длительностью.
• Control plane планирует изолированные runner, передает нормализованные результаты и удерживает p95 ожидания в очереди ниже двух минут.
• Команды сохраняют адаптеры Playwright, pytest, JUnit или Go test, а платформа отвечает за аутентификацию, артефакты, политики и observability.

Я бы классифицировал тесты по границе и владельцу сбоя, а затем привязал к каждому классу бюджет выполнения.

• В pull request unit- и component-тесты укладываются в пять минут, сервисные integration-тесты в десять, а критические end-to-end сценарии в пятнадцать.
• Контрактные тесты проверяют границы сервисов без полного окружения, а ночные наборы покрывают дополнительные комбинации браузеров и данных.
• Каждый тест указывает одно значение таксономии в манифесте, а квартальные отчеты показывают команды, переносящие дешевые проверки на дорогие уровни.

Я бы использовал выжившие мутации как диагностические данные о слабых проверках, а не делал общий mutation score релизным gate.

• Я бы сгруппировал выжившие мутации по риску для ценообразования и типу оператора, затем проверил эквивалентные и недостижимые мутации, чтобы шум инструмента не определял тестовую работу.
• Для высокорисковых мутаций я бы добавил проверки поведения на уровне unit-, contract- или property-тестов и подтвердил, что они падают при изменении правила, не повторяя детали реализации.
• Я бы отслеживал устраненные высокорисковые мутации, дефекты ценообразования, дошедшие до продакшена, и время тестов по областям правил, не задавая единую цель score, которую можно формально выполнить.

Я бы поддерживал небольшой протокол и сертифицировал адаптеры, а не создавал универсальный фреймворк.

• Каждый адаптер должен выдавать одинаковые test ID, временные метки, статус, номер попытки, владельца и ссылки на артефакты.
• Платформенная команда поддерживает по одному базовому адаптеру на язык, а community-адаптеры получают набор совместимости и окно поддержки шесть месяцев.
• Внутренности неподдерживаемых фреймворков остаются ответственностью команд, что сохраняет выбор и не превращает шесть платформенных инженеров в сопровождающих библиотек.

Перед сертификацией я бы потребовал детерминированное обнаружение тестов, машинно-читаемое выполнение и стабильный протокол результатов.

• Обнаружение без запуска тестовых тел должно перечислять неизменяемые test ID, теги, владельца, тайм-аут, ресурсы и историческую группу.
• Выполнение должно соблюдать фильтры shard, отменяться за 30 секунд и отличать сбой теста от сбоя runner.
• Набор совместимости внедряет тайм-ауты, падения, дубли событий и некорректный вывод, и плагин проходит его при каждом релизе.

Я бы заранее зарегистрировал эксперимент с зависимостью, использовал сопоставимую контрольную группу и убрал сохранение артефактов из критического пути завершения результата.

• Гипотеза стабильного состояния: при 12 000 заданий в час не менее 99,95% принятых заданий вне fault-когорты получают конечный результат за 60 секунд, а разница с контролем не превышает 0,1 процентного пункта.
• В одной зоне доступности отдельно запускаются две непересекающиеся когорты не более 2,5% глобального трафика каждая: для первой fault proxy добавляет ровно 300 мс задержки, а для второй внедряет 3% явных ошибок без дополнительной задержки; ограничитель маршрутизации удерживает суммарное воздействие в пределах 5%.
• Клиент хранилища использует тайм-аут 500 мс на вызов и размыкает circuit breaker, если не менее 20 из последних 50 вызовов завершились ошибкой или тайм-аутом, помечая доказательства как ожидающие ограниченного асинхронного повтора; автоматизация прерывает эксперимент, если завершение незатронутых заданий нарушает гипотезу, воздействие выходит за одну зону или 5% глобального трафика либо p95 получения результата превышает 60 секунд.
• Очистка удаляет правило fault proxy, дожидается успешных проверок для замыкания circuit breaker, выполняет отложенные повторы и перед закрытием сверяет принятые задания, конечные результаты, ссылки и контрольные суммы артефактов и недостающие доказательства.

Я бы выдавал каждому запуску изолированные сгенерированные данные с явным жизненным циклом вместо изменяемой общей базы фикстур.

• Data API создает записи в отдельном tenant из версионируемых фабрик и возвращает идентификаторы вместо фиксированных email или номеров счетов.
• Worker используют уникальные run ID и идемпотентную очистку, а TTL в 24 часа страхует случаи, когда отмена пропустила teardown.
• Производственные фикстуры токенизируются до хранения, а тесты совместимости схем запускаются при изменении фабрики или контракта сервиса.

Я бы использовал семантическое версионирование, телеметрию совместимости репозиториев и поэтапные автоматические обновления.

• Поддерживаемые основные версии работают параллельно в течение объявленного окна миграции, а исправления безопасности переносятся согласно опубликованной политике поддержки.
• Десять репозиториев, затем 10%, 50% и весь парк служат только этапами охвата; для каждого продвижения нужны минимальное число выполнений и приемлемая верхняя доверительная граница регрессий по вине SDK, а для объявленных тяжелых последствий действует нулевая терпимость.
• Старая основная версия поддерживается, пока ее использует хотя бы один поддерживаемый репозиторий, если он не завершил миграцию и не получил одобренное ограниченное по времени исключение.

Я бы стандартизировал конверт выполнения без потери данных, сохраняя предметные доказательства как типизированные вложения.

• Общая модель содержит run, suite, shard, test, attempt, status, timing, owner, environment, ревизию кода и категорию сбоя.
• Скриншоты, трассировки, HAR-файлы, логи устройств и гистограммы нагрузочных тестов хранятся в object storage по неизменяемым ссылкам.
• Исходный вывод адаптера сохраняется 14 дней, чтобы исправлять ошибки нормализации без повторного запуска дорогих наборов.

Я бы определил пользовательские SLO для приема, планирования, точности выполнения и доступности результатов.

• API нацелен на 99,9% успешного приема заданий и p95 задержки приема ниже одной секунды за 28 дней.
• p95 очереди остается ниже двух минут для стандартных заданий, а 99,95% принятых тестовых событий попадают в итоговый результат за 60 секунд.
• Доступность runner разделяется по классам ресурсов, чтобы дефицит GPU или устройств не скрывал деградацию обычного пула.

Я бы использовал надежную персистентную региональную очередь заданий, идемпотентный глобальный control plane и worker рядом с данными.

• Обнаружение создает неизменяемые спецификации shard, а аренда с heartbeat безопасно возвращает брошенную работу в очередь.
• Региональные планировщики размещают shard рядом с зависимостями и загружают append-only события в глобально реплицируемое хранилище результатов.
• Control plane не координирует отдельные тесты синхронно, что ограничивает межрегиональную задержку и радиус поражения при его сбое.

Я бы планировал через взвешенные справедливые очереди и явный лимит параллелизма на tenant вместо общего FIFO.

• Каждая команда получает базовую долю, свободные слоты можно занимать и возвращать при активации других очередей.
• Задания pull request имеют приоритет над ночными, но старение повышает долго ожидающую работу, чтобы низкий приоритет не означал никогда.
• Лимиты считаются в runner-минутах, а не заданиях, потому что одно задание на 32 ядра и 60 минут не равно двухминутному unit-набору.

Я бы отклонил цель менее 15 минут при текущей гранулярности, потому что один неделимый тест уже занимает 20 минут.

• Этот тест нужно разделить, оптимизировать, вывести из блокирующего контура или поднять SLA выше его измеренного p90 или p99, прежде чем шардирование сможет уложиться в цель.
• Для остальных тестов я бы привязал историю длительности к test ID и окружению и применил распределение от самых долгих тестов с консервативной оценкой неизвестных тестов.
• Я бы проверил прогнозы shard с учетом времени запуска и разброса длительности, оставляя запас вместо планирования ровно до дедлайна.

Для недоверенного кода я бы использовал одноразовые виртуальные машины или защищенные microVM с усиленной изоляцией, а не общий Docker daemon.

• Задания получают краткоживущие учетные данные только для синтетических тестовых аккаунтов и не видят production-сети или metadata endpoint облака.
• Исходящий трафик разрешается списком через proxy, диски workspace уничтожаются после задания, а кеши адресуются по содержимому и доступны только для чтения.
• Доверенные release-задания работают в отдельных аккаунтах и node pool, оправдывая большую стоимость предотвращением пересечения учетных данных и ядра.

Я бы привязал идемпотентные события к run, shard, test, attempt и fencing epoch, а затем сводил их по явным переходам состояний.

• Обнаружение сохраняет ожидаемые test ID и их число, диапазоны последовательностей выявляют пропуски, а глобально уникальные event ID удаляют дубли.
• Reducer принимает одно конечное состояние для текущей попытки и epoch, записывает противоречия и отклоняет каждую запись с устаревшим epoch.
• Финализация происходит, только когда каждый ожидаемый тест имеет принятое конечное состояние или явно признан отсутствующим к дедлайну; конечное событие shard само по себе не доказывает полноту.

Я бы сохранял неизменяемый манифест повторного запуска вместе с исходной попыткой и явно указывал незахваченные зависимости вместо обещания побитового воспроизведения.

• Манифест фиксирует ревизию исходников, digest образа, артефакты пакетов и lockfile, toolchain runner, конфигурацию, feature flags, версии фикстур и схем.
• Он записывает случайные seed, часы и часовой пояс, хеши входных данных и очищенные контракты внешних запросов и ответов с неизменяемыми ссылками на артефакты.
• Повтор выполняется в изолированной сети по этим ссылкам и сообщает об отсутствующем или несовпадающем состоянии; незахваченное поведение третьей стороны является диагностикой, а не эквивалентным повтором.

Я бы кооперативно отменял устаревшие запуски ветки, замененные более новым коммитом, а после короткого периода ожидания принудительно завершал их.

• Control plane помечает запуск отмененным, прекращает выдавать новые shard и отправляет токены отмены активным worker.
• Тесты получают 30 секунд на загрузку диагностики и очистку ресурсов, затем процесс runner или Pod завершается.
• Запуски merge queue и релизов не отменяются, а повторно используемый кеш публикуется только после успешного атомарного завершения.

Средняя потребность равна 600 параллельным runner, поэтому я бы начал примерно с 800 и проверил число по всплескам входящего потока.

• Расчет равен 9 000 умножить на четыре и разделить на 60, плюс около 33% запаса на пики, запуск узлов и обслуживание.
• Автомасштабирование учитывает возраст очереди и запрошенные CPU и память, а не только число заданий, при цели p95 очереди в две минуты.
• Зарезервированная базовая мощность выдерживает обычную нагрузку, а spot-worker поглощают прерываемые ночные наборы и снижают стоимость.

Я бы оптимизировал неизменяемые входы рядом с runner, сохранив чистые среды выполнения.

• Часто используемые подписанные образы заранее загружаются на теплые узлы и уменьшаются, чтобы p95 загрузки был ниже 30 секунд.
• Maven, npm и браузерные бинарники используют адресуемые по содержимому региональные кеши с ключом по lockfile и toolchain, но не общие каталоги для записи.
• Доля попаданий в кеш и переданные байты доказывают выигрыш, а canary с холодным кешем подтверждает воспроизводимость без сохраненного состояния.

Я бы сделал резидентность жестким ограничением планирования и выполнял failover только внутри разрешенной географии.

• Манифесты заданий помечают класс данных и допустимые регионы, а прием отклоняет набор, чьи зависимости нарушают эти метки.
• Очереди EU могут расширяться в два европейских региона, но никогда на runner в US, даже если это увеличит время завершения.
• Оповещения о мощности срабатывают до превышения p95 очереди в пять минут, а бизнес явно оплачивает резерв EU вместо незаконного переноса.