一分钟精华速览

本篇内容来源于 TakinTalks 稳定性社区「年度专家小会·杭州站」，感谢阿里、腾讯云、飞书、网易、华为、浙江移动、极氪、酷家乐、大搜车、二维火、亲宝宝等等企业 20 余位稳定性专家的积极贡献，为我们多角度呈现了不同业务、不同规模、不同团队下的优秀管理和实践经验。

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

作为技术管理者，在从技术角色到管理角色的转变中，关注点需要从个人成功转变为组织成功。个人高效能把事做好，组织也同样，效率是衡量组织价值的一个重要指标，提升组织效能是每一位管理者最重要的工作，但改变往往是反人性的，大部分人都不太愿意接受，所以管理者需要从人员组织、绩效、管理等多个维度采取有效的策略，一步步改变组织环境，保障组织的价值和输出效率。

今天我们邀请了 5 位不同业务线、不同岗位的稳定性管理者，聊聊他们是如何在人员组织层面提效的。

阿里云-彦林微服务引擎业务负责人

在人员组织方式层面，有什么比较好的做法？

• 挖掘主观能动性，提前解决问题而非事后指责

稳定性保障的意识形态与责任边界的问题，其实是管理和目标设定的问题。我认为在梳理风险和问题发生过程中，如果问题被提前梳理了，但是由于上级主管没有排期解决而导致故障发生，那么这个故障是管理者的责任。如果因为风险没有被梳理出来，在变更过程中没有意识到风险，而导致故障产生，那么需要一线同学来承担责任。这样可以尽可能让同学们发挥能动性，提前去梳理和解决问题，而不是在事后相互抱怨，这是我在管理上的一个思路。

• 不同业务对风险的容错率不一样，需要根据不同业务来平衡收益和风险

在稳定性和日常工作安排中，如何安排人力，如何维持平衡，这也是人员组织层面的问题，不同业务对于稳定性的要求不一，所以需要因地施策来做人员调配。我之前在华为做硬件业务，后来进入淘宝做软件业务，就我个人经验来看，我发现有一个很大的区别，就是大家做稳定性的时候，投入和收益其实是不同的。举个例子，华为、阿里云做芯片业务，如果出了问题返工，可能损失的就是几百亿；但是互联网行业，比如淘宝或者字节的部分业务，它的反脆弱性是很强的，容错性也很强，所以这些企业在做平衡的时候，会要求跑得快，跑得快比稳相对来说更重要（因为互联网是一个快鱼吃慢鱼的业务）。但对于很多的更底层、更传统的这些硬件企业，由于脆弱性比较强，所以这种公司其实会更加追求稳定性，也会在稳定性上投入更多人力。对于阿里云这样一个基础平台而言，稳定性就是我们的底，阿里云有一个基本文化叫“基础不牢，地动山摇”，就像是一个水桶，如果没有了底，业务是没法发展的。但是在我和很多外部团队的沟通中，我会发现很多企业在脆弱性比较强的情况下，是追求高速发展的相对稳定性。

• 建立统一故障认知的前提下，在每一个事件 action 中不断加强流程落地

每个公司都有一些传承，但制度和流程如何持续？这是一个问题。大家经常提到的“故障驱动”，故障驱动可以帮助我们向上要到资源投入到稳定性建设中，很多企业中没有明确的故障，老板大概率不会给加人，也不会在稳定性上增加投入。所以在平时的风险梳理、预防，包括线上问题出现的过程中，其实我们可以在每一个风险事件中不断地加强流程落地，而不是在发生故障的时候再采取行动，即见微知著，通过一些细小的点不断地去落地整个流程规范。

在招岗位：阿里云-微服务技术专家

简历投递：water.lyl@alibaba-inc.com

岗位详情：https://talent.alibaba.com/off-campus-position/887801?trace=qrcode_share

亲宝宝-李远研发负责人/ Java 开发主管

如何划分稳定性保障工作的团队组织形态和职责边界？

