DevOps听起来不错，但适合你的企业么？

Posted 2021-04-16 DevOpsClub

背景

近几年DevOps理念、方法、技术和实践不断成熟，在各个行业都开始被广泛接受和应用。但也有不少相对谨慎一些朋友，他们觉得DevOps的想法听起来很不错，但是对在特定的企业环境下DevOps能不能大范围实施、能实施到什么程度还是充满疑惑。

正好去年底我看到了Jez Humble在2017年DevOpsDays美国西雅图站的演讲《Continuous Delivery Sounds Great But It Won’t Work Here》。演讲中提到了一些很棒观点，贯穿的几个案例故事也非常有启发，于是笔者结合自己的一些经验和思考，整理本文分享跟大家。

Jez Humble一直是我非常关注的大神级人物，他在2010年的著作《持续交付》对我影响巨大，后来他参与合著的《Lean Enterprise》、《DevOps Handbook》也绝对是DevOps这一领域的必读书籍。

DevOps真的不适合你么？

DevOps体系中包含很多关键实践，而持续交付可以说是其中相当核心的一个环节，也是从工程角度支撑DevOps实现的关键使能者。
Jez对持续交付的定义是："The ability to get changes—features, configuration changes, bug fixes, experiments—into production or into the hands of users safely and quickly in a sustainable way."

也就是说，持续交付是能够把所有类型的变更（特性、配置变更、缺陷修复、实验等）以安全、快速和可持续的方式，交付到生产环境或用户手中的能力。做的好的话，也许你的项目就能进展的一帆风顺，不用每次为了合并代码、解决冲突搞到大半夜，不用焦头烂额地为了一次发布熬个通宵，也不用接下来的整个周末加班只为了解决发布后的线上问题。一切交付和发布都是那么平常，你再也不用到处救火，生活和工作终于可以平衡了。

听起来不错是吧？嗯，我也同意，这个想法是极好的。但你可能会说，这在我的企业中没法实现！通常大家反馈无法实施DevOps或持续交付的原因有以下几点：

• 我们受到严格监管，没法这么做

• 我们不是开发网站，没法用互联网的方法

• 我们有太多遗留系统，历史包袱太重

• 我们的员工太笨了，新方法玩儿不转

Jez也很犀利，他说真实的原因无外乎两条（台下一片掌声）：

• 我们的架构太糟糕了

• 我们的文化太糟糕了

接下来，让我们依次来分析一下以上大家反馈的几点原因，看看DevOps是否真的就无法开展，并通过一些案例故事帮助大家理解。

一. 高度监管的环境，如何实施DevOps？

在高度监管的环境中，反对DevOps或持续交付的声音有两种：

• 使用DevOps的方式可能有风险

• 监管要求与DevOps实践相冲突

对于第一种说法，其实直接与DevOps或持续交付运动的初衷相矛盾。因为我们提倡的所有方法与实践，目标之一就是要降低发布风险。而且统计数据也给出了很好的证据，连续四年发布的《DevOps现状调查报告》显示，高绩效企业可以同时拥有高级别的吞吐量和稳定性，也就是质量和效率是可以兼得的。

DevOps或持续交付使用了大量的自动化编译、自动化测试、自动化部署（发布）等技术，这与传统做法中通过大量规范文档、检查单、评审会的方式减缓风险不同，但这并不能说明DevOps的模式中风险就没有控制，反而DevOps这种持续和自动化的、内建质量的实践，其风险控制效果可能更好、效率更高。

对于第二种说法，企业中很多为了满足监管要求的设计，比如低频和严格审批的发布、按阶段切分软件交付生命周期、职责权限分离等等，看上去是无法进行快速交付的。而实际上，大家都听说过亚马逊的案例，在2011年就实现了平均每11.6秒就进行一次生产发布，每个小时最多有1079次部署（整个生产环境累计值）。

但亚马逊实际上是一个受到很多监管要求限制的企业，比如著名的萨班斯-奥克斯利法案会计实践（Sarbanes-Oxley Act regulating accounting practices）以及支付卡行业数据安全标准（PCI DSS）。

案例一：

与亚马逊类似，Etsy是一个DevOps领域常被提及的企业。Etsy主要业务是在线销售手工制品。Etsy追求创新速度，在其高度信任的文化中，开发人员经常自己将变更通过自动化的方式部署到生产环境上。

