|
|
|
质量是一个宏大的需要不断学习的领域，每次遇到新的问题都会有新的领悟。从每一行代码、每一次网上问题定位、每一次BUG修复中，我终于切身体会到，对待质量要始终保持战战兢兢，如履薄冰的心态才能保证我们的产品质量，这也是在保证我们的生活质量。
代码江湖，质量第一
质量“第一课”
“我们的产品是电信级的产品，要求是要达到5个9级别的。也就是说，每年业务中断的时间最多只有5分钟。”这是刚走出象牙塔进入公司的时候，主管和我们新员工座谈交流时说的一句话，我到现在都还记得。
其实当时我对“5个9”是啥，一头雾水，所谓“5个9”，意思是可靠性达到99.999%，即(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟，真可谓是“万足金”产品了。可是，这一年只能中断5分钟，对于当时的我来说简直是天方夜谭：“这是怎么做到的？电脑开机久了还会出现各种问题，需要重启一下呢！”这是当时我心中涌现出的最直观的想法。
然而没过多久，我就实实在在地感受到了5分钟对于质量的意义。经过一段时间的流程、编码规范学习和问题单修改等磨炼之后，师父决定让我开始进阶——独立开发一个特性。对于这一天我期待已久，信心满满，拍着胸脯向师父保证，肯定完成任务！一定要让师父看看我的实力，毕竟在学校时，也是导师的得力助手，代码能力也是同门中的佼佼者。
为了不让师父失望，我加班加点，一气呵成，快速将几K的代码写完。调试修改，功能一切正常！代码和用例提交给师父，期待着师父惊奇的表情和赞许的目光。
很快，我得到了一大盆冷水：
“这里主备场景考虑了吗？”
“如果这里的长度是个异常值呢？就死机了！”
“这里出现异常了怎么办？没有处理？”
“你的测试用例怎么都是正常场景？异常场景呢？”
我不禁陷入了自我怀疑，师父特地和我进行了一次深入的交流。我终于体会到，写代码不是完成功能就可以了，正常的业务流程只占到一小部分，大部分的工作都是在对于异常的处理上，要考虑出现异常了怎么办？要达到5个9级别的产品要求，不仅仅是完成代码功能就行了，还要对每一行代码、每一个分支、每一个场景进行充分的考虑，这才是编码人员对质量的敬畏之心。这一堂课让我受益匪浅，后来工作中每次提交代码前，我都习惯自己先检视两遍代码，同时确保各类场景不止覆盖到正常功能，还要能对异常的场景、分支进行构造，覆盖。
没有100%完美的软件
几年coding时光过去，我自认为对于如何保证代码质量已经有了比较深的认识。这时我被安排作为组内网上问题的定位接口人。“产品质量决定生活质量”，交接的同事意味深长地告诉我。很快，我就有了同样的体会。
那一天我被拉到了攻关室，这里充斥着紧张的气息，大家神情严肃，眉头紧皱——每一个网上问题都需要我们必须全力以赴。
“你们想想，周末你带着老婆孩子‘吃着火锅唱着歌’，突然网上问题就来了——Welcome to join the conference，你就只能在老婆杀人般的眼神中灰溜溜地回到公司攻关问题。”这是我们接口人之间流传的自我调侃的段子。我们明白只有产品质量做好了，网上问题下降了，紧急攻关减少了，生活质量才能够有保证。但在当时，我们经常遭遇的是“XXX局点突然发生断链，XX个APP无法访问”“XXX局点升级后单板无法启动，反复重启”“XXX局点和友商设备接失败”……这一类问题。为了保证业务，一个个网上问题需要在最短时间内完成定位、恢复，真正的争分夺秒。
可惜bug是难以避免的。写代码时的一个疏忽，就可能导致很严重的网上问题。
某天晚上10点，攻关组长一个电话打了过来：“XX局点版本升级后一块单板发不出去流量，业务受损。赶快到攻关室！”
我飞跑进去，首先快速了解问题情况，先分析整个业务流程涉及到的环节，从一线获取到日志和统计数据，到转发单板接收并发送数据，全流程定位问题。“找到了！是转发单板没有发出数据！”一位同事喊了出来，正当大家乐观地认为原因找到了，新的问题又来了：为什么转发单板没有发出去？发生了什么？转发单板根据Trunk表项（汇聚数据转发的内部查找表）进行数据转发，为什么表项会出错呢？我们相互看了看对方，无法回答，时间一分一秒过去，此时距离升级后业务不通已经过去两个小时，始终无法确定表项出错的原因。虽然已经将流量用备板接替，暂时没有影响到客户业务，但是问题不解决就存在隐患。
攻关室内充斥着压抑的气氛，每30分钟在攻关群内汇报进展时，我的心中不断默念：稳住，冷静才能解决问题。然而我们始终无法确定表项出错的原因，尝试复现一直未能成功。攻关到第二天早上天都亮了还是没有进展，无奈之下，主管决定优先恢复业务。接下来一个月，我们反复梳理转发单板的流程，不断尝试复现，增加定位手段，才终于定位出根因，解决了问题。虽然问题是解决了，但其中付出的代价是很大的，正是因为定位手段的缺失，导致我们付出了很多倍的时间和精力来定位。
这是我第一次对DFX（面向X的设计）有了直观深刻的认识，100%完美的软件是不存在的，bug无法避免，但是如何在出现问题后速定位定界，也是产品质量至关重要的部分。同时，业务的恢复能力的重要性，也成为我学习到的另一个重点：在出现问题的时候，怎么快速将业务恢复，保证产品的韧性，更是产品质量不可获取的一部分。
就这样，在不断的问题攻关中，我对于质量的认识和理解也在不断地刷新：产品功能固然重要，而隐形的DFX能力更是产品质量和竞争力的体现。在此之后，我写代码的时候不再只关注于功能的正确、正常及异常场景的覆盖，每一个功能点在设计之初，还会考虑这些问题：这里如果出了没有考虑到的问题怎么办？是否能够快速定位定界？是否能够快速恢复？
与时间赛跑，让代价小一点、再小一点
2019年，我们的部分产品需要进行服务器和操作系统切换，同时还需要保证新的产品可以快速接替原来的产品。硬件是新的，操作系统也是新的，挑战非比寻常。
时间争分夺秒，每一天都是重要的一天。但这么多年的教训和关于质量的理解让我深知，每一步都要走稳。问题越在前端拦截，付出的代价越小，每往下走一个环节发现问题，就会付出10倍的代价。
新服务器硬件架构与原来的服务器不同，多线程之间对内存的读写无法保证顺序，这意味着产品原有代码中涉及到免锁操作都要进行排查修改，保证内存序，也可以这么理解，不加锁（免锁）可以保证多线程间性能更好，但免锁本身依赖于多线程间对标记读写的判断，如果读写顺序保证不了，会出现不可预期的逻辑错误。如果在这一步发生了遗漏，那么就意味着代码逻辑会发生不可预知的时序问题，表现出来的问题现象可能是千奇百怪的，极难定位。这些bug，如果在编码阶段发现，只需要加几行代码就可以解决；而如果问题遗漏到测试，那么就要进行问题的复现、定位、修改、自验证、合入、回归，工作量大很多。一旦遗漏到了网上，那问题的影响和带来的负面效果则不能简单地用工作量来衡量了。
为了保证不遗漏，我们需要先对代码进行了全量的搜索，找到对应的点。但仅仅这样是不够的，有些地方用的关键字不一样，还得从代码流程开始梳理，一步一步地把产品代码中所有涉及到数据交互的点都找出来，把涉及到免锁操作的点一个一个排查修改。
在保证功能的前提下，我们还要保证新的系统有良好的性能。对于性能的优化同样刻不容缓，这涉及到大量代码的修改，在进行优化的同时，我也时刻提醒自己，代码在提交之前，务必要自己先检视两遍，自测试场景覆盖全了吗？可维可测足够吗？可扩展性怎么样？出现问题能隔离与快速恢复吗？无论时间再紧张，这些动作也绝对不能忘。最终，我们守住了时间点，同时本次性能优化也没有引入新问题，保证了产品的质量。
关于Committer的一点分享
今年初，我被任命为了Committer，这意味着更大的责任，不但要保证自己的代码质量，也要保证组内代码的质量。对于合入的每一行代码都要深入地考虑，对于存在疑问的代码，要和作者反复讨论确认。
我也因此，收获了一些“抱怨”，很多人不理解，为什么给我提了一堆无用的意见？明明已经实现功能了，又没有bug，为什么要改？但我把自己的经验分享给大家，同样是实现特性，怎样写才能更具有扩展性、健壮性、可维护性、韧性，即使没有发现bug，也要考虑足够的定位手段，以及出现问题后的恢复手段，这些都是非常重要的。没有发现bug不等于没有bug。
质量是一个宏大的需要不断学习的领域，每次遇到新的问题都会有新的领悟。从每一行代码、每一次网上问题定位、每一次BUG修复中，我终于切身体会到，对待质量要始终保持战战兢兢，如履薄冰的心态才能保证我们的产品质量，这也是在保证我们的生活质量。
# 我的质量我做主# |
|
发表于 2020-11-9 06:52:30
