<凤凰项目>读后小记
本书是DevOps培训及凤凰沙盘的配套用书，因为“穷”lan所以直到618活动才把这个系列给请回了家，在一口气花了大概5个小时的时间后，我完成了这本书的阅读，接着谈谈自己的总结。
1.开发为了在最后期限前发布，现在才考虑测试和部署的问题，企图把锅丢给运维和测试!
2.程序员们乃至项目经理每当想到要学的东西就近乎疯狂，一个人有几次做到把自己原有的知识全部抛下，去迎合新趋势？
3.当你意识到让所有人紧张在一线装出很重视工作是错误的时候，辞职吧，别让自己的正确掩饰领导的错误，如果领导不能在出现灾难后回心转意，那么你的决定是正确的，否则你还有挽回败局的主动权。
4.开发团队因为从来不把运维团队的时间正确计算在内，即使考虑了，也在不断蚕食，最终导致运维收拾烂摊子，那么测试何尝不是这样!
5.计划外工作会导致大家都停止思考，成为处理问题的接单员，这是在为前面的捷径偿还债务，并且利息的递增是和高利贷一样的。
6.当面临计划外工作过多的时候，降低中间件，让发布走起来，停止需求输入是非常好的办法。
7.任务的优先级往往来自于喊得最响和领导最大的，聪明的少数会通过贿赂，业务部门会通过请吃饭的方式来解决优先级的问题。
8.找到流水线上的瓶颈点，分解业务确认哪些和瓶颈点有关，哪些无关，计算瓶颈点导致的发布延误代价，就好像找性能的慢查询。最终确保实际开发时间和实际的规划时间接近!
9.如果你无法及时完成测试并在业务敏捷度上打败竞争对手，那么就玩完了。和传统制造业比，it制造业实在是太落后了，性能调优不也如此!
上面9点是我在凌晨3点完成这本书的阅读同时记录的（如果没阅读过这本书可能不能完全Get到这些点）。顺便看了一下这本书只有1.3w的发行量，而且是3年时间，大多数不是运维或者真的站在运维一线的人是看不懂的。这本书和我以前看过的《最后期限》有很多类似之处，其实做好事情的关键未必是技术细节，而是宏观的方向与思路。
最后作为我，应该替所有测试好好吐槽整个运维和开发，不要以为把东西放在哪里就行了，等我写本《一个it测试的传奇故事》吧!