这一章要面对的是第三方系统引发的几类故障。在开源火爆的今天，考虑使用开源项目已经不是稀奇事，但是毕竟开源代码的控制权不在自己手里，在使用时难免会碰到一些问题。
在使用一个服务时，应当先看看有没有其他人也在使用。如果用的人很少应该先思考一下为什么很少人用。如果要继续使用的话，要注意保持警惕，进行全面的测试。并且要准备好备选方案，当服务不符合预期时就不会手足无措。
【有时候在网上查找一些解决方案时会很难搜索到，这个情况下可以先想想，是不是解决的方向错了，其实这个问题有更合理更简单直接的方法。不过有时候迎难而上也会有很多收获。感觉第一节《面对小众需求，切记未雨绸缪》的小标题起的不是很准确，面对让人觉得是要去满足这个需求，而实际上主角是需求方。】
第三方服务并不可靠，和这个服务的受欢迎程度无关。对于依赖第三方服务的项目，一定要确定如何获知服务发生变更的情况。
【第三方服务发生变更是一个很常见的事情，文中的服务提供方宣布变更的方式并不正式。但是在日常使用中，经常乎出现用了第三方服务后就忘了这件事，哪怕第三方发布了服务变更也根本不会知道，这无疑是埋下了定时炸弹。所以对第三方服务做好追踪是很有必要的。另外，在使用第三方服务时，尽量选择大的提供商，比如他们会有正式的通知，保留旧的api接口，在接口快过期时调用会有提示。】
不太理解这里的模拟对象具体是指什么，大意是每次系统升级都要做好自动化测试，查找过期的模拟对象。
有时候烂代码不仅仅是来自于项目内部，还可能来自于外部（比如别人的爬虫）。让异常报告系统和客户通知系统分开投递。异常报告系统最好能把相似问题合成一个报告，否则一旦发生异常很可能会立刻耗尽报告的发送次数。
没有纯粹的内部问题，每个内部问题都可能对客户产生影响。所以不应该仅仅关注客户提出的需求，自身系统的稳定和质量也会影响到客户的评价。
【所以自动化测试一定要做好，保证代码最起码的质量。】
