分诊的顺序与记录
一句话总结
在应对障碍时，实力差异不是在工具上，而是在顺序和记录上。有顺序的话就不会再看同一个地方两次，有记录的话下一个人也不会从头开始。
为什么需要这个？
如果在凌晨3点收到来的报告，任何人都会感到着急。着急的话，顺序就会崩溃，顺序崩溃的话，就会反复问“刚才确认了吗？”所以熟练者会机械地遵循事先确定的顺序。判断是在收集数据后再做。
怎么行动
顺序从下面向上排列，因为如果下面楼层坏了，就不需要看上面楼层了。
- 名字 —
getent hosts <이름>科dig +short <이름>并行执行。两个结果不同，差异就是原因的位置。 - 到达 —
ping -c 3 <IP>.即使失败也不会马上得出结论。可能是ICMP阻止。 - 港口 —
nc -zv -w 2 <IP> <포트>. 是否是refused或timeout一定要区分清楚写出来。这个单字决定了下一步调查的方向。 - 绑定 — 在目标主机上
ss -ltnp | grep <포트>. Local Address127.0.0.1如果是的话，就到此为止。 - 回复 —
curl -o /dev/null -s -w '...'. 一起查看状态代码和各段时间的信息。
在每个阶段都**保留命令及其输出。**只有写着“已确认”的记录对下一个人没有任何价值。相反，如果附有命令和输出，下一个人也可以重新阅读该输出并得出不同的结论。
事后报告至少应该有这五项。
| 项目 | 内容 |
|---|---|
| 症状 | 用户实际看到的（不是猜测） |
| 层次 | 在哪个层停止了？ |
| 原因 | 伴随着成为依据的命令输出 |
| 措施 | 改变了什么，怎么改变的 |
| 防止复发 | 为了不让同样的事情再次发生 |
按层次敲什么呢
有缩小“不行”的顺序。从下往上走的话，每个阶段候选人都会 减少。
| 层 | 确认命令 | 如果在这里失败的话 |
|---|---|---|
| 1. 姓名 | getent hosts api.example.com |
DNS·/etc/hosts·搜索域名 |
| 2.路线 | ip route get 10.0.3.12 |
路由·基本网关 |
| 3. 到达 | ping -c1 10.0.3.12 |
ICMP可能被堵住了（即使失败也会继续下一个） |
| 4. 端口 | nc -zv 10.0.3.12 8080或者curl -v telnet://… |
不使用防火墙、安全群组、听取意见 |
| 5.服务 | curl -sv http://10.0.3.12:8080/healthz |
应用程序 |
即使在第3次失败也不停止很重要。ICMP通常被堵住，所以“ping不能 “是网络问题”经常是错误的。4号才是真正的判断。
nc的结果分为三种，各自含义不同。
- connected — 端口打开了。问题在5号上面。
- Connection refused — 数据包已到达，但没有人在听。 服务可能未启动或 粘在了另一个端口上。不是防火墙的问题。
- timeout — 数据包消失了。可能是防火墙、安全组、路由方面。
仅仅区分这三个就大大不同了调查范围。
确认在哪里听
Connection refused出来后，服务器方会查看。
ss -ltnp | grep 8080
LISTEN 0 4096 127.0.0.1:8080 0.0.0.0:* users:(("app",pid=42,fd=3))
↑ 여기가 함정
127.0.0.1:8080这样的话只能触及自己。在容器内curl localhost:8080 은 되는데 밖에서는 안 되는 전형적인 원인입니다. 0.0.0.0:8080
李娜[::]:8080要戴上才能在外面粘住。
在应用程序设置中选择绑定地址（--host 0.0.0.0，bind = "0.0.0.0").
无论如何修改端口映射，这个都不能出错。
在容器管理中再多一层
如果两个设备之间无法连接，首先怀疑网络政策。基本阻止（default deny） 在这个被锁定的命名空间中，政策中没有记载的通信全部是timeout。
kubectl -n <ns> get networkpolicy
kubectl -n <ns> describe networkpolicy <이름> # from/to 를 읽는다
如果症状“偶尔发生”，不是政策，而是看终端。只有其中一个Pad设置 如果不是Ready，只有请求用那个去失败，在外面看起来是间歇性错误。
kubectl -n <ns> get endpoints <svc> # 주소가 몇 개 있나
在现场相遇的样子
假设原因只有一个。实际障碍经常是两个以上的原因重叠的情况。如果修复一个，然后说“没好转”，转向其他方向，就会怀疑已经修复的东西。所以最好彻底检查每个层，把发现的东西都写下来，最终会更快。
修改后不进行验证。修改hosts后getent再次确认，修改绑定后，必须再次输入外部地址。用同样的命令重现失败并确认成功是措施的最后一步。
下次实习要做的事情
接受同时出现三个缺陷的障碍。逐个缩小层次，确定原因，进行修复，以确定的形式留下事后报告。