一、概述

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

IT价值交付链从对象层次上可分为公司、产品、用户，这三个对象是紧密不可分且相互影响的关系。社交网络事业群拥有众多海量规模的业务，在海量的运营压力下，服务器设备的数量也突破了 10w 大关，并有序的分布在全国不同的 IDC 中。

这些 IDC 有些投入运营的年代久远，已经不能较好支撑现在业务的发展了，我们经常遇见到的 IDC 的问题，如: IDC 机架不够用、IDC 出口带宽不足、机房规划老旧、硬件设施老化等问题。

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

·         业务优化服务质量主动迁移

·         业务因 IDC 的升级与裁撤从而被动迁移

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

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

1.    800W 用户即将停止服务；

2.    挑战与选择；

3.    乾坤大挪移;

二、800W用户即将停止服务

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

搞过大规模业务迁移的看官们都知道，这是一个费时、费力、费心，会产生大量的沟通、评估、实施成本的事情，并且在过程中还伴随着有损业务服务质量的风险。

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

·         早期 APP 版本的多样性，需要适配”百花齐放”的手机机型，不同架构的可维护性差异较大

·         移动互联网网络环境更加复杂、就近接入的粒度需要更细

·         对业务架构的容错、容灾、服务质量、用户调度的策略都有更高的要求

·         ……

手机 QQ 运维团队在此次的业务迁移过程中也面临了上述几点问题，待迁移的业务列表中，有手机 QQ 非智能机的业务。

在2004年—2009年智能机还没有普及流行与平台统一，那个时候用户所使用的非智能机大部分是 MTK、Symbian、Kjava 这三大平台，涉及不同的机型终端有几十种之多，不同机型上所运行的 QQ 版本也是各式各样。

非智能机上的 QQ 各版本之前都是由不同的异地开发团队开发完成，如果一定要说版本之间有共性的话，那就是都具备不可调度的特性，不可调度的特性，不可调度的特性（重要事情说三遍）。

如若支持调度，那么这800W用户，团队也只需小手一抖分钟内就可以调度到新的数据中心的服务集群上即可。

想了解手机 QQ 如何调度与登录流程的看官，可以参看 《【惊】腾讯：3亿人次的实战演习，如何做到丝般顺滑？》这篇文章，这里就不在赘述了。

也就是说这批不支持调度的 800W 用户，是没有办法做常规业务迁移，将会面临因 IDC 断电后停止服务的情景。

三、挑战与选择

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

根据这个业务流程，首先要保障用户能正常的接入才能访问到我们后台的一系列服务。

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. 浮出水面

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

1.    VIP 与待裁撤的 IDC 网络环境强耦合；

2.    客户端 HardCode VIP，且不支持云端更新接入 VIP；

问题的关键点就是用于用户接入的 VIP 要能持续提供服务，并且不能随 IDC

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

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

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

1.    新建 IDC 和待关闭的 IDC 因年代差距较大，基础架构和网络规划差异非常之大，需要将VIP所在的 2个网段整体迁移到新 IDC。

2.    要分别于三大运营商沟通并极力争取运营商侧都同意配合测试与迁移。

3.    网络安全与负载均衡策略也均要平移到新 IDC。

内部牵扯较多的跨事业群部门联合协作。

2. 持续推进

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

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

1.    在新 IDC 中部署全套非智能机的 VIP 后台接入服务，用于切换使用；

2.    确定了运营商切换方案与切换时间点；

3.    制定应急方案；

4.    给用户推送了相关信息，告知用户；

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

因为运营商此次切换是不能灰度的，只能一刀切的全量切换，这里面也牵扯大量的修改网络层面配置，如果切换失败，在切换到之前的环境费时费力不说，也可能引起其它问题。

整体的切换过程不是百分百有把握的，关键的操作都是在运营商处完成，并且这些操作对于腾讯的团队都是黑盒的。

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

这个项目成功的落地执行，挽救了800W 用户正常使用手Q服务。虽然运维团

队顺利平安的度过了这次难关，但长尾业务的迁移的困难也成为运维不得不面对的难题。

为此，我们在运维平台的规划中，结合 DevOps 的思考且落地了解决该类问题的运维方案：

1.    有效的纳管运维对象，包括标准化的定义对象和操作对象。将日常运维操作涉及的资源对象通过配置系统记录起来，并且由行之有效的场景化工具管理好，以此做到每个运维操作都是可量化、可管理、可追溯，保障工作的高效和经验的传承。

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

3.    规划标准操作流程，对重复度高、价值低、令人痛苦的工作应该及时工具化或自动化。

这正是织云平台所推崇的运维理念，织云提供标准化的运维操作流程，结合操作角色与业务权限管理，实现了无论谁发起变更都能获得同样的操作结果，为自动化操作打下坚实的基础。

五、总结

挽救 800W 用户这个项目与腾讯的业务形态密不可分，未必所有的运维都有遇到这种难题的机会，但是笔者相信有一点所有运维人都是共通的，那便是在面对困难时的态度。

而上文中保证了项目顺利完成的关键因素，就是腾讯运维坚持”一切以用户价值为依归”的决心和态度。

（李光原创）

