背景
昨天因客户私有部署问题，需要到客户公司去排查问题。
他们是一家外企，各种权限需要提前申请(最大的坑)。他们之前部署的一般为单域名，很少部署互联网类型多个域名的情形(第二个坑)。这次私有部署总计使用了十几个站点，我们之前提供过发布文件与配置信息，这次是过来检查部署，保证主功能正常使用。
出行问题
客户公司需要身份证登记，临行前我忘了带身份证又折回重拿。到地铁站和同事汇合时，同事又早下了两站(地铁站名相似)，耽搁了一些时间，本来预计9点半到，实际到时十点了。
网络问题
由于工作电脑已经换成了台式机，所以上周申请了一台笔记本过来，结果就遇到问题，连不上客户的wifi，无线网络可以搜到其他的wifi，但搜不到要我连的那个。然后客户和同事分别开了热点，竟然也连不上！没得办法，只能用同事的mac电脑远程公司服务器来开发了，这相当于浪费了一个人。
过了一二十分钟，我配好服务器的环境后，用自己手机开了热点，我的笔记本确能连上，真是奇葩了。由于已配好服务器环境，就没有继续用这个电脑了(事后想来，真是失策,在客户现场，时间是充足宝贵的，能连自己热点，应该立即使用，从而解放同事的电脑！谨记)
一遍一遍的日志
域名转发端口号问题
先解决第一个问题。客户部署的mj站点在sso站点跳转是带上了内部的端口号，而这个端口号在经过负载均衡转发后，对外网不可访问，应客户要求跳转时取的url统一去掉端口号。顺利解决
验证失败死循环跳转问题
我们的sso与客户方公司自己的sso配通后，sso已实现登录，但sso跳转到主站点mj时，验证失败重跳回sso，出现死循环跳转问题(由于内部访问其他站点超时，非常慢，这点当时没注意)。
经过漫长的几版加日志，由于客户方无法使用U盘，只能使用他们专用的文件邮件服务器来传送，速度也不快很耽误时间。
在这种反复折腾中，很快就吃过午饭一两点了，终于日志记录定位到一个访问sso站点验证cookies的地址超时，看到了明确的超时记录，又无意间到我们的站点在调用restA站点取config时也出现超时问题(这里取不到值上周五电话会议已知道，当时sso登录后默认跳转地址取不到，当时一直没在意，想的是优先解决跳转问题，取不到值后从web.config获取值，错过了一次提前发现问题的机会)
既然两个站点都出现超时，那便优先解决restA的超时问题吧，同事就开始上场了。
站点超时问题
一顿操作猛如虎，也折腾了一个会，取到了必要的请求参数放到fiddler里请求，然后返回了值。
这就很奇怪了！
我们又让客户重新走了一下流程，终于确认外部能直接请求，服务器内部访问超时！同事就询问服务器相互之间是不是有限制，防火墙等。终于找到了正确的方向！
沿着这个道路，我们发现客户部署我们的十几站点全是不同的ip，同一个物理机，每个站点虚拟不同的ip，配置的这么繁锁……
既然走在了正确的道路上，剩下的就通顺了。我们需要提供各个Api之间调用关系，让客户去申请防火墙权限。dev,was,production三套环境，每个环境那么多站点，相互之间要信任，我听着都累。他们审批最少一周后了。
这个时候已经四点半了！总算可以返程回公司处理下额外的一些事了。
事后总结
这次虽然我通过不断的打log定位到超时问题，同事针对特定超时链接，外网能访问，服务器超时，定位到问题。但其实我打log对这次实施来讲是十分低效耗时的，其实本可以直接通过取配置的接口定位问题，而不用通过sso的跳转来分析问题，如果采取定位配置接口查问题，估计上午就可以搞定了。
用最简单的办法，先解决掉普遍的问题。再针对重点区域重点分析。
延伸扩展
以上虽然表面是服务器之间超时，同样还是我们和客户都没有权限远程登录服务器操作的问题，客户也仅仅只有固定的一些目录权限。
当然还有关于日志，配置检测的不足，许多都需要临时打日志，这是非常低效的。如果每一个请求都能记录结果，这些请求参数能保存下来，对于分析问题都是很快的。这也是APM的重要性所在。虽然正式环境有了听云和搭了ELK日志，但听云也没有记录的那么详细，ELK使用率还不够，而且私有部署也不会考虑这些的。
当然还有老代码遗留的技术债，如这次打日志发现了很多问题，按Key取配置，竟然的单个取的，虽然只首次运行一回，但首次加载时间必然很慢。还有很坑的try catch后不处理，完全发现不了任何信息。
虽然这次用低效的方式处理了问题，但也多知道了一些坑，为后期优化提供了帮助，长远看还是有用的。
最后还有一个问题，如果很多请求都超时，是不是可以意味站点无响应？我们在外部已经通过部分页面确认站点可访问，这个时候是否可以直接得出内部服务器有限制？如果早意味到这个问题，也许在看到超时的那一刻就知道了答案。
这是我个人第一次遇到这次复杂的权限部署，域名转发后域名可正常访问，内部却因防火墙限制。做个总结，聊表慰藉。