身为甲方，IT 敏捷转型咋整？——从外包精细管理走向无边界精益敏捷

作者简介

黄倚霄

中国移动广东公司网管支撑业务主任

萧帮主给我打半天广告，我都不太好意思上来了，我今天分享的标题是《身为甲方，IT 敏捷转型咋整？》

先给大家交个家底，我现在带的团队，人不多事不少，我们有30多个自有人员，负责20+ 系统及平台，10+ 合伙厂家，管着乙方的 500多研发运维人员。

广东移动O域的IT敏捷转型分三步走，

第一阶段向传统管理学取经，让外包管理精细化；

第二阶段是向互联网行业取经，引入DevOps精益敏捷管理；

第三个阶段，再向经典管理中的无边界管理取经，最终形成融合传统管理学、无边界管理与 DevOps 的无边界精益敏捷模式，也称为外包环境下的受控 DevOps。

先看第一个，学管理的都知道，管理大师法约尔提出了管理的五个要素——计划、组织、指挥、领导、控制。先举几个例子看看我们是怎样推进精细化管理的。

第一个，需求管控的计划经济模式。作为IT研发运维部门，我们经常被生产部门怼——需求啥时候能上线？能不能给我加个塞？年初提的需求不算哈，年中重新给我来排。这样下去真的不是办法，我们无论如何努力，生产部门都不满意。

后来我们就想，既然国企的项目建设模式是计划经济模式，要不我们的需求也按计划经济模式来管理吧？我们做了两个事情，一是年初可研阶段，按投资额度排车次、分车票，将各厂家的开发资源，按比例分给各业主单位。

二是日常需求排版的时候，各业务单位凭票上车，根据自己的配额安排每一个版本的开发需求。如果票用完了可以向别的业主腾挪。如果所有的资源都用完了，就跟老板申请增加投资，这个就是明显的计划经济模式。

第二个例子，第三方交维，以前我们的研发运维是左边的模式，谁开发谁运维。我们后来发现这样不行，一是运维的知识没有办法沉淀，运维过程也没有标准化，每个厂家的运维水平也参差不齐。

二是有些供应商它的开发人员非常不注意质量，因为想着反正也是自己兜底，何必搞那么认真，开发的质量差，不是还能收一笔维护的费用么？如果开发质量高，连维护费都收不了了。

因为这个原因，我们在几年前，开始实施第三方交维。将运维工作区分为标准运维和高级运维，所有项目的标准运维打一个包，重新招标，引入第三方来做。

内容包括面向客户的热线受理、工单支持、邮件与Q群支持、信息发布、访问支持；面向内部的故障预处理、网元生命周期维护、运维知识库维护、运营数据分析、非功能点验收等等。

然而做完这个之后并没有解决我们研发运维的主要矛盾，这个只是减缓失控而已。

比如刚才说的计划经济模式进行需求管控，你觉得我们的需求快了吗？没有快。

搞了第三方交维，我们的故障就少了吗？也没有。开发慢、故障多、修复慢、对外包强烈依赖，这些问题怎么办？

所以第二阶段，我们对标互联网，引入DevOps。 

DevOps和在读书时候学的软件工程不太一样，软件工程是方法论，DevOps 除了方法论之外，还有很多价值观、原则和工具的最佳实践，强调IT专业人员在应用和服务生命周期中的协作和沟通，强调整个组织的合作，以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付。如果说实践DevOps有什么关键点的话，我会选持续交付。

看这三个图，瀑布、敏捷和 DevOps 的研发模式有什么差别？最大的差别，就是 DevOps 的持续交付增加了一个交付的环节，直接把软件的价值交付到用户手里，这个是跟传统敏捷最大的差别。

如果让我只讲一个图来介绍 DevOps，我就讲这个图。上面的叫集装箱模式，各个流程环节做了一堆东西，然后把它装在一个集装箱上，装满之后搬到下一个环节去进行下一个环节。

例如：大家每个月21日之前提交需求给开发团队，开发团队花一段时间开发，开发完打包提交给测试团队，测试团队又花好一段时间测试，再打包交给工程团队去部署，这样下来，可想而知效率是不高的。如果把大需求拆成一个个的小需求，每个小需求的交付过程用流程串起来，从需求到开发到测试到部署一次流动，对于这个需求来说一分钟内就可以上线，这种体验跟集装箱模式来比较，是多么大的改进。

所谓的单件流模式，将一个大系统解耦成若干可以单独存在的小模块（单件），每个单件在流水线上快速完成需求分析、编码、测试、集成、部署、上线交付使用。就能快速交付业务价值！这个我认为是DevOps持续交付的精髓所在。

持续交付的第二个基础，就是全自动的端到端的生产线。有了全自动的生产线，单件流才能快速地在不同环节流转。一个个的小需求，在 Jenkins 这样的生产线上编码、编译、测试、发布、部署，交付给用户使用。

说到 DevOps 的三步工作法，第一步，流动，好理解。

