团队新人多，稳定性经验不足，研发质量怎么保障？｜TakinTalks论道

# 一分钟精华速览 #
在研发和稳定性保障过程中，人与设备、程序、组织的交互是一个复杂的过程，虽然人们极少会恶意犯错，但由于受特定情景下的实际条件影响，人为失误也时有发生，那么，如何尽可能减少这些失误的发生？如何保障研发质量和系统稳定？

「TakinTalks论道系列」12月刊第三期，即将发布，敬请期待！

当我们把人有可能犯错的地方，通过代码、工具或者数据实现强有效的管控，就能做到不让人为因素随意破坏系统的稳定性，也就表明系统稳定性建设的成熟度达到了较高水准，在稳定性建设领域越来越多企业都在往这个方向优化迭代。

本文来源于TakinTalks稳定性社区「年度专家小会·杭州站」，来自酷家乐、飞书、婚礼纪、浙江华为、阿里云的5位不同角色的稳定性管理者，关于人员管理和“有效管控”上的15条经验建议分享给你。 

     

酷家乐-守仁

SRE团队负责人

# 有哪些有效手段，降低人为因素带来的稳定性问题？

降低人为因素带来的稳定性问题，我总结一下大概3个要点——

自动化工具覆盖，规范整个研发流程
当团队新人较多时，人为的变更我们一定要通过自动化工具覆盖，包括设计、编码、测试、发布、监控、变更、重保、应急的整个闭环，里面所有的DevOps 流程的工具我们都统称为稳定性工具，通过工具的覆盖是能确保提升稳定性的。          意识比工具更重要，需自上而下提升稳定性意识，可以考虑将稳定性工作和绩效挂钩 有工具只能减少稳定性的问题，并不能完全将其消除，我认为自上而下的对稳定性的重视程度很重要，比工具本身更重要。那么，人的意识如何提升？从人性角度讲，没有压力就没有动力，我认为稳定性的工作需要和每位员工的绩效挂钩，如果没有上层的政治压力，一线的人很难能完全愿意配合使用这一整套的稳定性工具，因为从开发、测试到线上应急，再到最后的故障复盘等等，这里面DevOps 工具少说也有十来个，再有限流降级熔断的演练和压测之类， 让一个开发同学脱离业务开发本身去熟悉这一套工具，其管理成本相对比较高 ，所以我们需要借助一定的“压力”来提升大家的动力。        
设置稳定性接口人，绩效与业务线故障绑定 我们现在每一个业务线，都设置有类似“稳定性接口人”的角色， 接口人需要一直驻扎在业务线团队，并和业务线的故障在绩效层面做绑定，他需要为业务的稳定性负责 。这个人可以是横向的职能团队，也可以来自应用运维，比如 SRE 部门，但他一定要驻扎在业务线上。

飞书-邓敏

研发技术团队负责人

# 团队新人多，稳定性经验不足，研发质量怎么保障？

       流程规范必须遵守，它是兜底稳定性的刚性条件

对整体的研发质量，不论是老人还是新人，在字节内部我们设置有一些规范，包括DevOps工具使用、稳定性保障的流程体系规范，这些都是刚性条件，目的就是兜底或者说提升整体的确定性。

       要允许新人犯错，年轻人需要“看过猪跑”，踩过足够多的坑才能快速成长

新人的特点是从意识到经验，包括处理问题上都是不够成熟的，在带新人上我的经验是，要允许他犯错。早年在阿里的时候，作为新人的我也犯了很多错误，那时候整个工具平台都不够完善，从我自己的经历来看， 犯过足够多的错误，或者看到过别人足够多的错误，新人才会快速成长，这是一个新人变成老人要成长的必经过程，不犯错是不可能成长的。

       内部设立“师兄制”1V1帮带，帮助新人快速融入稳定性文化

那么新人进来之后如何快速成长为老人？除了系统的培训外，我们一方面鼓励新人多做尝试，一方面在 mentor 的机制上会设定较多要求，即每位新人会设置一位师兄帮带，师兄需要对新人做更多的教育和兜底，让新人在实操的过程中，把稳定性的经验逐步培养起来。

婚礼纪-冯永祥

测试团队负责人

# 有哪些有效手段，降低人为因素带来的稳定性问题？

