2010年在IBM工作，开始参与DevOps相关的产品开发和实施。用今天的眼光来看，我可能是中国早期的DevOps从业者。这两年DevOps在中国开花结果的时候，我看到了很多错误转型的乱象。在这篇文章中，我将分享我对DevOps行业发展的观察，并介绍DevOps转型过程中的陷阱。希望通过这篇文章，让大家能够拨开云雾，看到阳光，真正让DevOps成为企业生产力增长的助推器。本文内容：1.软件工程开发2.DevOps转型陷阱3.DevOps核心实践4.DevOps生态环境1.软件工程开发1.工具开发首先，DevOps不是一个工具，而是一个概念或团队文化。为了实现这个概念，出现了一系列的软件工程支持工具（ComputerAidSoftwareEngineering）。说到CASE，就不得不说到两个软件巨头：微软和IBM。我们用他们的软件工程路径来说明行业的发展。早在1997年，微软就推出了可视化开发工具VisualStudio（VS）。相信写过C或C++的同学对这个工具不会陌生。接下来，.Net框架的诞生让微软统一了开发平台的架构。整个VisualStudio所支持的C#、VB、C++等都可以编译成中间语言运行在.NetFramework上。可惜当时微软够有钱了，还在闭门造车。.Net不仅不能跨平台，整个VS的架构也是比较封闭的。只有商业软件才会为VS制作插件。与风格截然不同的IBM不同，走开放道路的Eclipse诞生于2004年，Eclipse的诞生逐渐拉开了开源软件对抗企业软件的序幕。2005年前后，软件工具进入协同开发阶段，微软推出服务器端TFS（TeamFoundationServer）。TFS的推出使得多个程序员可以轻松地进行代码配置管理、任务管理、数据分析和构建。这时，软件开发工具开始与软件过程相结合，将敏捷思想注入到工程实践中。IBM这边，EricGamma等大师（相信看过GOF设计模式和Eclipse系列书籍的同学对这个名字不会陌生）将Eclipse中单人持续交付的体验延伸到整个团队，让整个团队在一个统一的流程，同一个平台，统一的计划，交互式的完成工作。RationalTeamConcert诞生，它让大规模（超过500人）的工程软件开发和设计变得更加容易。直到2012年左右，DevOps文化才逐渐在市场上盛行。事实上，传统软件并不擅长部署，因此这两家巨头收购了两家持续交付软件公司：InRelease和UrbanCode。因此，全生命周期的协同开发工具是完整的，DevOps从概念到实现都有完整的环节。从两大巨头的软件工程路径可以看出，DevOps的出现是一个循序渐进的过程。其内生原因是人们不断追求软件生产的工程化、产业成本的降低和效率的提高。近20年来，软件开发工具的发展趋势是不断集成软件生命周期不同阶段的工具，形成一个庞大而综合的软件生产平台。企业采用单一生命周期工具有时会受到学习成本、遗留系统、集成障碍和许多其他原因的限制。面向微服务的DevOps开发工具帮助用户解决了这个问题。许多PaaS平台上的DevOps实践都是以微服务工具链的形式展开的。可以说微服务的设计方法和相关的配套工具，以及持续迭代和持续交付的理念与DevOps这样的小团队简直是天作之合。2.组织变革团队的组织架构这些年来也发生了微妙的变化。无论是全栈工程师，还是时下流行的NoOps，都表明专业边界被打破，开发团队从技术向业务转型。对于很多测试人员来说，这是一个悲伤的话题。很多IT公司的功能测试部门FVT已经被开发人员取代。替换的基础是利用各种自动化软件实现更好的单元测试和冒烟测试。并利用开发人员的业余时间在迭代后期完成手工测试。传统的测试人员需要培养自己的能力来承担自动化测试用例、性能测试用例、系统测试等复杂的测试任务。当DevOps相关平台统一后，开发验证阶段的产品部署架构，部署模式可以无缝切换到生产状态。对于实际的生产部署，可能是环境切换。为了确保万无一失，在准生产系统上线。因此，传统开发和运维人员的界限会越来越模糊，云平台对服务FailOver策略的处理也会越来越成熟。未来的运维团队可能会非常轻量级。软件工程的大方向是经济利益驱动的，那么应用DevOps之后，很多开发者可能会“被迫”做更多的测试、运维工作，是不是有点无奈？3.软件过程的开发直到今天，瀑布开发模型仍然被许多组织所采用。不用说，瀑布法在中国是有一定的文化基础的。但是渐渐的我们发现严格的瀑布模式往往会造成一定的资源浪费。例如，同样的人员、同样的时间长度，传统的流程??交付可能需要花费大量的时间才能完成一份完整的需求文档，而留给软件开发的时间却所剩无几，再加上需求不断变化。回想起来，需求文档通常已经过时。一种类似RUP（RationalUnifiedProcess）的迭代开发模式，就是尽早获取用户意见，控制风险。它实际上是介于敏捷和瀑布之间的模型，没有敏捷灵活但比敏捷更可控。虽然RUP的迭代让需求和开发并行，但他还是强调大部分需求应该在主要开发工作之前完成，而不是在敏捷中编码，需求和开发相辅相成，不断完善。很明显敏捷需求的时间大大减少了，所以后期调整需求的成本也比瀑布和迭代要低。XPExtremeProgramming甚至不推荐过多的设计。类似于CRUD功能，程序员有时会不自觉地追求更高的可扩展性并想出一个框架。这让我想起了一个有趣的问题。这就是项目和产品之间的细微差别。大多数项目都是为了追求短期利益，第一是满足客户的功能需求。良好的可扩展性并不是项目的核心需求。不必要的设计会影响适应需求变化的能力，这与拥抱变化的思想有些不一致。对于ThoughtWorks这样的敏捷咨询公司，客户会为代码重构付出额外的代价。产品研发的需求是相对固定的，一个产品要想发展好，就必须培育出一个良好的生态圈来拥抱未来不同的拓展需求。从长远来看，框架化和平台化符合产品的利益。因此，敏捷中提倡的一些原则，有时需要辩证地看待。敏捷方法在国内还不热，已经诞生了大规模的敏捷软件过程。然而，在很多敏捷高手看来，SAFe和Less只是披着马甲的RUP。敏捷能否规模化发展？其实不是不能开发，而是怎么开发。我们都知道敏捷提倡小团队文化，类似于亚马逊提倡的Two-pizzateam，建议团队规模保持在7人左右。但是，在几千人的跨国研发组织中如何开展敏捷确实是个问题，这就是大规模敏捷的意义所在。2.DevOps转型陷阱DevOps简单翻译就是运维开发一体化。但是怎么整合，怎么做呢？不同的人可能对DevOps有不同的理解，就看你在哪个场合安利了。认识的盲点也造成了实践的误区。比如自动化，基础设施就是编码，配置管理数据库的应用，看板方法在运维中的应用等等，可以说这些都和DevOps的实践有关，但不是DevOps的全部。DevOps转型的路上有很多坑，我们先从文化转型说起。1、文化转型陷阱很多人对敏捷和DevOps的关系很好奇。敏捷是一个软件开发过程。最初只是在软件开发中推广。很多人提出从敏捷开发到敏捷运维，再到业务敏捷。毫无疑问，这个提议在文化、流程和工具方面都是一个很好的延伸。可以说，敏捷方法和敏捷工具为DevOps理念提供了很好的理论指导和工具支持。近年来，许多企业逐渐开始实施敏捷实践。例如，项目经理变成了Scrum主管，用户故事取代了以前的需求，开发计划变成了更短的冲刺计划。过去每周一次的小组会议变成了每天的站立会议。一开始大家都精神抖擞，但时间一长，就觉得每天的站会太麻烦了。而Scrumsupervisor还是那个逼着大家干活的项目经理。冲刺缩短了开发周期，减少了可以完成的功能数量。频繁的线上操作给运维人员带来了更大的压力，生产环境的BUG似乎也比以前多了。“如果你不了解团队自治、共担责任和面向交付，那么你就不了解DevOps文化。”2、工具转型陷阱无论是以前的Agile，还是现在的DevOps，很多人对CASE工具都有一个误解。一旦你有了这个工具，你就拥有了相应的软技能。但是用了一段时间后，发现根本不是这么回事。为什么会有这样的错觉？我们知道工具只是实际工作的一部分。如果只部署DevOps工具，但人员和整个工作流程没有改变，会发生什么？可能的情况是，大家使用通用工具工作，当然取得了比以前更好的效果，但工具障碍并没有消除。“如果CASE工具只是孤岛，就很难帮助企业开发良好的DevOps实践。3、DevOps这把双刃剑其实并不可怕。可怕的是拒绝风险，或者放过风险。你可能看过很多DevOps的宣传，认为实施了DevOps之后，就可以万无一失，从开发到交付，分分钟搞定事情。其实，这里有一个陷阱。也就是说，工具可以帮助生产快速交付，但从另一个角度来看，如果出现问题，错误也可能会快速传递到生产环境。那么如何快速的抓住问题，去解决问题，而不是让问题过去，这就是DevOps要处理的问题。另外，需要在持续交付的早期尽早发现问题，比如有价值的缺陷，然后将其作为单元测试的目标来预防。这是团队不断成长的过程。”精益的一面是控制风险，因此要小心风险随DevOps流程一起传递。》三、DevOps核心实践刚才提到了很多DevOps转型的坑，就是说一不小心就会掉坑里。我觉得DevOps就是这样，做起来很别扭，确实DevOps其实是一个面向软件交付的概念，文化转型真的很难，我们应该怎么做？我们从三个维度来描述DevOps的核心实践。1.自治的小团队是对很多公司来说很重要，尤其是目前国内很多公司可能很难，组织的自主性意味着控制力的弱化，控制力的弱化和人天生的惰性都会导致项目的失败。这可能是团队转型中的通病，其实自主并不是说没有管理，而是要对目标做出正确的预期，对结果做出合理的评价，中间过程进行引导和纠正虽然有一系列检查站。其余工作交由团队协调完成。首先，在敏捷实践中，明确用户故事和任务的责任人是一个非常好的实践。只有明确了责任，大家才能朝着目标前进。另一个分担责任的好方法是让每个人都参与团队计划的制定，大家一起帮助任务的负责人共同预估故事点数。这样不仅会培养团队成员的责任感，而且最终的预估结果也会比项目经理自己做出的决定更加准确。在项目执行过程中，看板等工具应用程序使团队中每个参与者的工作具有相同的可见性。每日站会的内容由看板中的待办事项和任务状态决定。不是架构师报告技术困难，项目经理报告开发状态，大多数人被忽视的情况。一个不超过10人的小团队已被许多公司证明是一个很好的做法。它可以让合适的人做他们擅长的事情。如果团队太大，很多人不能胜任自己的角色，也是一种浪费。此外，随着持续交付的演进，产品总是有新需求和老问题。如何合理分配人员以一石二鸟？一些组织开始将团队分成几个特性团队和维护团队。这带来了以下好处：每个功能团队都有一位同时也是Scrum大师的架构师。由于人数少，便于管理工作进度和工作量。特性团队和维护团队相互轮换。在维护团队中，成员可以联系客户，新成员可以通过修复bug熟悉产品，待产品足够成熟后再轮换到特性团队。不同的小团队甚至不必在一个地方。从DevOps的角度来看，一个庞大的产品团队可以完成从项目开发到上线的整个交付工作。2.可控的全流程追溯工具用以前流行的一句话，就是有了这么多高端工具，还是很难做好DevOps。如何正确使用DevOps工具？其核心理念是让我们在工具上所做的事情在不同的生命周期中是完全可追溯的，因此我们给出了以下实践：从需求出发，驱动Task执行。任务和代码生产被组合和跟踪。持续集成以任务为单位进行。以需求为单位持续交付。以质量为纲，进行体系验收。运维标准化。随时随地沟通。持续监控，持续改进。参考上面的做法，我们举个例子。一开始我们讲了两个业界知名的DevOps支撑平台，都是紧耦合的DevOps工具。随着开源软件越来越多，其功能也越来越强大，甚至有些已经超越了商业软件的能力。因此，越来越多的公司会基于公司原有的开源工具搭建DevOps环境。我们尽量选择公有云和私有云可用的工具版本进行说明。通过以上实践，可以搭建一个DevOps平台。根据用户的需求，可以选择不同的版本在不同的私有云和公有云中进行平台建设。只有将这些核心工件整合起来，才能形成有效的追溯环节。SourceToolTargetTool核心神器说明ZenHubGitHubTaskID,CommitID可以通过任务查看相关代码提交。GitHubJenkinsCommitID，哪些提交包含在哪些构建中，以及一个构建包含哪些实际需求的BuildID。JenkinsSwarmBuildID,InstanceID在环境上部署了哪些新特性。SwarmSauceLabsInstanceID,TestCaseID测试环境上的部署实例已经通过，以及测试结果。ITOPAlltoolIT资源信息使用CMDB对核心资源进行统一管理MatterMostAlltool团队协作oneAlert对所有工具的各种事件消息进行实时监控和预警这种集成方式可能会比传统研发带来更多的运维变革，因为传统运维在方法论、工具、标准化等方面远远落后于发展。比如与很多成熟的开发流程脱节，生产环境相对隔离导致运维出现黑账（碎片化脚本）。环境部署好后，用户和管理员的信息不同步，导致出现很多僵尸系统。近年来，基础设施即编码（IaC）和配置管理数据库（CMDB）的应用，实际上就是为了解决上述问题。由于运维实际上使用了一系列的脚本来部署和管理系统，所以这些脚本应该和开发代码一样进行管理，甚至包含在内。CMDB的作用是统一管理运维工作成果和企业其他IT资产，消灭那些僵尸系统。3.实时度量驱动的软件开发过程中充满了各种不确定因素，有时一个小情况就能极大地影响软件产品的按时交付。对于中高层管理人员来说，只能通过重复的手工周报和月报来获取信息。然而，不及时和混合人工数据的报告会极大地误导决策支持。DevOps就是打通数据链路，为管理者提供实时准确的生命周期数据。使管理者能够有效控制风险，防患于未然。也许在传统印象中，测量不只是一堆报告？其实这里有一个很大的误区，就是衡量的方法更多是通过数据看趋势，事前支持管理决策，而不是事后分析。例如，当项目经理看到缺陷开口呈上升趋势时，他们应该寻找问题并进行干预。当scrumsupervisor看到任务周转时间比原来预估的时间长了，就需要评估是否能达到原来的sprint计划。测量的实施符合拥抱变化的敏捷理念，帮助项目参与者尽早发现问题并在需要时进行干预。更多的metrics可以参考我之前的微课堂记录。4.可以用什么方法来整合三者的最佳实践？我们发现使用看板（Kanban）、基线（baseline）和流水线（pipeline）这三种方式可以将任务管理、版本控制、流程管理结合起来。紧密地联系在一起。看板：以任务状态为核心，管理在制品的生产情况。任务是自组织团队的工作合同。Baseline：以工件的版本为核心，选择合格的可交付成果。例如，开发团队决定哪个代码提交版本，或者编译构建版本是最终交付的版本。指标指导基线的生成。Pipeline：以生命周期阶段为核心，控制基线交付物的推出。例如，一个合格的代码基线当前处于编译状态或部署状态。自动化工具围绕管道相互集成。那么这三者结合的方法是什么呢？答案是工作项（WorkItem）。涵盖需求（史诗、特性、用户故事）、开发（任务、缺陷）、测试（测试用例、测试计划）等。工作项是看板显示的最小单元，是看板的泳道board是工作项的状态。基线是需求工作项计划、任务工作项生成和测试工作项验收的最终产品。工作项是生命周期中不同可交付成果的容器，可交付成果的最终生产通过流水线体现。4、DevOps生态环境近年来，IT行业可以说发生了质的变化。无论是方法论、软件工具还是基础架构，软件开发都与业务越来越紧密地结合在一起。可以说，DevOps是云平台开发运营的指导思想。在人员角色上，推崇全栈工程师，拉近开发者与业务的距离。在开发方式上，在这个平台上从开发到运维的交付物，都是用微服务方式开发的应用。在物理形态上，以集装箱的形式运送到生产部门进行操作。对于用户来说，这个业务最终的交付形式可能是一系列的API接口或者直接可用的应用。一切顺利。如果你想成为EAii架构研究院会员，加入微信群参与架构设计与讨论直播，享受微课堂PPT抢先下载等权益，请直接在这里回复你的微信号公众号。作者简介：胡帅朴元信息高级软件架构师，计算机软件与理论硕士。曾就职于IBM中国开发实验室，参与RationalTeamConcert、RationalInsight等产品开发，并担任著名开源BI产品BIRT社区顾问。为工商银行、招商银行、建设银行、通用汽车等大型企业提供DevOps和BI产品咨询和实施服务。在DevOps和BI方面积累了丰富的研发和实施经验。