第二个，反馈，其实就是快点给客户使用，让客户快速反馈问题，然后再快速修复问题，快点让用户满意起来。

第三个，建立持续学习和实验的文化，说的那么玄，其实就是度量驱动的持续改进，在团队文化、在管理模式上持续的向敏捷靠拢。

在DevOps转型过程当中我们也有一些心得，就是技术变革一定要为业务价值服务。CI/CD、微服务化是为了价值的快速流动，ELK统一日志、Ansible自动作业平台，是为了两个先于，比用户更早发现故障，比用户更早的解决故障。

引入自动化测试、引入云化、引入端到端高可用，引入蓝绿部署，是为了要消除浪费。开展工作的模式，要问题驱动不能工具驱动。

作为运营商，IT外包有什么特殊的难题？第一类过度依赖外包、议价能力低、被绑定，还有一个山头林立、动手积极性不高、外包厂家水平参差不齐。

我们回头看管理学的五要素。所谓领导是什么？领导是指挥和协调，作为一个优秀的甲方，就是要做好指挥协调，而不仅仅是当一名包工头和甩手掌柜。

我们的团队慢慢的在走向深度参与运维转型工作模式，我们希望对整个转型过程深度参与。我们为此制定了网管支撑系统的技术体系入网规范。入网规范有这么几个内容，总体原则是开源，解耦，受控。

开源是指，优先选用开源技术栈。

解耦是指“三解耦、三分离”，即软件功能分层解耦，运维分层解耦，数据共享解耦；开发运维分离、软硬件建设分离、运维人机分离。

受控是指：技术架构受控、部署架构受控、研发过程受控、开发规范受控、日志受控、账号管理受控、移动应用入口受控、数据库变更受控。

另外我们对架构也有要求，要求健壮、弹性。对开发的要求是持续交付、平滑演进、蓝绿发布。对运维的要求是脚本化、可视化、自动化、智能化。

软件功能分层解耦，是指所有厂家，对类似数据采集、网元连接及指令下发、网络配置、流程服务、报表分析等通用功能，由公共平台和能力中心承载，不允许自成体系做成烟囱。

第二个数据共享，系统间的数据共享，原则上必须通过ESB总线，不允许点对点互联。

第三个，厂家必须使用广东移动提供的IaaS、PaaS平台服务。不接受应用开发厂家提供涉及IaaS、PaaS层的一篮子解决方案。

第四个部署架构受控，部署架构必须遵循广东移动的架构规范，实现端到端的高可用。即：系统的数据库、存储、网络、应用服务，分布在不同可用区中。

第五个研发过程受控，所有系统必须从源码开始接入广东移动自建的DevOps生产线，实现持续交付，不允许手工发布软件包到生产环境中。

第六个开发规范受控，必须遵循广东移动的开发规范，尤其是数据库开发规范，要求我们所有的供应商的研发工程师必须参加数据库编程规范的考试，考过了才允许参与开发。

第七个日志受控，所有应用系统必须接入广东移动自建的ELK统一日志平台，提供应用全量日志，包括异常事件、接口与组件状态、业务流量流速、用户感知等给日志平台。

第八个运维人机分离，原则上不允许开发人员操作生产环境，所有运维动作（如启停服务、扩缩容、清除异常状态等）必须固化为脚本和可视化、傻瓜化的网页功能，接入广东移动自建的运维作业平台。具体做法是，观察运维人员是怎么操作的，把他们的操作固化下来。

第九个账号体系受控，不允许各系统自建用户账号权限管理体系，必须接入广东移动自建的单点登录SSO。

每个系统都要支持手机号码+验证码登录，并根据用户在公司OA上的角色身份，为其赋予系统的默认访问权限。

这也是为了消除浪费，每个系统都有单独的账号体系，一是没必要，二是让用户记那么多系统的账号密码，不是折腾人么！

最后一个，移动应用受控，也是为了消除浪费。每个系统都开发一个APP，岂不是用户的手机里面要装十几二十个APP？谁受得了？所以我们有了这个规定，不允许各系统自建单独的移动应用（手机APP），只可以开发移动应用的后台。

前台用户UI相关部分，要么提供源码，要么提供依赖包，在广东移动掌上运维APP上集成。不允许提供单独的apk或ipa。

做完这些之后带来什么样的变化呢？原来管理模式是甲方交钥匙现在是甲方总集成，甲方累了很多但是我们累并快乐着，以前的技术选型是乙方选什么我们只能用什么，现在我们是统一提供。

第三个是常年单一来源采购整套系统，现在我们可以采购单个模块，以前采购的方式只能走Capex，现在可以走Opex，这个对大国企也很重要，现在投资紧张，现在可以用预算来解决。

然后还有替换成本也变低了。原来是整套替换，现在可以单个模块替换。通过加强管控，可以说解决了过度依赖外包、议价能力低、被厂家绑定这三个问题。剩下的山头林立、员工动手意愿不高、外包厂家水平参差不齐这三个问题怎么办呢？

