读《凤凰项目》
Intro
程序员为了推广方法论写出的一本运维经理的爽文，十年混子运维(自言能长期平衡家庭和生活的好男人)一天在上司和上司的上司同时被裁的情况下临危受命成为运维代理副总裁，需要在九十天内完成凤凰项目拯救公司。但一开始就麻烦不断，幸得扫地僧版不拘小节的高人相助，掌握三步工作法，最终升职加薪走上人生巅峰。最妙的是书的最后部分就是专门讲使男主获得成功的屠龙术三步工作法，DevOps，持续交付。这能使一个公司的IT部门不再缓慢，而且能达到可怕的高速，同时也能减小审计，安全等对程序开发和部署的流程速度的影响
每个工作中心都由四种东西组成：机器、人员、方法，以及测评。
- 理清工作流中的约束点对其进行管理，任何对非约束点的改进都是幻觉。
- 加速反馈机制，一个关键部分是让等待时间可视化，监控改进的情况
- 形成持续改进的习惯，不断进行练习，改进日常工作比开展日常工作更重要
告知真相是一种爱的表现。隐瞒真相是一种恨的表现。甚至更糟，是一种冷漠的表现。
书摘
◆ 第一部分
俗话说得好，如果你的同事主动告诉你他们要离职，那多半是自愿的。但如果是其他人告诉你的，那他们一定是被迫的。
优秀的夸人方法，先肯定别人过去的努力
你以为我们会把那样的奖励随便颁给什么人吗？”他认真地说，“那是一个重要的项目。为了做成那个并购，我们必须做好那个项目。你和你的团队干得好极了
我需要一个可靠的、不怕告诉我坏消息的人。最重要的是，我需要一个自己可以信任的人去做正确的事。那个并购项目有很多困难，但你始终头脑清醒。大家都觉得你可靠、务实，而且愿意表达真实想法。
◆ 第2章 9月2日，星期二
你要是能找出一个不给生产体系添乱的开发人员，我就能给你找出一个往镜子上哈气却不会起雾的人。或者更有可能的是，他们也许今天又放假了。
◆ 第3章 9月2日，星期二
运维想要稳定，开发想变化，而信息安全想要尝试破坏
比一名开发人员更危险的就是开发人员和信息安全部门的人联手。
◆ 第4章 9月3日，星期三
我缓缓点头，不上她的当。“我期待你提出的任何建议，莎拉。
意识到这些话的弦外之音，我的心抽紧了。我以前见过这样的场景。剧本很简单，首先，接到一项紧急的日期驱动项目，由于对华尔街或客户做出的外部承诺，发布日期不能延迟；然后，增添一大帮开发人员，他们用完了所有的进度时间，没时间进行测试或运维部署；随后，由于没人愿意错过部署日期，开发部门之后接手的人只得不计后果地猛抄近路。
帕蒂坚持要给大家编号，等着她手下的那帮傻瓜审批和安排我们的变更项目。那绝对又荒唐又浪费时间。”
我们不能重蹈覆辙，但我们也不能再遭受工资核算故障那样的灾难。韦斯，我需要你参加会议，我也需要你帮忙提出解决方案。否则你就会变成问题的一部分。我能指望你吗？”
◆ 第5章 9月4日，星期四
其中大部分内容就像信息安全部给我们的报告那样大而无用，这也是约翰恶名远播的原因之一。
哦，天哪。”我喃喃自语，“布伦特。布伦特、布伦特、布伦特！要是没有他，我们就什么事都干不成了吗？看看我们！我们想就所承担的义务与所拥有的资源开展一次管理层讨论，而我们谈来谈去只是在谈一个人！我不在乎他有多能干。如果你是说，我们部门没了他就干不成事，那我们就遇到大问题了。”
他抱怨说，他得花很多时间培训和帮助新人，而且分身乏术，但还得参与所有的工作。
要是对工作需求、优先等级、工作进度、可用资源都一无所知，怎么可能管理好生产工作呢？
“一定要告诉大家，我们这样做是为了争取更多的资源。我不希望有人以为我们要外包服务或解聘谁，好吗？”
◆ 第6章 9月5日，星期五
我们恐怕得重新开始，但我们需要你的经验和技巧才能达成目标。这依然是你的流程，而且我知道，这对我们的成功至关紧要
◆ 第7章 9月5日，星期五
但它们都赞同一点：半成品是个隐形杀手
不应该根据第一个工作站的效率来安排工作，而是根据瓶颈资源所能完成工作的速度来安排工作。”
作为IT运维部的副总裁，你的工作是确保形成一条迅速、可预测、持续不断的计划内工作流，从而向业务部门交付工作价值，同时尽可能降低计划外工作的影响和破坏，那样你才能提供稳定的、可预期的、安全的IT服务。
◆ 第8章 9月8日，星期一
对我的团队来说，这可是第一次。
◆ 第10章 9月11日，星期四
我指了指他的座机：“无论如何都要想办法改正大家直接来找你帮忙的坏习惯。
◆ 第11章 9月11日，星期四
但是，我们何曾问过，是否应该接受这些工作？我们又是凭什么做出了决定？
◆ 第15章 9月17日，星期三
计划外工作则阻止你去开展那三类工作。
小小的核反应炉熔毁事故
“与其他种类的工作不同，计划外工作是恢复性工作，几乎总是让你远离目标。因此，知道你的计划外工作从何而来就显得尤为重要。”
计划外工作会让你丧失开展计划内工作的能力，因此必须不惜一切代价去消灭计划外工作，墨菲法则确实存在，因此总会有计划外工作，但你必须高效地处理它们。
你现在听上去和吉米一样，对你无法控制的事情怨天尤人。
◆ 第16章 9月18日，星期四
我突然感到怒不可遏。史蒂夫又要把事情搞砸了。我回忆起自己的军旅生涯，终于说：“先生，允许我自由发言吗？
◆ 第18章 9月23日，星期二
史蒂夫继续说：“我最喜欢的一本关于团队动力学的书是帕特里克·兰西奥尼的著作《团队发展的五大障碍》。他在书中写道，想要在团队中达成相互信任，你需要展现出自己脆弱的一面。所以，我要告诉你们一些关于我个人的事情，以及是什么让我有动力走到今天。
◆ 第19章 9月23日，星期二
当你们所做的只是被动应付，就没有足够时间开展繁重的脑力劳动，弄清楚是否可以接受新的工作。那
业务部门会做出一些不合理的承诺，保证在某个不可能的时间发送某些产品，无视系统中已有的全部工作
◆ 第20章 9月26日，星期五
每个工作中心都由四种东西组成：机器、人员、方法，以及测评。
“我知道了。”我微笑着说，“发布那些不需要布伦特的备选项目是安全的。”
我们经常需要寻找提升约束点的方法，也就是说我得采取一切必要手段，让工作经过更多环节才能到达布伦特那里。
‘改进日常工作比开展日常工作更重要’。
第三工作法’就是要让我们不断给系统施加压力，从而不断强化习惯并加以改进。
弹性工程学告诉我们，系统里要经常出些故障，长此以往，再遇到困难就没有原来那么痛苦了。
改进的内容几乎是无关紧要的，关键是你要不断改进。为什么？因为如果没有改进，无序状态必将使情况恶化，也就不可能达到零失误、零工作相关事故以及零损失的状态
“‘第二工作法’的一个关键部分是让等待时间可视化，那样就能知道你的工作何时在某人那里排了几天的队，
换句话说，‘实际加工时间’只占了‘总加工时间’的一小部分。
这些‘安全性’项目降低了你们的项目吞吐量，而你们的项目吞吐量是整个公司的约束点。它们还让你的部门里最受约束的资源疲于奔命。而且它们不会对公司的可扩展性、有效性、存活性、持续性、安全性、保障性以及防御性有任何帮助。”
◆ 第21章 9月26日，星期五
独坐此身缚
吾力本可平众怒
奈何众顽愚
◆ 第22章 9月29日，星期一
业务项目和内部项目
◆ 第24章 10月11日，星期六
告知真相是一种爱的表现。隐瞒真相是一种恨的表现。甚至更糟，是一种冷漠的表现。
◆ 第26章 10月17日，星期五
我们的滞销产品太多，而畅销产品又总是缺货。
客户关系管理系统（CRM）
◆ 第27章 10月21日，星期二
第一列是达成迪克期望结果所需要的业务能力和流程；第二列列出了那些业务流程所依赖的IT系统；第三列列出了IT系统或数据可能会发生的故障；在第四列，我们要写下防范那些故障发生的应对措施，或者至少能够侦测并做出回应的措施
他提出的内容激动人心。他的第一条建议是大幅度缩减SOX-404合规项目的范围。他精准地描述了为何这样做是安全的，此时我意识到，约翰也掌握了“第一工作法”，真正做到了“对公司系统具备根本性的认识”。
◆ 第29章 11月3日，星期一
工作流只朝一个方向移动：向前。在IT部门创建一个向前的工作系统。记住，目标是单一工作流。
◆ 第三部分
他们着眼于整个工作流，确认约束点的位置，并且尽其所能地运用各种技术和流程知识来确保工作得到有效执行。他们可以驾驭‘内心的阿尔斯帕瓦’。”
“我想，你的目标应该是……”他说着，停顿了片刻，“一天十个部署。为什么不呢？”我张大了嘴巴，说：“那是不可能的。”
只要开发部和运维部协同工作，连同QA和业务部门一起，这个‘超级部落’就能够成就各种不可思议之事。
在我看来，到现在为止，你们的所作所为都不过如此。这栋楼里的人可要比你们这些IT工作者更有创意，也更有胆量
◆ 第31章 11月3日，星期一
也许IT工作比生产制造复杂得多。IT工作不仅是无形的，因此更难追踪，而且可能出错的地方也要多得多。
◆ 第33章 11月11日，星期二
不过，想要跟上一天十个部署的节奏？”他继续说，“完全是疯了！但是集中精力把安全测试自动化，并把它整合到威廉用于他的自动化QA测试的同一套流程中以后，每当一个开发人员提交了代码，我们就进行一次测试。通过多种方法，我们现在的可见性和代码覆盖率比公司里的其他应用程序都要好！”
◆ 第35章 1月9日，星期五
我们需要建立起一种文化，强调勇于冒险以及从失败中汲取教训的价值观，并强调通过反复实践以致炉火纯青的必要性。
我不希望张贴宣传质量与安全的海报。我希望我们的改进能够体现在日常工作的所需所用上：应用到日常工作之中。
“你帮助我认识到，IT不只是一个部门。相反，它就像电力一样无处不在。IT是一种技能，就像能读会算一样。
在中国叫授人以鱼，不如授人以渔
一时的救世主固然好，但普世的圣经则更有用