Context
《发布!软件的设计与部署》这本书终于读完了，不过我感觉我现在的水平还有很多内容没有理解。所以这本书，我总还要找机会搞来的！
Chapter
这剩下的两节都是第四部分:运营 的内容，帮助
透明度
透明性是指这样一种特性，它能让操作员、开发者和商业赞助商理解系统的历史趋势、当前状态、瞬间状态和未来设想
如果系统的透明性很差，那么即便我们发现系统出现了异常或者故障，也很难快速的找到问题的根源。按照我的猜想，透明性大概就是在系统的各种关键点(继承点)增加控制接口、log记录等。因为在遇到问题的时候，知道的信息越多，定位问题越方便；组件提供的接口越多，操作起来越方便。
想一下，如果好不容易发现了问题，结果这个问题的解决方法只能通过修改系统代码(更新软件)来解决，那实在是太痛苦了；如果一个系统中很多的操作都是根据配置文件来确定的，那只要修改了配置文件，并重启服务(软件)，那么问题就解决了，岂不是爽歪歪。
没有透明性的系统不能在生产中长期存在。如果管理员不知道它正在做什么，就不能调整和优化。如果开发者不知道在生产环境中什么能行什么不行，就不能对它进行增强和更新
这一章从4个层次解释了透明性：历史趋势、未来预测、当前状态、瞬间行为。
历史趋势很有意思，作为一个初等程序员，对于历史问题，我可能只会关心什么时候产生错误警告，错误警告产生的原因，触发条件这些东西。而资深架构师运营经理总是可以问一些小白、普通程序员不会想到的问题。比如：我们昨天有多少订单；第一季度我们使用了多少磁盘空间；过去三年顾客流量的增加和CPU使用率增加相比的结果～
当我们觉得没有看到警告，没有看到错误就心满意足的时候，他们总是可以想的更加长远(现在我也可以想的更长远啦～)
当前状态简单说，就是要给出足够的数据来反映系统运行的状态，产生了多少报警，多少异常，内存用了多少，还剩多少，线程数量，可用线程、繁忙线程、等等等等。不能让系统运行的像个薛定谔的猫一样。说到这里，作者也提到了日志的规范性，不能说有了日志就大功告成了，日志要分级，要有良好的格式，让人阅读的方便。不然几万几万的日志，即使知道关键内容在里面，也会让人失去探索的兴趣。
适应
适应性差不多就是兼容性的意思。系统在不断的被完善，老用户如何适应新系统，新系统如何适应老用户。开发人员如何用更低的成本去维护系统，去更新系统。这就是这一章的主要内容。
依赖注入,对象设计,极限编程实践,敏捷数据库，这是适应性软件设计的四个方法。简单的说他们都在鼓励松耦合，高内聚，提高向下兼容的能力。
发布应无害 讲到了’部署成本太高，零停机时间部署`和其他的几点。这两点单独拿出来说，是因为，颠覆了我的认知～
本以为部署一个系统多容易啊，改了新的代码，重启服务即可，有什么成本呢？实际上专业的团队在部署的时候，需要创建发布分支，发布说明文档，与营销沟通，计划执行验证部署，后续的技术支持。这些都是人力成本～
平时看到停机维护的情况比较多，所以对零停机时间部署这个概念还是比较好奇的。说的是，部署行版本，可以一步一步慢慢来，按阶段分解部署，不是立刻添加改变删除一些东西。增加各种兼容性。
Addition
上一篇中没有说到 快速失效 ，在第18章《适应》中讲到了一个例子，让我猛的想起了这个有用的设计～
比如，一个请求，我们其实早就知道，这个操作可能要出现错误了，却还是让请求做到了出现异常的时候，才反馈。就相当于客户白等了很久得知，自己想做的事情不能被达成。所以快速失效可以相当于做一些中间件吧～提前做一些处理，早就知道要失败了，就直接返回，不再继续执行操作。
End
这本书终于读完了，我肯定还会再搞来的！现在觉得一些书看不懂，没意思，说不定并不是书的问题，而是自己段位太低了～哈哈
(每次写一篇博客，都会晚睡一次～)