P28:还是有办法的，我们回想一下，杰克·韦尔奇说过一句话——如今的组织要想取得成功就必须变的无边界。

无边界的这个思想借鉴的是人体的组织，每一个人的五脏六腑都是独立的组织，但是你的血液你的能量是可以很顺畅的通过五脏六腑，我们的国企也好，私企也好，组织可以不扁平化，只要推行无边界管理，让信息、资源、思想、能力等到共享，在各个组织间无边界通过就可以。无边界精髓我认为是八个字：跨接、众包、塔台、共享。

我讲讲移动怎么去实践无边界的。这个图是我们部门某年的工作报告里面的一页PPT。以前的沟通模式，是每个市公司都只跟省公司沟通，只跟省公司报创新，它们之间并没有交互，这叫以省公司为核心的星形连接。

我们为了打破市公司之间的边界，省公司搭了一个台，让市公司在这个平台上交流。具体做法是，省公司找了一堆的服务器，让市公司把他们的创新亮点部署在上面，然后每个市公司派两个人到省公司来，集中使用和体验别的市公司的优秀系统，然后投票选出最好的系统全省推广。

这样做的好处，大大减低了沟通的成本，提升了优秀实践的价值，并最终让全省的IT能力最大化。

第二个图是打破系统建设和运营之间的边界，系统建设运营最常见的现象是热建冷用，就是建系统建得很开心，从来不关心用得好不好。这就造成很多功能开发出来，根本没有人用。要么不知道、要么不会用、要么不好用。

我们的做法是，打破建设和运营的边界，你用的越多给你的投入越多，你反馈得越多，说明是我们的友好客户，我们提供的资源越多。

对那些沉默的网管，我们也试图唤醒它们，榨干系统的每一滴血。如果我们只有有限资源做一件事情，先把它做出来，叫做样板房。

然后用它来服务不同的同类用户群体，例如不同的市公司，就像体检时候的CT机那样，体检的时候不可能每一个人都自己买一台CT的，肯定是共用的，这就叫体检模式。

我们的一个心得是：运维变革，首先是文化和生产关系的变革首先是文化变革。先要理解和拥抱互联网的思维和组织，才有可能产生互联网的效率和生产力。

无边界的思想，正好可以用来解决解决外包环境下的 “边界”类问题。作为生产管理部门，搭台重于唱戏。给展示的舞台、搭交流分享的平台，做好“鼓励师”，搭支撑的平台，做好“主持人”。

作为甲方，我们是厂家的生产管理部门，所以我们要搭台，给厂家唱戏，让厂家之间充分交流，达到比学赶帮超的效果。比如说技术沙龙、案例分享等等各种形式。当然，我们还搭技术的平台，也就是CI/CD生产线，让厂家在上面开发应用。

这是我们前几天组织的一个案例分享会，各个厂家都要发言，讲讲自己在开发运维中有什么创新，讲的好我给你加分。

讲讲自己学了其他厂家的哪些好东西，学得好也要加分。这一点很重要，不能只给创新加分，对抄创新的人也要加分。

不然大家都只愿意做独创的东西，这也是浪费。明明有好东西，就要尽量先抄，不要什么都想着自己搞。

我们作为甲方，用好指挥棒，让乙方在你的平台上面共同成长，这就是打破厂家之间的边界。

经常有人问，广东移动通过 DevOps 成熟度三级评估认证，究竟有什么用？之前帮主说了评估标准是灯塔，它当然是指引我们敏捷转型的灯塔。

如果我们用无边界管理的思想去看这个事情，其实它还是一个样板房，就是你拿一个系统通过了这个认证，它就是你管的所有项目的样板房，你可以让所有的其他项目学它，它可以为所有其他的项目做体检。这样 DevOps 的成熟度认证，才能发挥最大的作用。

比如说我们通过认证的第一个项目是埃森哲做的，我就推动埃森哲传帮带来教其他厂家，甲方搭平台，搭舞台，因为厂家里面总有强的，让大家都学他。

然后下一个星期一我们组织了一个凤凰项目的 DevOps 沙盘的培训，30个学员里面有15个学员是合作伙伴的项目经理和技术经理，我作为甲方，花钱去培训乙方的项目经理和技术经理，必须让这个生态更加健康发展，我认为好的甲方，就应该带着乙方一起敏捷转型。

精细化管理+研发运营一体化+无边界管理等于无边界精益敏捷，我们暂且称之为外包模式下的受控DevOps。

简而言之甲方要搭舞台、建平台，让合作伙伴和自研团队在受控的环境下、以众包的模式开展DevOps转型。

• 一是要实现全生命周期的生产管控和快速反馈，不能只管敏捷开发不管敏捷运维。

• 二是甲方要自行掌控业务价值流动，不能假手他人。

• 三是要在组织内部推行敏捷精益、无边界管理的文化。
  

我的分享就到这里吧，谢谢大家。

相关阅读：

以通信网络敏捷转型的名义！广东移动 DevOps 标准认证独家揭秘