💡 Инструкция: Выберите один ответ из пяти. Время — 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, памяти или задержки может иметь несколько независимых объяснений.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Это объясняется тем, что симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Это объясняется тем, что безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката.
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Это объясняется тем, что локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Это объясняется тем, что симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Вопрос 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
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Причина такого результата: архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Причина такого результата: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Причина такого результата: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Причина такого результата: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Причина такого результата: технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Вопрос 3 из 30
Проследите выполнение фрагмента. Какой результат верен для темы «Локализация причины»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Локализация причины Копировать
# Проследите выполнение и выберите точный результат.
if Feature.enabled?(:new_cache, request_id)
NewCache.fetch(key) { compute.call }
else
compute.call
end
Код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint. Такой итог следует из правила: локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Такой итог следует из правила: сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Такой итог следует из правила: технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема.
Бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок. Такой итог следует из правила: локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием. Такой итог следует из правила: локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Вопрос 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)
Одновременное изменение пула, таймаута и запроса может улучшить метрику, но не показывает, что было причиной. Причина — симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Причина — симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов. Причина — симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений.
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Причина — безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката.
Вывод «сервер медленный из-за GC» только по высокому RSS смешивает удержание памяти, нативные буферы и нагрузку. Причина — локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному.
Вопрос 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
Какой принцип темы «Симптомы» переносится на другие примеры того же типа? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Безопасное исправление минимально, обратимо и сопровождается проверкой целостности; срочность не отменяет план отката. Поэтому код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений. Поэтому бинарное отключение нового кэша только для части трафика показывает, связан ли он с ростом ошибок.
Локализация сравнивает группы, версии и этапы запроса; минимальный воспроизводимый путь должен исключать соседние компоненты по одному. Поэтому код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений. Поэтому снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием.
Симптом — наблюдаемое отклонение, а не причина: рост 500, памяти или задержки может иметь несколько независимых объяснений. Поэтому код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Вопрос 14 из 30
Какой механизм объясняет и обычный, и граничный сценарий «Сбор фактов»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Архитектура должна эволюционировать по повторяющимся давлениям и измеренным ограничениям; один инцидент не всегда оправдывает новый сервис или очередь. Из этого следует, что снимок фиксирует монотонную временную отметку, RSS, число живых потоков и release одним событием.
Сбор фактов должен сохранять состояние до вмешательства: версия, процессы, очереди, профили, журналы, последние изменения и состояние зависимостей. Из этого следует, что код группирует ошибки по классу и маршруту, позволяя увидеть, что всплеск ограничен одним endpoint.
Технический долг после инцидента описывается конкретной отсутствующей защитой, владельцем и сроком; формулировка «переписать сервис» неуправляема. Из этого следует, что снимок фиксирует монотонную временную отметку, 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
Разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа. Это изменение устраняет проблему: перезапуск до сохранения heap/thread dump убирает симптом и уничтожает наиболее ценные данные о причине.
Подготовить безопасную команду снимка заранее и собирать минимум фактов до рестарта, если это не увеличивает ущерб. Это изменение устраняет проблему: патч `rescue nil` снижает число 500, но превращает повреждение данных в «успешные» ответы и лишает сигналов.
Сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения. Это изменение устраняет проблему: перезапуск до сохранения 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
Какую проверку стоит добавить, чтобы не ограничиться счастливым путём «Симптомы»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Проверить изменение трафика и мониторинга: новый датчик или маршрут может создать ложный «всплеск». Этот сценарий проверяет исправление: сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины.
Проверить изменение трафика и мониторинга: новый датчик или маршрут может создать ложный «всплеск». Этот сценарий проверяет исправление: закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Этот сценарий проверяет исправление: сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины.
Проверить выполнение follow-up через срок: закрытая карточка без работающей метрики не уменьшает риск. Этот сценарий проверяет исправление: сформулировать симптом числом, временем начала, охватом и сравнением с нормой до выбора причины.
Проверить изменение трафика и мониторинга: новый датчик или маршрут может создать ложный «всплеск». Этот сценарий проверяет исправление: менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы.
Вопрос 27 из 30
Чем дополнить базовый тест, чтобы проверить ограничение темы «Локализация причины»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Проверка относится к изменению: закрыть конкретный путь отказа, добавить регрессионную проверку и наблюдать ключевой инвариант после выпуска.
Проверить режим отказа нового компонента: изоляция нагрузки должна улучшать, а не расширять область недоступности. Проверка относится к изменению: менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Проверка относится к изменению: менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Проверка относится к изменению: разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа.
Проверить частично созданный файл/экспорт при падении между batch: нужен атомарный финальный шаг или возобновление. Проверка относится к изменению: менять один фактор, заранее записывать ожидаемый сигнал и сравнивать контрольную/экспериментальную группы.
Вопрос 30 из 30
Чем дополнить базовый тест, чтобы проверить ограничение темы «Эволюция архитектуры»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Проверить режим отказа нового компонента: изоляция нагрузки должна улучшать, а не расширять область недоступности. Такой контрпример нужен для решения: разбить последствия на защиту, наблюдаемость и упрощение; каждую задачу связать с обнаруженным механизмом отказа.
Проверить частично созданный файл/экспорт при падении между batch: нужен атомарный финальный шаг или возобновление. Такой контрпример нужен для решения: сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения.
Проверить, что feature flag стабильно распределяет один и тот же запрос/пользователя, иначе группы смешиваются. Такой контрпример нужен для решения: сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения.
Проверить режим отказа нового компонента: изоляция нагрузки должна улучшать, а не расширять область недоступности. Такой контрпример нужен для решения: сравнить самый простой локальный вариант с архитектурным разделением, задать метрики успеха и дату пересмотра решения.
Проверить режим отказа нового компонента: изоляция нагрузки должна улучшать, а не расширять область недоступности. Такой контрпример нужен для решения: подготовить безопасную команду снимка заранее и собирать минимум фактов до рестарта, если это не увеличивает ущерб.