Legacy System，常被翻译成传统系统或者直译成遗留系统。（指公司企业里经过很长一段时间使用，并具有多年软件开发和数据积累的大型计算机系统。多见于一些大型银行和跨国企业。）作为侍候着一个刚过完30岁生日银行老系统的团队中的一员，我更乐意把它叫做 ：传奇系统。在IT业日新月异，分秒之间翻天覆地的时代，这样的系统能继续服务于企业，本身就应该是一个传奇。
但当今需求瞬息万变，传统的瀑布式开发已经严重影响了“传奇”们对需求反应的时效性。加之服务渠道的变迁和新技术的冲击，传奇也慢慢变成了残喘在历史边缘巨大而笨重的恐龙。因此敏捷转型和 DevOps 改造，成了“传奇”能否继续老当益壮，砥砺前行的关键。
2016 年底，当我们决定全面引入 DevOps 的时候，基本没人会认为这个而立之年的系统能 DevOps 起来。一年半后，我们月平均上线的改动是原来的近三倍，人员配置精简了近四分之一，更新引致的系统出错率不断降低，用户满意度也逐步上升。而得益于团队的勠力同心，精诚协作，这个过程其实并非那么艰苦卓绝，反倒是充满了发现的乐趣与成功的喜悦。
由于我们的系统平台是IBMi（AS400),所以一些流程架构和工具的应用不普遍，可参考性不算高，这里就不详谈了。文章会着眼于方法和理论层面的讨论。结合我们的经验和实践，浅谈我们在DevOps改造过程中归结出的3个关键要素。希望能对在同样困境中的兄弟们有所启发和帮助。也请走在前面的大神们多多评点指教。
第一要素：人
There is no legacy system but only legacy thinking.
没有绝对落后的系统，挡道的只是不思进取的思维模式。要改造传奇系统，首先要改造的，是我们自己。
- 转变角色 - From Cost Center to Best Partner
我们以前比较喜欢说我们自己IT部门是cost center。直译过来就是花钱的部门，不带来直接利润，无法为公司赚钱。更多是根据系统用户的明确需求，开发和维护业务系统，并保证业务系统稳定运行。但是在数字化浪潮的强烈冲击下，IT技术逐步成为了公司核心竞争力的重要来源。IT部门能否与内外商业部门一起，以客户为中心，思考服务体验，并保持对业界先进技术的洞察与及时恰当的反应，成为了公司在数字化时代成败的关键。（这里推荐阅读ThoughtWorks肖然老师的文章《银行IT的敏捷转身》）。简而言之，我们的业务意识，必须从以前的等待用户需求下来，然后根据既定流程将其转化成程序，上线，之后做维护，转变为我们怎么才能成为商业部门的最佳合作伙伴，风雨同舟，荣辱与共，更高效地一起去为公司实现商业价值。
这一点转变其实很有挑战。大企业里，IT部门分工比较精细，多部门间的整体协作就已经很不容易。而且某些情况下，即使是IT做到了，其他商业部门还不一定有这样的觉悟。端到端团队整体协作意识的建立极为关键。方法还是有一些的，可以由Top Down和Bottom Up两个维度切入，明确利益的共通与绑定，建立新型的沟通平台/渠道等等。之后有机会可以再和大家深入些去讨论。
- **理解 DevOps - Simpler Better Faster
**
很多文章都在谈什么是DevOps和为什么要DevOps，这里就不再累赘了。前段时间刚发布的《研发运维一体化能力成熟度模型》就是一份集大成之作，非常推荐深读。这里想分享一下的是，非常佩服我们CIO，他用三个单词为我们定了总目标：Simpler Better Faster（更简洁，更优异，更快捷）。这也让我们明确理解了，从高层角度对我们系统改造的期待。这三点，也是过去一年多我们开展工作所围绕的核心方向。对于一些年资尚浅的同事，未能短时间内全面理解什么是DevOps, 我会告诉他，暂时忘记DevOps吧，在日常中围绕这三个方向努力就好。
- 敢于创新 - Innovate or die
创新的重要性，这里就不多说了。但如何在传奇系统团队里创新呢？
我们不少同事都觉得创新是很高大上的事情。谈创新就立马想到区块链，人工智能等等的高新科技，认为创新是技术大牛的事，而自己根据既定流程做好本分就可以了。这样的想法有些片面了。这类大型创新相当重要。但同时创新也可以很接地气的，是每一个人每天都可以做的事。特别是对我们传奇系统。这样的系统一般背负着浓厚的历史沉淀，在有资源能够全面整体改造前，相对碎片化的微创新更有必要，更能立竿见影。
其实这样的微创新并不难。只要同事们能在工作中发挥创意，不断改进一点微流程或者创作一些小工具，让自己日常工作生活更轻松合理一些，再整合推广出去给周围的同事共同改善使用，那就已经是非常好的创新。以为我们部门为例，在过去一年内，我们有记录的创意达到了近110个，其中成功落地推广的微创新近50个。它们成为了让这只恐龙能愉快起舞的绝对关键。当然，能否建立一个好的平台和机制鼓励激发创新，让优秀的微创新能高效地被识别，认可，整合和发布，并且让有贡献的同事得到及时而适当的回馈与奖励，是传奇系统创新能否推动的决定因素。这是一很有意思的题目，鼓励和激发创意本身，就很需要创意。但这有似乎点超出本篇的讨论了，有缘再议。
第二要素：流程
The past doesn’t define the future
一直这样做，就代表以后也得这样做？一直在用的，或者存在了很久的流程，就真的是最好，最恰当，最合时宜的了么？
称得上传奇的系统，相信在改造前，整个研发流程都会非常有历史沉重感。以我们而立之年系统的部署为例，改造前，一个系统进程里，一年一般只能有6到10次上线机会。在完成了所有相关开发测试之后，新的改动从封装到落地生产机，根据当时的流程，单是准备就要10个工作日。各种版本控制，代码整合，文档收集，上线批核，发布前沟通等等步骤让每次上线发布都纷纷扰扰。但即便大家已经严格按流程倾尽全力保证质量，上线那天，基本仍然是生产机维护部门的噩梦，问题不断。
既定流程的确有它存在的道理，也是企业特别是大型企业规模化运行的强力保证。但我们也要千万小心，别让公司花重金请回来的精英们，被流程硬生生绑成了机器人。流程的改造，是DevOps路上解放生产力和释放部门整体活力的极为关键要素。
其实流程的改造也是一件蛮有意思的事情。对于传奇系统，是一个重新自我认知和逐步蜕变的过程。传奇系统流程的条条框框非常多，一夜之间翻天覆地，全盘推倒，冲上DevOps是不实际的。但大体上，可以考虑从下面3步入手。
- 认清现状 - Where we are
千里之行，始于足下。要改造，就必须先从脚踏实地地认识眼下的流程开始。但我们真的清楚认识每天我们在勤勤恳恳地侍候着的流程们么？
问题似乎很傻，不清楚的话难道我们每天都是玩？但在开始思考DevOps流程改造的时候，我们产生了非常多的疑问。在一个完整的研发周期里，我们真的全面清楚知道总共要经历多少步？每步的目的是什么？应该谁负责谁执行？每步一般跨多长时间？要花费多少人力？有多少文档需要准备？谁会查阅这些文档？每一步里又有那些特殊情况需要注意等等么？更进一步研究，我们发现平时都知道怎么动手做的流程，竟然不少是没有文件记录，只依赖于大家口耳相传的。此外一部分，是纷繁杂乱地记录在五花八门的规定和指引文件里。有些步骤的缘由甚至无从考究了。
所以我们开始全面整理清顺整个流程。把每一步分门别类列在了一份详表上。尽全力为每一步解答上面提到的问题。当初稿出来的时候，真的有一种云消雾散，豁然开朗的感觉。但也引起了我们深思。单是前面提到的部署上线，我们竟然有9个大项80多个步骤…
- 订立目标 - Where to go
传奇系统的流程改造，长远目标当然是全面DevOps。但期望一蹴而就是绝对不现实的。所以中短期目标对于我们尤为重要。我们的中短期目标大致可以归结为SOA，就是：简化Simplification，优化 Optimization，自动化 Automation。
简化，顾名思义就是去繁就简。把一些陈旧的，可有可无的流程，或者是不再重要的步骤去掉。这对一些自己部门内部可以决定的步骤比较容易实现。如果牵连多部门协作的步骤，就要花时间讨论了。
优化，则是在时间线上，对一些繁复的步骤进行整合重构。让每个步骤更高效，步骤之间结合也更紧密，减少空置等待的时间。这其实应该是一个持续的过程。我们相信没有完美的流程。所以优化的机会无处不在。
自动化，就相对容易理解。能让机器去做的简单重复的步骤，为什么要人去做呢？自动化可以极大地减少人为错误。让流程更顺畅，效率更高。当然，开发自动化工具的确需要时间。这就要求我们好好找到平衡点了。下一个关于工具要素的讨论里，会谈到我们的一些自动化的经验。希望对大家能有所启发。
上面只讨论了我们一些方向性的目标。关于更具体目标的定立管理，可以结合实际情况，参考管理学大师皮得.德鲁克在《管理的实践》里提出的SMART原则进行操作。
- 开动！- Action！
清楚知道现状，明确目标方向，改造也就不难了。作为指导方向，上面提到的SOA在这里就不重复了。这里再谈两个我们行动中要注意的关键点。
提高投入参与度。改造不是一两个管理者关起门来就可以做到的。怎么让每个队员参与投入进来，是成功的关键。毛主席教导我们，发动群众，要从群众中来，到群众中去。要改，就要从团队成员们日常流程的切身痛点出发。基于DevOps的原则，鼓励和帮助大家们在日常中发现并指出不合理的地方，从改变他们手中最困扰他们自己的流程开始。让队员能很快地真真切切感受到改变给自己以及团队带来的便利和效率。和创新一样，建立起合理的奖励和表彰机制，让队员能及时获得合理的回报是很好的改造催化剂。
数据驱动。“If you can’t measure it, you can’t fix it”。数字化年代，数据的收集，整理，分析，挖掘和做出相应的反应是改造的重要支撑。在流程改造的全过程，我们都应该注意让数据说话。比如改造开始时列出的清单里，哪个步骤花费时间最长，资源投入最多，就最值得我们去关注。而在改造过程中，我们进度如何，每个改进为公司赢得了多少效率，目标实现的程度到哪了，哪些同事的贡献是最大的，计划是否需要改变等等问题，都需要相关清晰数据的支持。数据其实给了我们一双看清世界，也看清我们自己的眼睛。数据驱动，大致可以分为三步：掌握准确清晰的数据，对数据整理归类分析，对结果做出及时合理反应。这似乎超出本篇讨论范围了，之后有机会可以再详谈。
第三要素：工具
Man is a tool-using animal. Without tools he is nothing, with tools he is all.
工欲善其事,必先利其器。没有好的工具，我们现在应该还在山顶洞里烤火…
工具，在传奇系统DevOps改造中的重要性当然也不言而喻了。但这也是一开始我们很头痛的问题。由于是基于IBMi （AS400）平台，市面上现成的实用工具少得可怜。而且更新迭代慢。几番纠结，我们决定在适当采购同时，自己研究开发适用工具。几番周折下来，我们创建了自己的一套集成工具，算是有些收获。因为针对性比较强，就不介绍详情了。在这里分享我们探索过程中对工具的一些思考和理解，希望也能帮到大家。
我们在思考DevOps改造工具时，着眼于强化两大部份，监控工具和自动化工具的研发与协作整合。
- 监控工具
我们部门大体将监控分为生产机监控和研发过程监控两大部分。
在生产机角度，由底而上，我们监控的着眼点为系统层监控，应用层监控，和交易流程及相关数据监控。简而言之就是保证我们对生产机的硬件，软件以及内容有适时而准确的把握，在出现问题时能及时做出反应。更进一步，能通过一定程度的数据分析，在问题出现前就做出合理预判，提前防止问题发生和扩大。由于平台所限，我们与很多主流工具无缘，所以在改造过程中，我们基于上述理念，研发了一套专属的监控系统。实现了全球数十台生产机各层面状态集中可视化呈现。而且还提供内部移动设备接入。相关门负责人早上一起床，打开手机，全球生产机的状态以及交易大数据就可以了如指掌。
而在研发过程监控上，我们正在努力探索研发一套“单页监控/操作”系统。目标是我们的项目，从需求分析到生产机部署上线维护，每一步的状态都能“一页了然”。并能直接在上面进行多层面的审批，一键测试，一键上线等操作。这是基于部署管道（Deployment Pipeline）理念的延伸探索。还在开发阶段，暂时不做详细介绍了。
- 自动化工具
机器能做的简单重复劳动，为什么要人去做呢？传奇系统的DevOps改造中，要让优化后的流程更快，更准，更稳，就应该考虑尽可能多的常规步骤让机器去执行。比如说测试，上线，乃至常规系统维护。
更进一步理解，在传奇系统团队里建立敏捷的全功能团队，绝对不是简单地让每个人都要懂得所有角色的每个步骤和细节就是DevOps了。而是尽可能地通过自动化，将生产力从相对简单重复的步骤里解放出来，投入真正可以为客户系统增加价值的步骤上来。以我们为例，在测试/部署部门里，比起每天帮新项目做测试/部署更有意义的是，努力让这些测试/部署完全自动化。未来某天，我们或许不应该再有这些“辅助”部门（希望相关部门的领导能有这样的觉悟），取而代之的是全面应用的自动化新工具。或者是由原来这些部门的专家们组成的TMC机构（Tools，Matrices and Control），专门负责订立各方面的流程标准，并将它们自动化，然后安排应用到研发流程中去。
此外，不少新系统的运维已经在开始了AIOps的探索。但个人认为，在传奇系统考虑转型AIOps之前，要在DevOps基础上先实现“TechOps”。也就是在研发运维一体化的基础上先实现基本流程自动化，再考虑加入能自我学习判断的AI化。这是另一个主题，有缘再谈。
篇幅所限，详细的工具类别组成和开发就不在这里讨论了。简单来说，和创新类似，除了应用一些流行的工具软件，也可以建立一个好的平台和机制，鼓励队员在日常中做一些自己的新工具，之后整合推广。总之，工具没有最好的，只有更适合自己的。
结语
以上是我们传奇系统 DevOps 改造中的一些思考与总结。希望能对大家有所启发。
路，还在我们脚下不断向前延伸。我们相信：成功不是终点，失败也非末日，继续前进的勇气决定一切。一起改变思维，砥砺前行吧！我们的巨型恐龙都能在 DevOps 的舞台上舞动起来，您的系统一定也可以！
原文发布时间为：2018-08-08
本文作者：赵德辉
本文来自云栖社区合作伙伴“高效运维”，了解相关信息可以关注“高效运维”
