转载本文需注明出处：EAWorld，违者必究。
2010年，我曾在IBM供职，开始参与DevOps相关的产品研发与实施工做。今天看来，我也许是国内较早的DevOps践行者。这两年DevOps在国内开花结果的时候，我见到了不少错误转型的乱象。本文中，将为你们分享本身对DevOps行业发展的观察，并向介绍DevOps转型的路途中都有哪些陷阱。但愿经过本文，你们能更够拨云见日，真正的使DevOps成为企业生产力增加的助推器。程序员
本文目录：数据库
1、软件工程的发展编程
2、DevOps转型陷阱设计模式
3、DevOps核心实践服务器
4、DevOps生态环境微信
首先说DevOps并非一种工具，而是一种理念或者团队文化。为了实现这一种理念，因而就有一系列的软件工程的支持工具（Computer Aid Software Engineering）。说到CASE，就不得不说一说，两个软件巨头：微软和IBM。咱们以他们的软件工程之路，来讲明行业的发展历程。架构
早在1997年微软就推出了可视化的开发工具，Visual Studio（VS），相信写过C或者C++的同窗们必定不会对这个工具陌生。接下来.Net框架的诞生，让微软统一了开发平台的架构，整个VisualStudio所支持的C#, VB, C++等能够编译成中间语言，托管在.Net Framework之上运行。惋惜那时微软足够有钱，还在走闭门造车的路子。框架
.Net不只不跨平台，整个VS的架构也比较封闭，只有商用的软件才会为VS生产插件。与此风格大相径庭的IBM，走开放路子的Eclipse在2004年诞生了，Eclipse的诞生渐渐拉开了开源软件对抗企业软件的序幕。运维
进入2005年左右，软件工具进入协同开发的阶段，微软推出了服务器端TFS (Team Foundation Server)。TFS的推出，使得多个程序员能够方便的进行代码配置管理，任务管理，以及数据分析，构建等工做。这时软件开发工具已经开始和软件过程相结合，将敏捷的思想注入到工程实践中。在IBM一方，Eric Gamma（相信看过GOF设计模式，以及一些列Eclipse书籍的同窗们不会对这个名字陌生）等大师将Eclipse中单人持续交付的体验拓展到整个团队，使得整个团队在一个统一过程，同一平台，统一计划中，交互性的完成工做。
微服务
Rational Team Concert诞生了，它使得大规模（500人以上）工程化的软件开发与设计变得更加容易。一直到2012年左右，DevOps文化渐渐在市场中盛行起来。其实对于传统软件来说，作部署并不擅长，因此这两家巨头都不约而同的收购了两个作持续交付软件的公司：In Release和 Urban Code。因而全生命周期的协同开发工具已经完备，DevOps 从概念到落地都有了完整的链路。从两个巨头的软件工程之路能够看到，DevOps的出现是一个渐进的过程。它的内生缘由是人们不断追逐软件生产的工程化，产业成本下降以及效率的提高。
过去20年，软件开发工具的发展趋势是不断的将软件生命周期不一样阶段的工具整合起来，造成一个大而全的软件生产平台。一个企业采用单一的生命周期工具备时候会受到学习成本，遗留系统，集成壁垒等诸多缘由的制约。而微服务化的DevOps开发工具则帮助用户解决这一问题，诸多PaaS平台上的DevOps实践就是以微服务工具链的形式推出。能够说微服务的设计方法与相关的支持工具，和DevOps这种小团队，持续迭代持续交付的理念简直是天做之合。
团队组织结构也在这些年发生了微妙的变化。无论是全栈工程师仍是流行的NoOps都在说明专业的界限被打破，开发团队由技术向业务转型。
对于不少测试人员来讲，这是一个忧伤的话题。不少IT公司的功能测试部门FVT已经被开发人员所取代。取代的基础是用各类自动化软件，作到更好的单元测试，冒烟测试。而且在迭代的后期利用开发人员的闲暇时间来完成手动测试。传统的测试人员须要培养自身承担自动化测试用例，性能测试用例，系统测试等复杂测试工做的能力。
当DevOps相关的平台统一后，开发验证阶段的产品部署架构，部署模式能够无缝切换到生产态。对于实际的生产态部署来讲也许就是一个环境的切换，为了确保万无一失，在一个准生产系统之上演练上线工做。所以传统的开发和运维人员之间的界限会愈来愈模糊，以及云平台对于服务FailOver策略的处理愈来愈成熟。
从此的运维团队可能很是的轻量级。软件工程的大方向是被经济利益所驱动的，因此DevOps运用以后不少开发人员也许会“被迫”去作更多测试，运维的工做，是否是有点无奈？
直至今天，瀑布开发模式仍旧是许多组织采纳的方式。不用质疑，瀑布方式在中国有必定的文化基础。可是渐渐的咱们意识到严格的瀑布模式每每会形成必定的资源浪费。好比在相同的人员和相同的时间长度下，传统过程交付可能花费大量的时间去完成是一份完整的需求文档，可是留给软件开发的时间少之又少，再加上需求的变化。回头来看需求文档每每已通过时。
相似RUP（Rational Unified Process）的迭代开发模式就是尽量的早的得到用户的意见，控制风险。它实际上是介于敏捷和瀑布之间的一种模型，不如敏捷灵活可是控制性比敏捷更强。RUP的迭代虽然容许需求和开发并行，可是他仍然强调大部分需求内容都应该在主要开发工做以前完成，而不是敏捷中代码就是设计，需求和开发互为彼此，不断完善的方式。显而易见敏捷需求的时间大大减小了，因此后期调整需求的代价较之瀑布和迭代来说也更低。
XP极限编程甚至不太推崇你们作过分的设计，相似于一个CRUD的功能，程序员有时会不自觉的追求更高的拓展性，搞出了一个框架来。这让我想起来一个颇有意思的问题。那就是项目与产品的细微区别。作项目大可能是为了追求短时间利益，知足客户功能需求为先，良好的拓展性并非项目的核心需求。没必要要的设计会影响接纳需求变化的能力，这和拥抱改变的想法有些不一致。相似在ThoughtWorks这种作敏捷咨询的公司，客户会另外付钱购买代码重构的effort。而产品研发的需求相对固定，而且一个产品要有良好的发展，必须培养一个良好的生态系统，拥抱将来不一样的拓展需求。长期来看框架和平台化反而符合产品的利益。因此敏捷中倡导有些原则有时要辩证的看。
敏捷方法在国内还没焐热，大规模敏捷的软件过程已经诞生。然而在不少敏捷大师的眼中，SAFe和Less只不过是穿了马甲的RUP。敏捷不能大规模开展吗？其实不是不能开展，而是如何开展的问题。你们知道敏捷推崇的是小团队文化，相似亚马逊倡导的Two-pizza团队，建议团队规模维持在7人左右。然而动辄几千人的跨国研发组织，如何开展敏捷的确是一个问题，这就是大规模敏捷存在的意义。
DevOps简单的来翻译就是运维开发一体化。可是究竟如何来一体化，怎么作才能一体化？可能不一样人对DevOps有着不一样的理解，这取决于你们在哪一个场合被什么人安利的。认识的盲点也就形成了实践的误区。
好比说自动化，基础设施即编码，配置管理数据库的应用，看板方法在运维中的应用等等，能够说这一切都是有关DevOps的实践，而又不是DevOps的所有。向DevOps转型的路上有不少坑，咱们先从文化转型谈起。
不少人好奇敏捷和DevOps是什么关系。敏捷是一种软件开发过程，最初只是在软件开发中推广，不少人提出由开发敏捷转型到运维敏捷，从而到业务敏捷。这个提议毋庸置疑，无论从文化，流程以及工具层面都是很好的延伸。能够说敏捷方法，敏捷工具为DevOps理念提供了很好的理论指导和工具支持。近些年来不少公司逐渐开始进行敏捷实践，好比说项目经理变成了Scrum主管，用户故事替代了之前的需求，开发计划变成了更短的冲刺计划。之前每周一次的组会变成了天天的站会。一开始你们都精神满满，长此以往以为天天的站会太麻烦。而Scrum主管仍是之前那个逼着你们干活儿的项目经理。冲刺使得开发周期变短了，能作的功能也变少了。频繁上线给运维人员带来更大的压力，生产环境的Bug彷佛比之前还要多。
“若是不了解团队自治，责任共担，面向交付，那就不了解DevOps文化。”
不管是以前的敏捷，仍是如今的DevOps，不少人对于CASE工具都有一个误区，以为用了这个工具，就具备相应的软技能。可是用了一阵子以后才发现彻底不是这回事儿。为何会出现这种假象呢？
咱们知道工具仅仅是现实工做中的一部分，若是仅仅是部署了DevOps工具，然而人员和整个工做流程并未改变会出现什么？极可能出现的状况下是，你们用共同的工具进行工做，固然也取得了比以前好一点的效果，可是工具壁垒并无消除。
“若是CASE工具只是孤岛，那就很难帮助企业培养好的DevOps实践。”
其实风险自己并不可怕，可怕的是拒绝风险，或者听任风险。你们可能已经看过不少DevOps宣传，以为实行DevOps以后能够作到万无一失，从开发到交付是分分钟搞定的事情。其实这里有个陷阱。那就是工具能够帮助生产到交付快速进行，可是从另外一个角度讲，若是一旦出现问题，错误也可能会很快传递到生产环境中。因此如何快速捕捉问题，解决问题，而不是让问题传递，这才是DevOps要处理的问题。另外尽早的在持续交付的初期发现问题，好比说有价值的缺陷，而后把它做为单元测试的目标去防范，这对于团队来讲是一个不断成长的过程。
“精益的侧面是控制风险，因此要当心风险和DevOps流程一块儿传递。”
刚才说了不少DevOps转型中的陷阱，也就是说一不当心就会栽到坑里，以为DevOps就是那样了，作着挺别扭，更没带来什么好处。要知道DevOps其实是一种面向软件交付的理念。文化转型真的挺难，到底该怎么作呢？咱们从三个维度讲述DevOps的核心实践。
这点对于不少公司，特别是目前国内的诸多公司来说也许很难作到。组织的自治意味着控制力的减弱。控制力的减弱加上人类天生的惰性将致使项目的失败。这多是团队转型中存在的共同问题。实际上自治并非说缺少管理，而是说对目标作出正确的指望，对结果作出合理评价。中间的过程经过一系列的检查点作出指导和纠正。其他的工做交给团队去协调完成。
首先敏捷实践中将用户故事，任务等明确责任人，这是很是好的作法。明确了责任，你们才能向目标迈进。而另外一个责任共担的好办法是让每一个人参与团队计划的制定，你们帮助任务的负责人共同估算出故事点。这样不只会培养团队成员的责任感，而且最终估算的结果会比项目经理本身作出的决策更加准确。在项目执行的时候，看板等工具的运用使团队中每一个参与者的工做都具备相同的可见性。以看板中待办项以及任务状态肯定天天站会的内容。而不是架构师汇报技术难点，项目经理汇报开发状态，大多数人被忽略的状况。
不超过10人的小团队被不少企业证实是一个良好的实践。可让对的人去作擅长的事，若是团队过大不少人没法承担合适本身的角色也是一种浪费。另外随着持续交付的演进，产品总有新的需求，也有旧的问题。如何合理分配人员从而作到一石二鸟？一些组织开始将团队分为若干个特性团队和维护团队。这样能带来如下好处：
每一个特性团队都有一个架构师，同时也是Scrum主管。因为人数小因此很容易作到工做进度与工做量的管理。
特性团队和维护团队，互相轮岗。在维护团队中，成员能够接触客户，新成员能够经过修复Bug熟悉产品，对产品足够成熟后再轮岗到特性团队。
不一样的小团队甚至能够不用在一个地方。
从DevOps的角度，一个大的产品团队就能够完成项目开发到上线的整个交付工做。
用一句以前流行的话来讲，那就是有了这么多高大上的工具以后，仍是作很差DevOps。如何正确的使用DevOps工具呢？核心的概念其实就是让咱们在工具上所作的事情在不一样的生命周期时能够作到全链路的可追溯，所以咱们给出如下实践：
从需求出发，驱动任务执行。
任务和代码生产相结合，进行追溯。
以任务为单位进行持续集成。
以需求为单位进行持续交付。
以质量为纲，进行系统验收。
运维规范化。
随时随地的沟通。
持续监控，持续改进。
参照上面的实践，咱们来举个例子。开篇咱们讲了两个业界著名的DevOps支持平台，他们是紧耦合DevOps工具。随着开源软件愈来愈多，功能愈来愈强大，甚至某些已经超过了商业软件的能力。所以愈来愈多的公司都会基于本公司原有的开源工具之上构建DevOps环境。咱们尽可能的选取了公有云和私有云中都有的工具版本进行说明。
经过上面的实践，就能够将一个DevOps平台搭建起来了。根据用户的须要能够在私有云和公有云的不一样选择不一样的版本进行平台建设。只有将这些核心工件集成起来才能造成有效的可追溯链路。
源工具 |
目标工具 |
核心工件 |
说明 |
ZenHub |
GitHub |
TaskID, CommitID |
经过任务能够看到相关的代码提交。 |
GitHub |
Jenkins |
CommitID, BuildID |
哪些提交被哪些构建包括，一个构建包括哪些实际的需求。 |
Jenkins |
Swarm |
BuildID, InstanceID |
一个环境上部署的是哪些新的功能。 |
Swarm |
SauceLabs |
InstanceID, TestCaseID |
一个环境上的部署实例通过了哪些测试，以及测试的结果。 |
ITOP |
全部工具 |
IT资源信息 |
用CMDB进行核心资源的统一管理 |
MatterMost |
全部工具 |
团队协做 |
|
oneAlert |
全部工具 |
各类事件消息 |
实时监控预警 |
这种集成方式给运维带来的改变可能要多于传统的研发，由于传统的运维在方法论，工具，规范程度等方面还远不及开发，好比说：
与不少成熟的开发流程脱节，以及生产环境的相对隔离形成了运维的黑帐本（碎片化的脚本）。
环境部署后，使用者和管理者的信息不一样步形成了不少僵尸系统。
近些年来，基础设施既编码（IaC）以及配置管理数据库（CMDB）的应用实际上就是为了解决上面问题。既然运维实际采用一系列的脚原本部署和管理系统，那么就应该把这些脚本和开发代码同样统一化管理，甚至归入。而CMDB的做用就是将运维的工做成果和企业的其余IT资产统一管理，消除那些僵尸系统。
软件开发过程当中充满了各类各样不肯定的因素，有时一个小状况的出现就会成大程度影响软件产品的按时交付。对于中高层管理者来说，只能经过重复的人工周报月报来获取信息。然而不及时，且掺杂人工数据的报告讲给决策支持带来很大的误导。DevOps就是要将数据链路打通，为管理者提供实时，准确的生命周期数据。使管理者在风险到来以前有效的对其管控。
可能在传统的印象中度量不就是一堆报表吗？其实这里有个很大的误区，那就是度量的方法更多的是经过数据看趋势，事先为管理决策做出支持，而不是过后分析。好比说项目经理在看到缺陷打开不断呈现上升趋势就应该去寻找问题，进行干预。Scrum主管在看到任务周转时间要长于原先的预估时间，那就要评估原先的冲刺计划是否能达成。实施度量正是切合敏捷的拥抱变化的理念，帮助项目的参与者尽早的发现问题，在须要的时刻作出干预。有关于度量更多的信息，请参看我以往的微课堂记录。
用什么方法能将三者融合起来呢？咱们发现使用Kanban（看板）Baseline(基线)和Pipeline(管道)这三种方法能够将任务管理，版本控制，过程管理紧密的联系在一块儿。
看板：以任务的状态为核心，管理在制品的生产状况。任务是自组织团队的工做契约。
基线：以工件的版本为核心，选取合格的交付物。好比说开发团队决定哪一个代码提交版本，或者编译的构建版本为最终交付的版本。度量指导基线的产生。
管道：以生命周期阶段为核心，控制基线交付物的投产。好比说一个合格的代码基线目前处于编译态，仍是部署态。自动化工具围绕管道互相集成。
那什么又是将这三者融合在一块儿的方法呢？答案就是工做项（WorkItem）。它涵盖了需求（长篇故事，特性，用户故事），开发（任务，缺陷）,测试（测试用例，测试计划）等。
工做项是看板展现的最小单元，看板的泳道就是工做项的状态。
基线是经过需求工做项规划，任务工做项生产，测试工做项验收的最终产物。
工做项是生命周期不一样交付物的容器，交付物的最终投产经过管道体现。
最近这几年能够说IT行业发生了一个质的改变。不论从方法论，仍是软件工具以及基础设施都让软件开发这件事与业务结合的愈来愈紧密。能够说DevOps就是云平台开发运营的指导思想。在人员角色方面，推崇全栈工程师，让开发者更贴近业务。在开发方法方面，而在这个平台之上从开发到运营流转的交付物就是以微服务方法开发的应用。在物理形态方面，以容器的方式交付到生产部门运营。对于使用者来说，这种业务的最终交付形态可能就是一系列的API接口，或者直接可用的应用。一切都变得平滑起来。
如需成为EAii架构研究院会员加入微信群参与架构设计与讨论直播，享受微课堂PPT抢先下载等权益，请直接回复您的微信号至此公众号。
关于做者：
胡帅
普元信息高级软件架构师，计算机软件与理论硕士。曾供职于IBM中国开发实验室，参与Rational Team Concert, Rational Insight等产品研发，曾经担任著名开源BI产品BIRT社区顾问。为工行，招行，建行，美国通用等大型企业提供DevOps以及BI产品咨询实施服务。在DevOps以及BI方面积累了丰富的研发与实施经验。
关于EAWorld
致力于软件架构创新与实践，加速企业数字化转型，EAii（Enterprise Architecture Innovation Institute）企业架构创新研究院旗下官方微信公众号。
微信号：eaworld，长按二维码关注
本文分享自微信公众号 - EAWorld（eaworld）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。