Вопросы на собеседовании: SRE-инженер
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior.
Смотреть пример резюме: SRE-инженер →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Я запускаю полный request path в трёх зонах и рассчитываю любые две зоны на peak traffic.
- Monthly target 99,99% допускает около 4,32 минуты bad availability, поэтому zone recovery не может зависеть от manual provisioning.
- Stateless services, ingress, caches, queues и database quorum распределены по зонам без одного shared egress или identity dependency.
- Каждая зона даёт примерно половину peak capacity, удерживая normal peak utilization около 67% до потери одной зоны.
Зачем это спрашивают: Интервьюер проверяет перевод availability target в failure domains, redundancy dependencies и capacity math.
Я выбираю active-passive write ownership, потому что global ordering и RPO zero требуют одного fenced serialization path.
- Passive region постоянно получает synchronous или quorum-protected data ценой WAN latency или сниженной write availability при partition.
- Reads могут работать active-active, если freshness contract позволяет, но только один region имеет current fencing token для writes.
- Timed promotion test должен fence old writer и восстановить writes за десять минут до выполнения RTO claim.
Зачем это спрашивают: Сильный ответ выбирает topology по ordering, data loss и recovery, а не считает active-active лучшим default.
Я требую sustained user-path failure от independent observers и proof готовности destination.
- Минимум три из пяти probes из разных networks должны видеть больше 5% errors или SLO-breaking latency две минуты.
- Target region должен иметь healthy dependencies, replication внутри RPO и capacity на 40 000 requests в секунду.
- Failover использует hysteresis и minimum hold 15 минут, чтобы краткое recovery не flapping traffic между regions.
Зачем это спрашивают: Интервьюер оценивает failure detection, false-positive control и destination readiness с явными thresholds.
Я выбираю asynchronous cross-region replication, потому что synchronous acknowledgement не помещается в 25 мс через link 80 мс.
- Local writes подтверждаются после durable regional commit, а replication lag измеряется против RPO 30 секунд.
- Alerts срабатывают до полного расходования budget, а promotion блокируется при replica position за его пределами.
- Ledgers с настоящим zero loss требуют другого latency contract или quorum placement ближе к writers.
Зачем это спрашивают: Сильный ответ явно выбирает между latency и data loss и не обещает несовместимые guarantees.
Я требую consensus-backed lease и fence former primary до приёма writes новым region.
- Promotion получает monotonic fencing token из odd quorum в трёх independent failure domains.
- Storage и downstream consumers отклоняют writes со старым token, даже если old primary виден части clients.
- Loss of quorum останавливает promotion и write availability, но не ослабляет single-writer invariant ради пяти минут.
Зачем это спрашивают: Интервьюер проверяет consensus, fencing и готовность пожертвовать write availability вместо corruption ordered state.
Я запускаю autonomous cluster в каждом region и заранее готовлю recovery region к заявленному traffic shift.
- Каждый cluster имеет local ingress, DNS, registry, secrets, observability и не зависит от control plane другого region.
- Recovery region держит warm capacity для достижения 60 000 requests в секунду внутри 15 минут после cache warm-up.
- Global traffic движется после data fencing и dependency checks, а GitOps сохраняет equivalent configuration без одного shared runtime controller.
Зачем это спрашивают: Сильный ответ сохраняет regional autonomy и включает capacity, data и platform dependencies в RTO.
Я создаю минимум 20 repeatable cells и детерминированно направляю каждого user в одну cell.
- Каждая cell владеет bounded compute, queues, caches и data partitions, поэтому overload не потребляет pool healthy cell.
- Global identity и routing остаются minimal и redundant, иначе shared dependency разрушит blast-radius goal 100 000 users.
- Capacity planning включает одну spare cell и controlled tenant-rebalancing path вместо перемещения users во время active failure.
Зачем это спрашивают: Интервьюер оценивает blast-radius arithmetic, dependency isolation и operating cost cell recovery.
Я использую regional Vault performance replica с tested promotion и leases дольше 30-минутного isolation window.
- Applications authenticate через regional workload identity и cache только current credentials, не reusable root или bootstrap tokens.
- Promotion включает seal или auto-unseal availability, storage health, token semantics и fencing former active cluster.
- Game day доказывает renewal или safe degradation всех 80 сервисов за 30 минут без bypass authorization.
Зачем это спрашивают: Сильный ответ охватывает Vault replication, credential lifetime, promotion и application behavior во время isolation.
Сначала я оспариваю total global order и shard serialization по account, если invariant позволяет.
- Per-account leaders сохраняют нужный users order, а independent shards параллельно обрабатывают unrelated accounts.
- Если total order обязателен, один consensus leader и WAN quorum становятся throughput и latency ceiling.
- Benchmark должен выдержать 50 000 writes в секунду при leader loss и показать write unavailability во время quorum changes.
Зачем это спрашивают: Интервьюер проверяет способность сузить дорогой ordering guarantee и измерить неизбежную coordination cost.
Я запускаю полный traffic и data exercise из external probes, а не только останавливаю application instances.
- Test удаляет regional ingress и replication link, затем отдельно измеряет detection, decision, promotion, traffic shift и cache warm-up.
- Database positions и business checks доказывают data loss внутри 60 секунд, а old-primary fencing предотвращает dual writes.
- Design проходит после двух consecutive exercises с user recovery до 12 минут и rehearsal failback.
Зачем это спрашивают: Сильный ответ валидирует end-to-end recovery и data correctness повторяемыми timed evidence.
Baseline forecast составляет около 57 800 requests в секунду, затем я добавляю failure и forecast headroom.
- Расчёт: 25 000 умножить на 1,15 в шестой степени, а не добавить плоские 90%.
- Я benchmark sustainable throughput на latency SLO и планирую минимум 30% uncertainty сверх forecast.
- Zone-loss capacity считается отдельно, чтобы normal placement не съело headroom крупнейшего tolerated failure.
Зачем это спрашивают: Интервьюер оценивает compounding growth, performance limits, uncertainty и failure capacity как отдельные inputs.
Я provision 15 000 requests в секунду на зону, получая 45 000 total и 30 000 после failure одной зоны.
- Normal peak использует около 67% total capacity, что является ценой immediate one-zone tolerance.
- Расчёт включает database connections, queue throughput, egress и cache capacity, а не только application CPU.
- Zone-loss load test должен удержать latency и errors при 30 000 requests в секунду до признания headroom реальным.
Зачем это спрашивают: Сильный ответ выполняет failure-capacity math и применяет его ко всем constrained dependencies.
Я держу warm capacity для 60-second burst, потому что node autoscaling не обгонит четырёхминутный startup.
- Workload scaling использует leading signal вроде queue age или concurrency до CPU saturation.
- Placeholder capacity или minimum node floor покрывает measured burst, пока присоединяются новые ноды.
- Отдельно я измеряю cloud launch, bootstrap, CNI, image pull и warm-up для сокращения четырёх минут без обещания instant response.
Зачем это спрашивают: Интервьюер проверяет recognition timing mismatch и сочетание predictive scaling с reserved headroom.
Я рассчитываю requests для каждого workload из sustained percentiles и burst behavior, а не cluster-wide average 35%.
- CPU requests около p95 с workload-specific margin улучшают placement, а latency-sensitive bursts используют spare CPU без tight cap.
- Memory использует более высокий working-set percentile, потому что underestimation вызывает eviction или OOM, а не throttling.
- Я canary новые values и сохраняю allocatable capacity на one-zone loss, проверяя throttling, Pending Pods и SLOs.
Зачем это спрашивают: Сильный ответ отличает averages, tail usage, CPU и memory behavior и failure headroom.
Для recovery нужно минимум 13 workers: 400 в секунду drains burst, а 100 в секунду обслуживают новые arrivals.
- Drain requirement равен 240 000, делённым на 600 секунд, затем incoming traffic добавляется до division на worker throughput.
- Я provision около 16 workers для retries и processing variance в рамках broker и downstream limits.
- Queue age, а не только depth, управляет scaling и подтверждает oldest message ниже десяти минут.
Зачем это спрашивают: Интервьюер проверяет queue-drain arithmetic с new arrivals, variability и downstream capacity.
Сначала я optimize и vertical scale primary, потому что read replicas не убирают write bottleneck.
- Query profiles, batching, indexes, connection overhead и WAL или storage limits показывают истинность CPU constraint.
- Более крупный primary покупает время с минимальной application complexity, но его hardware и failover ceiling документируются.
- Sharding начинается, только когда projected writes превышают ceiling, по key с ровным load и сохранением transaction boundaries.
Зачем это спрашивают: Сильный ответ выбирает scaling method по measured write bottleneck и считает sharding deliberate complexity cost.
Я воспроизвожу production endpoint mix через open workload model и тестирую выше peak и failure capacity.
- Payload sizes, cache state, geographic latency, authentication и background jobs соответствуют production вместо uniform empty requests.
- Load проходит 50%, 100% и 130%, затем повторяет peak после удаления одной зоны.
- Test фиксирует latency histograms, errors, saturation, queues и dependency limits достаточно долго для leaks и autoscaling delay.
Зачем это спрашивают: Интервьюер оценивает representative workload, coordinated-omission avoidance и explicit failure-capacity validation.
Я планирую regional reservation ranges за шесть недель и держу portable overflow tier для forecast error.
- Demand делится на committed baseline, launch-driven upside и batch work, movable во времени или region.
- Каждый region отслеживает quota, reserved GPUs, allocatable GPUs, queue age и lead time следующего block.
- Я резервирую critical baseline плюс measured uncertainty, а interruptible batch поглощает range 40% вместо duplication везде.
Зачем это спрашивают: Сильный ответ сочетает long provisioning lead time, uncertain demand, regional constraints и movable workloads.
Я измеряю successful eligible checkouts и completion ниже user-relevant latency threshold на transaction boundary.
- Availability считает committed orders good, а 5xx, invalid responses или lost confirmations bad.
- Latency считает eligible journeys до 800 мс, а fast errors остаются bad outcomes.
- Dependency metrics объясняют failures, но retries и internal calls не inflate user denominator 10 000 requests в секунду.
Зачем это спрашивают: Интервьюер проверяет precise good и valid events, latency semantics и measurement на user boundary.
Я даю самый строгий target классу с наибольшей user и correctness cost, а не highest volume.
- Interactive writes могут получить availability 99,99% с latency threshold 500 мс.
- Interactive reads используют 99,9% при useful cache fallback, а batch completion 99% внутри deadline.
- Каждый request относится к одному class, поэтому high-volume reads не скрывают failure low-volume critical writes.
Зачем это спрашивают: Сильный ответ сегментирует SLO по business impact и не даёт aggregate traffic скрыть critical paths.
Закрытые вопросы
- 21
API зависит от трёх services с claimed 99,9%. Почему multiplication в 99,7% недостаточно для service SLO design?
designsloapi - 22
Streaming endpoint законно работает 30 секунд, а normal API calls должны закончиться за 400 мс. Как latency SLI обработает оба?
endpointslatencystreaming - 23
Рассчитайте monthly error budget для availability 99,9% при 100 миллионах valid requests.
reliabilityavailabilityerror-budget - 24
Спроектируйте multi-window burn-rate alerts для SLO 99,9% на 30-дневном window.
designsloalerting - 25
Critical admin API получает только 200 requests в день. Как определить meaningful reliability objective 99,9%?
reliabilityapi - 26
Search возвращает cached results возрастом до пяти минут при overload. Считать ли requests good в SLO 99,9%?
slocaching - 27
Checkout journey имеет SLO 99,95% и зависит от payment, inventory и identity. Как задать internal objectives?
slo - 28
Спроектируйте OpenTelemetry collection для 500 сервисов в трёх regions при 1 миллионе telemetry events в секунду.
designobservability - 29
Как эксплуатировать Prometheus для 30 clusters и 15 миллионов active series с retention 13 месяцев?
retentionmonitoring - 30
Metric volume растёт с 4 до 20 миллионов series после добавления user_id и raw URL labels. Какие controls нужны?
designmonitoring - 31
200 сервисов отправляют metrics, logs и traces, но release нельзя проследить во всех трёх. Какой correlation contract задать?
correlationmonitoring - 32
Tracing platform получает 2 миллиона spans в секунду, но может хранить только 5%. Как делать sampling?
- 33
Спроектируйте observability, полезную при traffic 3x normal и угрозе overload collectors от telemetry volume.
designobservability - 34
Platform имеет 800 сервисов и отправляет 600 pages в день. Какой alerting design внедрить?
alertingdesign - 35
Grafana имеет 200 dashboards, а core incident views загружаются 18 секунд. Как их переделать?
incidentsincident-managementmonitoring - 36
Определите severity levels для platform на 80 сервисов и 5 миллионов users.
severity-priority - 37
Спроектируйте sustainable 24/7 on-call rotation для десяти SRE, поддерживающих 60 сервисов.
on-calldesign - 38
Sev1 bridge собирает 30 engineers за десять минут. Какая incident-command structure должна быть готова?
incidentsincident-management - 39
Как спроектировать follow-the-sun incident handoff между тремя regions во время восьмичасового sev1?
incidentsincident-managementdesign - 40
Postmortem program создаёт 120 actions за quarter, но закрывает только 25%. Как переделать process?
incidentspostmortemsconcurrency - 41
Payment provider может быть unavailable 20 минут, а API должен ответить за две секунды. Какой degraded mode спроектировать?
designapi - 42
Multi-region API принимает 100 000 requests в секунду, а один tenant ограничен 1 000. Как распределить rate limit между regions?
api - 43
Service безопасен при 60 000 requests в секунду, но может получить 90 000. Как shed load?
- 44
Four-stage pipeline получает 8 000 events в секунду, но stage three обрабатывает только 6 000. Как спроектировать backpressure?
designresiliencebackpressure - 45
Service делает 50 000 dependency calls в секунду. Как cap retries на 10% extra load?
dependencies - 46
Задайте circuit-breaker behavior для dependency с normal load 20 000 calls в секунду и errors 0,2%.
dependencies - 47
Как совместно проверить load shedding, retry budgets и circuit breakers при 80 000 requests в секунду?
resiliencevalidationload-management - 48
Спроектируйте первый chaos experiment для three-zone service с availability 99,95% и без прошлых game days.
designavailabilitychaos-engineering - 49
Спланируйте regional game day для RTO 15 минут и RPO одна минута без риска для всех customers.
disaster-recovery - 50
40 tier-1 services требуют recurring chaos coverage. Какую программу провести за 12 месяцев?
chaos-engineeringcoverage - 51
В 09:02 UTC checkout 5xx растёт с 0,2% до 18% через две минуты после того, как release 4.17 дошёл до 40% Pods. Что вы делаете в первые 10 минут?
- 52
В 14:10 UTC payment dependency замедляется с 80 мс до 3 секунд, а три client layers усиливают 8 000 запросов в секунду до 54 000. Как вы сдержите retry storm?
resiliencedependencies - 53
С 16:00 до 16:12 API p50 остаётся 45 мс, но p99 растёт с 320 мс до 4,8 секунды у 7% users в одной зоне. Как вы проведёте диагностику?
api - 54
В 11:25 UTC PostgreSQL достигает 500 из 500 connections, API errors растут до 22%, а CPU равен только 38%. Какое incident-решение вы примете?
incidentsincident-managementapi - 55
В 08:40 UTC Kubernetes не может создавать nodes: cloud account использовал 2 000 из 2 000 vCPU, а 180 Pods остаются Pending. Как вы восстановите сервис?
kubernetes - 56
В 03:15 UTC Elasticsearch data node заполнен на 97%, watermarks блокируют writes, а logs поступают по 140 ГБ в час. Что вы сделаете до заполнения disk на 100%?
search - 57
В 19:00 UTC Kafka consumer lag растёт с 20 000 до 9 миллионов records после замедления одного downstream shard до 400 events в секунду; входящий traffic равен 6 000 в секунду. Что вы сделаете?
shardingkafka - 58
В 12:01 UTC DNS change снижает успешные lookups с 99,99% до 91% у Android clients с TTL 30 минут. Каков ваш recovery plan?
recoverydns - 59
В 06:50 UTC 28% clients отклоняют обновлённый TLS certificate из-за отсутствующей intermediate chain, а старый certificate истекает через 40 минут. Что вы сделаете?
tls - 60
В 02:20 UTC Redis выполняет failover за 18 секунд, но 600 application Pods одновременно reconnect и поднимают CPU до 96% при 35% timeouts. Как вы стабилизируете сервис?
redisresilience - 61
Release в 10:00 расходует 18% 30-дневного error budget за 25 минут, но ломается только новая reporting feature. Откатывать ли весь release?
error-budgetreliabilityrollback - 62
В 17:30 UTC включение recommendation flag для 50% users поднимает checkout p99 с 700 мс до 1,9 секунды без роста errors. Какое решение вы примете?
- 63
В 13:05 UTC schema migration держит ACCESS EXCLUSIVE lock 95 секунд, 1 800 writes стоят в очереди, а replication lag равен 70 секундам. Что вы сделаете?
schemamigrationsreplication - 64
В 09:45 UTC cache размером 2 ТБ истекает одновременно, origin traffic растёт с 15 000 до 110 000 requests в секунду, а CPU database достигает 89%. Как остановить stampede?
zero-to-onedatabasecaching - 65
В 18:20 UTC shipping provider возвращает 429 для 70% calls, 24 000 orders ожидают, а quota сбросится через 35 минут. Что вы сделаете?
- 66
В 04:12 UTC Kubernetes node upgrade вытесняет 220 Pods, 65 остаются Pending, а API availability падает до 96%. Как вы ответите?
availabilityapikubernetes - 67
С 01:00 до 05:00 memory сервиса растёт на 120 МБ в час на Pod; 14 из 80 Pods получили OOM kill, а p99 равен 1,4 секунды. Как управлять leak ночью?
memory - 68
В 15:40 UTC Java service показывает stop-the-world pauses по 9 секунд каждые 2 минуты после heap occupancy 82%, хотя CPU равен 45%. Что вы сделаете?
data-structures - 69
В 20:05 UTC одна availability zone показывает 4% packet loss, gRPC retries утраивают traffic до 72 000 calls в секунду, а provider не даёт ETA. Что вы сделаете?
availabilitygrpc - 70
В 10:30 UTC 12 из 100 API Pods получают 46% traffic и достигают 95% CPU, а остальные остаются ниже 30%. Как устранить imbalance?
restsoft-skills - 71
В 21:15 UTC один tenant отправляет 18 000 requests в секунду при контракте на 2 000, поднимая shared API p99 до 2,2 секунды для 300 tenants. Что вы сделаете?
api - 72
В 07:10 UTC NTP drift достигает 95 секунд на 32 nodes, из-за чего 14% OAuth tokens выглядят expired. Как восстановиться без приёма invalid tokens?
oauthtokensiac - 73
В 05:55 UTC identity provider ротирует signing keys, 38% API requests не проходят JWT validation, а JWKS endpoint отвечает timeout через 6 секунд. Что вы сделаете?
jwtvalidationendpoints - 74
В 09:20 UTC release добавляет customer_id в Prometheus labels, active series растут с 6 до 48 миллионов, а collectors теряют 30% samples. Что вы сделаете?
monitoring - 75
В 23:40 UTC Grafana и tracing недоступны во время роста API errors до 12%, но application logs и cloud metrics работают. Как вы поведёте диагностику 20 минут?
monitoringapi - 76
После outage длительностью 25 минут в очереди 4,5 миллиона jobs, normal capacity равна 8 000 в секунду, а новые arrivals равны 6 000 в секунду. Как восстановиться без второго outage?
capacitydata-structurescapacity-planning - 77
В 18:00 UTC traffic достигает 140 000 requests в секунду при tested safe limit 100 000, а checkout errors растут до 9%. Какую нагрузку вы отбросите?
- 78
В 10:05 UTC mobile clients повторяют requests каждые 100 мс после 503, превращая 20 000 user actions в секунду в 160 000 requests; client update нельзя выпустить 24 часа. Что вы сделаете?
resilience - 79
В 03:00 UTC primary region недоступен, replica отстаёт на 75 секунд, а 11 000 orders могут отсутствовать; business требует немедленный failover. Что вы решите?
replicationfailover - 80
В 13:40 UTC reconciliation находит 620 duplicate charges, созданных во время incident с timeouts длительностью 17 минут; сервис уже здоров. Что делать дальше?
incidentsincident-managementreact - 81
Outage длительностью 42 минуты начался в 09:07, когда engineer изменил Envoy timeout с 2 секунд на 200 мс; rollback занял 31 минуту из-за неясного ownership. Как провести postmortem?
ownershipincidentspostmortems - 82
Один и тот же queue overflow вызвал 3 outages за 6 месяцев, хотя action по runbook был закрыт; последний impact длился 28 минут. Что изменить после review?
runbooksdata-structures - 83
Четыре SRE тратят 26 часов в неделю на ручной restart failed batch jobs; automation потребует около 120 engineering hours. Автоматизировать ли сейчас?
batch - 84
Два engineer тратят 9 часов в неделю на renewal 240 certificates, а один пропуск вызвал outage на 16 минут. Какую automation вы одобрите?
- 85
On-call SRE тратит 14 часов в неделю на temporary production access, причём 60% requests приходят ночью. Что вы измените?
on-call - 86
Release engineer тратит 18 часов в неделю на 45 manual deployment steps, а 7% releases требуют исправления. В какой последовательности автоматизировать?
deployment - 87
Команда тратит 11 часов в неделю на разбор 320 alerts, но только 24 требуют action. Что вы сделаете за следующие 2 недели?
alerting - 88
За 12-часовую смену primary получает 17 pages, включая 6 после полуночи, и пропускает один acknowledgement target 10 минут. Что сделать до следующей смены?
- 89
В 02:10 UTC один on-call engineer получает database Sev1 и отдельный CDN Sev1 с интервалом 3 минуты; доступны только 4 responders. Как их распределить?
on-calldatabase - 90
Sev1 продолжается 7 часов; у уходящей команды 25 минут на handoff, активны 3 mitigations, а replication lag равен 48 секундам. Как передать command?
replication - 91
Junior on-call engineer видит рост errors с 0,3% до 6% после canary 10%, но хочет ещё 20 минут диагностики до rollback. Как вы наставляете его в моменте?
mentoringon-callrollback - 92
Mid-level SRE вручную повышал PostgreSQL connection limit с 400 до 800 во время 2 incidents и ухудшил оба. Как обучить его и контролировать следующий incident?
incidentsincident-managementpostgres - 93
Новый incident commander 15 минут debug один Pod, пока 12 responders не получают задач во время outage с 9% errors. Как вмешаться и обучить?
mentoringincidentsincident-management - 94
Traffic растёт на 12% еженедельно 5 недель, database storage осталось на 9 дней, а добавление shard занимает 14 дней. Что вы сделаете сегодня?
databasesharding - 95
Во время traffic spike finance просит убрать 30% reserved compute ради экономии $18 000 в день, хотя headroom при потере одной зоны равен только 12%. Что вы решите?
- 96
Rollback с version 7.4 на 7.3 снижает errors с 14% до 4%, но затем застревает: 7.3 не читает 8% новых records. Что вы сделаете?
rollback - 97
В 22:00 UTC L7 attack увеличивает traffic с 25 000 до 900 000 requests в секунду, WAF CPU равен 88%, а 3% legitimate logins не проходят. Как вы ответите?
- 98
В 01:30 UTC ransomware indicators появляются на 6 build agents, а production hotfix нужен через 20 минут; security изолирует CI. Как безопасно продолжить outage response?
- 99
В 11:11 UTC inventory call замедляется до 1,5 секунды, checkout имеет deadline 2 секунды, а 4 последовательных retries поднимают p99 до 7 секунд. Что изменить во время incident?
incidentsestimationincident-management - 100
После outage длительностью 63 минуты errors ниже 0,2% уже 8 минут, но в очереди остаётся 1,2 миллиона messages, а replication lag равен 35 секундам. Когда объявить recovery?
replicationdata-structures