大家好，本次内容我在我司上个月的PWorld大会上分享过，线下会议参与人数有限，这次应邀在微信上向更广泛的人群分享。希望对大家能有帮助，谢谢！
今天分享的主题是加速企业敏捷的DevOps平台。DevOps在2009年提出，经过云计算、微服务、容器等技术概念的推动，DevOps已经被大多数的企业接受并开始付诸实践。
根据我们的实践，接下来我从四个维度为大家分享DevOps：
一、DevOps的认知
我们先来看个问题，企业实施DevOps的情况：应用上线（哪怕是改动一行代码）需要多长时间？
大家的周期通常是月、周、天、小时？
如果大家发布周期在周级别，还有大量的工作靠人工执行，我们需要尽快引入DevOps了。
目前业界对DevOps的了解可谓千人千面，我们先看下维基百科给出的定义：
DevOps是一组过程、方法与系统的统称，用于促进开发、运维部门之间的沟通、协作与整合。
DevOps是提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。
从广义的角度来讲，我们认为DevOps应该从支持项目敏捷到支撑企业敏捷。
我们认为：DevOps不仅是打通开发运维之间的部门墙，更多的需要从应用的全生命周期考虑，实现应用全生命周期的工具链路打通、跨团队的线上协作能力。
纵向集成中DevOps强调的重点是跨工具链的「自动化」，最终实现全部人员的「自助化」服务。
横向集成中DevOps强调的重点是跨团队的「线上协作」，也即是通过IT系统，实现信息的「精确传递」。
对于DevOps的理解，目前业界存在不少的误区，希望大家在实践的时候能够快速跳过这些误区，成功实施DevOps。
采用了云计算（IaaS、容器）才能开展DevOps，确切的讲应该是采用云计算有助于加速DevOps的落地，云计算决不是实施DevOps的先决条件，传统的基础设施一样可以支撑DevOps的落地；
微服务架构开发的应用才适合；实施DevOps与应用架构无关，无论是采用微服务架构、SOA架构，都可以开展DevOps工作；
采用自动化工具本身不是DevOps，只有将这些工具与持续集成、持续交付、持续的反馈与优化进行端到端的整合时，这些工具才成为DevOps的一部分；
设置独立的DevOps部门，在责任没有清晰定义的情况下，这么做会导致更多的竖井，创造更多的混乱。
自动化是DevOps非常重要的一部分，但不是唯一的部分。
我们认为，实施DevOps需要从敏捷、持续、协作、系统性、自动化五个维度进行建设与改进。
敏捷、自动化大家已经比较熟悉，大部分企业也已经付诸了实践工作。
另外我们还需要实现跨部门与组织的协作，从技术、流程维度实现系统化的改进；最后我们认为实施DevOps是一个持续的过程，需要不断的进行总结、反馈、优化。
二、DevOps实践总结
接下来给大家看下我们在组织、技术、流程方面的一些实践：
实施DevOps，可以参考总结的“DevOps实践模型”，从组织、技术、流程三个维度中选择部分开始实践。
根据我们的实施经验，在传统企业中，技术方面的实践最容易在团队中实现、流程次之、组织的优化与变革最为艰难；大家尝试的时候，可以由易入难。
接下来我们看如何在组织方面实现敏捷。
全栈团队，而非全栈员工，按照「两个披萨原则」进行团队组建；团队分组是需要基于特性而非技术维度进行团队划分，确保每个团队开发出来的都是可用产品；
特性团队，是指在大型项目中，根据功能特性进行团队的划分与组件，而不是根据技术特性，根据功能特性组件的团队每次交付的都是用户可用的产品，可以提前进行确认，避免项目结束时候发现交付的产品是不可用的。
通过全栈和特性团队的磨练，逐渐形成自治的、自交付的团队组织。
在技术层面，我们实施了基础设施即编码的能力，将基础环境可编程化，项目团队成员可以自助获取；
形成持续编译、自动化测试、持续部署的能力；
另外我们正在做一件比较有意义的事情，ChatDevOps。ChatDevOps是基于对话驱动的，将开发、运维工具植入对话中的，一批的开发运维机器人为我们提供各种服务。大家如果有兴趣，可以关注下hubot。
在流程方面，我们实施了看板文化。看板通常被当作任务协调沟通的机制；我们把看板作为在制品管制平台，量化组织生产能力；
在产品交付上采用MVP模式，快速交付产品原型，通过市场来验证，修正产品，最终适应市场的需求；
每个项目必须建立持续发布机制，形成自动化、自助化两种能力；
建立度量体系，让数据说话，建立组织的各种数据基线，一方面可以掌控组织的生产力水平，另一方面通过度量数据，反向优化组织瓶颈点；
基于上面的最佳实践，总结了企业DevOps宣言：
三、构建DevOps平台
我们认为实施DevOps的终极目标是加速企业的敏捷转型，从根本上提升IT的生产效率，加速部门、企业的业务创新能力。让团队从IT支撑部门，转向为IT创新部门。
针对技术、流程我们通过平台进行了最佳实践的固化，形成了支持DevOps的平台。
在平台建设时，一个非常重要的思路是建设“以应用为中心的DevOps平台”。大家如果关注业界DevOps平台的话，会发现市面上的DevOps平台更多的是偏向“以资源为中心的”，提供更多是创建容器、VM的能力。
DevOps平台通常具备的几个核心特性：
1、完整的DevOps平台至少提供统一的工作台，支持部门的协同工作；
2、打通工具链，做到自动化和自助化；
3、实现研发过程的度量，建立组织基线数据；
4、无缝支持多种环境公有云、私有云，常见的容器、VM；
5、运行期提供应用高可靠、伸缩漂移等能力；
大家可以看下我们在DevOps平台打通的工具链。
如果团队要自主掌握庞大的工具需要大规模的团队，而使用统一的工作台可以简化整个工具的使用。
基于容器云的DevOps平台主要分为三层：
1、基础设施层：包括IaaS，CaaS，我们分别是基于Kubernetes、Docker实现，上层有一层不同环境的适配，可以无缝对接私有云、公有云、混合云；
2、基础服务层：包括服务管理与调度的基础能力，如注册中心，编排，伸缩漂移；还有一堆具体的企业级或互联网式的云服务；
3、DevOps层：提供支撑全生命周期的18大领域系统更多的是工作流程（需求、设计、开发、测试、发布等）的串接，看板等文化的体现。
为大家展示下一键发布能力，通过DevOps平台，可以一键从源代码获得可访问的环境（自动根据应用的部署编排，实现了自动化的编译、集成、打包、部署、启动等）。
实施DevOps后的改变，首先团队变得更自治，成为使命型组织；沟通协作更顺畅；实现了开发人员的自助化服务；开发运维机器人提供更多的辅助功能。
四、实施DevOps从哪里开始？
大家可能非常关心，如何在各自的企业中如何落地DevOps平台呢？
在企业进行DevOps落地时，我们给大家推荐两个原则：
1、寻找痛点，从痛点入手；
2、将重复的、无价值的事情尽快自动化；
基于这两个原则，我们认为持续的部署，是目前企业实施最大的痛点，因此推荐实施DevOps从持续发布开始，后续可以建设量身定制的DevOps平台。逐渐搭建企业的云计算平台、采用微服务架构进行应用的拆分。
最后，我们回顾下今天的分享，一共分享了三方面的知识。
第一：我们对DevOps的狭义和广义的理解；
第二：在实施DevOps过程中，需要从组织、技术、流程三个维度进行改进；
第三：我们讨论了实施DevOps从持续发布开始。
今天就分享到这，谢谢大家！
关于作者：
刘相
EAII-企业架构创新研究院 专家委员
计算机应用技术硕士，现任普元软件产品部副总兼SOA产品线总经理。十年IT行业经验，专注于企业软件平台，在SOA、分布式计算、企业架构设计等领域。先后主导公司EOS7、Portal、云PAAS平台、云流程平台、BPM等系列产品的开发和设计工作。著有国内首本解析SpringBatch的中文原创图书《SpringBatch批处理框架》。个人爱好：阅读，慢跑。
