在读本书之前，我一直好奇一个IT项目是如何写成一本小说的，但是各种原因导致一个月前才购买了本书。
下面随便写写，欢迎交流，不喜勿喷。
说说翻译
作为一个译者，谈谈一些感觉。
感觉名字有些不切题……说笑了，如果不这么起名国内的读者谁会买呀？不过原名也挺好的，比较顺应潮流。
真心记不住翻译成中文后的英文名称，包括人物名、公司名等。英文名反而好记一些。阅读本书过程中，无数次的翻到人物表对对应各种人物的关系，着实有些头晕。“无极限”这个公司名字也是醉了，如果要打入中国它估计不叫这名字。
一些术语还是不要翻译的好，比如“DevOps”、“ID”（记录其它的纸片找不到了）。
“Code Base”是基准代码吧？
注释，打的位置不是太好，有些在注释文字前面，有些在后面，晕了。
最后，参考书籍中，国内是否已有译著建议注明（如果有建议使用译著的名字），如果没有则建议备注原名。经过翻译的名字如果没有译著找起来也是比较困难的（其中很多书虽然很老了，但是内容还是很有用的）。
再说说感受
阅读本书的过程，让我感觉和阅读《三体》三部曲一样，前面有些平淡无奇，但是随着故事的发展，越看越兴奋，兴奋之后则是陷入深思。
这是一本少有的写到运维的小说，而且不缺技术，相反，涉及到技术的范围还很广。
本书的前一段内容我感同身受，各种各样的紧急工作、混乱的IT变更，而Bill来自的地方，则有着自己建立的IT变更管理，井然有序。或许所有的IT在前期的阶段基本上都面领着这样的问题。
而后来，面临着公司即将被拆分，IT业务被外包的局面，在Eric的指点下，Bill将运维、开发、业务聚集到一起，通力合作。感觉这种方式有着敏捷、DevOps的因子。
每一次变更成功，每一次故障的避免，都让我欣喜若狂，仿佛就是身边的事情。
尤其是看到Bill和Kris开始合作后，其实心中除了兴奋，还有一丝羡慕。
得知DevOps的概念时，大概是13年初（源自于《DevOps的各个阶段》）吧。当时网络上不少人都在高呼运维要下岗了，认识的一些运维攻城狮都人人自危。但是这么多年了，至少在我司中，干运维的还在干运维，基本没啥变化。搞软件开发的倒是自己做了些运维的工作——没办法，现在内部支持也要费用，能省点儿是点儿。
Bill自始自终都是作为一个副总裁，在自上而下的推动整个故事的发展。他为什么没有在原有的部门就将变更管理推广出来呢？自上而下很重要。
虽然没有ITIL工具的管理，仅仅利用看板，就能将如此多的变更管理得井然有序。而现实中，管理员们懒到极点，一个字段都不愿意填写，更别说写纸条了。
这么多年了，开发和运维从来没有通力合作过，往往是交接，而且只有交接，开发只是为用户服务，压根不考虑运维的事情，毕竟，考虑到安全、易运维的问题都会增加成本——又开始吐槽了。
或许本书中，开发、运维同属一个公司，有着共同的目标，而现实中的我们，只有盈利才是共同的目标，其他的——考虑那么多作甚？