外包环境下的DevOps实践

• 列表项

luna

作者：黄倚霄

• 作者介绍：黄倚霄，来自广东移动。江湖人称“岛主”。

1. 面临的挑战

大家是否注意今年GOPS论坛设了这个专场，只有金融和通信行业面临互联网最大的冲击。我们有微信和QQ，谁还用手机发短信。有支付宝和微信支付，谁还用银行卡。这些是互联网行业对传统行业带来的冲击，其差别巨大，我暂且不谈体制上、流程上、管理上、人员上的差别，今天我们谈谈IT上的差距。

传统行业不包括招商银行、工商银行，我说的是普通的传统行业。传统行业以“交钥匙”模式为主，远程开发后拿包过来现场部署，现在运维成本高，花的是国家的钱，最麻烦的是效率和质量特别差。对面的互联网行业主要是自研自维，他们用的是DevOps体系，高效高质的交付，灵活的应对变化。

2. 实践DevOps的道路选择

如何学习DevOps体系，我们有不同的选择。有些国企、传统行业选择依赖外包，希望通过外包带动我们转型。这就像“输血”，把外部新鲜血液输入到传统企业里。“输血”很好，可以解燃眉之急，但我们不能一直依赖它。

自研自维的全面转型，我们称之为“换血”，运营商在推全面IT化、数字化转型，招一大批计算机专业新员工，希望可以学习，自主研发，自己运维整个网络体系和IT体系。这是一个很好的愿景，但同时它是很难实现的。在实现过程中，可能会面临很多坎坷。我们希望培育基因，持续改良。

3. 技术的实践

3.1 选择普适、完备的体系来对标学习

培育基因，总得有基因，基因从何而来。每个互联网行业都有自己的特性，也有其成功之处，我们难以全盘复制。我们应该找普适完备体系，我向大家推荐两个比较好的体系，一是高效运维道法术器，二是中国信息通信研究院的《研发运维一体化能力成熟度模型》，这两个是从传统行业引进，进行复制和发展。

道法术器，明显是文化体系和中国风特别浓，我不太敢学道法术器，很容易被大家看成道术法器，所以我们学国标。

中国信息通信研究院DevOps模型，当中包括42个过程，难以全学。比如敏捷开发管理，传统行业之前以外包为主，外包哪有敏捷开发，你连代码都没有。

"在瓶颈之外的任何地方作出的改进都是假象"--艾利•高德拉特《目标》

3.2 选取六大过程，优先解决痛点

我们可以从中找到解决目前的瓶颈和痛点。广东移动选择了哪些痛点作为切入点，

• 一是故事与任务排期，管理需求的涉众期望；
• 二是部署与分布模式，痛点是改进版本上线效率；
• 三是应用监控，为了解决故障定位的痛点；
• 四是事件响应及处理；
• 五是高可用规划，提升系统可靠性；
• 六是度量指标，定性定量评估DevOps转型效果，持续优化。

3.3 选取六大过程，优先解决痛点

3.3.1 第一个过程——故事与任务排期，传统行业IT管理部门是甲方，甲方有痛苦，面对乙方和用户时经常被投诉。半年过去了，提需怎么还没开发，我敢得罪谁？我也很绝望。IT管理决策很无奈，你们年初不提，年中说急。集团3月份开工作会，1月份立项，立项时没需求，开完年度工作会提出一堆的需求，老板很痛苦，是厂家不给力还是我们管理水平差，明显是管理水平差。我们的药是管理好各方期望。目前我们解决痛点不是从根上釜底抽薪，而是引入全盘DevOps敏捷开发体系，在很难做到的情况下，难以把源代码拿进来的时候，我们先管好各方期望，先让用户和老板觉得不那么痛苦，我们自己也不那么痛苦，先缓解痛苦再考虑后面的改进。

因此，我们提出年度版本发布计划，关键点是“排车次，分车票”。年初工作会还没开，我们可以估算全年可用的人力资源，假设有1.2万人，根据项目金额和人天单价估算，制定全年版本的分配计划，需求在哪天截止、哪天受理、哪天排版、哪天上线。分配各版本的资源数量，根据全年闲忙规律安排各个版本的资源数量。12个月里，并不是每个月都平均分配，年底特别忙，需求特别多，我们要为第二第三季度多安排。分配用户的资源比例，不是平均分配，要看谁对系统要求提得多。去年这个部门提出60%的需求，来年我给他们分60%的资源，年初分饭票，用完饭票只能等着。预留10%的机动资源，紧耦合系统功能要统一发车时间。

