xAI 域名故障到Nginx权限：分层定位与恢复渠道

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 场景给出域名访问问题、某机房LB、L7 Nginx无日志，最终指向二进制缺可执行权限；chmod也不可用。操作系统和已有运维工具未给，以下Linux分支仅作练习。
• 先区分“chmod可执行但调用者不能改文件”与“chmod程序本身没有执行权限”。两种情况恢复方法不同；选择经过授权且可信的管理员/恢复环境。

解题路线

1. 画出客户端→DNS→机房LB→L7→上游链路，比较不同机房、客户端及已知健康请求的失败范围。携带请求ID核对每层是否接收与转发；无日志只能提示请求没到、进程没运行或日志链路坏，不能直接断言是权限。
2. 查看服务启动错误、进程状态与实际加载路径，再核对服务身份、文件mode、父目录搜索权限和挂载属性。执行被拒绝不只可能是文件没有x位；Linux还可能有目录权限或noexec等原因。只修已证实的分支。
3. 若chmod能执行但改mode被拒，核实文件所有者、只读挂载或管理策略；交给授权身份和既定变更渠道处理。给应用进程长期root权限并不能修复部署产物的根因。
4. 若chmod自身不能执行，不要复制一个未知同名程序。优先使用可信配置管理/包管理代理、已有可用管理运行时调用系统权限接口，或进入可信恢复环境修正已核验路径。调用chmod系统接口仍受同样权限限制，不会凭空提升权限。
5. 先从LB摘除坏实例、在健康实例承担流量的前提下恢复；保留mode和部署记录、核对可信包的期望权限，再恢复服务并逐层验证探针。最后检查打包/复制是否丢执行位，以及构建验收为何没发现。

手动走一遍

机房A失败、B正常，A的LB已收请求但L7无日志；服务管理器报告启动时Permission denied，证据显示目标binary缺执行位。若/usr/bin/chmod也不能执行，先走可信管理代理恢复mode，再启动服务并验证请求ID穿过L7；若错误其实是调用者无权修改，则升级给授权操作者，而非继续换命令。所有路径均为示意，不是线上操作指令。

规模与取舍

排查按链路层数及实例采样量计，单实例路径检查与日志检索成本受工具/数据量影响，无固定O(1)总排障时间。容量上先确认健康机房可承接被摘流量，恢复顺序与回滚点比机械执行命令更关键。

易错点与追问

容易失分的边界

• 没有access log便断定请求没有到LB。
• 把chmod执行失败与chmod syscall无权修改混为一谈。
• 用777或随意下载工具扩大权限，仍未修包装流程。

继续深挖

• 如果service进程已启动却返回403，如何把内容访问权限与binary执行权限区分？
• 如果所有管理工具都不可执行，如何使用可信恢复盘/控制台并保存故障证据？