DevOps系列：DevOps的方法论

最近给某银行做运维规划，由于此银行在推进持续发布和部署，客户明确提出要考虑微服务的管理。恰巧2020年也考取了DOM，借此机会，聊聊DevOps这个话题。由于这个话题过大，一篇博文肯定写不完，那么分成几次来写吧。这篇，先写DevOps的方法论。

---

DevOps产生的背景和解决的问题

程序员写出的代码，生产的软件功能要被真正的客户使用，必须部署到生产环境，才能产生价值。大部分公司每月，甚至每季度，半年才进行一次生产的发布，大大延缓了代码产生价值的效率。尤其是很多公司实行了敏捷之后，提升了代码开发的效率，却发现代码部署到生产环境，是最大的瓶颈。另外，大部分公司都实行的是烟囱式的组织架构管理，写代码的人在开发部门，基础设施维护在运维部门，开发部门的目的是让代码快速上线，而运维部门的职责是一定程度上维护系统的稳定性，很多公司的开发人员是没有生产环境权限的，都需要运维人员来帮忙部署。由于出发点不同，工作性质不同，开发和运维长期处于各种冲突中。

为了解决这个问题，技术人员开发出一系列工具，可以使代码快速地、自动地部署到环境中，这需要从软件架构到基础设施环境，一系列的变化。开发和运维人员，需要加强合作，才能实现。这就是Development+Operation=DevOps。

在2008年加拿大多伦多的敏捷大会上，Patrick Debois和Andrew Clay Schafer主持了一场研讨，提倡将敏捷原则应用到基础设施而不是应用程序的代码上。在2009年的Velocity大会上，John Allspaw和Paul Hammond分享了题为“每日10次部署，Dev和Ops在Flickr的协作”的演讲。在2009年比利时的根特市（Patrick Debois)的居住地，Patrick发起了第一次DevOpsDays的活动，“DevOps”术语也应运而生。

由此可见，DevOps从诞生之时，就是为了解决如何可以使得代码快速部署的问题，从而用技术手段来解决开发和运维的部门冲突，推倒开发和运维之间的部门之墙。

---

DevOps的知识体系

DevOps发展至今，不仅仅是持续发布和部署（CI/CD)，它的知识体系包含了更广阔的内容。DevOps思想包括了一个基础，三个支柱：以精益为基础，涵盖了敏捷，持续交付和轻量级的ITSM，如下图所示：

1. 精益Lean: 精益思想（Lean Thinking）源于20世纪80年代日本丰田发明的精益生产（Lean Production）方式，精益生产方式造成日本汽车的质量与成本优势。精益思想更进一步从理论的高度归纳了精益生产中所包含的新的管理思维，并将精益方式扩大到制造业以外的所有领域，尤其是第三产业，把精益生产方法外延到企业活动的各个方面，不再局限于生产领域，从而促使管理人员重新思考企业流程，消灭浪费，创造价值，其目标是以最小的浪费来实现消费者的最大价值。精益是一种思考和运营的持续方式，而不是一次性的战术或成本降低的努力。

精益五原则：识别价值，映射价值流，流畅化作业，建立拉动，持续改进。精益提倡消除浪费，并提出了八种浪费：库存，才能，等待，动作，缺陷，运输，过度加工，过度生产。

可以说软件工程领域目前提倡的聚焦价值，从价值流出发，消除浪费等思潮都是源于精益思想，精益思想又生于制造业。

2. 敏捷： 介绍敏捷的书太多了，这里不再做过多的介绍。对比瀑布开发模式的大步迈进，敏捷就是小步快跑。

3. 持续交付CI/CD：让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。我更愿意把持续交付理解为工具和技术，也认为这是使得DevOps方法论可以落地的基石，也可以说先有了技术工具实现了持续交付，才提出了DevOps思想。

4. 轻量级ITISM：提及ITSM，一定会想到ITIL。ITIL作为ITSM的最佳实践，从服务的视角，以流程为方法，将软件的运维重复性、繁琐的工作从技术管理转为流程管理，优化分工，促进协作。ITIL发展至今，一定规模的运维团队一定程度上都实施了ITIL流程管理，其流程理念已经深入人心。但是目前在DevOps的推动下，运维部门面临一系列的转型，ITIL如何适应DevOps发展，还在进一步实践和探讨中。

---