日常需求，列车模式来自于高效运维公众号的定义。列车模式重点在于开两会、出车许可、按时出车。平时做完需求，能否做设计评审会。用户需求是第二个会，我们管理用户的需求无非是让谁来定厂家的开发资源，给谁用。我们的根本是把权利还给业主，作为IT开发的管理部门，凭什么你说了算，一定是业主说了算。为什么我给你提半年的需求，你都没做，因为你没有把它排进两会。

管好期望，皆大欢喜。大家知道发车时间表，用户知道他有多少资源可以，安排时不会乱提，不会毫无成本的提需求，开发者也知道自己要做什么事情。

3.3.2 第二个过程——部署与发布模式。（下图）这是广东移动的痛点图，A系统发布，B、C、D得联调。一个厂家熬夜，其他厂家要跟着熬夜。我们升级当天晚上才发布跨系统的联调。

如何解决此问题，我们的措施是新增预生产环境，改造发布流程为两级部署。预生产环境做的是跨省联调、模拟设施、统一版本替换，最后统一到生产环境上。预生产环境可以白天做，合作伙伴的同事不用那么辛苦。

在我们做高效部署的过程中，我们向腾讯蓝鲸进行学习，本图由腾讯蓝鲸的运维自动化发展历程来。我们给自己定了目标，基准目标是跟厂家的软件发布包，参数的配置文件标准化，升级流程标准化，厂商可以数据脚本自动化，可以用DevOps生产线驱动的自动发布、整体发布脚本化。

我们做的自动发布并不是让他们做网站和系统，我们完全可以从DevOps体系中获得养分。（左图）参加过DevOps大会的都很熟悉，我们做的改造是同时适配外包和自研项目。这边是外包项目，这边是自研项目。有源代码的走这条路，没有源代码的走那条路，直接生产环境部署。

无码项目（无源代码缩写），从制品开始接入Pipeline，编辑好的包上传到Nexus，这是由DevOps驱动。

有码是用DevOps生产线渠道，各租户使用GitLab管理源代码，合作伙伴可以在自己的软件中心工作，不用到甲方现场。上传软件脚本到Nexus，发布到生产平台和预生产平台。

3.3.3 第三个过程——应用监控，痛点是故障发现迟，根源定位慢。监控是可用性、性能和流量，数据质量让人特别难受。我们以前做得更多的是标准化采集接口，拼主机，我们用的是Oracle RUEI，我们要解开黑盒子，只能自己报。DevOps比较大的创新是端到端的应用监控，我们现在要把应用监控串起来，成为端到端的业务监控，使得定位更加方便。

本次DevOps主题是AIOps，我们要从应用监控扩展到统一日志。应用监控只是监控异常，目的是快速定位故障点。统一日志是借助大数据挖掘、机器学习技术挖掘隐患、故障预警，使得传统运维可以向运营转型，也向AIOps进化。我们的目标是做端到端监控、日志，目标是“两个先于”前半部分，一是先于用户发生问题，二是先于投诉解决问题。

3.3.4 第四个过程——事件响应及处理，痛点是故障修复忙乱，只能围观，束手无策。问题根源在于这哥们两次故障都穿绿色衣服，我们让他把这件衣服扔了，以后就再也没有故障了（开玩笑）。

运维工具脚本化，如果今天上午有参加主会场论坛的朋友应该知道，这是一个路径。措施是访谈厂家运维人员，常见故障和处理方法。厂家运维人员说接口拥塞、卡单、缺数、应用进程吊死，解决方法是手工过单、开启限流、增开服务器、手工补数、手工重启等，我们问他能否做到脚本化、傻瓜化，能做到给他们加分。做到傻瓜化才能做到智能化，这是一个铺垫。最近通信运营商说最麻烦的是投诉。

3.3.5 第五个过程——高可用规划,要抄就抄最好的。这张图是从腾讯蓝鲸党受辉那里抄的。腾讯蓝鲸运维人员主要有三项工作，包括处理报警、设置预警、修复高可用。腾讯蓝鲸不用抢修故障，因为他们IaaS的运用架构是高可用，不需要抢。只需要有告警时，设置预警的阈值，超过阈值出现告警，有时间再修复高可用。更换卡，不用抢修，可以他们叫咖啡党。

运营商能否做高可用改造，上面是互联网行业的软件架构，他们用的是Cloud-Native、Docker、MS、Ceph、SDN，我们用的是集中式IBM SVC、传统三层网络结构、VLAN、VMware。我们难以等到那天，我们可以从部署层面开展HA改造，消除单点，不用改代码，不用中断业务，只需要在部署层面开展。花点钱多部署几套，这是“给飞行中的飞机加装引擎”。

