前几年，我外包进入一家外企，碰到了一件颠覆我三观的事情：一方面，中国的产品经理拼命催活儿，要求尽快上线新功能。另一方面，CICD 流水线由国外的 DevOps 团队管理，虽然其国外的发布很顺利，但是国内的流水线根本不能正常工作，然而开发看不到流水线源代码，更没有权限做出修复。
因此，开发就通过 Slack 和国外的团队沟通这个问题，尽管对国内的开发来讲，已经火烧眉毛，但是国外的 DevOps 团队根本不怎么搭理国内的开发。第一个原因是时间差，往往将问题反馈之后，要第二天那边才能看到。但即使看到了，国外的团队并没有任何的紧迫感，一方面不紧不慢，另一方面，并不认为当前有什么问题。如此往复，最终导致一个功能开发好了，花了整整两个星期才发布到测试环境！
后来我离开了，加入了另一家外企，并且是正式员工身份。这家公司和前一家有着很大的区别，我一开始认为在这里不会再遇到前面所说的问题了，因为我认为，前面的问题只是这样的原因导致的：
- 因为我是外包，所以不被重视
- 因为团队划分不合理，开发和 DevOps 不应该是两个不同的团队
- 权限不合理，开发应该有必要的 CICD 控制权
但是在新公司我仍然遇到了类似的问题。
有很多服务，由国外团队提供，但是在中国很难用甚至不可用，是所有在中国工作的同事们，不限于开发，还有业务同事都头疼已久的问题。
有一次和国外团队开会时，我提出了这个问题，得到的答复竟然是：我们的服务很稳定，你所说的全部是基于错误的事实。
当在会议结束时，关于有什么需要改进的地方，结论是不需要做任何修复。因为问题根本不存在。
我非常诧异，内心呼喊：你们来几个人吧，过来在中国工作一段时间来实地感受一下。
这些问题，其中之一就是关于应用的访问性问题。举个例子，我说为什么中国的公司在员工数字化生命周期管理上更倾向于使用企业微信而不是微软 AD （Entra ID），或者说被强制要求使用微软 AD （Entra ID），但仍然会再开启一份企业微信的方案并行着，原因之一就是因为在连接微软 AD 服务上不够稳定，有时候会彻底断掉，经常是时延很高。但他们反馈说服务很稳定，他们有监控。他们也没有收到任何来自中国的服务支持工单抱怨过这个问题！
这时我感觉自己和之前在外包到前一家公司时，似曾相识。之前的问题我说了 3 点原因，都成立，但正好都是在我的控制范围之外的。
我这才意识我们的沟通方式上的差别，我发现除了以上 3 点原因，还有一个原因就是：
- 我在陈述问题时反复强调自己的感觉，但他们反复强调数据！
尽管这些感觉，对我来说都是真实的，但是他们听起来却没有依据，不值得重视。
和前面 3 点不同，第 4 点是我可以控制的。因此我列出了两项行动计划：
一、收集数据。将出现问题的历史数据列出来。
二、在遇到问题时，通过正式渠道上报。其实这也在积累数据。
