周末看完了《凤凰项目：一个IT运维的传奇故事》这本书，也太真实了，这不就是我们早期IT生活的真实写照么，看得我内心很澎湃。一开始看到凤凰这俩字的时候，我还以为是什么涅槃重生，向死而生之类，因为前阵子在周志明那个课也说到了phoenix这个词，说的是软件服务必须具备顺利“死去”而“重生”的能力，也就是具备架构演变的驱动力，从另一个角度看，则是我们在整体架构设计中，会植入熔断、服务淘汰和重建的机制，以达到服务稳定和健壮的目标。而这本书，则是因为，他们的项目确实就叫凤凰项目。
作者的叙述能力真的很强，同时又极具幽默感，吐槽了一大段上司之后，下面一段来了个非常讽刺的“谢谢你。”跟最近”听我说，谢谢你。“这个梗有异曲同工之妙，真的好好笑。还有，“我对冒烟测试的说法报以假笑。这是电路设计师的一个术语。行内有个说法：‘打开电路板，只要没冒烟，那基本上就能用。’“
在看书的过程中，我不断回想起我第一家公司到现在的公司持续交付能力的转变，我毕业的第一家公司，当时上线的时候必须提前发起审批，将打好的包发给运维，然后在午夜的时候和测试以及运维一起，然后在晚上上线，如果出了问题，我们势必会弄到两三点，再严重一点就是通宵了。第二家公司则是有了自己发布系统，某种程度上也实现了发布的自动化以及容器虚拟化，但是当时我们的构建时间长的不可思议，我们发布的很多时候都是在等待构建，现在想起来，是服务拆分的不好，构建部署平台也做的不好，导致每一次的发布都要构建所有的服务，并且构建的速度非常慢，所以尽管我们下班就可以发布，不顺利的话也要到半夜。我当时其实也有参与到发布平台那个项目中，但我那时候并没有那种意识，我只是在上级分配的任务里埋头干，很多时候没事做我也不会主动思考我们可优化的地方在哪里。甚至在别人吐槽系统的时候，我常常觉得我已经尽力了，现在看来我没有，他们的吐槽我应该用自我批评的眼光去看待。啊，我真的成熟了。
现在所在的公司，我们有了真正意义上且是自研的运维平台，真的实现了快速迭代的能力，一天我们就能发布很多次，而我最终又参与到了这个项目，这本书也让我感同身受，这些年的技术变化，同时也促使我更多地去思考自己的定位，我一直觉得我自己是个开发的角色，事实上也是这样，但我学会了要在更高的层次去看待问题，看问题的俯视角越大，看到的视野也越宽广，就会发现能做的事情有很多，我现在终于明白，我所担任的一个角色，或者说运维平台的角色，并不是蚕食掉运维的工作，而是作为一个开发部门和运维部门的一座桥梁，或者纽带，去将他们的工作连接起来，更好地进行协作。运维平台的功能，除了服务于开发人员，也要服务于运维人员，所有人最终的目标，应该是一致的，最终都是为了公司的利润，最终利润又反馈回我们自己身上，形成一条健康的闭环。
##三步工作法 书里描述了我们工作的划分，大多数情况都是分为四类：业务项目、内部项目、变更以及常常打乱我们节奏的计划外工作。三步工作法则包含了以下原则：
- 流动原则：主要内容是我们的工作流，一个好的工作流能够加速从开发、运维到交付给客户的流程。
- 反馈原则：第一步是从左到右的流程，那么这一步就是从右向左的一个反馈机制，通过这种方式，我们能创造出更安全的工作系统。
- 持续学习与实验原则：这一步主要是和企业文化相关，通过创建一个学习型组织，以及创造主动承担风险并且从风险中学习的文化，让所有经验可持续地积累，组织里的人都可以相互借鉴彼此的经验和智慧。
这本书也让我真正的理解到了技术债务这个词，我们在工作中常常会由于某种原因，需要快速但是用不好的方法走捷径去实现一个东西，我们常常安慰自己，等有空了就会去优化这个地方，但事实是永远有新的需求，占用了你原本承诺自己要去做的事，这就是那些重要但不紧急的事，其实它的优先级应该与重要的新需求一样高，或者我们应该从一开始就避免这些情况产生，这也是devops存在的一个目标之一。所以devops确实是不应该只包含开发与运维，更应该包含一整套管理以及协作的哲学，作为IT工作的一份指导方针。
另外一句让我印象深刻的话是，”所有在非约束点做出的改进都是假象。“约束点大多数情况下指的是瓶颈，我们要优先优化的永远是系统里的瓶颈。在瓶颈之前做出的改进只会让压力更多地堆积到瓶颈处，而在瓶颈之后做出的改进都是徒劳。
这本书没怎么出现微服务，敏捷开发流程，容器，但是又似乎都在讲这些，并且这些年发展基本都是按着这些技术的趋势发展，而且书还是以小说的形势写的，真的了不起，太真实了。
