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

Я рассматриваю это как связанную с деплоем регрессию производительности и локализую её с помощью метрик, трейсов и контролируемого сравнения.

• Я начинаю с того, что сравниваю diff деплоя и сопоставляю скачок задержки с точным временем выката на дашборде метрик, потом смотрю p50 против p99, чтобы понять, идёт ли речь об общем сдвиге или о регрессе в хвосте.
• Отсутствие ошибок обычно говорит о добавленной работе, а не о сбоях, поэтому я ищу новые синхронные вызовы, N+1 запросы, потерянный кэш или изменение конфига вроде размера пула соединений.
• Я вытягиваю трейсы медленных запросов, чтобы найти, какой спан вырос, и при необходимости гоняю старую и новую сборку рядом под одинаковой нагрузкой, чтобы подтвердить регресс.

Я различаю упор в CPU и I/O по профилям, метрикам загрузки и трейсам, а уже затем выбираю решение.

• Я проверяю, совпадает ли процессорное время с реальным временем запроса, сэмплируя профайлером вроде py-spy или perf: если время на CPU занимает большую часть длительности запроса, значит упор в CPU, а если поток в основном ждёт сокеты или диск, значит упор в I/O.
• Метрики тоже помогают, ведь высокая загрузка CPU при низком iowait говорит про вычисления, а низкий CPU с длинными спанами внешних вызовов в трейсах указывает на I/O.
• Решения разные: работа с упором в CPU требует улучшения алгоритмов, кэширования или параллелизма, а работа с упором в I/O требует батчинга, пула соединений, конкурентности или устранения лишних round trip.

Я ищу утечку памяти по росту удерживаемого хипа, прослеживаю владельца объектов и подтверждаю исправление длительной нагрузкой.

• Я снимаю хип-снапшоты через интервалы и сравниваю их, чтобы увидеть, какие типы объектов продолжают расти, используя инструменты вроде Chrome DevTools или хип-профайлера Node для JS, либо tracemalloc и objgraph для Python.
• Постоянно растущий RSS вместе с растущим удержанным набором обычно означает, что где-то держатся ссылки, часто это кэши без вытеснения, неудалённые обработчики событий или неограниченные очереди.
• Найдя растущий тип, я прослеживаю путь удержания до владеющей структуры, чиню удержание и подтверждаю soak-тестом, что память выходит на плато.

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

• Это классический гейзенбаг, и обычно он означает проблему тайминга или конкурентности, где логирование достаточно меняет расписание, чтобы скрыть гонку, либо отладчик сериализует потоки, которые обычно чередуются.
• Причиной также бывает неинициализированная память или оптимизация компилятора, которую меняет отладочная сборка.
• Я действую так: добавляю наблюдение с низкими накладными расходами вроде счётчиков, кольцевых буферов или thread sanitizer вместо блокирующих логов, и нагружаю конкурентность большим числом потоков и случайными задержками, чтобы гонка стала воспроизводимой.

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

• Я запускаю сэмплирующий профайлер под реалистичной нагрузкой и читаю flame graph, ища самые широкие фреймы, которые дают наибольшую долю общего времени, а не самые глубокие стеки.
• Частые ошибки: профилировать прогрев или нерепрезентативную нагрузку, доверять одному прогону вместо агрегации, путать self time с общим временем и оптимизировать функцию, которая выглядит горячей, но занимает всего 2 процента реального трафика.
• Ещё я слежу за эффектом наблюдателя от тяжёлой инструментации и предпочитаю сэмплинг полной трассировке ради чисел, близких к продакшену.

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

• Сначала я воспроизвожу нагрузку инструментом вроде k6, Locust или wrk, чтобы проблема стала наблюдаемой, потом слежу за сигналами насыщения: исчерпание пула потоков и пула соединений, конкуренция за блокировки, паузы GC и глубина очередей.
• Проблемы, которые видны только под нагрузкой, обычно вызваны конкуренцией или лимитами ресурсов, а не логическими багами, поэтому я смотрю на размеры пулов, таймауты и backpressure.
• Непрерывное профилирование и трейсы отдельных запросов во время нагрузочного теста показывают, где концентрируются время и ожидание по мере роста конкурентности.

Я прослеживаю запрос от начала до конца по проброшенному trace id, а при необходимости связываю логи по request id.

