左右摇摆——线上测试的成败案例(2)

　　项目期间我在堪萨斯州，我设法取得一些我感兴趣的(那些我正为之开发代码的)交换机模型的IP地址。让我很高兴的是，我能实际接触它们而不是呆在无聊的会议室中，这样我能完成一些测试和开发，伴随着周遭的庞然大物嘎吱嘎吱地磨动那些装置。一切运转得很好，我的代码发送查询请求，几乎得到了期望的所有响应，除了做了一些小改动让我的代码更棒。实际上不到几个小时之后，我们发现这些数百万美元的交换机，原本设计是每秒处理TB级通信转换，现在却有一个有趣的现象……它们本来没想到会接收到比普通人类更快的TL1指令，而你却给它们连续发送了和计算机一样快的命令，奇妙的是那些交换机仍然响应得特别好，只是一段时间之后突然就毫无反应，正是这种现象促使堪萨斯州的电话服务开始改进，并变得更好。(是的，我在堪萨斯州，交换机是服务于堪萨斯州的，因为估摸着他们给我“玩”的交换机就是一个本地的设备)。结果就是道歉声四起，允许测试什么和何时测试有了新的方法，同时一个很棒的新抑制系统加到我们的产品中。

　　教训：TiP在这里意义非常。因为购买这些昂贵的交换机，把它们放到测试实验室中毫无价值。但另外一件有意义的事是关于测试什么和何时测试的方法。我在会议室的各种奇怪行为并不是正确的处理过程(公平地说，过去一直是行得通的)，取而代之的是测试中的，真正生成的，会给客户带来各种可能结果的一条清楚的报文。既然这样，我们在采取进一步行动前，几乎都要检查下我们的测试过程是否正确。

　　封闭度：用户曝光控制

　　前面我曾说过，曝光控制能将用户完全隔离在你的新服务之外。但要是你需要一些用户参与怎么办?如果你正在部署一些新的、危险的东西到你的生产环境中(为了测试)，你需要用户看到它，否则就不叫真正的用户测试，但既然影响这么坏，你只希望少量的用户受到影响。理论上你要从少量用户开始然后监控，接着再增加一些用户，再监控，就这样一直重复，直到所有的用户都在你的新系统上，直到系统拥有高可信度。

　　在微软我们有实验平台(ExP)，通常用做A/B测试，正好也能用作这种用户扩大的测试。虽然他们不用ExP，但微软的新搜索引擎Bing在他们的预发测试中使用了这种曝光控制。在微软之外，我想我听到过的这类测试的最娴熟的运用实例之一是在聊天引擎IMVU，他们已经将这类测试融入到每一次部署中，可参考Timothy Fitz的文章，IMVU的持续部署：不可思议的一天50次

　　回到部署过程， 9分钟过去，网站的一次提交新鲜出炉。程序员运行IMVU的推送脚本，将代码同步到集群的数百台机器。平均负载，cpu消耗，php错误和退出等更多内容被推送脚本采样，作为一个基准线。一个软链接用来切换到小客户子集上。一分钟之后，推送脚本再次采样集群的数据，如果统计出来有显著差异那么系统将会自动回滚。不然，它会推送到整个集群，然后以相同的方式每隔5分钟监控一次。这一来代码活着并全部推送到整个系统。这整个过程非常地简单，只需要执行几个shell脚本即可。

　　未完待续

　　好了，我还有非常多的例子，但这需要延长不少时间……让我了解下你们想些什么，如果我得到一些积极反馈，我会告诉你们更多……

原文转自：http://blogs.msdn.com/b/seliot/archive/2009/12/14/feeling-tipsy-testing-in-production-success-and-horror-stories.aspx