《DevOps实践指南》前言

误区1：DevOps只适用于创业公司。他们所遇到的问题和传统企业相比并无二致：软件的高风险代码容易导致灾难性故障，无法快速发布新功能来击败竞争对手，存在安全合规性问题，服务无法扩容，开发和运维彼此高度不信任等
误区2：DevOps将取代敏捷
误区3：DevOps与ITIL不兼容。许多人认为，DevOps与1989年发布的ITIL（Information Technology Infrastructure Library，IT基础架构库）。DevOps实践可以与ITIL流程兼容。然而，为了支持DevOps所追求的更短的发布周期和更频繁的部署，ITIL流程的许多方面需要完全自动化
误区4：DevOps与信息安全及合规活动不兼容。集成到了软件开发生命周期的每一项日常工作中，因此会得到更好的质量、安全性和合规性
误区5：DevOps意味着消除IT运维，即“NoOps”。许多人错误地将DevOps解释为完全消除IT运维的职能，然而，这种情况是很少见的。通过这种方式，IT运维人员变得更像是开发人员（或者QA和信息安全人员），融入到了产品开发过程中，而该产品则是开发人员在生产中用来安全快速地测试、部署和运行IT服务的平台
误区6：DevOps只是“基础设施即代码”或自动化。但是DevOps还需要文化规范和架构，以便在IT价值流中实现共同的目标
误区7：DevOps仅适用于开源软件。但实现DevOps与所使用的技术无关

产品经理、开发人员、QA人员、IT运维人员和信息安全人员互相帮助，齐心协力，整个公司的业绩蒸蒸日上
“技术债务”这个术语是Ward Cunningham首次提出的。类似于金融债务，技术债务是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。即使我们审慎地承担技术债务，也依然会产生利息
开发部门通常负责对市场变化做出响应，以最快的速度将新功能或者变更上线。而IT运维部门则要以为客户提供稳定、可靠和安全的IT服务为已任，让任何人都很难甚至无法引入可能会危害生产环境的变更。这种配置方式让开发部门和IT运维部门的目标和动因之间存在巨大的冲突
公司对不同部门的考核和激励不同，阻碍了公司全局目标的实现
这些长期冲突常常导致技术工作者交付出质量低劣的软件和服务，打造出糟糕的客户体验，每天都要采用临时解决方案、应对紧急情况

第一部曲：我们日常工作中的很多问题源于应用程序和基础设施过于复杂、异常脆弱、文档不完备。更令人担忧的是，我们最脆弱的组件正支撑着最重要的业务系统或者最关键的项目
第二部曲：某个产品经理承诺了一个更大规模、更大胆的吸引客户的功能，或者是业务主管设置了一个更高的收益目标。又导致了技术债务的增加
最后一部曲：所有事情都变得更加困难——所有人都越来越忙，工作所消耗的时间越来越多，沟通变得更加缓慢，工作积压得越来越多

对于我们的员工而言，这意味着长时间工作、周末加班、生活质量下降，而且影响的不仅仅是员工，还有所有依赖他们的人，包括他们的家人和朋友。当这种情况发生时，我们失去最好的员工（除了那些因为责任感和义务而觉得不能离开的人）也就不足为奇了
2011年，约5%的全球GDP（即3.1万亿美元）用于IT（含硬件、服务和电信）。如果我们估计这3.1万亿美元中的50%用于运营成本和维护现有系统，而且这50%的三分之一用于紧急和计划外工作或返工

通过在流程中的每一个步骤创建快速反馈回路，每个人都可以立即看到工作效果
自动化测试可以帮助开发人员快速发现错误（通常在几分钟之内），实现更快速的修复以及真正的学习。如果错误是在6个月后的集成测试中发现的，那时相关的记忆和因果关系早已消退
想要让新功能生效，我们只需要改变一个功能开关或者配置项即可，而不再需要经历数天或者数周的辛苦工作。这个小变更使新功能对更大规模的客户群可见，一旦出现错误，就会自动地回滚。因此，发布新功能变得可控、可预测、可逆，且压力也小了
在出现问题时，我们进行不指责的事后分析，这并不是要惩罚某人，而是为了更好地理解导致事故的原因，以及如何防止事故再次发生。因为注重质量，所以我们甚至会故意在生产环境中注入故障，从而了解系统是怎样以预期方式发生故障的

Frederick Brooks在其著名的《人月神话》一书中强调过这一点。他解释说，当项目延迟时，增加更多的开发人员不仅降低了单个开发人员的生产力，而且也降低了整体的生产力
另一方面，DevOps证明了在拥有正确的架构、技术实践和文化规范的情况下，小型开发团队能够快速、安全、独立地开发、集成、测试和部署变更到生产环境

0 人点赞