0922后端课程-5课前预习成果检测
哈喽!仝学~本次课程主题为“线上问题排查 ”。请完成上次课程学习验收+课前预习检测题目，成功提交问卷即为签到完成。
1. 学员信息
姓名：
部门：
后端第四次课《微服务治理与方案设计》课程学习成果检测
2. 某服务有多个健康、可接收请求的实例。团队希望根据实例负载和用户缓存的使用情况选择分配策略。以下判断哪些正确？
使用加权随机，实例A、B的权重为2:1，就能保证每连续3次请求中恰好有2次分配给A。
实例繁忙程度经常变化时，可以采用课上介绍的P2C方式：随机选两个候选，比较负载指标，再选择负载较低的实例。
希望同一用户尽量复用同一实例的本地缓存时，可以按用户ID做一致性哈希；实例集合与哈希规则不变时，相同ID保持相同映射。
P2C中的load就是CPU使用率，因此判断采用哪种实现时，只需要比较CPU，无需了解它实际使用的负载指标。
3. 镜像的/app/config/目录中原本有app.yaml和logback.xml。上线时，将只包含app.yaml的ConfigMap挂载到了整个/app/config/目录，随后应用找不到logback.xml。如果只想替换app.yaml，同时保留镜像中原有的其他文件，哪种调整最合适？
保持整个目录挂载不变，只重启Pod，让镜像重新加载原文件。
使用subPath将ConfigMap中的app.yaml单独挂载到/app/config/app.yaml。
保持整个目录挂载不变，把镜像中的logback.xml改名后仍放在/app/config/下。
将ConfigMap改成只包含app.yaml的Secret，仍挂载到整个/app/config/目录。
4. Pod已就绪，为什么Service仍访问失败？已确认以下情况：Service的selector正确选中了目标Pod。应用实际监听9090，探针也通过9090检查，Pod状态为就绪。Service配置为port: 80、targetPort: 8080。客户端需要继续通过Service的80端口访问。针对上述配置，最直接的修正是什么？
将Service的port改为9090，保留targetPort: 8080。
只将Pod清单中的containerPort改为8080，不改应用实际监听端口。
保持端口配置不变，增加Pod副本数。
保持Service的port: 80，将targetPort改为9090。
5. 某Java服务的容器内存上限为4Gi，JVM最大堆也配置为4Gi。运行一段时间后，容器出现OOMKilled，即因内存问题被终止。以下判断或处理方式哪些合理？
JVM堆之外还存在非堆内存、线程栈等开销，最大堆占满容器上限会带来内存超限风险。
保持内存上限和最大堆不变，只把内存requests提高到4Gi，就能解决容器内存超限问题。
结合监控和压测重新分配内存预算，为堆外开销留出空间，再验证是否还会出现OOM。
保持内存配置不变，只放宽存活探针的失败阈值，就能避免内存超限导致的终止。
6. AI已按确认的范围生成了一份方案，包含服务边界、调用图、接口契约、正常业务流程和K8S部署清单，但没有说明上线后出现异常时如何发现和处理。为了判断这份方案能否支持异常处置，下一轮最应要求AI补充哪组内容，并由团队核对？
补充正常流程的时序图和接口示例，作为上线异常时的主要处理依据。
补充副本数和资源配额表，把扩容作为上线异常时的统一处理方式。
补充失败路径、发现异常的监控依据、回滚条件与步骤，以及回滚后的验证方法。
补充完整实现代码和正常流程测试，待首次出现线上异常后再整理处理方案。
后端第五次课《线上问题排查 》课前预习成果检测
7. 用户反馈“订单查询很慢”。收到这条信息后，以下哪项最适合作为排查的第一步？
立即重启订单服务，观察用户是否继续反馈。
补全开始时间、具体接口、正常基线、影响范围和近期变更，确认问题是否仍在发生。
根据经验直接认定是慢SQL，先为数据库增加索引。
先调大JVM堆内存，排除内存不足的可能。
8. 关于线上问题排查中的假设、验证和闭环，以下哪项做法最合理？
只要某个原因过去出现过，就直接按这个原因修改生产配置，无需重新验证。
同时修改多个参数，只要问题消失，就能确定其中每项修改都有效。
提出可被验证或推翻的假设，优先采用低风险方法逐项验证，修复后再用同口径指标确认恢复。
修复后只要不再出现异常日志，就可以结束排查，不需要检查用户业务结果。
9. 10:05之后，订单查询接口错误率明显上升，但应用CPU使用率仍处于正常范围。以下哪项判断最合理？
CPU正常说明系统没有问题，告警可以直接关闭。
错误率升高一定是实例数量不足，应立即扩容。
当前证据不支持“CPU饱和”，还应在同一时间窗口检查数据库、缓存、连接池和下游依赖。
只要重启后错误率下降，就可以认定根因是JVM故障。
10. 以下哪项最符合本次培训的监控建议？
把TraceId和requestId作为所有指标的标签，以便按单次请求查询。
接口返回HTTP 200就代表业务成功，不必再记录业务结果指标。
低流量场景只看错误比例即可，失败数量和样本量没有参考价值。
优先复用内置指标，控制标签取值范围，并通过可控异常验证采集、告警和通知链路。
11. 使用Counter累计报表失败次数。现在需要分别观察“最近5分钟的平均每秒失败速率”和“最近1小时新增的失败总量”，以下哪种组合更合适？
前者使用increase，后者使用rate。
前者使用rate，后者使用increase。
两者都只读取Counter当前累计值，不需要时间窗口。
两者都使用Gauge，因为Counter在进程重启后可能归零。
12. 订单查询失败时，以下哪条日志最有助于后续排查？
查询失败
用户手机号=13812345678，Token=ey...，查询失败
TraceId=abc123，订单查询，cache=miss，dbCost=4.8s，result=failed，并由日志框架记录异常对象和完整堆栈。
在Controller、Service和DAO每一层打印同一异常的完整堆栈，数量越多越容易定位。
13. 关于跨服务TraceId，以下哪项描述最完整、准确？
只需在入口生成TraceId，下游服务会通过网络自动获得该值。
TraceId写入MDC后可以永久保留，请求完成时无需清理。
入口接收或生成TraceId后写入MDC，调用下游时继续透传，请求结束时清理；跨线程时还要显式处理上下文传播。
TraceId只用于监控指标标签，不需要出现在日志或调用Header中。
14. 执行Person p = new Person()时，以下哪项描述最符合本次培训中的JVM简化模型？
Person对象和局部变量p都存放在Java栈中，方法返回后一起消失。
类元数据和方法信息在方法区，对象在堆中，p属于当前栈帧中的局部变量，程序计数器记录下一条指令位置。
new只会在方法区创建对象，堆只保存数据库连接和线程池。
构造方法返回后，对象一定立即被GC回收，因为构造方法栈帧已经弹出。
15. 某Java应用的Pod memory limit为2Gi，JVM的-Xmx也设置为接近2Gi。高并发时Pod被标记为OOMKilled，却没有看到Java heap space堆栈。以下解释最合理的是哪一项？
只要没有Java OOM堆栈，就能证明内存与故障无关。
Pod只统计Java堆，堆未超过-Xmx时不可能被终止。
Java进程除堆外还有线程栈、Metaspace、直接内存等开销，进程总内存可能先超过容器限制而被系统终止。
OOMKilled与递归造成的StackOverflowError完全相同。
16. 线上故障仍在影响用户。以下哪项处理方式最符合本次培训的建议？
先停止收集现场信息并重启所有实例，恢复后不再追查根因。
保留最小必要证据并采用可逆方式止损；AI只辅助整理脱敏材料，结论经真实证据验证，修复后再确认业务恢复并复盘。
将未经脱敏的完整生产日志交给AI，由AI直接决定是否回滚和修改配置。
只要AI给出的原因与工程师经验一致，就可以跳过监控、日志和Trace验证。
关闭
更多问卷
复制此问卷