如何做高可用规划，借鉴公众云的可用区，一个可用区出现基础设施故障不影响另一个可用区。每一层是多可用区，安全反亲和原则，业务系统跨不同的可用区进行部署。某个应用系统在网络层是跨可用区，应用本身跨多个可用区的部署。通过多可用区的部署实现高可用，简单粗暴。

端到端的高可用部署体系有网络高可用、主机高可用、公共SaaS高可用、存储高可用和应用部署高可用。

高可用部署之余要反亲和部署，高可用规划同步的同时，要进行CMDB清洗。做到什么程度？不要做大HA，够用就好，尽力而为。我们在高可用区时，必须有CMDB，你不知道谁跟谁反亲和，你不知道谁跟谁是异常的。我们在高可用规划时做CMDB是高效的，为高可用切换、定位做，我们取的是CMDB最小级。

3.3.6第六个过程——度量指标，国企有“铁打的营盘流水的领导”，在国企注意体系的可持续发展，将最佳实践固化形成企标。应用系统交维标准，必须满足一键部署、一键启停，一键切换HA。数据库编程规范很重要，我们制定了《数据库应用编程的N条军规》，否则做更多的高可用都是无效的。IaaS、PaaS、SaaS架构的规范，要求单平面故障时可支撑业务高峰，多可用区部署、反亲和写原则。DevOps工具选型建议，开源原则、主流原则、能力原则。

制定标准，DevOps实施的评价体系。六个端到端（Chart CD），端到端CMDB、端到端的HA、端到端的Alarm and log、端到端的Repair、端到端的CD。

4. 管理感悟

万事开头难，后面结尾也很难。架构还没改变，大家都在观望的时候，可以耐心培育种子，不妨先创造环境。我们总结了三个势，顺势、借势、造势。

顺势，运营商最近今年要做NFV，去年、前年时我们想办法从NFV“硬掰”DevOps，如果没有DevOps，根本无法做NFV。

借势，她是萧帮主的手下，上了贼船。 2017年10月，我们经过一来二回的联系，跟他们形成关系。去年年底在广东移动开了家门口GOPS，请了萧总、咖啡党给我们领导讲课。实际上是想借势，我说的领导不听，我可以请专家过来讲，培育出文化。借势，我们要走出去，请进来，请到组织里，成为你的助手。

造势，开始时很多领导认为DevOps是自研，我们办了两届自研大赛，自研形成的结果是引起老板重视，兴起学IT的热潮，开发了一批小工具，培养了一批IT高手。我们把势造起来，让大家觉得IT不那么难，做网络运维的人也可以写代码。从各大高校招的电信专业、光电专业、物理专业也可以写代码，根本是为“换血”打下基础，有人才可以转型，造势很重要。造势不仅如此，今年2月份广东移动下一代网络智能运维IT技术沙龙，这个沙龙很厉害，主题是让同事上台讲。去年请外面的专家来讲，我培育了一年，我借足了势，再进行造势。我请了计划部、优化部门等不同部门的专家过来讲。萧帮主说“带着身边小伙伴，一起愉快地玩耍”。一起玩耍，一起造势，把DevOps势头造起来。

搞定后，团结一切可以团结的力量。对团队，我们要加强培训，拓展新视野，派出BAT、GOPS学习。绩效倾斜，我们鼓励愿意投身到转型工作中的员工，提供平台，给成长机会。我们董事可以自己上台讲，对大家的鼓舞很有帮助。

对厂家，转型亲自管，莫用外包管外包。用好指挥棒，能做到两个先于可以加分，先于用户发现问题，先于投诉解决问题。能够一键修复的加分，HA切换的加分，从源码开始CI、CD的可以加分。

互联网标杆，鲁迅先生说过“我们要运用脑髓，放出眼光，自己来拿”。

我们要寻求老板的支持，没有老板的支持，所有事情在国企都是不可行的。

5. 总结

成功可以复制吗？李开复有一本书说《我的成功可以复制》，还有人写《我的成功不可复制》，所以万能药丸不存在。领导的风格、员工的素质、厂家的能力和自己的眼光不一样，注定每个企业和团队的DevOps转型之路是独一无二的，必须边走边试边学。我们要务本求实，回归本性，你做DevOps是为了什么。我做DevOps转型是要解救熬夜值班的同事，让他们不用经常连轴转，这对我们同事来说是很好的救赎。软抄学神，大家可以到各地方学习，不一定要全抄，要剪切粘贴。

