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

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

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

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

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

业务镜像往往是非常精简、基础（处于安全考虑也不应该安装非业务内容）。不含常见的curl、ping、tcping、tcpdump等工具，甚至没有sh，kubectl-debug太重，需要在node安装agent，有更简单的方法：nsenter，是大多数系统自带的用于进入指定命令空间的工具。

#查看容器位置
kubectl get pod xxx -n xxx -o wide

#在容器所在物理机查看容器id
docker ps |grep nginx-new-57f8fcdc7d-6r69n
#容器内查看Pid
docker inspect c5decf942415|grep -w Pid

#nsenter进入，此时和容器处于相同进程空间，可以使用宿主机的所有命令
nsenter -n -t 87296 #可以看到只能看到容器本身IP

#从抓包内容验证，只有访问此container ip的请求才能被抓到
#使用完成记得ctrl+d退出