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 点的时候电话把同事叫起来进行修复（当然，也有可能是这一块的负责人那个时候还没下班）？
这些都是很有意思的话题，而且已经不完全是技术的范畴。腾讯这样规模的公司能做到这样快速的反馈，的确很厉害；同时这也意味着，即使你是一个小公司，在产品迭代、响应速度上要赶超腾讯，是难度很大的。
现在就开始建立这样一个快速响应的开发 + 运维 + 测试的体系吧！
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论