然而，由于Etsy要处理信用卡交易，所以必须遵守支付卡行业数据安全标准（PCI DSS），这里面详细规定了持卡人数据环境必须在物理上隔离，而且涉及到持卡人数据的人，必须要有职责分离，对权限也有非常严格的控制。那么Etsy是如何同时满足合规要求和快速发布需求的呢？主要有以下几点：

• 最小化合规要求的影响范围，区别对待。在系统架构设计上将有关不同合规需求的关注点分离。将安全标准所约束的范围限制到一个隔离的区域，区别对待。比如将涉及到应用和基础设施与其他环境分离，并由一个跨职能团队开发和运营，而不扩展到其他团队。

• 建立机制来限制合规框架与法规对组织的冲击。比如安全标准强制要求职责分离，但并不妨碍这个团队在同一地点一起工作。代码提交到部署过程全部是自动化的，而审批活动都在本地完成，这样就可以消除大量的瓶颈和延迟。

• 采用补偿性控制。理解和尊重法律法规非常重要，但同时我们也需要认识到有很多变通的方式可以实现相同的目标。比如Etsy就使用部署流水线的方式，提供了一种有效的补偿性控制，实际上是对职责分离提供了一种替代方案。

案例二：

美国联邦政府的IT项目也是被高度监管的，与发布和信息系统运行相关的法律法规有超过4,000页，一个新系统上线通常需要花费数月进行文档准备和测试。大多数工作的实施、文档化和测试都需要在联邦政府风险管理框架的管理下进行。一个中等影响程度的系统，至少有325个控制项需要实施。

美国联邦政府中有一个数字化服务机构，他们的任务就是通过技术改进政府服务。他们使用开源组件（包括Cloud Foundry）在AWS上搭建了一个名为Cloud.gov的PaaS平台，接管了应用开发、服务生命周期管理、流量控制、日志、监控和报警等功能。

Cloud.gov平台应用持续交付的方式，所有相关代码和配置都存储在Git仓库中，部署过程全部自动化。Cloud.gov平台的建设对项目交付的效率提升意义重大，因为它处理了325个控制项中的269个，极大降低了满足合规所消耗的时间成本。

二. 除了Web类应用，DevOps也适用于其他类型的系统

有很多DevOps的成功案例都是来自于互联网公司，但我们想说的是，其他类型的应用系统同样可以。DevOps与持续交付的实践可以成功运用到软件系统的各种领域中，有很多组织在构建移动App或嵌入式系统时也可以做的很好。

案例三：

这里分析一个惠普LaserJet固件团队的案例。这是一个嵌入式软件开发团队，负责开发他们所有的打印机、扫描仪和多功能设备中的固件。团队由分布在美国、巴西和印度的400多人构成。他们遇到的问题就是：进度太慢，多年来一直是新产品发布的瓶颈，无法按时交付新特性，有时6~12个月才能交付新需求。

从上图数据可以看出，他们工作中有大量不增值的活动，比如在分支之间移植代码、详细的前期规划，以及由于质量问题导致的大量支持性工作。真正用于”价值需求”（而非”故障需求”）的工作才占团队成本的5%。于是团队进行了大胆的改进工作：

• 引入持续集成实践；

• 大量投资自动化测试；

• 创建一套硬件模拟器以便测试可以在虚拟平台上运行；

• 在开发人员工作台上可以重现失败的测试；

在接下来的三年时间力，他们创建了几千个自动化测试用例，并且建立了完善的持续部署流水线体系。

如上图所示，部署流水线共分为四级（L1到L4），根据自动化测试结果递次晋级。

• 不同国家的开发者首先把代码提交到各自独立的Github仓库中，然后由持续集成系统运行L1级自动化测试；

• 如果测试失败，开发人员会得到通知，在本地工作台上进行Debug；

• 如果测试通过，这些满足了质量要求的代码才能更被合并到主干，并进行第二阶段的L2级自动化测试；

• 以此类推，流水线逐步晋级到L3级（每天六次）、L4级（每天一次），进行完整的自动化回归测试。

这样，开发人员在一天内就能得到代码问题的有效反馈，摆脱了原来在发布前花费六周时间进行集成测试才能发现问题的困境。这套系统固化了小批量、内建质量的工作方式。

使用这种方式，这个拥有1000万行的代码库，每天大致有100次代码提交，而每天都能产出10到15个通过L1级别测试的可用构建，极大的增强了交付的能力。

通过实施持续交付、完备的自动化测试和更加敏捷的项目管理方法后，团队的软件交付能力得到了很大提升。整体开发成本降低了约40%，能够用于创新的资源投入增加了8倍。