我从测试团队管理的角度，分享我的一些策略和正在实行的方法。

       修复后的bug做回归测试，不断复查才能避免故障再次引入

针对测试流程中发现的问题，在我们对测试环境和预发环境测试完成后，会把之前发现的问题全部重新进行一次回归测试，把问题当用例去跑一遍，确认没有引入新的错误或导致其他代码产生错误 。

       每周五定期复盘，以业务线的角度复盘故障风险

我们每周五会进行一次复盘，复盘时我们会邀请公司里包括产品、研发和测试等，有意愿参与复盘的人，我们都会邀请参与到项目中，我们会提前设定好复盘话题，比如，我们投入到哪个业务线上，大家一起去发现这个业务线上的问题和存在的一些隐患；不了解业务的我们就从用户的角度去看，了解业务的我们就从业务上去看，去和库存进行一些校验。用这种方式我们会发现很多的隐患问题，就尽量在团队内部消除掉。

       单个业务由多人back up，避免人员流动带来风险

我们 不允许单个业务或者是单个模块完全交接到单个人负责 ，都是由多个人来熟悉这部分业务，这就避免了当人员出现流失或者无法及时响应时，导致业务断链的情况发生。目前我们是按照个人能力加员工的意愿度，按照这个模型去推进业务交叉。

浙江华为-鞠新宇

测试团队主管

#有哪些有效手段，降低人为因素带来的稳定性问题？

我的理解是稳定性问题的保障主要从三个方面——人防、技防、流程防。

 人防：定期培训来提高能力，排行榜来激发潜力

在人防层面，一方面需要通过培训去提高人员的能力，另一方面还需要通过一些软性的手段（比如排行榜）来做提示和激励。比如，针对开发人员，可以组织对代码曲线密度或者引入问题等这些数据做排行榜，定期做数据晾晒；针对测试人员，问题漏测率、测试执行效率或者测试用例的设计效率，也可以做排行榜后定期做数据晾晒。这些日常的排名情况，和个人绩效关联后，能一定程度上促进个人主动提升工作质量。

        

技防：自动化工具部分取代人工，最大程度减少人力介入

技防主要就是通过一些自动化工具，比如监控等，减少部分的人工投入。因为自动化也不需要人力投入，你可以让它一直去跑，把一些问题能够发现出来。

        

流程防：在细节处优化流程规范，重要动作上做到交叉审核

对上线发布制定一系列流程，比如bug修复后在预发环境跑一遍再发布；再比如，为了防止部分研发人员疏于自查导致的故障，在项目尾期或者上线前，修改提交的代码需要经过小组内能力较强成员的 review 之后，再合到我们的分支上到生产。这样通过非常多细节上的流程规范设计，来从流程上防止人为因素带来故障。

阿里云-草谷

微服务引擎稳定性负责人

#团队新人多，稳定性经验不足，研发质量怎么保障？

我认为可以从3个方面去做研发质量保障——

       为新人设置保护期，期间由师兄兜底和担责，促进师兄为新人提供更多稳定性文化输入

每个新人刚入职阿里云的时候，会分配一个师兄，师兄的机制会起到团队稳定性经验传帮带的效果，帮助新人快速了解团队内的稳定性文化。同时， 新人会设有一个保护期，即新人在成长出来前，线上出现的任何可能导致故障的问题，都需要师兄承担主要的责任 ，以此来反向地 push 师兄，一定要把传帮带这个事情给新人做好。

       已有的机制需快速熟悉，重要发布和变更规范需严格遵守

从机制上来说，任何一个系统线上的变更、上线等，一定要有很明确的流程机制。比如，开发团队有开发的质量保障流程，上线变更有类似变更三板斧，这些在新人工作中是一定要严格遵守的。

       新人的稳定性意识来自于对故障的重视程度，需不断输入并建立对故障的敬畏感

新人对待线上故障的意识需要不断加强，也就是说，让新人能意识到每次线上出问题，对整个团队、对公司、对用户/客户带来的影响，这是我们要不断地去向新人灌输的理念，让他能意识到做线上稳定性的重要性，从而新人自然而然会对线上故障产生敬畏思想。

更多稳定性技术实践和管理经验，欢迎扫码进入 「读者交流群」 实时互动（请备注“入群+企业+城市”）。

微信公众号后台回复【交流】进入读者交流群

声明：本文由公众号「TakinTalks稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。