1，对于不易重现问题的应对思路。可以为每一个起始的处理过程都分配一个traceid，然后分析与这个traceid相关的所有log，来还原整个处理过程。
2，测试旁路。引入线上流量到线下的测试环境，用以验证线下功能有没有大的问题，这一部分处理结果会被抛弃。
3，快速搭建依赖mock环境的实践。这个是用ICE这样的中间件就可以比较轻松的达到这个目标，这样就可以在单机上模拟一个真实的环境。
4，数据采集（应用监控）的定制框架。每个service上线前都要落实要采集哪些数据，并把他们在代码中实现。这块对于后面搜索相关性的测试，还有重要作用，后面会提到。
5，服务自治，松散的结构。这个有点像是现在的iprocess，各自的处理单元只关注自己要完成的功能。这个跟我们的isearch不太像，他没有严格的行、列的定义，但是实际上有很多机器的索引数据还是相同的，其实就是扮演了这种角色。
6，相关性的测试。“最不好做的测试”。这类的项目，在立项之初，必须做的一件事情就是在整个项目组确定什么是衡量相关性好的标准，怎么在统计数据上来体现这一点。然后，测试执行过程中的一个重要测试，就是这种数据能不能被有效收集，因为这个数据是对于项目的发展具有决定性意义的数据参考。
7，自动化的发布过程。这个我之前的周报提到过了，但不知道到bing就是这么做的。我们持续集成中心应该把做到这一点作为一个远期的目标。这个可以从小项目来着手尝试，比如我们的textanalyzer。
8，有效抛弃。我还是第一次听这种说法，判断一个query的结果是不是相关，不是看有没有后面的点击，而是看后面有没有做继续的搜索，做了的话就认为相关性不好，如果没有做（也就是抛弃），则说明用户已经获得了足够的信息，则认为相关性是好的。这个有点像之前听到的那个关于搜索结果的externallity（外部性）的研究，这种还是挺有意思的，我关心的更多的是你怎么佐证这个是说法是对的。