• Я использую распределённую трассировку с correlation или trace id, который пробрасывается через границы сервисов, например через OpenTelemetry и заголовки W3C trace context, чтобы один запрос давал единый связанный трейс в Jaeger или Tempo.
• Я ищу по этому trace id, вижу всё дерево спанов, нахожу, на каком хопе была ошибка или таймаут, и читаю теги со статус-кодами и ретраями.
• Если трассировки нет, я откатываюсь на request id, логируемый в каждом сервисе, и сшиваю логи в агрегаторе.

Метрики помогают мне обнаружить проблему, трейсы локализовать её, а логи объяснить конкретное событие.

• Метрики представляют собой дешёвые агрегированные числа во времени, которые отвечают, есть ли проблема и как часто, поэтому я использую их для дашбордов и алертов.
• Логи представляют собой отдельные события с деталями, которые отвечают, что именно произошло в конкретном случае, и полезны, когда алерт сработал и нужен контекст.
• Трейсы показывают путь и тайминг одного запроса по компонентам, отвечая, где живёт задержка или сбой, и вместе они складываются в поток: алерт по метрике, поиск запроса через трейс, чтение логов для деталей.

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

• Сначала я изолирую подозреваемого, написав минимальное воспроизведение, которое вызывает библиотеку напрямую с теми же входными данными, исключая мой код-обёртку.
• Потом я проверяю трекер задач и changelog библиотеки на известные баги в моей версии, фиксирую и бисекчу версии, чтобы найти, где поменялось поведение, и читаю нужный исходник, раз он доступен.
• Если подтвердилось, я завожу issue в апстрим с воспроизведением, применяю локальный обходной путь или патч вроде форка или monkeypatch и фиксирую безопасную версию, пока не выйдет фикс.

Каждую гипотезу о таймаутах базы я связываю с конкретным измерением и сопоставляю данные со временем всплесков.

• Мои первые гипотезы: исчерпание пула соединений, конкуренция за блокировки или долгие транзакции, отсутствующий индекс, вызывающий редкие полные сканы, и насыщение ресурсов на хосте базы.
• Я проверяю их метриками использования пула, логом медленных запросов и pg_stat_activity для блокировок, EXPLAIN ANALYZE по подозрительным запросам и графиками CPU, IO и памяти хоста во время всплесков.
• Периодичность обычно значит корреляцию с чем-то, поэтому я совмещаю таймауты с пиками трафика, батч-джобами или ожиданием блокировок, чтобы найти триггер.

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

• Я держусь идеи пирамиды тестов: много быстрых модульных тестов на логику и краевые случаи, крепкий слой интеграционных тестов для частей, что касаются реальных границ вроде базы или очереди, и тонкий набор end-to-end тестов для нескольких критичных пользовательских сценариев.
• Баланс зависит от того, где живут риск и сложность, поэтому сервис с упором на оркестрацию и I/O требует больше интеграционных тестов, чем библиотека чистых вычислений.
• Я оптимизирую уверенность на секунду прогона и избегаю перекошенного вверх набора медленных, флаки end-to-end тестов.

В обычных тестах я заменяю внешний API контролируемыми дублёрами, сохраняя небольшой отдельный набор реальных интеграционных проверок.

• Я изолирую внешний вызов за интерфейсом и подставляю фейк в тестах, а для HTTP поднимаю stub-сервер вроде WireMock или записанную фикстуру, чтобы реального сетевого вызова не было.
• Контрактные тесты или записанная кассета держат заглушку честной относительно реальной формы API, а небольшое число реальных вызовов я гоняю в отдельном, более редком интеграционном наборе.
• Так обычный прогон остаётся быстрым, детерминированным и без флаки из-за лимитов частоты или простоя.

Контрактные тесты проверяют, что независимо деплоящиеся потребители и провайдеры по-прежнему согласны о своём интерфейсе.

• Контрактные тесты проверяют, что провайдер и потребитель согласны о форме и семантике их интерфейса, не поднимая обе системы вместе, обычно с инструментом вроде Pact.
• Потребитель записывает свои ожидания как контракт, а провайдер проигрывает их в CI, доказывая, что всё ещё удовлетворяет каждого потребителя.
• Они решают проблему независимо деплоящихся команд, которые молча ломают друг друга, ловя несовместимые изменения до того, как те дойдут до продакшена.

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

