关于解决问题的思考

产品经理反馈海外某地工厂停工，原因是产线有道环节是设备开机上传key至加密机。经与研发沟通后，链路：客户-CDN-源站api-上海机房加密机。头天凌晨2点出的问题，销售同学帮挡了一道。
第二天上班看了源站日志，下意识以为CDN问题，更换两次节点后，客户反馈仍有问题，视频里桌子上一排商米设备，国内15秒激活，这里要1分钟，还有超时。客户的极度不配合加上已经是半夜1点，群里的产品经理不断催促、强调问题严重性，心烦意乱，还要和他battle。
查看日志，没一条非200的。判断用户网络到CDN间的问题，直接去掉CDN回源

事后产品追着大家要长短解，
我：缩短网络距离，智能解析切换CDN、激活服务就近部署
深圳研发：传key动作后置，不在生产环节做，牺牲一部分设备掌控性
大家畅所欲言时，被批评 “不专业、开会效率低，应该只提痛点，专业的事交给专业的人，不要替其他人做决定！”
CTO：加密机批量生成sn、key对应关系，保存在当地IDC，异步申请key，不再怕弱网、间歇被墙

高下立判，我深陷“知识的诅咒”，完全从自己的视角出发；研发多少带了业务场景，用较低的售后成本避开问题；CTO则结合了技术与业务，创新性的引入“异步前置仓”

优势：
对网络轻车熟路，日志、变量因素，发现多项关键线索，快速定位

反思：
容易被情绪左右，对待“刷存在感”的同学不能无视
还是缺乏系统性思考，只能站在技术的狭小角度