3.6　我们的心得
TiP测试使我们可以找出数据中心上线过程中引入的问题和有时在产品中客户还没发现的问题。随着时间的推移，还可以让我们找出潜在问题、性能和总体功能表现的非常有趣的发展趋势。
3.6.1　合作方服务相关的问题
对TiP测试至关重要的一个组成部分就是：找出我们所依赖的并在其上进行构建的与合作方服务相关的问题。我们的服务，与几乎所有其他云端服务一样，依赖于许多特定领域相关的不同服务。例如，我们依赖Windows Live ID来提供专门的身份验证层。又如，命名空间管理和提供是依赖于在线域名服务的。在找出上面这些通过别的方面无法捕获的依赖问题方面，我们的测试是非常有帮助的。
3.6.2　云端监视的挑战性
Exchange作为服务很独特的一个方面是它的目标客户是IT专业人员，他们在升级到新的服务时总是非常谨慎，而且很多大客户都定制了一些写在Exchange顶层的产品。此外，有一些客户在混合模式下运行，而另一个客户仅仅只在公司的Exchange Servers中运行，也有一些是在云端运行的。在处理单个云端中版本的一些值得注意的、更持久的变化方面，标准监控解决方案设计得并不是很好。TiP测试在流经系统时，其版本和配置变化使我们能更好地在异构的云端测量和保证质量。这些挑战对于很多云端服务来说是非典型的，如Bing、Facebook、Twitter, 更多的是使用同构的和松耦合的服务架构来获取连续的部署模型。
尽管如此，我们的服务是分层的，且依赖于比Exchange团队更快速的发布周期。网络本身就是随着新的Firmware版本和访问控制列表（Access Control List, ACL）的改变而不断更新的一个层。当那些层发生灾难性的改变时，由监控服务（如Gomez 和Keynote）提供的黑盒方法会向运营中心发出警报，但是对于间歇型或边缘情况却不会发出警报。TiP使我们可以在这些依赖问题变成灾难性问题之前深入分析并捕获它们。在某些情况下，我们甚至可以在合作方服务升级过程中捕获问题，这样就可以提醒他们将这些变更进行回滚。
3.6.3　在线TiP测试所发现的一些问题
以下是通过TiP测试在产品中找到问题的一些样例：
都柏林（爱尔兰*的首都）的服务提供的一个队列挂起了，但是监控器并没有检测到。
检测到服务提供的延迟。
TiP检测到了Hotmail运行中断，Exchange团队可以暂停并等待Hotmail的修复。
Live ID运行中断影响了Exchange Cloud的客户；Live ID的运营需要进一步加强。
TellMe, 一个可以将电话在我们的系统和手机交换器（Quest/Verizon负责的地上通信线和T-Mobile的移动电话）之间转换的VoIP网关系统，需要对最终用户连接场景的运行中断进行监控。TiP是找出集成试点测试中所使用的电话号码故障的唯一方法。
也常用TiP测试来鉴定发生随时间不断流逝的间歇失效的根本原因（随着时间流逝出现故障的百分比，而不仅仅只是在单个事故中出现故障）。
3.6.4　聚集处理结果中的“噪声”
我们学到了很多关于对一个实时服务如何执行测试的知识。学到的第一点就是，这种自动化的运行并不简单。例如，因为是在公司防火墙后面运行的，所以只好按照雷德蒙德的代理服务器的路线来发送请求。这些代理服务器并非旨在拥有这种用途，所以导致了有时会出现请求丢失、主机查找失败和其他奇怪的网络故障等。这很快导致了第二种实现方法的出现，即在产品系统中运行自动化测试时，重要的不是个体的通过或者失败的结果，而是随着时间推移，这些结果的聚集体。聚集可以帮助识别一个问题是持久中断问题还是仅仅只是一次网络故障，因此可以将噪声级减少到足够低，这能对服务安全性进行更精确的提高。同时还可以帮助预测未来的发展趋势，而只通过简单地适时看一看统计结果是无法做到这些的。
【小窍门】
对细节过程进行监控是非常重要的，但留意总体趋势也同样重要。
当你注意到测试一个小时运行一次的时候，上述最后一点（关于噪声消减）就变得十分重要。这一频率受到测试执行框架上的内置假设的影响，即关于测试通过之后怎么配置（比如，假设每一个测试运行执行都必须出现在一个新部署的机器上）和关于测试本身是如何执行的。我们发现那些假设因为很多原因存在一些漏洞。
它们一个小时运行一次的另外一个原因是担心消耗太多的生产力。我们发现一个服务必须要留出一些额外的设备来支持实时网站监控、使用过程中的高峰和低谷、拒绝服务攻击和成长。如果以一个增长的频率，比如每5分钟一次，在每个产品簇中运行一个自动化功能测试集合来对服务的边缘进行检测，那么运行的这项服务的时间就太密集了，需要增加设备。但事实上，对许多IT组织来说，采购和安置专用硬件的成本太高，以至于他们觉得准备额外设备留作备用是很不可思议的。然而，随着转移到进行云计算并具有了对电脑和存储资源的动态增长能力，很多组织都能负担得起通过一些合理的额外设备构建一个服务以用于在线测试。
3.6.5　易犯的错误
我们得到的一个教训就是，测试自动化比由外到内的基本监控更完整，并且由于这些测试的质量不错，团队很快就想将TiP系统作为一个加强的监控解决方案。但问题是，我们不可能对频率为1小时的测试进行适时的反应，因为收集足够的样本来分析一个问题是否真的需要花费的太长时间。另一种办法是在测试中实施重试逻辑（retry logic），这样有可能进一步降低通过率并有可能因为瞬态问题而给你提供假阳性的结果（例如，因节流机制而引起发送信息失败）。
我们得到的第二个教训是，当处理横向扩展的产品系统时，如果没有一个类似的自动化测试横向验证策略，就有可能导致一种虚假的安全感。在最初的实施过程中，我们为每一个规模化单元的每个人创建了单个邮箱账户集合，问题是，规模化单元还有进一步的粒度分割，因为它们是由多服务器、可用组织和其他最初未说明的资源组成的。事实上，这意味着每个站点只能覆盖一个可用的组织或者邮箱数据库。这会导致事故不被基础设施所捕获的情形，因为规模化单元受到影响的那部分并不是我们所覆盖的那部分。
除了作为回归测试的金丝雀之外，TiP测试像我们的系统一样，应该将其当作更健壮的持续改进项目（continuous improvement project，CIP）中的一员来对待。与大多数CIP一样，高层管理人员的参与和带动是成功的关键。管理人员与团队的同心协力将保证工程团队获得支持以改善产品服务、弥补TiP和整个监控解决方案中其他元素（单服务器并且由外到内）的空缺。