运维的难题 : 800 万用户，救 or 不救?

李光，任职于腾讯社交网络运营部/织云产品团队，负责织云监控告警平台规划与运维新产品开发工作，多年业务运维、运营规划经验。

概述

读完关于DevOps前世今生的《凤凰项目：一个运维的传奇故事》，书中传达了若干理念，其中一点也是老生常谈的IT的价值体现在帮助业务与用户的价值提升，当时看到这里的时候，想起团队进行过的一个挽救用户的项目。

IT价值交付链从对象层次上可分为 公司、产品、用户，这三个对象是紧密不可分且相互影响的关系。社交网络事业群拥有众多海量规模的业务，在海量的运营压力下，服务器设备的数量也突破了10w大关，并有序的分布在全国不同的IDC中。这些IDC有些投入运营的年代久远，已经不能较好支撑现在业务的发展了，我们经常遇到的IDC问题如: IDC机架不够用、IDC出口带宽不足、机房规划老旧、硬件设施老化等。

一般迁移服务是有两种因素合力而成的：

• 业务优化服务质量主动迁移
• 业务因IDC的升级与裁撤从而被动迁移

在业务的实际迁移中，经常会遇见长尾业务迁移成本高、迁移难度大的挑战。

本文主要从三个部分介绍了笔者所服务的手机QQ运维团队在一次业务被动迁移过程中遇到的挑战，在面对挑战的时候团队是如何坚守“一切以用户价值为依归”的价值观。

• 800W用户即将停止服务
• 挑战与选择
• 乾坤大挪移

800W用户即将停止服务

先给各位看官们唠叨一下整体的背景，在去年的时候我们要开始因IDC硬件设施老化需要被整体裁撤掉而带来的业务被动迁移，此次迁移机器数涉及2K+,业务模块数量涉及150+，其中手机QQ运维团队所负责的部分，无论是机器量还是业务量都是TOP1，而且裁撤时间进度比较紧张, IDC将最后会在运营一段时间后，断电断网。

[1502355341634_5442_1502355341998.jpg]

搞过大规模业务迁移的看官们都知道，这是一个费时、费力、费心，会产生大量的沟通、评估、实施成本的事情，并且在过程中还伴随着有损业务服务质量的风险。工欲善事必先利器，虽然运维团队有经过多年持续打磨DevOps最佳实践平台—织云，可以高效地提升我们迁移部署、扩容、缩容等事务性操作的效率。但却依然改变不了大规模迁移业务是一个很苦逼事情的本质(……….此处省略1000字，避免传播负能量的嫌疑)。

可能有的看官还不太熟悉腾讯织云是什么东东？这里再唠叨几句，概要介绍下织云。

织云是团队2013初开始规划并上线的，上线后也获得了集团内卓越运营奖这项殊荣，至今织云已经持续打磨了四年。织云的运维理念是“业务价值导向”，这也吻合了运维这个岗位最朴素的目的“为业务创造价值”。

[1502355451057_3208_1502355451306.jpg]

DevOps持续交付原则中，有两个基准原则：

• 为软件的发布创建一个重复且可靠的过程
• 将几乎所有事情自动化

重复且可靠与自动化是相辅相成的，二者公共的基础是标准化。回到业务裁撤这个具体的场景中来说，设备的上架、业务的部署、设备的下线等操作就是高频的重复动作，织云将这些具体的运维场景全部封装成标准化操作。

[1502355707980_31_1502355708446.jpg]

通过众多的一键式的标准操作，可以极大地提高运维同学的效率。笔者在业务裁撤中，经常就会通过这些一键式的标准化操作同时启动若干个版本部署、设备下线等操作流程。

PC互联网时代逐步的结束到全面进入移动互联网时代的过程中，也带给了运维团队很多全新的挑战与压力如：

• 早期APP版本的多样性，需要适配”百花齐放”的手机机型，不同架构的可维护性差异较大
• 移动互联网网络环境更加复杂、就近接入的粒度需要更细
• 对业务架构的容错、容灾、服务质量、用户调度的策略都有更高的要求
• ………….

