SRE问题排查四步法——以建立HTTPS连接失败问题排查为例

文章建议收藏关注再品，谢谢。

本文说明

本文是个人在做SRE时，排查问题的一些经验总结。最近刚好遇到一个比较典型的案例，所以就写下此文。希望能和大家多多交流。

问题背景

业务背景是设备需要连接上云端，然后进行登录。终端开发人员说他的设备无法连接上云端。

SRE问题排查四步法

以下是我总结的问题排查四步法：

1. 信息收集；

2. 提出猜测；

3. 验证猜测；

4. 如果没有找到问题，重复1，2，3步。

以上每一步都必须有文档记录下来，方便其他进行review、协作。这点真的非常非常的重要。

根据以上四步法，我们开始第一步。

第一步：信息收集阶段

通过与终端开发人员沟通，我们得到以下信息：

1. 设备A能连上生产环境，连不上预发布和测试环境；

2. 另一些设备类型B、C、D，所有的环境都能连接上；

3. 空中抓包设备A的连接信息发现，设备A有client hello发出，但是服务器端并没有返回 server hello，而是返回了一个RST的包，从而无法建立连接；

4. 设备A通过HTTP的方式能正常建立连接，但是通过HTTPS的方式就不行。

当终端开发人员描述完，我第一件事情是通过执行命令 curl-v https://httpbin.example.com:2111尝试复现问题。顺手确认一下是不是他的网络本身的问题。

但是，多次试验curl，返回的都是404。这说明请求是能到达后端服务的。我的这个操作是在尝试初步复现问题。这个过程，叫复现问题。别人的描述本身，我们也要进行验证。

复现问题的目的是为了验证“证据”本身的真实性，这样才能保证，我们后面的猜测的基础是正确的。

同时，我们还必须收集云端本身的架构的信息。这次出问题的预发布环境的调用关系是：

客户端 —> LB（TCP） —> ingress（TLS） —> 后端服务

能正常连接的生产环境的是：

客户端 —> LB（HTTPS） —> 后端服务

可以看到预发布环境的TLS在放在Ingress上实现的，而生产环境是放在LB上实现的。

本阶段，要注意的是：

1. 尽可能全面、客观、准确的收集信息；

2. 自己亲自复现问题，验证别人所描述的信息的正确性；

3. 注意区别沟通对象口中说出来是“他认为的”，还是“真正的现象”；

4. 记录下所有的信息及复现方法。

第二步：提出猜测

什么时候开始第二步？估计你会有这样的疑问。答案是现实中，第一步和第二步是交叉着进行的。在现象收集过程中，你的大脑可能就已经在提出猜测了。

我们通过终端开发人员所描述的信息，分析结果是：

信息1基本可以说明和环境有关，信息2说明设备A本身与其它的设备类型是有区别的。同时，两个信息组合起来，也基本排除后端的业务级别的问题了。

信息3就是实实在在的技术问题了（能检验TCP/IP TLS方面的真正能力）。信息4验证了信息3，可能是TLS方面出了问题（信息之间是可以相互验证的）。

在排除后端服务和网络的问题后，我们初步猜测是服务器端和客户端之间的TLS加密套件匹配不上导致的。

这个阶段，我们需要注意的是：

1. 能提出多少猜测，很能体现一个人的逻辑思维能力、技术能力。我们可以在这个过程中，识别人才。

2. 可以与其他交流，个人能力是有限的。

第三步：验证猜测

在提出猜测后，可以马上进行验证，而且应以低成本的方式快速进行验证。

笔者使用SSL在线工具得到了生产环境的LB支持的TLS加密套件列表后，再手工设置Ingress支持的加密套件，保证Ingress和生产环境的LB提供的是相同的加密套件。

结果，验证结果并不是加密套件的问题，终端还是无法连接上。将验证方法和结果记录到文档后，我们进入第四步。

这个阶段，需要注意的是：一次只验证一个猜测，避免交叉验证。

第四步：重复123步

现在我们需要再回到第一步进行信息收集。

这次，我们只能通过tcpdump进行抓包，才能知道更多的信息。现在的问题是我们应该在LB抓，还是Ingress呢？由于LB是公有云的，我们无法抓包，所以，只能在Ingress上抓。

然而好不容易抓到包，由于笔者才疏学浅，在对比了有问题的请求和没有问题的请求后，还是没有看出问题。好在，有tcpdump的pcap文件。请教团队中的在TCP/IP方面的高手后，我们得到了新的猜测：

出问题的是握手包中，没有加入server name扩展值，导致Ingress无法判断请求的域名。

如何验证这个猜测呢？我们是通过openssl命令进行验证：

openssl s_client -msg -debug -state -connect httpbin.example.com:2111 -servername httpbin.example.com

结果是我们的猜测是正确的。最后，终端在发起请求时，带上了servername，问题解决了。

慢着，就这样结束了？本次案例是结束了。但是实际工作中，导致问题的原因可能不止一个。这点需要注意。

后记

在排查过程中，技术能力严重限制了排查的速度，但是排查过程学习到的东西是印象最深刻的。以前看再多次TLS的握手过程文章，不如排查一次。因为我没有看到加密套件匹配失败时的抓包现象，所以，一开始没有排除这个猜测。

欢迎关注 持续交付实践指南 公众号

参考资料

• 深入学习TLS握手过程：https://segmentfault.com/a/1190000019718974

• 什么是 TLS 握手？https://www.cloudflare.com/zh-cn/learning/ssl/what-happens-in-a-tls-handshake/