• Моки вредят, когда слишком жёстко фиксируют взаимодействия, и тест проверяет, как код работает, а не что он выдаёт, и тогда любой рефакторинг ломает тесты.
• Они также вводят в заблуждение, когда мок расходится с поведением реальной зависимости и даёт зелёные тесты против фантазии, и когда мокаешь типы, которыми не владеешь, так что заглушка кодирует неверные допущения.
• Я предпочитаю мокать на настоящих границах, использовать реальные объекты или фейки для внутрипроцессных коллабораторов и проверять наблюдаемые результаты, а не последовательности вызовов.

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

• Я делаю флаки видимой, вынося известные флаки-тесты в отдельную дорожку и отслеживая долю флаки, чтобы основная сборка снова работала по принципу зелёное значит зелёное, а красное реально блокировало мержи.
• Потом я чиню корневые причины по одной: общее состояние и порядок тестов, реальное время и sleep, сетевые и таймингованные гонки, недетерминированный порядок.
• Настоящая цель в том, чтобы вернуть доверие к сигналу, ведь набор, который все игнорируют, не даёт защиты, сколько бы тестов в нём ни было.

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

• Я никогда не читаю системные часы прямо в бизнес-логике, а внедряю абстракцию часов, чтобы тесты могли подать фейковое или фиксированное время и двигать его детерминированно, с инструментами вроде libfaketime или управляемых часов в языке.
• Для запланированных задач я тестирую логику триггера отдельно от расписания и проверяю границы вроде момента прямо перед истечением и сразу после.
• Так истечение токенов, ретраи с backoff и окна cron становятся полностью воспроизводимыми без ожидания реальных секунд.

Сначала я защищаю тестами рискованное поведение легаси-кода, а затем создаю швы для более точечных проверок и безопасных изменений.

• Я начинаю с характеризующих тестов, которые фиксируют текущее поведение, даже если оно с причудами, чтобы получить страховку до любых изменений, следуя подходу Майкла Фезерса с поиском швов для разрыва зависимостей.
• Сначала я добавляю тесты на самом высоком уровне, куда дёшево дотянуться, часто вокруг целого модуля, потом опускаю покрытие ниже по мере ввода швов и точек внедрения.
• Приоритет идёт коду, который я собираюсь менять, и самым рискованным путям, а не гонке за числом покрытия по мёртвому коду.

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

• Я намеренно вызываю сбои через инъекцию отказов: заставляю мок бросать исключение, возвращаю ответы с ошибками, симулирую таймауты и оборванные соединения и подаю некорректный ввод.
• Я проверяю не только что оно падает, но и что падает правильно: верный статус, чистый откат, отсутствие утечки ресурсов и полезное сообщение, а ещё что ретраи и фолбэки реально срабатывают.
• Инъекция отказов и инструменты вроде проксирующего инжектора сбоев или хаос-экспериментов помогают покрыть пути, которые редко исполняются при нормальной работе.

Быстрый набор минимизирует дорогие границы и сохраняет для команды короткую и надёжную петлю обратной связи.

• Скорость идёт от того, что большинство тестов держат в процессе и чистыми, избегают реального I/O, разделяют дорогую подготовку, гоняют параллельно и используют test containers только там, где реальная зависимость необходима.
• Медленные наборы запускают реже, поэтому баги находят позже, а разработчики теряют поток, ожидая, и это тихо разрушает всю петлю обратной связи.
• Я отношусь ко времени набора как к метрике первого класса и закладываю бюджет, ведь набор, который проходит за секунды, гоняют на каждое сохранение, а двадцатиминутный пропускают.

Я применяю TDD к понятному нетривиальному поведению и ослабляю подход при реальном исследовании или для одноразового кода.

• Я использую TDD там, где поведение хорошо понятно, а логика нетривиальна: пишу падающий тест, делаю его зелёным просто, потом рефакторю, и это держит дизайн тестируемым, а обратную связь плотной.
• Я пропускаю или ослабляю его, когда исследую неизвестный дизайн или делаю спайк-прототип, где интерфейс ещё плывёт, и для тривиального клеевого кода или одноразовых скриптов.
• Даже тогда я обычно дописываю тесты, когда форма устоялась, чтобы исследование не уехало в продакшен непокрытым.