在求职过程中遇到过这样的问题：当系统出现故障时，你是自上而下进行排查，还是自下而上
一个有趣的问题排查过程
今天，同事找我处理一个奇怪的问题。他在 rsa 私钥配置正常的情况下，能登录大部分服务器，唯度某一台服务器无法登陆。
首先，按照惯性思维，通过 ssh -vvv <hostanem> 直接查看 debug 信息，因为之前大部分同事因为没有配置好私钥或者权限导致无法登陆。
但后面发现问题不在私钥中，随之我登陆到服务器，检查公钥内容，比对能成功的服务器的公钥，内容是一样的。
在毫无头绪情况下，我尝试删除公钥，重新同步下来。同步公钥的过程中发现一个有趣的问题，公钥不能同步写入了 ~/.ssh/authorized_key，文件的 ownner 被修改了。
欣喜若狂，赶紧修正用户权限，怼改同事几句乱修改，然后重新尝试登录，发现依然失败。
这时候，重新陷入后无头绪的环节，我再尝试删除整个用户，尝试重新创建用户。这时候，问题终于暴露了：
代码语言：shell复制sudo userdel -r tom
userdel: tom mail spool (/var/mail/tom) not found
userdel: /home/tom not owned by tom, not removing用户（假定为tom）的home文件夹整个ownner都被篡改了，这就是导致 ssh 无法公私钥校验的原因。
后续通过修正 ownner 权限，与同事再次确认，就是因为他某次操作导致的这个问题。
引申思考
整个问题排查并发复杂，幸好也没有占用我太多的时间，但这里让我想起之前我在求职过程时:
“当系统出现故障时，你是自上而下进行排查，还是自下而上”
我当时是这样回答：
”由通过自上而下的，也有通过自下而上的，看告警位置，告警在前端，自上而下排查；告警在数据库，自下而上排查“
当时其实我没有任何思路，胡乱回答的。
现在想想，有了新的领悟。
当问题出现时，可以通过下面步骤 自上而下 排查解决：
- 找到出错点
- 可以利用惯性思维，常识，尝试快速修复
- 如果问题还没有解决，尝试回放整个操作步骤，并且从开始到结束各个环节添加适当日志，分析
- 尝试从 0 到 1 重新构建步骤中各个关键点依赖的文件、组件等
- 重复不断深入，一个关键点再拆分多个小关键点，继续分析
暂时没有想到“自下而上”分析的场景，硬要说个例子的话，可能当前端服务出现问题时，后端数据库同时报错了，这时候可能从数据库侧开始分析，也算是自下而上吧。（但实际感觉还是用到了“自上而下”分析，因为受影响点是前端服务，为此找到的原因点是数据库）
