面试SRE：别只问“值班累不累”，先问告警后谁分诊

消息提到，有团队分享过一种值班用法：Slack告警触发后，工具会拉取指标、对比部署差异并检查功能开关，找出可能原因并提出修复方案，供人工批准合并。消息还提到，相关配置答疑目前需要Team或Enterprise套餐才能预约。这类信息不能证明所有团队都已采用同类工具，但可以帮你设计面试问题。

面试时不要只问值班频率。更值得问的是：告警触发后，谁负责第一轮分诊？是值班人独立判断，还是有明确的升级路径？修复方案由谁最终确认，值班人有没有直接合并的权限？如果对方回答“看情况”，你可以追问最近一次故障里，第一响应人是谁、花了多久定位。这比问“累不累”更能判断你接不接得住。

人工审批边界，决定你能否接得住

素材里有一个关键细节：工具提出修复方案，但要“供人工批准合并”。这说明引入辅助工具不等于责任转移，审批边界仍要由人来定。面试时可以顺着问：“如果工具或脚本给出修复建议，最终由谁签字确认？”再问：审批人不在线时怎么办，有没有兜底流程？

另一个细节是，相关配置答疑需要付费套餐才能预约。这提醒你，工具是否可用、以什么方式可用，和组织的采购与权限设置有关。面试时不必假设对方一定在用某款工具，而应问清：团队目前有没有辅助排障手段，人工审批环节卡在哪里，出问题时责任怎么划分。如果对方说不清，你就要把“责任模糊”当成风险，而不是只当成技术挑战。

交接与复盘，问出团队的真实流程

值班能不能接住，还取决于交接和复盘。面试时可以问：值班交接是口头还是书面？上一班没处理完的问题，怎么让下一班知道？故障结束后，复盘是走形式还是能推动改进？你可以用假设场景反问：如果某次告警定位到部署差异，修复方案已提交，但审批人迟迟不批，你们会怎么记录、怎么交接？以下为模拟示例，仅体现思考方法：假设你拿到一条错误率上升告警，先确认最近部署，再查功能开关，最后写“可能原因+建议动作+需要谁确认”。这不是实际经历，而是展示你的排查顺序。

面试前，挑一个你熟悉的故障场景，按“现象—分诊—建议—审批人—交接”五步写成一页笔记，面试时用它反问对方流程。这样既能判断团队底子，也能让你在回答中显得有准备。