• 在创业团队中，单一做稳定性会脱离实际，研发和稳定性可以不设边界但要有 owner

我们是一家创业公司，团队规模不大，所以我不太有可能设置专职的人来做稳定性的事情。目前主流的分享基本都是大厂的一套稳定性保障机制，对于我们创业公司来讲，可参考性比较有限——因为我没有那么多人，也不需要做到那么精细化。

我曾经尝试过在我仅有的 20 个人的团队里，抽两个人出来不做业务需求，只做一些稳定性的预研之类的事情，但是这个效果非常不好，因为完全脱离实际了，没有业务作为基础，其实这个组的很多投入就是拿着锤子去找钉子，至于对业务产生的帮助，这个也是收效甚微。所以我的经验总结来说，就是不设边界，但是需要有 owner ，就是大家做轮值，所有人都来参与稳定性这个事情，我可以让一部分人或者每个人分一部分精力来做稳定性的事情。另外，基于云厂商给予的一些支持，在此基础上我们尽可能地做一些力所能及的事情。

在人员组织方式层面，有什么比较好的做法？

• 确保日常不低于 10%的精力投入在稳定性建设中

我们团队比较幸运的一点是，老板和 CTO 都是技术研发出身，我可以从高层得到较多支持，我们对于产品需求、优化需求的比例有一个硬性投入比例，需要保证不低于 9 比 1 的比例，即每个季度我需要保证至少有 10%的人力投入，来做一些稳定性的建设，比如技术预研之类。如果这个时间不在平时做点滴投入，当遇到业务有快速变更的情况，工作承接是非常吃力的。

大搜车-冯金标系统运维专家

如何划分稳定性保障工作的团队组织形态和职责边界？

• 问题由稳定性团队提出、业务线团队改进，改进中反向促进稳定性团队优化工具体系

我们稳定性团队的人不多，内部分工我认为可以分为两部分——发现问题者（即提稳定性要求的人）、提供工具者。稳定性相关的事情一定是由稳定保障团队来负责牵头的，所以要求这个团队有主人翁意识，要发现问题、提出要求、推动业务线团队做优化。作为问题发起者，我们需要通过各种方式，比如政治政策或者其他约束等，目标就是推动业务线去解决问题。

在业务线团队解决问题的时候，肯定会反过来去找稳定性团队，提出各种挑战，比如有没有更好的工具，这种时候会反向 push 提供一些工具来做支撑，以及去补齐工具层面的短板，这样来配合把稳定性的工作形成闭环。

怎么保障一线在业务工作较多的情况，也能持续投入稳定性工作？

• 帮助一线同学提高故障处理效率，减少告警

我认为业务一线的同学来解决稳定性的问题，对他来说不是一种负担。为什么这么说？因为线上告警多或者故障多，那他肯定要去参与故障复盘、故障后的数据订正等，也会影响日常的研发和迭代。“解决故障、告警减少其实是提升研发的工作效率”，首先要把这个意识要传递下去。

• 虚拟奖励政策

除此之外，也需要有一些奖励政策，比如，某个研发同学作为应用 owner ，他的应用可用率比较高，或者告警的处理率有明显下降时，我们可以给一些荣誉性的奖励，比如邮件表扬，设置一些稳定性之星的嘉奖，公告其解决了多少风险、多少故障等。

稳定性规范如何落地？

• 人天生具有惰性和惯性，要依靠工具来做强制约束

去年我们做了很多规范，但是在推行过程中，不管是发邮件提醒，还是开大会告知的形式，其实效果都不佳，最终结果是故障处理规范只有稳定性团队在遵守。

我们意识到，规范的落地还是要依靠工具，因为人都是有惯性和惰性思维的，那么就需要靠工具来做强制性约束。比如说我们在对于研发侧 coding 的一些规范，限制低版本的二方包不能引用。对于故障处理流程，比如说可以引用或者是自己研发一些故障处理流转系统，在流转系统里自动 @到应用的负责人，通过工具把我们的规范落地，这部分我们仍然处于探索阶段。

