花了2天的时间看完这本书：《凤凰项目（沙盘特别版）》，感触颇深。和所有讲DevOps相关的书不同，感觉就在读小说一样，而且非常的励志，讲述了一家陷入困境的传统制造业公司，怎么凭借凤凰项目（或者独角兽项目）起死回生的。IT运维在其中发挥了只管重要的作用。
最近这半年来，我大部分的工作也集中在开发运维上，在这个过程中，也接触到了很多DevOps相关的知识和实践，虽然书中很多东西比较旧，但是还是有很多只得借鉴的地方。 读这本书的时候，有很多地方产生了共鸣，一度让我回忆起了之前参与公司的TWI中的课程，关于敏捷和精益的部分，尤其是精益思想。
开发运维从何而来
“开发运维”这个词最初是在2008年由帕特特里克·德布瓦和安德鲁·谢弗提出的，并于2009年因为约翰·阿斯帕尔瓦和保罗·哈蒙德那场著名的“每天超过10次部署：Flickr的开发与运维合作”演讲，在Velocity技术大会广为流传。
书中认为“开发运维”是在IT价值流中应用精益理论的结果。
三步工作法
书中很大的篇幅为读者阐述了这一基础原理，即所有开发运维模式都来自“三步工作法”，它旨在阐明指导开发运维的流程与实践的价值与理念。
第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率机票运维有效性指标等局部目标）进行优化。
必要的做法包括：持续构建、集成以及部署，按需创建环境，严控半成品，以及构建器能够顺利变更的安全系统和组织。
第二工作法是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头保证质量。
必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；日复一日地持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普通的产品遥感技术，让每个人都能知道，代码和环境是否在按照设定的运行，以及是否达到客户的目标。
第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。
尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。
必要的做法包括：营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。
对开发运维的误解
一如各种变革性、颠覆性的运动，开发运维也会被误解或曲解。以下是对开发运维的一些主要误解。
开发运维取代了敏捷开发
开发运维与敏捷开发完全兼容。事实上，开发运维是始于 2001年的敏捷开发的逻辑延伸，因为我们现在知道，“完成”的真正定义并非开发部完成了编码，而是只有在代码经过充分测试并按设计在生产中运行时，代码才算“完成”。（注意，敏捷开发并非采用开发运维的前提条件。）
开发运维取代了ITIL
尽管有些人可能会把开发运维看作ITIL(IT Infrastructure Library,信息技术基础架构库）或ITSM(IT Service Management,信息技术服务管理）形对立面，但是开发运维与ITIL也是可兼容的。ITIL 和ITSM仍然是支撑 运维流程的最佳编码法则，而且它们描述了为了支撑开发运维协同工作的流程，IT运维部所需要具备的很多能力。
为了适应与开发运维相关的更短的交付周期和更高的部署频率，ITIL流程的许多方面都需要自动化，特别是变更、配置和发布流程等方面。
因为在发生服务事故时，我们同样需要快速检测和修复，所以关于服务设计以及事故问题管理的ITIL准则仍然和以前一样有意义。
开发运维意味着无需运维
有时候，“开发运维”被错误地理解为“无需运维”（例如，IT运维部被整体取消了）。然而，更准确地说，开发运维经常会让开发部承担更多开展代码部署和维持服务水平的责任。这只不过意味着开发部接管了许多IT运维部和运维工程的职责。
为了支持快速交付并让开发人员提高工作效率，开发运维确实要求把许多IT运维任务转变为自助服务。也就是说，不再是开发部开出一张派工单，等着IT运维部完成工作。许多这一类的活动将会自动化，让开发人员自己就能做这些事（例如，构建一个类生产的开发环境，为产品远程添加一个功能指标）。
开发运维只适用于开源软件
尽管开发运维的很多成功案例都来自使用LAMP栈（LAMP stack)等软件的公司，但各组织通过Microsoft.NET、SAP,甚至COBOL 应用程序，将开发运维的模式植入到大型机和惠普激光打印固件上。
开发运维的原理是通用的，它们在很大程度上独立于所采用的底层技术。一些开发运维模式有特定的技术要求（例如，可支持自动测试，可公开能够在版本控制中核查的配置），这在开源软件中更为普遍。
开发运维只是“作为代码的基础架构”或自动化
尽管本书展示的许多开发运维模式需要自动化，但开发运维也需要IT价值流自始至终拥有共同的目标并共同解决问题。这远非自动化所能涵盖的。
开发运维只适用于创业公司和“独角兽”公司
开发运维适用于任何一家亟需提高开发部门计划内工作流，同时为客户保持质量、可靠性及安全性的企业。
事实上，我们认为开发运维对于“马驹公司”的重要性更甚于“独角兽”公司。毕竟，如理查德·福斯特所言：“1955年的财富500强公司中，有87%业已消失。1958年，财富500强公司的平均寿命为61年，而现在只有18年。” 我们知道，每一家IT公司都有螺旋式下降的过程。然而，绝大多数公司的IT部门都会给出无数条理由，证明其不能采用开发运维，或者证明开发运维与其无关。
“马驹公司”最主要的一个反对意见是，所有的“独角兽公司”（例如谷歌、亚马逊、Twitter、Etsy)都是生来如此的。也就是说，“独角兽公司”从一开始就在做开发运维。实际上，几乎每一家开发运维“独角兽公司”都曾是“马驹公司”，都曾有过“马驹公司”所面临的全部问题。
「真诚赞赏，手留余香」
请我喝杯咖啡？
使用微信扫描二维码完成支付
