这几天感恩节放假中。下午碎片时间看看微信消息，发现曹政哥发了一篇「出了 bug 怎么办」（见文末 {阅读原文} ），说的是第一次使用 Airbnb 在注册过程中的邮件验证环节遇到的一些 bug。这个 bug 曹老师先是直接跟我说的，当时只能找同事帮他临时解决了他的问题，又过了一两天，bug 才被完全修复。曹老师不是第一个跟我直接反馈 Airbnb bug 的朋友，之前小道消息的冯老师、歪理邪说的霍炬哥，以及一些写公众号认识的朋友等也跟我说过一些各式各样的 bug。曹老师的这篇文章写的很好，很有共鸣。摘录文中的一些话如下：
一个正在线上运营的系统，如果遇到有反馈说，产品出现了 bug，作为运维，作为研发，正确的应对策略和步骤，应该是怎样的。
那很多人会说，出 bug 第一步就去检查代码呗。
但代码哪是那么容易检查的。
一个程序员水平高低，写代码的时候你很可能看不出来，但出 bug 的时候，分析代码的时候，有经验有思路的，其处理效率往往比缺乏经验没思路的高一个数量级。
一般而言，一个大公司，已经上线的系统，bug 应该不是说那种非常表露的，往往可能需要一定条件才会触发。
文中又详细提到了他的四个步骤和建议，即评估影响范围、试图重现问题、临时方案和终极方案、风险评估及持续优化。
处理过bug 的人都知道，这四个步骤可以说是经典方案。如果能够按照这样去做，在 bug 处理上就会做的很好。
所以这篇文章只想说一说一些在实际执行中一些会影响 bug 有效处理的一个很重要的因素 —— 资源管理和分配。
正如曹政哥在文中说的，其实有效解决和处理一个线上的 bug，往往更能体现出工程师水平的高低。换句话说，可能真的有能力快速或者正确解决这个 bug 的工程师，也许公司的工程师里，只有那么几个。因为很多问题都是和业务逻辑、Legacy 代码等盘根错节的，通常只有对这一块比较熟悉的人才能更快更准地发现问题和解决问题。
因为解决 bug 通常最好是负责开发的工程师，所以，单独开出一个运维组用来处理 bug 其实是不太可行的。这些人如果技术能力不够强，在没有足够背景知识的情况下效率会很低；而如果把公司技术能力很强的精英放到 bug 处理上，似乎又有些不合理。
因此，bug 处理往往还是相关的技术组去处理。
很多公司都有大同小异的 Bug Report 系统，可以由自己员工提交 bug，提交的同时选择 bug 相关的技术分类，如注册、支付、邮件、搜索……等等。另外附加的一些选项还有：严重程度、紧急程度、影响范围和人数、设备（web、iOS、Android）、bug 描述、相关文件等等等等。
这些 Bug 会分到每个组，而每个组对于处理 bug 的资源分配又很不一样。除了一些特别严重和关键的问题会成为组里工作的 Priority，组里最 Senior 或者最相关工程师会立马进行处理，大部分的 bug 都会由 PM、EM 等评估后，或者分配给相关项目的工程师，或者分配给组里的 Oncall 或者 Goalie（负责一周所有产品问题的人员）。后一种看似公平，但是一个问题有时候这些工程师可能因为背景不够，并没有能力独立解决这个问题，因此，又会需要等到 Senior 有时间帮助的时候才能解决。
而因为上述种种，组里如果有几位又有能力、又愿意牺牲自己时间去处理这些问题的老人，就是极其幸运的一件事了。为什么说是牺牲自己时间？因为很多时候老人也是忙人，自己的项目和工作其实往往已经忙的一塌糊涂。那么去处理这些额外的问题，必然意味着额外的加班等。
有人会说 bug 也是工程师自己引起的啊？谁弄的谁修啊。说这样话的人，在一定程度上是对的。但其实，在大部分时候，亲历过大项目的人都知道，现实并不是那么简单。很多明显的 bug 其实不太有问世的可能，在代码审核和系统自动测试化阶段，就会被发现，很少能进 Production 的。偶尔进了，问题很明显，工程师顺手也就修了。既然问题出现了，还大刺刺地存在着，那么大部分时候其实是因为很多相关条件被触发了。这种时候往往不是一个工程师的问题，更大可能是多个人的问题。更有甚者，是整个系统架构里潜在的坑，不过不幸被这位踩上了。
所以最容易被忽略的，也就是那种灰色地带的 bug。公司慢慢变大，很多组会不断细分，有些问题就很难被界定为某个人甚至某个组的问题。有点像 “三不管地带”。这种时候，大组里若没有几个特别有责任心的老人，问题的严重程度又不足以引起 PM、EM 的关注，那么这些问题就有可能在一些项目管理的 Backlog 或者 Icebox 里逗留很久了。
当然，我的本意不是替那些没有快速有效被解决的 bug 开脱。尤其是有些产品和 App，出问题的时候用户除了不用你的产品几乎没有别的选择，这种情况下 bug 的存在对用户体验和产品口碑的影响就格外不好。对公司的长期发展也会有负面影响。
其实 Airbnb 的工程师人手比起我们要处理的事情来说，比例应该算小的。即便这样，我们也有自己的微信群，很多通过朋友反映的问题，小伙伴们都会牺牲自己的业余时间，尽可能地帮着第一时间解决。但是大家的时间和精力毕竟有限，并不能做到尽善尽美、解决所有的问题。但是至少，我们心里知道，大家都是很有责任心、以主人翁的态度，希望第一时间解决 report 的 bug，把公司的产品做得更好。
这里不得不提一下，微信的开发团队也是极其靠谱的。之前听冯老师、池老师常说发现问题立马给拉个群解决了。前一段时间我也遇到一个微信的 bug，我分享到朋友圈的文章，很多再也打不开了。我在朋友圈说了下这件事，因为我的朋友圈里近几个月也积累了一些腾讯微信的工程师朋友，那天也有人很热心地帮我拉了个群，详细询问 bug 的细节。似乎过了两天，就跟我说已经修复了，并让我再遇到类似问题，直接跟他们说。对于这样的敬业精神，作为工程师，会由衷的 Respect。
我也一直很感激直接跟我报告 Airbnb bug 的朋友们。但是有些其实是我们已经知道并正在解决的；有些是极少出现或者没有办法重现因此不得不降低其优先级的；还有一些是没有特别的快速解决的办法。所以，很多时候，我也没有时间一一给以满意的答复。还有一些问题，其实应该联系客服而不是工程师，因为我们能直接做的，还是很有限。无论如何，还是感谢！