这些产品 bug，真是很难搞！
共 2146字，需浏览 5分钟
·
2021-07-16 12:22
昨天，我在抖音上刷到一个视频，事情发生在青岛一家餐馆门外，一位外卖小哥坐在地上端着电脑帮一个程序员改 bug。
这个程序员起初是在餐馆里面和同事吃饭，期间接了一个估计是公司打来的电话，于是拿出电脑开始操作。
可能是为了不影响其他同事吃饭，他拿着电脑来到了餐馆门口并坐在地上开始修改。或许是 bug 比较棘手，几度抓耳挠头。
后来一个外卖小哥路过，看到他痛苦不堪，于是上去看了一眼并安慰他，然后接过电脑就是一顿操作。程序员在一旁看得很认真，估计内心也是十分佩服。
对于这件事，其实我的关注点更多是在一些难搞的产品 bug 上，因为我知道那种感觉真的是非常难受。
以前我也是程序员，有时候写代码碰上一些无语的 bug 时，真的是有砸电脑的冲动。
后来做产品了，同样碰上一些毫无头绪的 bug 时，同样也是一脸懵逼。
这里我说几种谜一样的产品 bug，或许你们也有过类似的经历。
第一种，只出现在生产环境的 bug。
在测试环境下开发新功能，开发阶段和提测后都没发现什么问题。可等产品正式上线到生产环境后，问题出现了。
对于已经上线的产品来说，出现线上 bug 就属于项目事故了，不仅影响用户使用，而且修复起来也特别麻烦。
如果涉及的用户体量很大，那短时间内受影响的范围就会非常广，尤其是涉及交易类的产品，那更是会带来直接损失。
出现这种问题的原因，往往是测试环境下的数据样本和生产环境不一样，或者是生产环境的历史数据和新功能出现不兼容，并且在测试阶段没有考虑到。
解决的方法，要么回滚到上一个系统版本，要么紧急修复后重新上线。
总之，这种 bug 的出现往往是特别棘手，也是特别紧张的。
第二种，使用第三方服务或依赖库时发生的 bug。
现在几乎所有的产品在开发阶段都会引入第三方服务或者一些开源项目的依赖库。
所谓第三方服务，就是使用现成的服务，比如推送服务、IM 服务、短信服务等，这些服务都是由第三方公司开发并以收费的方式提供给开发者使用。对于开发者来说，既方便快捷，也省了成本。
另外就是一些开源项目，通常是由开源组织或个人维护的，他们无偿开放出源代码给外界使用，有的还会有专门的开源基金会。说白了，就是互联网技术圈里提供公益服务的。
一旦是这两种情况下导致的产品 bug，往往也比较棘手。原因很简单，问题出在别人那，你想改也没法动手。
举个例子，如果是因为别人的代码出了问题而导致了你的产品出现 bug，除了给对方提报问题，那基本就只能等着了。
第三方服务还好，毕竟人家是收钱服务的。如果是开源项目，要么换一个项目库，要么就只能等着别人来修复。
要解决这种问题，有的公司会采用全部自研，目的是强把控。有的会选用一些比较靠谱的第三方服务和依赖库，以此来提升系统稳定性。
第三种，就偶尔出现过一次的 bug。
这种是最让人迷惑的，有时候偶尔出现一次的 bug，你想定位都没有复现的手法。
最诡异的是，这种 bug 往往是在你不经意间突然出现，让人措手不及。
至于原因，那就非常多了。
有的是因为偶然的数据异常，有的是因为多线程出现的问题，有的是因为突然增加的并发导致的不稳定。总之，这些问题没有规律可言。
所以，对于技术和产品来说，只能尽力去防止 bug 出现，并不能做到万无一失。
更靠谱的做法，是制定在 bug 出现时的应对策略，这也是很多成熟产品都会大力投入的地方。毕竟，只要出问题都不是小事。
不过话也说回来，不管是做技术还是做产品，遇上难搞的产品 bug 真的是头疼，谁做谁知道。
产品不易，且行且珍惜。
最后说一个消息，今年的全球产品经理大会 8 月份会在北京召开。具体时间是 8月6-7日，地点在北京金茂万丽酒店。
之所以特意跟你们介绍，是因为今年的大会有一个重磅嘉宾会带来关于产品创新的干货分享，他就是产品经理必读书籍《启示录》的作者 Marty Cagan。
对于做产品的读者来说，他的书《启示录》我是一定会推荐的，我自己看过很多遍，每一次阅读都会有不同的收获。
可以说，不管是产品新人还是产品专家，从他的书里都能找到一些灵感和答案，他的书也帮助过很多产品经理。
今年的议题都非常贴合行业热点，很多主题都是大家关心的内容，嘉宾阵容也都不错，值得期待。
对于产品经理来说，除了自己学习和实践，偶尔出去看看外界的最新信息，听听行业一线从业者的干货分享，帮助还是挺大的。
参会不仅是听分享，还能去认识一些同行朋友，扩大自己的圈子，给自己更多机会。
机会难得，感兴趣的读者可以到他们官网仔细了解下，我把官网地址放在原文链接里了。
相信，你们一定会有所收获。
················· 唐韧出品 ·················
结合今天的主题，突然想到一句话：「被困在 bug 里的程序员，被困在逻辑里的产品经理」。
本是同根生，携手共进退。