致敬和祝愿，今年是改革开放40周年，改革开放是从深圳这片土地开始的，根据中国的实际情况制定了发展之路，我们移动DevOps转型也是如此，根据日常生活所做的尘世和实践，我们不是从头做起，我们是站在巨人的肩膀上发展，一是高效运维社区，二是蓝鲸。我们从这两个巨人身上学习到很多东西，一并向他们表示感谢。如果有需要用到移动网管力量的朋友，我们随时献出我们的梯子。

6. QA环节

台下：昨天我在问传统企业的DevOps怎么做。第一，DevOps比较关注的是业务价值，您不想让兄弟姐妹那么累，除此之外您做完DevOps转型，实现了什么，实现了多少您对老板的承诺。
黄倚霄：我的目标不仅仅是不希望同事们那么忙那么累，我希望DevOps转型可以带来价值。我们网管系统是支撑网络运维，实际上也有运维是跟业务，比如戴维管理系统，它有很多需求，你快点上线，对装维师傅的反应度有帮助。这个片子没有谈到您的提问，我们准备在4月份开始把某几个管理系统从源代码开始做起，放在我们的DevOps生产线上。我们尝试成功一个小工具，我们以前外包给厂家做，大概半个月或者一个月更新一次版本。我们同事用源代码接入后，每天可以贡献。我跟老板承诺，下半年实现某些系统交付周期，从一个月变成一天或者一周，这是DevOps给我们带来的业务上的价值。

台下：第二，你们有自研团队和厂家无码团队，你自研的占比会越来越大，厂家和合作伙伴会支撑您这么做吗？把源代码交给中国移动。
黄倚霄：作为移动，难以把管理软件变成自研，毕竟各个厂家沉淀十几二十年的东西，难以靠几个人用半年或者一年时间替代它。我们做的是关键组件资源，比如SSO、网络投诉日志查询、行业数据库关键组件。无论是自研还是外包，最终诉求是把源代码放在广东移动的DevOps生产线，放在广东移动的GitLab进行预警。我们保证是自己员工管理DevOps生产线，不让外包厂家管理。有些厂家愿意把源代码放在我们上面的，我们要扶持这种厂家。

台下：我们理解外包环境下的DevOps运行，核心在外包。合作方是非常重要的力量，推行DevOps非常重要，特别在我们行业体系下。合作方各有各的不同，有时候由于其定位、业务导向问题，需求不一样。运营商体系中，势必要推动大家往前走。通过指挥棒调整，这需要投入，有没有更好的解决方案，毕竟不是每个运营商都像移动这样可以有大投入的。
黄倚霄：借鉴毛主席打仗的做法，拉拢一批，忽视一批，打击一批。我们的蛋糕这么大，总会有人愿意配合你。我们的计费系统有华为、亚信和联创，总会有人配合你的。我们作为甲方管理人员够不够坚定，领导是否足够支持你。当厂家去领导那里告状，你能否顶住。我们从痛点着手，解决的是现实中的困难，并没有做颠覆性的东西，你没理由不配合我。我从头到尾都是为了解决四个痛点，我开始时并没有让你交出源代码，你可以不交，当厂家发现交制品非常累，交源代码钱又多又轻松，就一定会选择交源代码。

台下：非常赞同您谈到的外包转型，但同国企实践来看，除了您谈到的痛点，我们还有其他的痛点。一是人力资源方面，我们无法独立自主，我们由公司主持，在人力上难以实现增加人员；二是国企团队创新能力肯定不如厂家，一旦进入国企团队，其创新能力马上不足，这是我们的现实情况，您能给我们提出什么建议？
黄倚霄：第一，人力资源确实是长期的问题，万事开头难，你必须学会顺势、借势和造势，要顺着当前企业所在引进，比如更快的交付、更高的运维质量。借势，多带你的领导和同事参加各种论坛，多向互联网行业和互联网公司学习，了解、对标，让他走出去看，他自然会有了解。人心是肉长的，有触动之后，要多向领导请示和汇报，多说案例。我们原来内部挖潜，从一个团队抽出一两个有想法有能力的人，让他专职做DevOps。很多人看到他做出来的东西很有意思，我也去学。你可以找出一个种子——造血，找到这个基因，并将其点燃。我们同事一年来好像没做什么，那一年他的绩效是最差的，我也让他升岗了。

台下：自有团队的创新能力。
黄倚霄：我们国企团队不像互联网公司那么有激情，前面相对颓废，尽力而为，不要强求，比以前好就行了，不要跟互联网公司比，这影响幸福感。