一、概述

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

IT价值交付链从对象层次上可分为公司、产品、用户，这三个对象是紧密不可分且相互影响的关系。社交网络事业群拥有众多海量规模的业务，在海量的运营压力下，服务器设备的数量也突破了 10w 大关，并有序的分布在全国不同的 IDC 中。

这些 IDC 有些投入运营的年代久远，已经不能较好支撑现在业务的发展了，我们经常遇见到的 IDC 的问题，如: IDC 机架不够用、IDC 出口带宽不足、机房规划老旧、硬件设施老化等问题。

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

·         业务优化服务质量主动迁移

·         业务因 IDC 的升级与裁撤从而被动迁移

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

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

1.    800W 用户即将停止服务；

2.    挑战与选择；

3.    乾坤大挪移;

二、800W用户即将停止服务

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

搞过大规模业务迁移的看官们都知道，这是一个费时、费力、费心，会产生大量的沟通、评估、实施成本的事情，并且在过程中还伴随着有损业务服务质量的风险。

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

·         早期 APP 版本的多样性，需要适配”百花齐放”的手机机型，不同架构的可维护性差异较大

·         移动互联网网络环境更加复杂、就近接入的粒度需要更细

·         对业务架构的容错、容灾、服务质量、用户调度的策略都有更高的要求

·         ……

手机 QQ 运维团队在此次的业务迁移过程中也面临了上述几点问题，待迁移的业务列表中，有手机 QQ 非智能机的业务。

在2004年—2009年智能机还没有普及流行与平台统一，那个时候用户所使用的非智能机大部分是 MTK、Symbian、Kjava 这三大平台，涉及不同的机型终端有几十种之多，不同机型上所运行的 QQ 版本也是各式各样。

非智能机上的 QQ 各版本之前都是由不同的异地开发团队开发完成，如果一定要说版本之间有共性的话，那就是都具备不可调度的特性，不可调度的特性，不可调度的特性（重要事情说三遍）。

如若支持调度，那么这800W用户，团队也只需小手一抖分钟内就可以调度到新的数据中心的服务集群上即可。

想了解手机 QQ 如何调度与登录流程的看官，可以参看 《【惊】腾讯：3亿人次的实战演习，如何做到丝般顺滑？》这篇文章，这里就不在赘述了。

也就是说这批不支持调度的 800W 用户，是没有办法做常规业务迁移，将会面临因 IDC 断电后停止服务的情景。

三、挑战与选择

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

根据这个业务流程，首先要保障用户能正常的接入才能访问到我们后台的一系列服务。

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. 浮出水面

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

1.    VIP 与待裁撤的 IDC 网络环境强耦合；

2.    客户端 HardCode VIP，且不支持云端更新接入 VIP；

问题的关键点就是用于用户接入的 VIP 要能持续提供服务，并且不能随 IDC

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

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

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

1.    新建 IDC 和待关闭的 IDC 因年代差距较大，基础架构和网络规划差异非常之大，需要将VIP所在的 2个网段整体迁移到新 IDC。

2.    要分别于三大运营商沟通并极力争取运营商侧都同意配合测试与迁移。

3.    网络安全与负载均衡策略也均要平移到新 IDC。

内部牵扯较多的跨事业群部门联合协作。

2. 持续推进

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

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

1.    在新 IDC 中部署全套非智能机的 VIP 后台接入服务，用于切换使用；

2.    确定了运营商切换方案与切换时间点；

3.    制定应急方案；

4.    给用户推送了相关信息，告知用户；

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

因为运营商此次切换是不能灰度的，只能一刀切的全量切换，这里面也牵扯大量的修改网络层面配置，如果切换失败，在切换到之前的环境费时费力不说，也可能引起其它问题。

整体的切换过程不是百分百有把握的，关键的操作都是在运营商处完成，并且这些操作对于腾讯的团队都是黑盒的。

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

这个项目成功的落地执行，挽救了800W 用户正常使用手Q服务。虽然运维团

队顺利平安的度过了这次难关，但长尾业务的迁移的困难也成为运维不得不面对的难题。

为此，我们在运维平台的规划中，结合 DevOps 的思考且落地了解决该类问题的运维方案：

1.    有效的纳管运维对象，包括标准化的定义对象和操作对象。将日常运维操作涉及的资源对象通过配置系统记录起来，并且由行之有效的场景化工具管理好，以此做到每个运维操作都是可量化、可管理、可追溯，保障工作的高效和经验的传承。

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

3.    规划标准操作流程，对重复度高、价值低、令人痛苦的工作应该及时工具化或自动化。

这正是织云平台所推崇的运维理念，织云提供标准化的运维操作流程，结合操作角色与业务权限管理，实现了无论谁发起变更都能获得同样的操作结果，为自动化操作打下坚实的基础。

五、总结

挽救 800W 用户这个项目与腾讯的业务形态密不可分，未必所有的运维都有遇到这种难题的机会，但是笔者相信有一点所有运维人都是共通的，那便是在面对困难时的态度。

而上文中保证了项目顺利完成的关键因素，就是腾讯运维坚持”一切以用户价值为依归”的决心和态度。

（李光原创）