这个案例给我们的启示中最重要的一点是，只有在团队大量并持续投入自动化测试和持续集成的基础上，才有可能有如此巨大的成本节约和生产率提升。

就像Jez说的，”Lean is not about cutting cost, it’s about investing to remove waste, and in the medium and long term, this drive down transaction cost of making changes, so you can move faster!”

三. 在遗留系统的基础上实施DevOps

很多组织把业务关键数据保存在十多年前设计的系统中，这类系统经常被称为遗留系统。我们要说明的是，DevOps与持续交付的原则和实践同样也可以应用到这类系统中。

案例四：

澳洲最大的保险公司Suncorp成功在大型机系统上实现持续交付。他们在自动化测试框架上进行了大量投入来支持快速的系统开发、维护和升级。针对使用COBOL的大型机系统开发的自动化测试框架，可以对核心功能进行UAT测试，既支持功能测试，也支持系统间的集成测试，能够覆盖500到1000个业务逻辑。

一旦端到端的业务场景中通过测试发现缺陷，必须要在数小时或数天内给出对策并解决，而不是像很多大型企业通常需要数周的时间。下图是大型机”绿屏”系统进行自动化测试的截图，出乎意料的是，执行速度非常快（笔者在数年前也开发过类似的自动化测试框架）。

很多企业工作在非常复杂的环境中，有成百上千个系统或服务需要管理。最大的障碍其实并不是工作在大型机系统上，而是进行变更的时候需要一次性部署整个系统的多个关联系统。这是实施DevOps和持续交付在架构上面临的最大挑战。

在每年的《DevOps现状调查报告》中，都会涉及这样的问题：你能够独立于所依赖的应用和服务进行部署或发布么？你能脱离集成测试环境进行测试么？这些就是你需要考虑的架构上的约束，在架构层面除了经常考虑的可靠性、可扩展性、安全性、性能等特性之外，我们需要额外关注可测试性和可部署性。

• 架构的可测试性。开发可以在他们自己的工作站上运行自动化测试发现大部分缺陷（有关联系统时可利用Mock），而不需要依赖在复杂的、集成的环境上运行很多验收和回归测试。

• 架构的可部署性。部署特定的系统或服务可以独立、自动化的执行，不需要进行复杂的编排，这样的架构可以帮助我们实现零停机发布或最小化服务不可用时长。

实现可测试性和可部署性，可以从建立产品和服务的组件化，高度封装和相互解耦的架构开始。为了实现这个目标，创建版本化的API并实现向下兼容是非常值得投资的。虽然这样增加了系统的复杂度，但是所带来的部署灵活性的回报会数倍地高于投入成本。

当然，现实世界中很多组织面临的情况，就是有大量的遗留系统没有实现上面所述的可测试性和可部署性。虽然从短期看，我们可以通过更好的管理、加强协作解决其中的部分问题，但是中长期推荐的方案是渐进式地对系统架构进行重构，有时也描述为”演进式架构”。

一种演进式架构的模式被称为“绞杀者模式”，单体架逐步被很多遵守SOA原则的组件所替换掉，随着时间的发展，越来越多的新功能使用新的架构实现，逐步把老的架构替换和”绞杀”。下图展示了这一模式，更多细节可以参考Matin Fowler的博客文章。

关于绞杀者模式，在《DevOps Handbook》中也提到一些案例可以参考，篇幅原因，我们今天暂不展开。

四. 实施DevOps中如何发展员工的能力及文化的因素

组织转型中的一个有意思的案例是美国新联和汽车制造公司（NUMMI）的例子。

案例五：

NUMMI是通用汽车和丰田的合资子公司，也是加州唯一的汽车制造工厂。在1980年代，这家工厂还属于通用汽车，当时这个工厂生产汽车的质量是通用汽车中最差的，当时劳工关系已经崩溃，工人们一边工作一边酗酒和赌博。所以通用汽车在1982年关闭了这个工厂。

但恰逢丰田希望在美国建立一家汽车工厂，于是与通用公司合资，重新雇佣原来的工人，并把他们送到日本的丰田城学习丰田管理系统（TPS）。令人吃惊的是，短短三个月的时间，NUMMI就生产出了与丰田一样的质量几乎完美的汽车，而成本却比之前低的多。

这个案例带给我们启示的是，员工本身也许并不是问题，工作的方式和系统才是问题。另外一个业界的故事，曾担任Netflix云架构师的Adrian Cockcroft，经常被500强公司问起Netflix如何迁移到云，以及这些能力超强的员工是从哪里招聘到的？他的回答非常简单：”我是从你们公司招过来的!”