数列科技-杨德华 TakinTalks 社区发起人/数列科技联合创始人

稳定性规范如何落地？

• 有时候不是大家主观意愿上不配合，而可能是客观条件影响，加强稳定性规范的培训和考核是比较好的手段

在我们公司很多时候他们说我不按规范做事，我常常不自知并反驳“规范是我定的，我怎么可能不按规范做事情”，所以这里我有一个思考——为什么在很多企业内，规范设定了但是没法落地？

我们可以适当参考福格行为模型——动机、能力和提示。先分析问题发生的原因再考虑怎么去解决，我认为原因其实有几方面——

第一，可能他根本不知道你设定了什么规范。你以为他知道，但实际上他其实不知道，因为可能开大会、发邮件，其实根本没人听，也没有人看。

第二，可能他不具备这个能力。即你说的那东西他理解不了，不知道你在说什么，比如你和他说苹果，明明你表达的是苹果手机，他会以为是吃的苹果，这是很有可能的。

第三，可能他真的忘了。因为事情太多，当一件事情没有反复被提醒，就可能被忘掉。

所以规范落地，我认为培训和考核机制是比较有力的，给一线的同学做培训，培训完之后做细致的考核，录个视频交作业，比如，遇到故障要怎么处理，让每一位一线同学录个视频，通过后才能“持证上岗”，这样才能很大限度让大家都按照规范做事。

• 互联网企业的稳定性远不及传统行业，可以参考传统企业的“精益生产”思路落地稳定性规范

我们互联网行业在搞的稳定性，即使是已经非常精细化的头部企业，其实也远不及传统行业的“精益生产”，因为他们的故障容错率相对会低很多，比如飞机随便出故障那是危及生命的。所以，我比较推荐大家多去学习丰田、通用汽车之类的传统企业，参考他们的生产规范落地的思路。

知名互联网公司-薛明资深中间件开发工程师

如何划分稳定性保障工作的团队组织形态和职责边界？

• 设置横向的稳定性小组和虚拟成员，主持故障评定、梳理、跟进，不设边界统管稳定性问题

我们公司是有几个主要的专职人员在做架构治理和稳定性相关的工作，但是只靠这几个人是无法完全实现稳定性保障的，所以会从各业务团队吸收一些虚拟成员，来共同成立稳定性小组，比如说每个业务线定期出一个人专门配合处理稳定性工作，每周有一个架构师周会，把问题收敛上来后做分析，然后去做一些工具化、平台化的支撑，如果发现一些共性的问题，则会把它抽象成一些规范。

如果系统出现故障，也是由稳定性委员会来主持，评估事故影响面、做故障定级，然后稳定性小组再去梳理和跟进。从规范制定、到故障评定、再到跟进处理，这一系列工作其实赋予了稳定性小组比较大的权利，所以它的工作可以说是没有设边界的，质量问题、架构问题都是稳定性问题，都是这个虚拟小组的工作覆盖范围。

怎么保障一线在业务工作较多的情况，也能持续投入稳定性工作？

• 由业务线负责人把控需求分配，若稳定性问题严重，则由稳定性小组介入立项整改

我们在这个点上是没有统一标准的，它由各个业务线负责，业务需求和稳定性相关的需求平衡是由业务线负责人去把控的。我们现在有非常多 API 接口，按照二八原则，活跃的接口可能只有 20%，大家发现问题之后，只需要重点去保障就可以了。

这里有一个特殊的场景，即有些业务线稳定性问题发生比较频繁，稳定性需求严重影响了开发进度，这种情况怎么处理呢？今年我们出现了两次这样的情况，一般是专项推进来改善。把这个业务线的稳定性作为一个重点项目去推进，按照稳定性小组制定的整改流程，由 PM 整体推进和跟进完成。

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

回复【交流】进入读者交流群

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