V2EX 使用指南里面有这么一条“如果你要教别人做事，请确认那件事情是你自己确实已经做过并且做得很好的”。
这条很赞同，如果你生活工作时间很长，跟身边的人交流这点是非常深刻的。
我讲一个故事：
有个客户最近跟我们反馈，在 xx 上的业务在 xx 偶尔 connect time out ，偶尔 read time out,请求协查。
老实讲，这个问题非常糟糕，搞技术的人遇到这个问题需要大量的沟通来确认，什么时候，什么业务域名或 IP ，哪些地域的 IP ，请求哪些目标对象发生了报错。
于是，我们经过一番的交流，确定了链路拓扑结构，找了一些全球网络层监控数据、增加了 7 层监控数据看，都没有发生问题。后来经过几天的挤牙膏式的沟通，跟对方业务研发沟通，说是源站里面有一个业务逻辑组件会直接回调 weixin 某接口超时。这样看来，就不经过中间代理节点，就变成了直连，路径是单独的，跟中间节点无关了，这个问题就变成了源站跟 weixin 的逻辑关系了，既然跟我们没关系，那就可以调整方向了，我可以退出。
从这个过程也发现对方在技术上思路不清晰，缺少经验，着急冒进（可能是业务方的压力），秉着负责的态度，我还是给他了一个探测工具，让他在服务器上部署向外探测 weixin 接口，采集一些数据进一步分析。
幸运的是，我自己部署的采集数据没有发现问题，客户也没有继续收到终端上报问题。但是这个问题也没有“复现”，成了悬案。
我的建议：
1. 如果你提问，请把一个问题按照 5W2H 描述清楚，高效沟通。
2. 作为技术人员，需要在面对压力时，有消化压力，正确沉稳应对的方法。比如：弄清楚业务架构拓扑、业务逻辑处理关系，影响面等关键信息，这样你会有很好的方法和心态去面对掌控局面。
3. 技术问题的第一感觉非常重要，这个需要在日常技术问题中扎实挖深训练和积累，比如你看到 connect time out 就知道是四层的问题，看到 read time out 是七层的问题，如果业务逻辑复杂，也可能是因为四层问题导致微服务组件没有及时响应返回数据导致全局 read time out 。
技术问题第一感觉的训练很简单，我认为需要对每个技术问题刨根问底，事后写总结文章，写的多了，你就会对问题理解更加深刻，回头看，大家用的理论可能都很基础，只是自己对基础掌握和理解角度不够不深，或者是缺少体系化的思考和稳定的情绪。
上一篇我说的数据管理，在这个 case 上同样适用，其实也是暴露了数据不全面的细节型问题，这点我也跟客户说明了。
基础运维基本的链路数据四七层要齐全，否则，你的工作整天就是处于紧张、焦虑，不确定性中，时间长了身体上也会给出负面反馈，比如：疼痛、掉头发、结节等问题。
so,想要舒服顺利，认真考虑你当前工作的不足，并不断寻找方法建设解决，面相外部“客户”，你会更加专业，更加的从从容容，游刃有余。时间长了，这些专业和从容会成为你的核心竞争力。
God bless us ，have nice day ！
这条很赞同，如果你生活工作时间很长，跟身边的人交流这点是非常深刻的。
我讲一个故事：
有个客户最近跟我们反馈，在 xx 上的业务在 xx 偶尔 connect time out ，偶尔 read time out,请求协查。
老实讲，这个问题非常糟糕，搞技术的人遇到这个问题需要大量的沟通来确认，什么时候，什么业务域名或 IP ，哪些地域的 IP ，请求哪些目标对象发生了报错。
于是，我们经过一番的交流，确定了链路拓扑结构，找了一些全球网络层监控数据、增加了 7 层监控数据看，都没有发生问题。后来经过几天的挤牙膏式的沟通，跟对方业务研发沟通，说是源站里面有一个业务逻辑组件会直接回调 weixin 某接口超时。这样看来，就不经过中间代理节点，就变成了直连，路径是单独的，跟中间节点无关了，这个问题就变成了源站跟 weixin 的逻辑关系了，既然跟我们没关系，那就可以调整方向了，我可以退出。
从这个过程也发现对方在技术上思路不清晰，缺少经验，着急冒进（可能是业务方的压力），秉着负责的态度，我还是给他了一个探测工具，让他在服务器上部署向外探测 weixin 接口，采集一些数据进一步分析。
幸运的是，我自己部署的采集数据没有发现问题，客户也没有继续收到终端上报问题。但是这个问题也没有“复现”，成了悬案。
我的建议：
1. 如果你提问，请把一个问题按照 5W2H 描述清楚，高效沟通。
2. 作为技术人员，需要在面对压力时，有消化压力，正确沉稳应对的方法。比如：弄清楚业务架构拓扑、业务逻辑处理关系，影响面等关键信息，这样你会有很好的方法和心态去面对掌控局面。
3. 技术问题的第一感觉非常重要，这个需要在日常技术问题中扎实挖深训练和积累，比如你看到 connect time out 就知道是四层的问题，看到 read time out 是七层的问题，如果业务逻辑复杂，也可能是因为四层问题导致微服务组件没有及时响应返回数据导致全局 read time out 。
技术问题第一感觉的训练很简单，我认为需要对每个技术问题刨根问底，事后写总结文章，写的多了，你就会对问题理解更加深刻，回头看，大家用的理论可能都很基础，只是自己对基础掌握和理解角度不够不深，或者是缺少体系化的思考和稳定的情绪。
上一篇我说的数据管理，在这个 case 上同样适用，其实也是暴露了数据不全面的细节型问题，这点我也跟客户说明了。
基础运维基本的链路数据四七层要齐全，否则，你的工作整天就是处于紧张、焦虑，不确定性中，时间长了身体上也会给出负面反馈，比如：疼痛、掉头发、结节等问题。
so,想要舒服顺利，认真考虑你当前工作的不足，并不断寻找方法建设解决，面相外部“客户”，你会更加专业，更加的从从容容，游刃有余。时间长了，这些专业和从容会成为你的核心竞争力。
God bless us ，have nice day ！
目前尚无回复
Select Language