丰田生产系统之所以成功，它是把”质量内建于产品“作为最高优先级，发现问题必须马上解决，而且必须对系统进行改进，努力确保同样的问题不会再次发生。比如他们使用著名的”安灯拉绳”机制，当出现问题时，呼叫管理者过来协助解决问题，如果问题短时间无法解决掉，工人可以停掉整条生产线，直到问题被最终解决。之后，团队会进行实验并采取改进措施，防止问题再次发生。这种理念和方式与当时欧美生产制造管理的那种把工作分解为独立任务，然后按照清晰划分的职能”各管一摊”的方式完全不同。

后来通用汽车想把NUMMI取得的成功复制到其他工厂，甚至把NUMMI工厂的每一个角落拍下来精确复制到其他地方。但结果是，他们建立起了一座带有”安灯拉绳”装置，但却没有人去拉的工厂。因为这里对管理者的激励因素是汽车下线的速度（无论是否可用）。多年后的2009年，通用汽车破产并退出了NUMMI，丰田随后于2010年关闭了该工厂。

不过故事的精彩还在继续，后来一家公司在工厂的原址上进行改造并继续生产汽车，也许你已经猜到了，这家公司的名字叫做特斯拉。 特斯拉把这个工厂重新命名为Tesla Factory，生产著名的Tesla Model S轿车。

NUMMI的案例告诉我们，一个已经垮掉的组织在新的领导力和管理范式下得到了再造。要改变文化，首先要去改变的是行动方式，而不仅仅是思维方式，文化的改变是行为改变的结果。试图改变组织的文化时，首先需要清晰定义我们期望的行为是怎样的，接下来提供必要的培训，然后采取措施来强化这些行为。

以上的案例是关于精益生产的，其实其中很多实践可以直接映射到软件研发和交付领域。比如我们经常说的持续集成是否做到位了，有三个问题可以衡量：

• 团队所有的开发人员是不是每天至少一次将代码提交到主干？

• 每次提交到主干的变更是否都会触发一次构建过程，包括执行自动化测试来发现回归问题？

• 当构建和测试过程失败时，团队是否停下手头工作立即处理，然后在数分钟内解决掉问题？

这三个问题直接映射了精益生产中关于减小批量、内建质量和安灯拉绳的实践，当你要求团队遵循这些实践，提供培训并反复强化这些行为时，文化的逐步转变就是可期待的了。

总结

本文通过对实施DevOps或持续交付持怀疑态度的四个常见问题及其本质进行了分析，并贯穿了五个案例故事辅助说明。最终想表达的观点是，DevOps和持续交付在各种场合下都能起到积极作用，只要保持对改进的坚定信心，以及最佳实践的正确牵引，实施持续改善，相信都会对IT效能和组织绩效产生巨大的正面影响！《DevOps现状调查报告》中的数据也充分证明了这一点。

本文重点：

• 在高度监管的环境中实施DevOps：最小化合规要求的影响范围（关注点分离）、建立机制来限制合规框架与法规对组织的冲击、采用补偿性控制；

• DevOps同样适用于非Web类应用：小批量、内建质量的工作方式，持续集成实践、投资自动化测试、自动化部署与发布；

• 在遗留系统的基础上实施DevOps：增强架构的可测试性和可部署性，从建立系统和服务的组件化，高度封装和相互解耦的架构开始。架构需要持续演进，可采用绞杀者模式；

• 实施DevOps强调发展员工的能力及文化的因素：员工本身也许并不是问题，工作的方式和系统才是问题。要改变文化，首先要去改变的是行动方式，而不仅仅是思维方式，文化的改变是行为改变的结果。

感谢你看到文章的最后，有这样一句话：

Don’t Fight Stupid, Make More Awesome，送给专注于通过DevOps等优秀的软件工程实践，追求卓越产品和软件能力的我们，大家共勉 :-)

这句话来自前亚马逊被称为的”灾难专家”的Jesse Robbins，他曾负责整个亚马逊的站点可靠性。他创立了”GameDay”项目，用于增强系统的可恢复性，这种方式已经被Google、Netflix、Yahoo、Facebook等公司广泛采纳。

其他资源

看完以上内容还是感觉意犹未尽？好消息来了。

DevOpsDays北京站即将启程

DevOpsDays大会2018北京站，即将于5月5日正式举办。届时我也会有主题演讲，并有一份神秘大礼送给大家，我在大会现场等你。

近期培训：