手机QQ运维团队在此次的业务迁移过程中也面临了上述几点问题，待迁移的业务列表中，有手机QQ非智能机的业务。在2004年--2009年智能机还没有普及流行与平台统一，那个时候用户所使用的非智能机大部分是MTK、Symbian、Kjava这三大平台，涉及不同的机型终端有几十种之多，不同机型上所运行的QQ版本也是各式各样。

非智能机上的QQ各版本之前都是由不同的异地开发团队开发完成，如果一定要说版本之间有共性的话，那就是都具备不可调度的特性，不可调度的特性，不可调度的特性（重要事情说三遍），如若支持调度，那么这800W用户，团队也只需小手一抖分钟内就可以调度到新的数据中心的服务集群上即可。也就是说这批不支持调度的800W用户，是没有办法做常规业务迁移，将会面临因IDC断电后停止服务的情景。

挑战与选择

手机QQ用户的概要服务流程是: 用户通过客户端Get到的VIP接入我们的后台服务，后台服务返回请求结果于用户。

[1502355822908_7993_1502355823196.jpg]

1. 我们面临的关键挑战

• HardCode VIP 在2004年--2009年的非智能机时代众多的QQ版本中，有些版本因为平台框架与当时大的2G网络环境的限制只能将用于提供用户接入服务的VIP HardCode到版本中，且不同机型、运营商、厂商HardCode的VIP也不尽相同。同时支撑这批VIP的后台接入服务是和所部署IDC网络环境强耦合。非智能机版本的QQ是不支持动态下发与测速动态更新接入VIP列表的，我们同样也不能通过调度系统干预用户的接入地址。
• 客户端版本停止迭代

MTK、Symbian、Kjava 这三大类客户端是2004年--2009年间是由不同的异地团队开发完成，至今已经有7年多没有版本迭代了。随着人员流动，对于这种长尾业务已经找不到当时主要负责开发的同学了。

• 版本覆盖率 假定我们不计人力与时间成本去重构三大类非智能机的众多QQ版本，但因为APP的升级行为依然是依赖用户主动发起的行为并不能透过厂商的渠道强制更新，所以新版本覆盖到全量800W用户也是一个极其漫长的时间。
• 迫在眉睫

业务迁移的最终结束时间点也都是既定好且不能更改，因为到期后IDC就会断电断网，停止提供基础服务。

面对这些挑战，我们似乎陷入了一个僵局，既不能调度用户、也不能推送新版本，而且还要让原本负责用户接入服务的20+VIP能一直稳定的工作，否则800W用户就会停止服务。

2. 800W用户 VS 大盘数据

800W用户对于QQ所服务的海量用户中占比有多少呢？从两个运营指标来衡量。DAU(日活跃用户数量)， 现在QQ的DAU是8.3亿，800W占比有1%，日最大同时在线数量，QQ大盘日同时在线2.3亿，而800W非智能机用户同时在线175W，占比不到1%。从上面两个数据来看，平均不到1%的占比基本是对大盘不会有影响。

3. 我们的选择

从挑战与数据来评估，其实是给运维团队带来个很大的难题 如何成功的解决这个难题？又或者放弃这800W用户？

客观说不是没有想过放弃这800w用户，因为这是对于团队成本最低甚至可以说是一劳永逸的做法，业界也有类似强行挂公告停止服务的先例: 尊敬的用户 因XX原因在XX年XX月即将停止对XX版本用户的服务。再说，用户换置一台智能机的成本也很低，换置后还能享用到更好的服务质量！ （备注：非智能机版本的用户因为受限于机型硬件配置与2G网络的限制，客户端一般只提供消息类的基础服务）

放弃800w用户的方案在初始讨论的时候就被否决，原因其实也很简单，这和团队一贯所坚持的价值观不符合：运维的价值在于运用技术方案保障服务的质量，让用户能获得优质体验。运营过程中的每个难题、每次故障，都促使我们多想一点，多做一点，不断的深耕细作锻炼运维能力来服务用户。倘若就这样放弃这800W用户，不仅放弃了运维自我成长的机会，更会伤害了一直信赖QQ这个产品用户的感情。

既然已经决定了要挽救这800W用户，那我们该如何去做呢？

乾坤大挪移

1. 浮出水面

如前所述我们遇到的核心问题：

