2025年SRE工程师试题及答案

2025年SRE工程师试题及答案一、单项选择题（每题2分，共20分）1.某电商大促期间支付服务的SLO定义为“99.9%的请求在1秒内完成”，若当日总请求量为1亿次，其中超时请求为8000次，慢响应（1-2秒）请求为12万次，完全失败请求为2000次，则当日SLO达成率为？A.99.89%B.99.90%C.99.91%D.99.92%2.以下关于混沌工程的描述，错误的是？A.应在生产环境中直接验证系统韧性B.实验前需明确“稳定状态”的判断指标C.需制定完善的回滚计划D.优先针对高风险、高影响的系统模块3.某微服务系统通过Prometheus监控，发现某服务实例的CPU使用率长期稳定在70%，但近3日突然升至90%且持续，可能的根因不包括？A.服务流量突增30%B.数据库慢查询导致应用线程阻塞C.代码中新增了未优化的递归函数D.节点宿主机的NTP服务同步异常4.变更管理中“灰度发布”的核心目的是？A.降低单次变更的影响范围B.减少测试环境的准备时间C.提升用户的体验一致性D.简化回滚操作的技术实现5.以下可观测性指标组合中，最能全面反映API服务健康状态的是？A.QPS、错误率、平均响应时间B.CPU利用率、内存使用率、磁盘IOC.数据库连接数、缓存命中率、消息队列堆积量D.GC频率、线程池等待队列长度、网络延迟6.某K8s集群中，Pod频繁出现“CrashLoopBackOff”状态，优先排查的步骤是？A.检查集群节点的资源使用率（CPU/内存）B.查看Pod的事件日志（kubectldescribepod）C.确认容器镜像的拉取策略和镜像版本D.分析集群网络插件（如Calico）的状态7.设计SLO时，以下原则不适用的是？A.与用户体验强相关B.指标需可观测、可计算C.目标值应尽可能设置为100%D.需明确时间窗口（如月/季度）8.某分布式系统出现跨可用区延迟升高，使用traceroute发现跳数增加，可能的故障点是？A.客户端DNS解析异常B.跨区负载均衡器配置错误C.服务端防火墙规则误拦截D.底层网络交换机路由表老化9.容量规划中，“负载预测”的核心输入不包括？A.历史流量的时间序列数据B.业务增长的季度目标C.新功能上线的技术方案D.云厂商的EC2实例规格列表10.以下关于故障复盘的描述，正确的是？A.重点关注责任划分和处罚措施B.需输出“永久性解决方案”而非临时补丁C.无需邀请非技术岗位（如产品经理）参与D.复盘报告只需记录故障现象和处理过程二、填空题（每题3分，共15分）1.Prometheus的查询语言是__________，其通过__________机制实现时间序列数据的持久化存储。2.混沌工程的四大核心原则是：______、______、在生产环境中持续实验、最小化爆炸半径。3.SRE的“服务可靠性”通常通过__________（指标类型）衡量，而“服务可维护性”更多关注__________（指标类型）。4.变更管理的“黄金三问”是：本次变更的目的是什么？__________？__________？5.分布式系统中，常见的一致性模型包括强一致性、__________、__________和最终一致性。三、简答题（每题8分，共40分）1.请对比SLO（服务等级目标）与SLA（服务等级协议）的区别，至少列出3点差异，并说明SRE在制定SLO时需考虑的关键因素。2.某电商秒杀活动前，SRE团队需对支付系统进行容量评估。请描述容量评估的核心步骤，并说明如何通过“负载测试”与“混沌实验”验证系统容量是否达标。3.简述“可观测性”与“监控”的本质区别，列举可观测性的三大支柱，并说明如何通过这三大支柱定位“用户反馈支付失败但系统无告警”的异常问题。4.某微服务系统每日有1000次变更，近期故障次数同比上升30%。作为SRE，你会从哪些维度分析变更与故障的关联关系？请提出至少4项具体改进措施。5.设计一个针对“订单服务”的告警规则，要求覆盖关键异常场景（如错误率突增、响应时间变长、流量异常），并说明告警的分级策略（P1/P2/P3）及对应的处理流程。四、案例分析题（每题12.5分，共25分）案例1：高并发下的服务不可用某外卖平台“午高峰”期间（11:30-12:30），用户反馈下单失败，提示“系统繁忙”。监控显示：-订单服务QPS从平时的5000突增至15000（大促活动引流）；-订单服务错误率从0.1%升至15%；-数据库（MySQL）主库QPS从8000升至20000，CPU利用率95%，慢查询数量增加300%；-缓存（Redis）命中率从90%降至70%，内存使用率85%；-集群节点CPU/内存均未超限（使用率70%）。问题：（1）请结合监控数据，分析可能的故障根因（至少3点）；（2）请列出应急处理步骤（按优先级排序）；（3）提出3项长期优化措施，预防类似故障再次发生。案例2：分布式事务中断的排查某金融系统的“转账服务”调用A（账户扣款）、B（对方入账）、C（日志记录）三个下游服务，采用TCC（Try-Confirm-Cancel）模式实现分布式事务。近日，用户反馈“扣款成功但入账未到账”，且事务未触发回滚。监控显示：-A服务返回“成功”；-B服务返回“处理中”（超时未完成）；-C服务返回“成功”；-事务协调器日志显示“未收到B服务的Confirm/Cancel响应”。问题：（1）可能导致该问题的技术原因有哪些（至少4点）？（2）作为SRE，你会如何定位具体故障点（列出排查步骤）？（3）提出2项针对TCC模式的可靠性增强方案。答案及解析一、单项选择题1.A解析：SLO关注“1秒内完成”的请求占比。总请求1亿次，超时（>1秒）包括完全失败2000次+慢响应12万次=122000次。达成请求数=100000000-122000=99878000，达成率=99878000/100000000=99.878%，四舍五入为99.88%？但题目选项无此答案，可能慢响应是否算超时？若SLO定义为“1秒内完成”，则慢响应（1-2秒）属于未达成，完全失败也属于未达成。正确计算应为：达成请求=总请求-（超时+失败）=1亿-（8000+12万+2000）=1亿-13万=99870000，达成率99870000/100000000=99.87%，但选项可能出题时仅将“完全失败”和“超时>1秒”视为未达成，需根据题意调整。原题可能设定“超时请求”指>1秒，慢响应（1-2秒）是否算？若题目中“超时请求”定义为>1秒，则8000次超时+2000次失败=10000次未达成，达成率=（1亿-10000）/1亿=99.99%，但选项不符。可能题目描述有误，正确选项应为A（99.89%），可能计算时将慢响应计入未达成：12万+8000+2000=13万，1亿-13万=9987万，9987万/1亿=99.87%，但选项无，可能题目中“超时请求”指>1秒，慢响应（1-2秒）算达成，则未达成=8000+2000=10000，达成率99.99%。此处可能题目存在矛盾，按常规SLO定义，“1秒内完成”包括≤1秒，因此慢响应（1-2秒）属于未达成，正确计算为（1亿-8000-12万-2000）/1亿=9987万/1亿=99.87%，但选项无，可能正确选项为A（99.89%）是出题时的笔误，暂选A。2.A解析：混沌工程应优先在模拟生产环境（如预发布环境）中实验，生产环境实验需严格控制风险。3.D解析：NTP服务异常影响时间同步，不会直接导致CPU使用率长期升高。4.A解析：灰度发布通过逐步放量降低变更对整体系统的影响。5.A解析：QPS（流量）、错误率（正确性）、平均响应时间（性能）是API服务的核心健康指标。6.B解析：CrashLoopBackOff通常是容器启动失败，优先查看事件日志（如启动命令错误、依赖服务不可用）。7.C解析：100%的SLO不现实，需平衡用户体验与工程成本。8.D解析：traceroute跳数增加通常由网络路由路径变化（如交换机路由表异常）导致。9.D解析：EC2实例规格是容量分配的工具，非负载预测的核心输入。10.B解析：复盘重点是根因分析和长期改进，需多角色参与，避免责任追责。二、填空题1.PromQL；WAL（预写日志）+块压缩存储2.建立稳定状态的假设；最小化变量隔离3.可用性/延迟/错误率（任一列）；可维护性指标（如MTTR、变更失败率）4.变更可能影响哪些服务？；如何验证变更成功/回滚？5.弱一致性；会话一致性（或因果一致性）三、简答题1.区别：-目的：SLO是内部目标（指导工程实践），SLA是外部承诺（法律约束）；-范围：SLO可针对单个服务，SLA通常涉及整体服务；-后果：SLO未达成触发改进，SLA未达成可能需赔偿。关键因素：用户体验阈值（如用户感知的延迟上限）、历史性能基线、业务优先级（如核心服务SLO更高）、成本（高SLO需更多资源）。2.容量评估步骤：（1）确定关键指标（QPS、响应时间、错误率）；（2）收集历史数据（高峰流量、业务增长趋势）；（3）模拟负载（如用JMeter压测，覆盖正常/峰值/极端场景）；（4）分析瓶颈（数据库、缓存、网络）；（5）预留缓冲（通常1.5-2倍峰值）。负载测试验证：模拟120%预测流量，观察系统是否满足SLO；混沌实验验证：在负载测试中注入故障（如缓存宕机、数据库慢查询），验证系统冗余能力。3.本质区别：监控是“事后检测”（已知问题），可观测性是“事前发现”（未知问题），通过数据反推系统状态。三大支柱：指标（Metrics）、日志（Logs）、链路（Traces）。定位步骤：-日志：搜索用户支付失败时的请求ID，查看订单服务、支付网关、下游服务的日志，确认错误信息；-链路：通过Jaeger追踪该请求的全链路，检查各节点耗时、错误码，定位慢节点或失败节点；-指标：分析对应时间段的错误率、QPS、依赖服务（如数据库）的延迟，确认是否有异常波动。4.分析维度：-变更时间分布（如高峰时段变更是否更易引发故障）；-变更类型（代码变更/配置变更/基础设施变更的故障率）；-变更审批流程（是否跳过测试/审核）；-变更回滚率（频繁回滚的变更是否高风险）。改进措施：-实施变更窗口（非高峰时段限制变更）；-自动化预验证（如CI/CD中集成冒烟测试）；-变更影响分析（用工具自动识别关联服务）；-推行蓝绿部署/灰度发布，降低单次变更影响。5.告警规则设计：-错误率：5分钟内错误率>5%→P1告警（立即处理）；-平均响应时间：5分钟内>2秒（基线1秒）→P2告警（30分钟内处理）；-QPS：10分钟内流量突增>200%（无大促）→P3告警（1小时内排查）。处理流程：-P1：SRE立即介入，启动故障排查，15分钟内止血（如回滚、限流）；-P2：值班工程师30分钟内确认根因（如数据库慢查询），2小时内修复；-P3：分析流量来源（如爬虫/误操作），决定是否限流或扩容。四、案例分析题案例1（1）可能根因：-数据库主库容量不足（QPS突增导致CPU过载，慢查询增加）；-缓存命中率下降，大量请求穿透到数据库（缓存失效或热点Key分布不均）；-订单服务未做限流/熔断（流量突增导致下游数据库压力过大）；-数据库索引缺失或查询语句未优化（慢查询增加进一步占用数据库资源）。（2）应急步骤：①对订单服务实施限流（如拒绝50%非核心请求），快速降低数据库压力；②启用数据库读从库分担查询（若主库写压力大，需确认业务允许延迟）；③刷新缓存热点Key（如通过Redis预热或分片），提升命中率；④手动终止数据库慢查询（通过SHOWPROCESSLIST+KILL命令）；⑤临时扩容订单服务实例（增加计算资源分担流量）。（3）长期优化：-数据库层面：分库分表（按订单时间/用户ID分片）、引入读写分离、优化慢查询（添加索引、重写SQL）；-缓存层面：使用多级缓存（本地缓存+Redis）、设置热点Key自动续期、监控缓存命中率并触发预热；-服务层面：实现动态限流（根据数据库负载自动调整QPS阈值）、引入熔断（当数据库延迟超阈值时拒绝请求）、大促前进行全链路压测（覆盖订单-缓存-数据库路径）。案例2（1）可能原因：-B服务处理超时（如数据库锁竞争、外部接口调用慢），未在协调器超时前返回Confirm/Cancel；-事务协调器与B