在互联网产品研发过程中，经常遇到一些看似严峻的问题，但最终其实是可以轻松解决的。关键在于是否找到了“根因”，并且从根本上解决这个问题，而不是仅仅局限于问题表象，结果看似解决了，但其实并没有根治，某一天这个问题再次复发了。

最近负责了两个比较大项目的交付，过程中有做的好的，也有做的不好的，但能暴露问题总是好事，这样可以有个思考的抓手去思考。

第一件事是稳定性的事情。老板说让我背部门P2级以上故障的KPI，P2以下不背，也就是起码不能出现高级别的故障。截止到Q3为止我们部门整体的稳定性是可控的，但总会有些低级的问题出现，如果不能根治这些低级问题，说不定哪天就会酿成一个大的问题，必须重视起来。

两个case表面都是流程类问题，线上测试环境访问了线上真实资源，代码有bug触发了数据被错误修改。

这个case其实非常可怕，因为你都不确定这个bug怎么触发，而且不能通过发版记录找到并快速恢复，影响较小算是万幸。

如果把这两个case视为流程类问题的话，能做的就是流程强约束。但也有副作用，就是无形中增加了研发成本，降低了交付效率。

这两个case会不会出现在我身上呢？

我想一定不会，因为我脑中就不会想到在测试环境连接到真正环境去做数据处理，哪怕要做也会有开关。

所以我想这可能是个意识问题。但究竟是不是意识问题呢？

后来想了下两个同学经验都比较少，可能是经验和能力问题，有心无力确实考虑不全。

解法也比较干脆直接，收敛权限，没经过cr和评审的代码没机会上到线上。能力匹配，个人能力要和负责系统相匹配，杜绝不胜任系统的人负责系统。

还有一些常见的问题，比如我们经常遇到研发质量不过关、大量bug出现、导致测试时间不够、研发进度不符合预期、最终产品质量不理想、上线之后被用户触发了bug影响了用户体验，然后产研团队紧急修复bug，导致产研团队处于被动的状态。

很多人认为解决这类问题有以下几种方法：

1. ?增加测试时间，3天不够5天，5天不够8天，总之测试时间一定要给足；

2. 增加测试人手，尽可能确保能在上线前测出更多的bug，让团队有时间来修复bug；

3. 上线前严格对产品质量把控，测试用例尽可能完整，测试过程尽量完备，测试用例覆盖率达到100%，且不存在P0、P1、P2级的bug时才允许上线；

以上三种方法在一定程度上可以缓解这个问题，但只是解决了表象问题，没有从根因上真正解决这类问题。

有效的方法可以从以下两个方向入手：

1. ?在开发阶段不断加强代码质量管理，每天做CR。这些CR工作需要一线的开发组长亲自去给组员去做，每天下班前花半小时看组内工程师今天提交的代码，可从代码逻辑实现上评审是否有更好满足产品需求的空间。同时从代码规范上评审是否满足团队制定的编码规范，通过CR可以很好的发现性能问题和安全问题。只有提升了代码质量，才能提升产品的外部质量，能让提测阶段bug数量从根本上得到控制；

2. 在提测阶段抓一个核心指标，比如首轮测试通过率。具体来说是，开发人员完成产品需求实现后，将代码提交至测试阶段，此时测试人员根据预先设计测试用例，逐一对产品功能和性能进行测试，当所有测试用例跑完了，在统计通过率，比如达到80分才算合格。此时及时对开发人员的绩效进行评估和激励，如果没有达到80分，则可能影响研发人员绩效。保障产品质量不仅仅是QA同学的工作，也是开发人员应承担的责任，线上出现bug不是个人造成的，而是团队造成的；

不仅仅针对质量管理，在产品研发过程中所产生的问题非常多，但普遍问题都能找到根因。

管理者需要从根因加以解决，而不是看到哪里有问题就立即着手开始解决那个问题，有可能我们解决了当前的问题，却总会有新的问不断出现，所以必须找到根因，从根本上有效解决问题。

我在负责另一个系统的研发效率和稳定性上就是采用了这种找根因的方式。

首先我会基于我对于系统功能的理解+产品需求频繁次数+出现故障造成事故影响这三个维度识别出这个系统的核心链路和核心功能点。我会对这部分功能做很强的review和重构，起码做到我心中有数和完全可控。

心中有数的意思是，究竟哪里会有哪类问题，哪类问题出现时，大概是什么原因导致的。

完全可控的意思是，代码进行必要的容错，增加必要的监控报警，在问题出现或恶化之前，我已经接入并做了一定的有损降级，保证不出现大问题。

因为总会有新同学来负责这个系统，如果能降低每个新同学负责这个系统的心智负担和不出现问题的比例，那就需要持续重构的。

我的方式是找到变与不变的边界，不断抽象、沉淀核心功能，保证这部分功能不会被轻易触达和修改，以扩展和插件的方式提供给新同学做业务扩展，这样既可以交付产品的需求，也可以不动核心功能，起到了稳定性和效率的完美平衡。

因为系统的效率和稳定性问题的根因在于系统的技术债，如果可以很好的解决这些债务，其上面的表象问题也就迎刃而解了。