14｜平台自身的稳定性怎么保障？平台挂了怎么办？

开场先讲一个反讽的认知：测试平台自己就是被测系统，它自己也需要测试——这个自觉是本题的立场分。平台的单子挂了耽误的是全公司的测试执行，稳定性要求按内部核心系统对待。

回答思路

第一步：讲自测体系（吃自己的狗粮）

• 平台自身的自动化测试（核心接口的回归、关键链路的冒烟——自己平台发版前自己先跑）
• 数据库变更的灰度（schema 变更先在备份库演练）
• 发布的灰度机制（新功能开关化，先放给种子团队再全量）

第二步：讲架构上的保障

• 执行层和平台层的分离（Web 挂了执行不受影响——07 题的设计在容灾上的回报）
• 数据的备份（用例资产是团队多年的积累，丢了是罪人——定期备份加恢复演练）
• 依赖的降级（报告渲染挂了不影响执行、通知服务挂了任务照跑）——降级设计保证核心链路（执行）永远可用

第三步：讲监控告警

• 平台自身的健康监控（服务存活、队列积压、任务成功率突降）
• 业务指标的异常检测（定时任务静默失败的告警——08 题的伏笔）
• 用户反馈的快速通道（问题响应的 SLA）

监控覆盖「平台坏没坏」和「平台空不空转」两类故障。

第四步：讲应急预案

• 挂了的第一时间动作：用户公告、紧急修复路径、执行任务的临时替代方案（比如本地脚本兜底）
• 恢复后的数据补偿（中断任务的自动恢复或重跑）
• 复盘和改进闭环

有预案的平台故障是事故，没预案的平台故障是灾难。

考察重点

维度	说明
企业动机	平台成为流程基础设施后，它的故障就是全团队的故障（CI 门禁挂了阻塞所有发布）——这题考察「建设者思维」里最稀缺的运维责任意识
过线标准	自测体系 + 执行核心链路的降级保障 + 监控
区分度	讲数据备份演练、讲静默失败告警、讲应急预案和恢复补偿的是真值过班的
加分项	「测试平台自己就是被测系统」的立场表述
减分项	从没想过平台会挂，「重启就好了」，运维意识为零

来源

整理自知识星球帖《面试情报 08｜测试工具平台开发 20 题》，返回题库。