看所有的书，都明确指出架构师不能停留在象牙塔内，否则设计出的架构是不会符合实际情况的。不过一般理解上，都是指架构师要加入开发，至少要了解代码现状，却很少有人提到架构师在部署、运维上应当发挥的作用。虽然从实际工作经验中，也多少知道架构师要负责项目的整个生命周期（至少在大部分公司是这样），却没有仔细想过这两个在理论上靠后、又正是实际发挥作用的阶段。
这本书恰好弥补了这方面的不足。实际上，这也是一本需要一定的知识和经验作为基础的书，对于现在的我，很多地方只是浏览，没有时间仔细看，也不能理解得很深入。未来如果有需要，我还会再看一次。
项目（基本上）永远是为了赚钱。软件项目要赚钱，就要能够长期稳定运行，尽可能不发生崩溃。功能、创意这些当然是前提，但是没有后续的支持，不能把功能和创意实现并带给用户稳定的使用体验，都是没有意义的。作为架构师，一定要意识到这一点，从设计架构时，就把运营纳入考虑范围。
书中以案例为出发点，从四个方面研究了运营阶段会遇到的问题：稳定性、容量、一般设计问题及其它运营问题。
稳定性可以从系统设计的角度开始做预防。对于一个系统，稳定性问题是很容易扩散的。模块本身的稳定固然重要，但是模块间尽量减少故障的影响，是更加重要的。
在“稳定性反模式”一章中，提到了若干种造成不稳定的设计方法：集成点、连锁反应、连锁故障、用户、阻塞的线程、自我否定攻击、尺度效应、不平衡的容量、慢响应、SLA倒置、无边界结果集。
在“稳定性模式”一章中，提到了一些增加稳定性的方法：使用超时、断路器、隔板、稳定状态、快速失效、握手、测试装置、去耦合中间件。
容量指的不仅仅是一个节点、一台服务器能够支持的用户会话数量，它的范围更广。性能、吞吐量、可扩展性都是容量的一个方面。在一定负载下，对每个事务保持可接受的响应时间的系统最大吞吐量，称为容量。容量是可以实现动态扩展的。
在“容量反模式”中，提到了若干造成容量问题的情况：资源池竞争、泛滥的JSP碎片、AJAX过度之伤、驻留过久的会话、HTML中浪费的空间、刷新按钮、手工的SQL语句、数据库富营养化、集成点延迟、Cookie怪兽。这些并不是那么直观容易考虑到的问题。
在“容量模式”中，提出了一些方法：使用连接池、谨慎使用缓存、预计算容量、调整垃圾回收器。
一般设计问题从几个方面指出了会在运行阶段引发问题的关键点：网络连接、安全（最少特权原则与密码配置）、可用性（可用性需求的收集和记录、负载均衡、集群）和管理（测试与产品匹配、配置文件管理、启动和关闭、脚本化的管理接口）。
运营部分指出了一些其它需要注意的问题：透明度和适应性。
总体来说这是一本很值得一读的书，也适合于当成工具书放在手边收藏。
