爱立信电信软件的持续交付

CD 持续交付 DevOps KVM

摘要

最近几年，DevOps原则和工具的应用已经改变了电信行业的服务交付流程。在2017年DevOps企业峰会伦敦大会上，爱立信公司发表了演讲。他们的持续交付论文概括了他们面临的挑战以及他们如何克服这些挑战。

正文

最近几年，DevOps原则和工具的应用已经改变了电信行业的服务交付流程。在2017年DevOps企业峰会伦敦大会上，爱立信公司发表了演讲。他们的持续交付论文概括了他们面临的挑战以及他们如何克服这些挑战。

电信系统供应商在部署系统时面临的困难在规模、监管限制、健壮性、可用性需求方面是独一无二的。之前，在一个开发周期中，爱立信需要花7个周测试、6个月部署、2到3年开发，现在，他们只需要90分钟测试、3个周部署、6个月开发。电信软件的任何新版本都会向多个网络运营商推出。他们在最初采用这种比较新颖的实践方法时遇到了困难，但随着时间推移有了改善。一个版本从正式发布到在运营商的节点上线之间的时间逐渐缩短。特性发布频率为每月一次，而网络运营商可以选择一月一次部署，也可以选择一季度一次。

图片来源：http://cloudpages.ericsson.com/continuous-delivery

开发模型是首先需要改变的——从多个并行版本链转为“单轨（single track）”。第一个采用这种变革的产品是GPRS服务支持节点——移动管理实体软件——然后是“演进型分组网关（Evolved Packet Gateway）”。演进分组核心是一个电信框架，其目标是在4G网络上提供统一的语音和数据服务，而不是分别针对数据和语音采用数据包交换和电路交换。

转型过程从2009年开始。首先开始的是流程变革——像小型跨职能团队、产品经理任务分配、Scrum管理员任命。他们引入了精益流程。类似代码提交频率这样的指标被用来衡量他们的效率。然而，这导致了这些指标的误用。在部分变革显示出良好的前景后，领导者就有了增加团队数量的压力。这导致了更深层次的问题，包括快速增长的团队以及低估了平台变革所要具备的条件。他们的平台不是对此有利的云就绪平台。开发环境和CI实践方法也还不成熟，加之程序结构也不成熟——这导致他们无法很好地监控团队的进度。团队的整体速度比以前慢了。2015年的一次盘点活动暴露出了这些问题。

他们进行了一些变革来解决这些问题。相对于速度，质量被赋予更高的优先级，而且特别重视质量验收测试。他们增加了一个引入新团队及新成员的新流程。在工具方面，团队开始借助Kernel Virtual Machine（KVM）实现虚拟化，这将他们的升级时间由22个小时缩减为3个小时。KVM是一个框架，是一个运行在Linux内核上的虚拟层，同时也是爱立信云平台的重要组成部分。他们还采用了持续集成框架，其中一部分是基于Docker的。他们还采用了一个集中式的硬件分配模型，根据请求分配资源。这简化了管理，从整体上提高了硬件的使用率。组织变革包括项目管理实践、更好的规划、特性团队、每日站立会议以及分享知识的培训（指导）。

爱立信的其他产品也已经采用了CD模型。这是电信行业大趋势的组成部分，传统的服务交付方法已经让位于DevOps。这也是由先前基于硬件的网络服务功能（NFV）的软件虚拟化所推动的。这简化了DevOps工具和实践的应用，因为越来越多的功能改由软件实现。

查看英文原文：Continuous Delivery of Telecom Software at Ericsson