虽然是讲一本运维的书，但是从整个书中可以看到整个企业的IT架构。
掌握整个企业流程，而非盲人摸象
作为一名技术人员，无论开发和运维，多多少少都会有一些极客思维，沉浸在技术的世界里。随处可见的产品和开发之间的矛盾就可见一斑。一个专业的技术人员应该自变为上帝视角，看到整个企业的流程，从订单到销售，再到生产，采购，财务等等，只有真正理解一个公司是如何运营的，才能真正理解技术是如何为企业服务的，才能真正做出契合用户的软件。如果仅凭个人的臆想，去设计功能，如此做出的软件基本上都是不堪入目。
迅速的从0到1，而非制造很多的0.5
书中反复讲到半成品，对比软件也是如此。相信很多人都在企业中看到，很多软件做到一半不做了，或者是快要推向市场时，总是不稳定，之后就无人问津！这就是一直在忙碌的制造0.5，从没有一个真正的1。半成品是无法推向市场的，无法实现营收，这就产生了极大的资源浪费。 对比与一个人的工作也是如此，如果你手中有10件工作，你针对10件工作都完成了50%，这在上级看来，你是没有任何进展。而如果你聪明的完成了5件工作，这才是真正的完成了50%！！所以在任何时候，请专心制造1，而非很多个0.5.
开发到运维的一体化
运维和开发是息息相关的。中国的很多企业，运维基本都是由开发人员兼职去做的。证明运维在很多的企业是依附于开发的，这就导致很多开发人员一个错误的观念，运维相对于开发是不重要的。当然不要认为运维的技术含量小，因为你接触的运维不是真正的运维。运维是可大可小的，真正好的运维，能帮助开发省掉50%以上的工作。从自动化部署Jekins到Docker，再到zookeeper都有运维的影子。
部门间永远有冲突，分清是恶意还是无意
开发是一个需要团队通力合作才能成功的一件事，所以作为开发，基本上见识不到所谓的办公室政治。而一旦需要和别的部门进行合作，无论是较远的销售部，还是较近的运维部，一定会有冲突，这种冲突不一定会上升到办公室政治的地步，但是用冲突来定义是OK的。一旦遇到冲突，我们要首先定义，冲突是不是恶意。多数冲突而言，大家都是站在自己的立场上想做好这件事情，这种大家只要平心静气去解决就好！但是如果是恶意的推诿责任等等，那就需要你用自己的智慧去打赢这场战争，有人的地方就有江湖，不能指望自己在一片和谐的职场里步步高升！ 自然，很多时候，办公室政治不一定是拔刀相向的冲突，还有可能是冲你微笑的甜言蜜语。
技术储备
这是一个很虚无缥缈的话题，书中也可能根本没有提到。作为技术人员或者运维人员，在如今的时代里，技术储备都是不可或缺的。如果一个运维不能了解技术，就根本不知道如果做出更为人性化的自动化运维，慢慢沦落为一个网管。如果一个技术不了解运维，那么就没办法提前设计架构，做出来的软件就不能自动化处理，这是另一个悲剧。 所以，无论作为哪一方面的从业人员，都要慢慢加强自己的技术储备，一旦放弃学习，一定会慢慢被这个时代所抛弃，特别是IT行业。
关于“布伦特”
布伦特是一个技术大咖，各种人员有问题都会找布伦特，布伦特也总能解决问题，所以越来越多的问题积攒在布伦特身上。 在管理层的角度而言，布伦特确实不应该存在，因为他是部门效益的短板，太多问题只能依靠他。但对于个人而言，这是在某一阶段的好事，只有当你做到能“挟持”整个部门利益的时候，作为员工，算是半个成功了。当你到达如此地步，就要想想如何更近一步，如何脱离重复性的工作，让自己更近一步了。 很多技术性人员到达这一步就止步不前了，很遗憾。更多的技术人员是还没到达这一步，就天天想入非非了，这更悲哀。
查字典图书网