• VIP与待裁撤的IDC网络环境强耦合
• 客户端HardCode VIP，且不支持云端更新接入VIP

问题的关键点就是用于用户接入的VIP要能持续提供服务，并且不能随IDC关闭而停止服务，且VIP是与IDC网络环境强耦合的，此时一个大胆的方案再被拿出来重新评估，为什么会说在被重新评估，是因为这套方案在初期就拿出来概要评估过，就是因为涉及到外部三大运营商与太多的不可控因素，团队认为是很难执行下去的。

这套方案是什么呢？是IP(网络)平移, 概要介绍就是我们将待裁撤的IDC中，VIP所依托的网络环境整体1：1的迁移到新的IDC中，也只有将网络环境全部迁移过去才能保证用于接入的VIP服务不会中断掉。夸张点说这个方案的整体执行难度可以借鉴下图表达。

[1502356137934_4921_1502356138356.jpg]

这个方案有哪些可预见的关键难度呢？

• 新建IDC和待关闭的IDC因年代差距较大，基础架构和网络规划差异非常之大，需要将VIP所在的 2个网段整体迁移到新IDC。
• 要分别于三大运营商沟通并极力争取运营商侧都同意配合测试与迁移。
• 网络安全与负载均衡策略也均要平移到新IDC。
• 内部牵扯较多的跨事业群部门联合协作。

2. 持续推进

概要方案确定后，我们就卷入不同部门的同学来评估细节与落地，并也积极与商务同学一起与运营商沟通寻求支持。经过多次沟通，所幸的是运营商侧愿意支持与配合我们做IP(网络)平移。这个项目当中有大量的沟通协调工作。

获得运营商的支持后，整体项目也就进行的比较顺利了，我们依次又确定了具体方案关键节点:

1. 在新IDC中部署全套非智能机的VIP后台接入服务，用于切换使用
2. 确定了运营商切换方案与切换时间点
3. 制定应急方案
4. 给用户推送了相关信息，告知用户

在某个月黑风高的凌晨2点钟，开始了网络地址切换方案，切换前的心情是这样的。

[1502356216991_7230_1502356217248.jpg]

因为运营商此次切换是不能灰度的，只能一刀切的全量切换，这里面也牵扯大量的修改网络层面配置，如果切换失败，在切换到之前的环境费时费力不说，也可能引起其它问题。整体的切换过程不是百分百有把握的，关键的操作都是在运营商处完成，并且这些操作对于腾讯的团队都是黑盒的。

幸运的是，当晚网络切换很顺利，VIP平移后，用户自动重新登录与消息收发均成功，服务一切正常，三个月的努力成功了，800W用户在无停止服务的风险了！

[1502356259619_8405_1502356259794.jpg]

这个项目成功的落地执行，挽救了800W用户正常使用手Q服务。虽然运维团队顺利平安的度过了这次难关，但长尾业务的迁移的困难也成为运维不得不面对的难题。就长尾业务的迁移过程中，哪些技术点与流程点能被优化的呢？笔者这里抛砖引玉的抛出几点粗浅的想法：

1. 非功能性规范的重要性。历史问题导致了长尾业务迁移的痛，假如运维能够在业务开始之初就规范好业务的非功能管理规范，提出能被执行的运维标准化要求（如无hardcode IP等要求），有望极大的降低了历史问题的发生。

2. 云技术的运营。 长尾业务因为多数都是运行在物理服务器上的，通常的迁移步骤都是梳理当前环境在重新部署，如果能用镜像的方式，更好的自动转换(P TO V)，会极大的提高迁移效率。

3. 更前瞻的规划。运维不但要维护业务，还要对业务的分布进行全局的规划。此案例中，假如运维能提前规划好未来3-5年的业务分布，所有的紧急任务都会变得有条不紊。

总结

挽救800W用户这个项目与腾讯的业务形态密不可分，未必所有的运维都有遇到这种难题的机会，但是笔者相信有一点所有运维人都是共通的，那便是在面对困难时的态度。而上文中保证了项目顺利完成的关键因素，就是腾讯运维坚持”一切以用户价值为依归”的决心和态度。

欢迎关注「腾讯织云」公众号，获取织云最新技术资讯。