💡 Инструкция: Выберите один ответ из пяти. Время — 85 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 6 тематических результатов и разбор всех ответов.
Вопрос 1 из 30
Разберите выражения по порядку. Как завершится фрагмент из раздела «Симптомы»? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Симптомы Копировать
# Проследите выполнение и выберите точный результат.
errors = events.group_by { |e| [e[:route], e[:error_class]] }
summary = errors.transform_values(&:count)
p summary.sort_by { |_, count| -count }.first(5)
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Это объясняется тем, что симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Это объясняется тем, что симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Это объясняется тем, что безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Это объясняется тем, что симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Это объясняется тем, что локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Вопрос 2 из 30
Какой вариант верно описывает состояние объектов после выполнения кода «Сбор фактов»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Сбор фактов Копировать
# Проследите выполнение и выберите точный результат.
snapshot = {
release: ENV['APP_REVISION'],
monotonic_s: Process.clock_gettime(Process::CLOCK_MONOTONIC).round,
pid: Process.pid,
rss_kb: `ps -o rss= -p #{Process.pid}`.to_i,
threads: Thread.list.count,
gc: GC.stat.slice(:heap_live_slots, :major_gc_count)
}
p snapshot
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Причина такого результата: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Причина такого результата: технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Причина такого результата: архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Причина такого результата: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Причина такого результата: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Вопрос 3 из 30
Проследите выполнение фрагмента. Какой результат верен для темы «Локализация причины»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Локализация причины Копировать
# Проследите выполнение и выберите точный результат.
if Feature.enabled?(:new_cache, request_id)
NewCache.fetch(key) { compute.call }
else
compute.call
end
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Такой итог следует из правила: локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Такой итог следует из правила: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Такой итог следует из правила: локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Такой итог следует из правила: технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Такой итог следует из правила: локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Вопрос 5 из 30
Что произойдёт после последней строки в примере по теме «Технический долг»? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Технический долг Копировать
# Проследите выполнение и выберите точный результат.
require 'date'
follow_up = {
owner: 'reporting-team',
due: Date.today + 14,
action: 'add queue age SLO and idempotency regression test',
evidence: incident_id
}
p follow_up
Выделение компонента рассматривается только после определения границы данных, нагрузки, отказа и эксплуатационного владельца. Наблюдение согласуется с тем, что технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Задача фиксирует лимит очереди, метрику возраста и тест повторной доставки вместо общей просьбы улучшить надёжность. Наблюдение согласуется с тем, что сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Задача фиксирует лимит очереди, метрику возраста и тест повторной доставки вместо общей просьбы улучшить надёжность. Наблюдение согласуется с тем, что архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Задача фиксирует лимит очереди, метрику возраста и тест повторной доставки вместо общей просьбы улучшить надёжность. Наблюдение согласуется с тем, что технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Ограничение размера batch уменьшает память без изменения формата результата и может быть быстро отменено. Наблюдение согласуется с тем, что технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Вопрос 6 из 30
Как следует прочитать результат показанного примера «Эволюция архитектуры»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Эволюция архитектуры Копировать
# Проследите выполнение и выберите точный результат.
decision = {
problem: 'report generation saturates web memory',
options: %w[streaming bounded_job separate_service],
metrics: %w[rss_mb queue_age_seconds failure_rate],
review_after: '30d'
}
p decision
Задача фиксирует лимит очереди, метрику возраста и тест повторной доставки вместо общей просьбы улучшить надёжность. Этот вывод опирается на правило: архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Выделение компонента рассматривается только после определения границы данных, нагрузки, отказа и эксплуатационного владельца. Этот вывод опирается на правило: технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Ограничение размера batch уменьшает память без изменения формата результата и может быть быстро отменено. Этот вывод опирается на правило: архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Выделение компонента рассматривается только после определения границы данных, нагрузки, отказа и эксплуатационного владельца. Этот вывод опирается на правило: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Выделение компонента рассматривается только после определения границы данных, нагрузки, отказа и эксплуатационного владельца. Этот вывод опирается на правило: архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Вопрос 7 из 30
Обычный сценарий проходит. Какой риск остаётся в теме «Симптомы»? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Симптомы Копировать
# Обычный запуск проходит. Найдите скрытый риск.
errors = events.group_by { |e| [e[:route], e[:error_class]] }
summary = errors.transform_values(&:count)
p summary.sort_by { |_, count| -count }.first(5)
Патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов. Причина — симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Причина — локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной. Причина — симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Причина — безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката.
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Причина — симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Вопрос 8 из 30
Какой отказ связан с причиной в коде, а не с внешним шумом, в теме «Сбор фактов»? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Сбор фактов Копировать
# Обычный запуск проходит. Найдите скрытый риск.
snapshot = {
release: ENV['APP_REVISION'],
monotonic_s: Process.clock_gettime(Process::CLOCK_MONOTONIC).round,
pid: Process.pid,
rss_kb: `ps -o rss= -p #{Process.pid}`.to_i,
threads: Thread.list.count,
gc: GC.stat.slice(:heap_live_slots, :major_gc_count)
}
p snapshot
Перезапуск до сохранения heap/thread dump убирает симптом и уничтожает наиболее ценные данные о причине. Этот риск связан с тем, что сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Перезапуск до сохранения heap/thread dump убирает симптом и уничтожает наиболее ценные данные о причине. Этот риск связан с тем, что архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов. Этот риск связан с тем, что сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Перезапуск до сохранения heap/thread dump убирает симптом и уничтожает наиболее ценные данные о причине. Этот риск связан с тем, что технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной. Этот риск связан с тем, что сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Вопрос 9 из 30
Какое допущение делает этот код по теме «Локализация причины» ненадёжным? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Локализация причины Копировать
# Обычный запуск проходит. Найдите скрытый риск.
if Feature.enabled?(:new_cache, request_id)
NewCache.fetch(key) { compute.call }
else
compute.call
end
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Уязвимое место возникает потому, что локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной. Уязвимое место возникает потому, что технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной. Уязвимое место возникает потому, что сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов. Уязвимое место возникает потому, что локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной. Уязвимое место возникает потому, что локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Вопрос 10 из 30
Какое скрытое условие делает фрагмент «Безопасное исправление» хрупким? Верный вариант не содержит частично правильной подмены причины или следствия.
Ruby Ruby — Безопасное исправление Копировать
# Обычный запуск проходит. Найдите скрытый риск.
scope.find_in_batches(batch_size: 500) do |batch|
Exporter.write(batch)
end
Патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов. К такому сбою приводит правило: локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. К такому сбою приводит правило: безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката.
Патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов. К такому сбою приводит правило: безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката.
Одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной. К такому сбою приводит правило: безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката.
Патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов. К такому сбою приводит правило: симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Вопрос 11 из 30
Какой рабочий сбой вероятнее всего связан именно с механизмом «Технический долг»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Технический долг Копировать
# Обычный запуск проходит. Найдите скрытый риск.
require 'date'
follow_up = {
owner: 'reporting-team',
due: Date.today + 14,
action: 'add queue age SLO and idempotency regression test',
evidence: incident_id
}
p follow_up
Большой рефакторинг сразу после инцидента без характеризующих тестов добавляет риск повторного отказа под видом устранения долга. Источник риска: технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Большой рефакторинг сразу после инцидента без характеризующих тестов добавляет риск повторного отказа под видом устранения долга. Источник риска: архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Перенос метода в микросервис сохраняет тот же алгоритм, но добавляет сеть, повторную доставку и распределённую целостность. Источник риска: технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Источник риска: технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Большой рефакторинг сразу после инцидента без характеризующих тестов добавляет риск повторного отказа под видом устранения долга. Источник риска: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Вопрос 12 из 30
Какой рабочий сбой вероятнее всего связан именно с механизмом «Эволюция архитектуры»? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Эволюция архитектуры Копировать
# Обычный запуск проходит. Найдите скрытый риск.
decision = {
problem: 'report generation saturates web memory',
options: %w[streaming bounded_job separate_service],
metrics: %w[rss_mb queue_age_seconds failure_rate],
review_after: '30d'
}
p decision
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Проблема возникает из-за того, что архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Перенос метода в микросервис сохраняет тот же алгоритм, но добавляет сеть, повторную доставку и распределённую целостность. Проблема возникает из-за того, что архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Перенос метода в микросервис сохраняет тот же алгоритм, но добавляет сеть, повторную доставку и распределённую целостность. Проблема возникает из-за того, что технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Перенос метода в микросервис сохраняет тот же алгоритм, но добавляет сеть, повторную доставку и распределённую целостность. Проблема возникает из-за того, что сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Большой рефакторинг сразу после инцидента без характеризующих тестов добавляет риск повторного отказа под видом устранения долга. Проблема возникает из-за того, что архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Вопрос 13 из 30
Какой принцип темы «Симптомы» переносится на другие примеры того же типа? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений. Поэтому код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений. Поэтому снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием.
Локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному. Поэтому код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений. Поэтому бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок.
Безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката. Поэтому код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Вопрос 14 из 30
Какой механизм объясняет и обычный, и граничный сценарий «Сбор фактов»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей. Из этого следует, что код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей. Из этого следует, что снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием.
Архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь. Из этого следует, что снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием.
Технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема. Из этого следует, что снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием.
Сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей. Из этого следует, что бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок.
Вопрос 15 из 30
Что является технической причиной наблюдаемого поведения «Локализация причины»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений. Наблюдаемое следствие: бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок.
Технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема. Наблюдаемое следствие: бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок.
Локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному. Наблюдаемое следствие: код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному. Наблюдаемое следствие: снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием.
Локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному. Наблюдаемое следствие: бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок.
Вопрос 17 из 30
Какое правило остаётся верным, даже если вход и порядок вызовов изменятся, в теме «Технический долг»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема. Это правило даёт такой результат: ограничение размера batch уменьшает память без изменения формата результата и может быть быстро отменено.
Технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема. Это правило даёт такой результат: выделение компонента рассматривается только после определения границы данных, нагрузки, отказа и эксплуатационного владельца.
Сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей. Это правило даёт такой результат: задача фиксирует лимит очереди, метрику возраста и тест повторной доставки вместо общей просьбы улучшить надёжность.
Архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь. Это правило даёт такой результат: задача фиксирует лимит очереди, метрику возраста и тест повторной доставки вместо общей просьбы улучшить надёжность.
Технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема. Это правило даёт такой результат: задача фиксирует лимит очереди, метрику возраста и тест повторной доставки вместо общей просьбы улучшить надёжность.
Вопрос 18 из 30
Какое общее правило связывает результат и риск в разделе «Эволюция архитектуры»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей. Практическое следствие правила: выделение компонента рассматривается только после определения границы данных, нагрузки, отказа и эксплуатационного владельца.
Технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема. Практическое следствие правила: выделение компонента рассматривается только после определения границы данных, нагрузки, отказа и эксплуатационного владельца.
Архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь. Практическое следствие правила: выделение компонента рассматривается только после определения границы данных, нагрузки, отказа и эксплуатационного владельца.
Архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь. Практическое следствие правила: задача фиксирует лимит очереди, метрику возраста и тест повторной доставки вместо общей просьбы улучшить надёжность.
Архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь. Практическое следствие правила: ограничение размера batch уменьшает память без изменения формата результата и может быть быстро отменено.
Вопрос 19 из 30
Что нужно поменять, чтобы ошибка «Симптомы» не возвращалась при следующем изменении? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Симптомы Копировать
# Выберите изменение, которое исправляет причину.
errors = events.group_by { |e| [e[:route], e[:error_class]] }
summary = errors.transform_values(&:count)
p summary.sort_by { |_, count| -count }.first(5)
Сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины. Так закрывается риск: одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной.
Закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска. Так закрывается риск: вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку.
Менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы. Так закрывается риск: вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку.
Сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины. Так закрывается риск: вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку.
Сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины. Так закрывается риск: патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов.
Вопрос 20 из 30
Какое изменение устраняет причину проблемы в теме «Сбор фактов», а не маскирует симптом? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Сбор фактов Копировать
# Выберите изменение, которое исправляет причину.
snapshot = {
release: ENV['APP_REVISION'],
monotonic_s: Process.clock_gettime(Process::CLOCK_MONOTONIC).round,
pid: Process.pid,
rss_kb: `ps -o rss= -p #{Process.pid}`.to_i,
threads: Thread.list.count,
gc: GC.stat.slice(:heap_live_slots, :major_gc_count)
}
p snapshot
Подготовить безопасную команду снимка заранее и собирать минимум фактов до рестарта, если это не увеличивает ущерб. Это изменение устраняет проблему: патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов.
Подготовить безопасную команду снимка заранее и собирать минимум фактов до рестарта, если это не увеличивает ущерб. Это изменение устраняет проблему: перезапуск до сохранения heap/thread dump убирает симптом и уничтожает наиболее ценные данные о причине.
Подготовить безопасную команду снимка заранее и собирать минимум фактов до рестарта, если это не увеличивает ущерб. Это изменение устраняет проблему: одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной.
Разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа. Это изменение устраняет проблему: перезапуск до сохранения heap/thread dump убирает симптом и уничтожает наиболее ценные данные о причине.
Сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения. Это изменение устраняет проблему: перезапуск до сохранения heap/thread dump убирает симптом и уничтожает наиболее ценные данные о причине.
Вопрос 21 из 30
Какое инженерное решение лучше всего соответствует механизму «Локализация причины»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Локализация причины Копировать
# Выберите изменение, которое исправляет причину.
if Feature.enabled?(:new_cache, request_id)
NewCache.fetch(key) { compute.call }
else
compute.call
end
Закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска. Такая правка нужна из-за риска: одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной.
Менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы. Такая правка нужна из-за риска: одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной.
Менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы. Такая правка нужна из-за риска: патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов.
Разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа. Такая правка нужна из-за риска: одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной.
Менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы. Такая правка нужна из-за риска: вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку.
Вопрос 22 из 30
Какой вариант правки выдержит граничный сценарий темы «Безопасное исправление»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Безопасное исправление Копировать
# Выберите изменение, которое исправляет причину.
scope.find_in_batches(batch_size: 500) do |batch|
Exporter.write(batch)
end
Разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа. Решение адресует следующий дефект: патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов.
Менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы. Решение адресует следующий дефект: патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов.
Закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска. Решение адресует следующий дефект: патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов.
Закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска. Решение адресует следующий дефект: одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной.
Закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска. Решение адресует следующий дефект: вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку.
Вопрос 23 из 30
Что следует изменить в решении «Технический долг», чтобы закрыть исходный риск? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Технический долг Копировать
# Выберите изменение, которое исправляет причину.
require 'date'
follow_up = {
owner: 'reporting-team',
due: Date.today + 14,
action: 'add queue age SLO and idempotency regression test',
evidence: incident_id
}
p follow_up
Разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа. Именно эта мера закрывает риск: большой рефакторинг сразу после инцидента без характеризующих тестов добавляет риск повторного отказа под видом устранения долга.
Подготовить безопасную команду снимка заранее и собирать минимум фактов до рестарта, если это не увеличивает ущерб. Именно эта мера закрывает риск: большой рефакторинг сразу после инцидента без характеризующих тестов добавляет риск повторного отказа под видом устранения долга.
Закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска. Именно эта мера закрывает риск: большой рефакторинг сразу после инцидента без характеризующих тестов добавляет риск повторного отказа под видом устранения долга.
Разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа. Именно эта мера закрывает риск: перенос метода в микросервис сохраняет тот же алгоритм, но добавляет сеть, повторную доставку и распределённую целостность.
Разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа. Именно эта мера закрывает риск: вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку.
Вопрос 24 из 30
Какой подход сохраняет намерение кода и устраняет дефект в теме «Эволюция архитектуры»? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Ruby Ruby — Эволюция архитектуры Копировать
# Выберите изменение, которое исправляет причину.
decision = {
problem: 'report generation saturates web memory',
options: %w[streaming bounded_job separate_service],
metrics: %w[rss_mb queue_age_seconds failure_rate],
review_after: '30d'
}
p decision
Подготовить безопасную команду снимка заранее и собирать минимум фактов до рестарта, если это не увеличивает ущерб. После изменения не должен сохраняться риск: перенос метода в микросервис сохраняет тот же алгоритм, но добавляет сеть, повторную доставку и распределённую целостность.
Сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения. После изменения не должен сохраняться риск: перенос метода в микросервис сохраняет тот же алгоритм, но добавляет сеть, повторную доставку и распределённую целостность.
Сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения. После изменения не должен сохраняться риск: большой рефакторинг сразу после инцидента без характеризующих тестов добавляет риск повторного отказа под видом устранения долга.
Сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения. После изменения не должен сохраняться риск: вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку.
Разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа. После изменения не должен сохраняться риск: перенос метода в микросервис сохраняет тот же алгоритм, но добавляет сеть, повторную доставку и распределённую целостность.
Вопрос 25 из 30
Какую проверку стоит добавить, чтобы не ограничиться счастливым путём «Симптомы»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Проверить выполнение follow-up через срок: закрытая карточка без работающей метрики не уменьшает риск. Этот сценарий проверяет исправление: сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины.
Проверить изменение трафика и мониторинга: новый датчик или маршрут может создать ложный «всплеск». Этот сценарий проверяет исправление: сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины.
Проверить изменение трафика и мониторинга: новый датчик или маршрут может создать ложный «всплеск». Этот сценарий проверяет исправление: закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска.
Проверить изменение трафика и мониторинга: новый датчик или маршрут может создать ложный «всплеск». Этот сценарий проверяет исправление: менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Этот сценарий проверяет исправление: сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины.
Вопрос 27 из 30
Чем дополнить базовый тест, чтобы проверить ограничение темы «Локализация причины»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Проверка относится к изменению: разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Проверка относится к изменению: закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска.
Проверить частично созданный файл/экспорт при падении между batch: нужен атомарный финальный шаг или возобновление. Проверка относится к изменению: менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы.
Проверить режим отказа нового компонента: изоляция нагрузки должна улучшать, а не расширять область недоступности. Проверка относится к изменению: менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Проверка относится к изменению: менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы.
Вопрос 30 из 30
Чем дополнить базовый тест, чтобы проверить ограничение темы «Эволюция архитектуры»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Такой контрпример нужен для решения: сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения.
Проверить режим отказа нового компонента: изоляция нагрузки должна улучшать, а не расширять область недоступности. Такой контрпример нужен для решения: сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения.
Проверить частично созданный файл/экспорт при падении между batch: нужен атомарный финальный шаг или возобновление. Такой контрпример нужен для решения: сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения.
Проверить режим отказа нового компонента: изоляция нагрузки должна улучшать, а не расширять область недоступности. Такой контрпример нужен для решения: подготовить безопасную команду снимка заранее и собирать минимум фактов до рестарта, если это не увеличивает ущерб.
Проверить режим отказа нового компонента: изоляция нагрузки должна улучшать, а не расширять область недоступности. Такой контрпример нужен для решения: разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа.