主题
昨天遇到了一个比较有意思的服务器问题,然而就这么发生了,有些异形问题在多方协作模式下发生,协调甩锅、“坐等靠”,证明等乱七八糟的内容太消磨热情,本次通过一个异常的问题排查分享,来谈谈横向能力的问题,谈谈看法
起因
事情的起因是这样,运维的堡垒机访问发布一直未发生任何问题,但节后,C系统出现统一认证异常的情况,但其他集成系统均无任何问题,堡垒机同样，这个C系统是正常的、出现了一方正常其他方不正常的情况,一般规律,软件出现问题,这个情况会在某些场景下复现,出现异常情况.
注： 这里补充一下,统一认证起到的作用是保证内部系统的统一，同样承担着接入外部系统以及接入外部认证逻辑的作用，而此时的异常系统为自身系统、因此才有了排查的前提
认证的逻辑,基本上是通过,统一存储服务域下的localStorage,通过ifame隐藏打开指定页,通过postMessage 进行唯一交换进行的（唯一交换的好处是不用源头统一,不用处理乱七八糟的不一致问题）
经过
基于以上前提,经过异常反馈的情况和代码的确认,剔除了自身逻辑的问题(之所以要确认一次，是为了核实),怀疑问题出自于服务器网络问题,了解到之前一直没有任何问题,C系统中间经过发布,而且都笃定之前没出现过此种情况，因此有了退版本的情况，但情况依然不正常,又找到了我这里,此时有了远程的可调试环境,此时观测到一个特殊标记，在域下明明有token的情况下,通过这种方式获取不到、又核实了其他系统均正常。
此时的问题已基本定位到服务器上了,但如何在当前条件下快速的验证证明此项结论的正确性,是个问题（业主方服务器相关已经过沟通,绕进了鸡生蛋、蛋生鸡的循环种）。
过程大略是经过nginx的重新代理访问,达到切换服务的目的,通过路径配置进行更改验证,一番操作下来,验证了外部认证逻辑的正确性,但又产生了跨域问题，原因是C系统的发布用的是绝对地址，配置有服务指定访问地址,源码替换，重新docker镜像发布之后,添加服务的nginx访问后,问题得到了解决,当然过程回溯很容易,中间也是各波折。
如何证明
说实话,这个问题,我也属于第一次遇到,怀疑可能是安全策略的问题导致的,两个服务器的连通性是没有任何问题的,期间怀疑过nginx配置问题，docker问题,就也不知道怎么证明服务器的什么因素影响到了无法有效获取localStorage,有知道的老哥，也还请赐教、
回溯
这个问题,现在分析来看,涉及到前端、后端、运维的三重交接处,nginx这个问题，经常被甩来甩去，均认为是运维的职责、而此项问题,运维也无法跟踪排查得出结论，试错的条件和成本较大（并非别人想不到），但问题需要解决,此时的情况下,最小化的验证和解决问题就需要有横向的能力去综合评判、某方面缺失,很容问题就变成三方证明，这个问题不是我的问题,结果显而易见，就跟死锁一样得不到解决,当然这只是很小的一方面、
分析
每个人的想法和态度,会随着不同阶段变化,在某一个情况下希望努力学习新的知识内容用以变化成薪资、某个阶段需要安稳,又可能在某个阶段变成需要休息和清闲,但这一切的选择，有个前提是事前的努力,运气和时代的洪流并不是一直都有,求而不得是常态,为啥都经历过高考,却想不明白,更高的分数才有更多的选择,未来也才有更多的机会、至于年龄大转行这个问题，这是个人姿态的问题,积极向上总是好的,丧着也不是不能过,各自容忍，毕竟过的都是自己的人生,不是他人的，姿态和态度总要有，那么，你的态度又是啥？
