3 月 24 日晚 11 点 22 分, @左耳朵耗子想改 QQ 密码,触发了 QQ 安全中心的一个 bug:
于是发微博吐槽之。大家初步分析这是一个比较低级的错误, @翁雨键在评论中认为:
目测是因为#是非法字符。程序员偷懒跟密码长度不对用了同一个错误提示,QA 不知道有这样的规定设计测试用例没覆盖到,PM/UE 太 junior 只关心正常的 path 没给错误用例设计提示。
然后过了半个多小时, @腾讯 QQ 安全中心的运营人员发现了这条吐槽,并进行了反馈:
又过了一个多小时, @腾讯 QQ 安全中心又回来这条微博下评论,说 bug 已经改好了:
此消息一出,腾讯 QQ 安全中心背后的运维、响应、部署流程立刻引起了大家的关注。当事人陈皓对腾讯这次的响应速度进行了高度评价:
只有高度自动化测试 + 程序员完全自主才会有这样高效的流程。
在看到这条消息的时候,InfoQ 编辑正好在跟腾讯互联网产品运维副总监Coati 沟通 QCon 北京分享的事情,便问他腾讯在快速响应、部署这方面是怎么做的。Coati 表示,虽然 QQ 安全中心属于基础运维部,而自己负责的范围属于应用运维,但根据他跟同事的沟通,他们在运维响应方面的很多处理流程是差不多的,比如:
一般我们推送新版本,大体分为三级:一种是大版本的更新,涉及到特性增减改动等方面的,一般每周会做 2-3 次,而且会选择周一到周四之间做推送,一般不在周五做推送;另外一种是运营性的版本更新,这个更新频率不一定。这两种都是需要 QA 参与的。第三种是 bug 修复,这里也分级别,比如外网对 bug 进行快速修复,大的 bug 是需要走灰度的,而小的 bug,比如只是涉及到界面、体验相关的,是可以免测试的。
这次密码功能 bug 的修复,因为涉及到程序逻辑,所以上线之前还是要经过测试的。不过这并不是说测试人员就一定要在公司,我们可以 VPN 登陆,从家里也可以随时响应的。
Coati 表示会在 QCon 北京上的分享介绍更多的细节,包括:
- 腾讯的互联网产品运维这块是如何划分领域的?
- 运维和开发有明确的界限么?平时如何协作?
- 代码部署和代码审查都使用什么工具?发布流程如何?发布的频率如何?
- 应用运维的监控分为几个层面?信息源来自哪里,监控的力度、频率如何?
想了解腾讯运维体系的同学们,可以重点关注 Coati 的分享。
InfoQ 在前不久刚刚介绍过 Etsy 的运维体系。根据 Sam Haskins 的介绍,Etsy 的核心平台团队平均每天的部署次数在 20-30 次,最高时甚至能达到 70 次。他们的监控手段也比较立体,在自动化监控工具之外,有大量的工作是靠人肉看图表来完成的,另外帮助论坛和客服那里也是重要的反馈来源(他倒是没提到有没有在用 Twitter 做这方面的监控)。
阿里系方面,应用运维的刘勇( @淘宝仲明)也公开介绍过他们的运维流程。阿里应用运维的发布观察期一般在一个小时左右,涉及到交易等重要的变更则走灰度,需要24 小时的观察期;监控也分为很多维度,针对底层有常规指标的监控,针对业务层面有交易量等业务指标的监控,也有对用户投诉的监控,根据投诉出现的频率和修复bug 需要的时间来确定bug 修复的优先级。仲明也是今年QCon 北京自动化运维专场的讲师。
乔梁也对百度的DevOps 运动进行过介绍,提到了从2010 年到2011 年之间,百度内部的提测耗时和上线部署耗时大大减少的情况。对于不了解DevOps 文化的同学,这篇文章也是一个很好的入门资料。
最近几年在运维界流行的 DevOps 文化,可以说是开发领域的敏捷运动的一个延伸,提倡开发和运维协同工作,以实现快速部署、快速响应。这个理念尤其适用于互联网产品和移动互联网产品,因为此类产品的迭代速度是核心竞争力,不仅影响产品本身的质量、功能发展,还很大的影响到产品的市场口碑和传播效应。像本次 QQ 安全中心的例子,用户反馈的信息源出现在新浪微博这个第三方平台上,而众所周知,官方微博的运营人员往往是不懂技术的。
微博运营人员如何能够判定这个 bug 反馈的重要程度(无论是在技术层面还是营销层面)?运营人员把此类 bug 反馈到哪个渠道(一般的情况下,腾讯这样大的公司,你不可能很快知道负责 QQ 安全中心这个产品的技术经理是哪位的)?谁来决定这个 bug 值不值得在凌晨 12 点的时候电话把同事叫起来进行修复(当然,也有可能是这一块的负责人那个时候还没下班)?
这些都是很有意思的话题,而且已经不完全是技术的范畴。腾讯这样规模的公司能做到这样快速的反馈,的确很厉害;同时这也意味着,即使你是一个小公司,在产品迭代、响应速度上要赶超腾讯,是难度很大的。
现在就开始建立这样一个快速响应的开发 + 运维 + 测试的体系吧!
评论