断断续续4个星期了，Golive到底结束了吗？谁知道呢。
这次Golive真是惊心动魄，很多问题都没见过，而且在staging环境上都没出现过。
遇到的第一个问题是，SSO对一个应用的保护时断时续。访问它的时候，SSO保护的出现机率只有50%。查了很多遍，最终证实为DNS冗余的问题。DNS和IP绑定的混乱，让SSO服务器无所适从。在SSO服务器端锁定应用域名后，问题消失。调试和解决这个问题用了6个小时。
遇到的第二个问题是，SSO对第二个应用的保护有50%的几率不按设计的方式工作，有时设置的保护策略不起作用。查证发现是系统管理员没有通过一般方式将应用在两台负载均衡的SSO服务器上注册，而导致无法与其中一台正确通信。重新注册后，问题消失。调试和解决这个问题用了3个小时。
再后来遇到的两个问题都是非常棘手的问题。一个是SSO Agent会导致我们其中一个应用每隔一段时间就响应变慢。问题的可能性包括SSO服务器的响应和缓存，应用到SSO服务器的链接，DNS，路由，VPN，DMZ，防火墙，负载均衡，集群，等等等等……我们用了一个星期才把问题定位到SSO方面的通信问题，又用了几天才发现这和防火墙有关系。最终向System Administrator Team证明了我们的发现，开了一个emergency ticket，让他们去解决这个问题。但到现在也没有得到回应。
另一个问题是一个需要客户端证书与用户帐号绑定认证应用，有15%的几率认证失败。检查SSO Agent的log，没有任何异常，客户端证书已经通过的应用的web server验证。测来测去，感觉可能出在客户端证书向SSO服务器的传递上。想要得到详细信息的话，需要打开产品机SSO服务器的trace log。这简直是不可能完成的任务。一是打开这个log需要重新启动服务，二是这个log以每秒几十MB的速度增长。SA team是不会轻易帮我们做这件事的。庆幸的是客户在测试的时候，这个问题竟然一次都没有发生。所以这个问题的优先级被定为“低”，在下一个release的时候解决。
接下来就是浑浑噩噩的一个月，忙着给各个问题擦屁股。向vendor，SA team， security team等等各个相关的team要信息、证明，自己不断测试。
唉，原来总是说“概率性的问题不可能用穷举法证明已解决”。但现在除了这个办法还真没有其他的路。
真是头大了，我被活生生的逼成了一个半吊子系统管理员。
不过幸运的是，最终压力压到我们team上的还是很少的，可以自然的等待下一个release。
Post a Comment