从2018年加入阿里，转眼已有5年。收到周年祝福那一刻，就有写一篇关乎这几年思考的冲动，作为缅怀也作为总结，没想到陆陆续续写了好几个月，险些写到了六周年 。我在阿里一直从事测试开发相关工作，这几年学习很多、收获很多，认识了很多新朋友。深知在阿里做测试开发是巨大挑战；相比于其他公司，我们需要不断学习和趋于全能；是卷亦是成长，边谩骂边奔跑。仅把这几年的经历和思考，以及拜读很多前辈高文所得结论，一并分享给大家，希望给还在该方向摸爬滚打的同学一些启发和方向。
有人说，阿里的测试开发主要的工作内容是业务保障+专项。诚然这些年，我和我的团队也在做这些事；与其他公司不同的是：“专项”的涉及面很广。外部公司的“专项”更多的聚焦在“过程改进”，但在这里至少有效能、稳定性、资损、业务、性能（压测）、研发流程、用户体验、大促保障等等。“方向多”本没有毛病，但是结合“变化快”和“业务保障压力大”，就会暴露几个问题：a. 专项频繁变化没有沉淀，深度不够；b.专项进展缓慢对业务价值低，无成就感；c. 压力大、变化快，工作浮于表面，个人成长慢。近几年在跟同学one on one的时候，发现这几个问题也是大家的主要困扰。而我个人也在不断摸索，在这样的环境下，如何去解决这些问题。所以本文会从成长和专项两个方面总结我的经历和思考。
《个人成长》
这些年我的钉钉签名一直是“不负韶光！”。何为“不负韶光”？大概就是我用生命中的这段光阴换得的价值是自己满意的。“价值”可以有很多种，因人而异，因时间而异，如快乐、成就、钱等等。那何为 “成长”？大概就是单位时间换取价值的能力在提升。从物理上讲就是价值密度变大了，从数学上讲就是价值相对于时间的导数变大了。我自己的经历：
刚开始从事测试开发的时候，写一些代码会很开心，觉得很有进步和成长。-- 做了之前不能做的事
后来开始做平台，提升自己和团队的效率，觉得被认可很开心有成长。-- 提升了个人影响
再后来又做了很多平台，并没有原来的成就感了。--重复产出的是价值，提升的是熟练度，但没有成长的快乐
因此，我现在每年会问自己，“今年做的事，去年是不是可以做？”。以及我去看团队同学的时候，也会看是否相比于去年有了新的方向的认知和产出。
成长的路径
回想工作这几年，我个人是比较追求成长这件事。同时也尝试了很多手段，比如看书、写代码、跟人交流等等。但并没有摸索出一套成长的路径，在我当时的意识里，“天道酬勤”就是成长的主要手段了，以至于团队同学咨询我关于成长的问题，我也总会说“多看书”。直到最近读到了一篇文章，才系统的认识到了成长的路径。认知-实践-价值-客户（引用自 《技术一号位的方法论【个人篇】——人成长的本质以及如何让自己成长【总结】》）。（关于这套理论的介绍，可以参考原文。）
回到测试开发这个岗位，成长的关键点在于，识别自己当前所处的阶段，并做对应的行动。可以将职业的规划分成几个阶段：
1～3年：有点像读本科一样，会学很多基础课程。认识测试开发这个岗位，并在多个领域尝试。也就是所谓的“专项”。
3～5年：有点像读研一样，在一个领域（专项）上，了解前沿，有自己的解决方案并拿到成果。
5～8年：有点像读博一样，可以在这个领域更加精通，也可以了解多个方向。
我认为比较好的状态还是在1～3年强化实践，3～5年完成价值转换。在后面的阶段不断重复“认知-实践-价值-客户”。在工作中也会出现两种不太利于成长的状态：a. 1～3年不断提升认知但没有实践。新同学执着于学习但眼高于顶，导致对现有细节不了解，无法找到合适的切入点，从而团队融入感较差。b. 8年以上不断重复实践，没有提升认知。不能持续学习和与时俱进，导致竞争力下降。
这些年我在成长上也走了很多弯路，但有一个过程是我回想起来，确实是个人成长和提升的案例，就是飞云平台 的搭建。
认知：测试开发的职责不止是业务保障，团队效能的提升不只是提升测试过程。
实践：发现研发过程主要卡点，并通过学习搭建平台工具解决。
价值：引发团队工作习惯变化，缩短日志排查和数据构造、订正周期。
客户：对外拓展，向更多团队推广，并持续维护。
成长的路径是这4个状态的循环。通过不断走完一个一个的周期，来实现能力的提升。从职业生涯上看，每个状态可以是几年、几个月。同时类似于“分形学”理论，在每个状态里面也是多个循环的叠加。甚至我们做每一件事，也可以用这样的思路进行套用。
成长的标准
我从开始工作以来，感觉就没有停下学习的脚步，一个是因为工作需要、一个是因为总想进步。但也常常迷茫，是否学习了就是成长？成长的标准是什么。有一段时间我在思考，是不是有一个比较明确的度量标准，来衡量自己是否在进步。像身高一样，又或者像热血动漫里面的“战斗力值”。这样，我可以很清楚的回答自己，也可以给团队同学一个客观的评价。如果没有明确的标准，甚至“揠苗助长”都没有方向。
刚来阿里的时候跟很多同学一样，我觉得“晋升”就是对成长很好的度量方式，所以我在阿里的前几年是“面向晋升的成长”。就拿测试开发这个岗位来说，每个层级都有着清晰的JD标准和关键字，比如 P6独当一面，P7一杆到底、又比如“点、线、面”。我的看法是，p6需要有“高质量交付的能力”、p7需要有“体系化解决问题的能力”，P8需要有“顶层设计的能力”。
成长是晋升的既不充分也不必要条件。我在阿里参与过几次晋升，每一次都与众不同、刻骨铭心。有从3.25到3.75然后晋升的“咸鱼大翻身”，也有两年内晋升两次的“运气爆棚”。结合我的经验，我认为成长是晋升的既不充分也不必要条件。首先成长了不一定晋升，职级是一个阶梯状分布的（阶跃的），成长是日积月累的（连续的）。我们可能每天都在进步，但不可能每天都在晋升。所以我们不能用“没有晋升”来否认自己在进步。晋升的周期是相对漫长的，如果总是盯着晋升来激励自己，中途可能会泄气。其次晋升了不一定成长，晋升其实是组织和个人的双向选择。在变化和调整频繁的当下，可能是曾经你的部分能力和产出正好被放大，从而到了新的层级。如果总是用晋升了就是成长了来安慰自己，反而会导致无法在新的层级站稳。（事实上每次晋升完，我都会迷茫一段时间，就有点像爬楼梯后的短时间缺氧。）
回到当下，我认为成长的标准就是“做了之前做不了的事”。方式就是“每次都尽可能做到最好”。虽然成长是连续的，但是从微分的角度来看，做好手头的每一件事，每一件事都比之前做的更好，就是成长了。基于这样的标准，感觉就成了每天反思一下“今天是否做了超自己能力的高质量交付”（浓浓的pua味，但以我目前的认知 确实如此）。
成长的矛盾
在工作的某一段时间，我认为（相信还有很多同学有同感） 个人成长最大的矛盾是主管。主要有两个原因，主管没有给我时间成长，主管没有给我机会成长。
在阿里的这几年，好像业务压力就没有小过，相信每一个互联网从业人员都感同身受。这个行业就是这样，需要快速的发展和迭代，以适应用户的诉求和占据竞争的优势。所以无论是我还是我团队的同学，经常会陷入一个困恼：业务压力太大，每天疲于业务支撑，觉得自己没有成长。但现在想一下，成长最快的那段时间反而是最忙、团队基建最差的那个阶段。所以有的时候，我会想：是不是真的空闲下来了，就可以主动成长了？以我对自己的判断，空闲下来后，我并不会主动寻找成长的方向，或者可能成长会变慢。理想败于懒惰，所以最适合我的成长方式还是压力下的被迫成长。面对业务压力，测试开发同学容易陷入“点、点、点”的循环；但其实这是一种“用四肢的勤劳弥补思维的懒惰”表现。就像执着于写crud的业务开发，不如想一下如何可拓展，来降低后续开发成本。我觉得测试点也是可以用来设计的，保障手段也是可以不断整合的。对用例的分层，抓住主干和核心链路，使用更加自动的方式来取代重复执行。突破了一个一个的困局，也就成长了。
每个季度，跟团队同学对接OKR的时候，我会说我们要做XXXXX，有些时候同学会面露难色。我也理解，因为这些年当我听到我的目标的时候也有同感。一者因为目标比较难实现，二者这个目标似乎和我的成长方向不匹配。当我们把成长和机会挂钩的时候，主管就站在了对立面。每个主管都至少有两件事：对上“完成业务目标”，对下“成就他人”。但往往这两件事并不能很好的契合，所以就出现了矛盾，这个很考验主管的统筹能力（尴尬，事实上这件事确实很难）。而当这两件事出现矛盾的时候，相信大家也可以理解主管会优先保障“完成业务目标”。结合前几年做一线，这几年做主管，我也经常会反思，在成长上主管可以给的帮助是什么？我的结论是“平台和视野”。如果主管给的方向和自己想成长的方向是匹配的，那是很幸运的。如果不一样，我觉得可以优先满足工作需要，然后用剩余时间完成自己感兴趣的方向。在有了demo后，让主管帮忙推广产生价值和用户。所以主管可以结合当前的业务和团队的平台，帮忙将我们的想法和实践成为有影响力的产品，以及给予一些方向性的意见。前些年做 Xlog感觉就是这样诞生的。自己寻找到一个团队效能卡点，然后加班加点的做完demo，听从多个老板的意见，并在帮忙的推动下产生影响力。然后实现自己在认知->客户的成长循环。所以我认为，机会更多来自于自己，只有自己更清楚自己工作中的痛点是什么，而这个痛点就是提升的机会。
成长是自己的事，而成长最大的矛盾是懒惰。随着工作经验的积累，主管会把更多的自由度给到个人。因为他们相信我们可以完成工作，过多的干预只会引起不信任。而这个时候，就会发现成长最大的矛盾其实是懒惰。如何克服懒惰，不放弃思考、不放弃奔跑可能才是我们要时刻提醒自己的。（此处多为自勉，无pua之意，“懒惰”也是一种生活态度，无关对错。）
成长的课题很大，与其迷茫于这个目标，不如单纯的脚踏实地。愿后续的时间里，可以克服惰性，识别阶段，时刻自省。继续“不负韶光！”。
《研发效能》
现在的背景下，研发效能几乎成了每个团队都绕不开的课题。刚来阿里的前三年，我的核心专项就是研发效能。研发效能不是一个很新的课题，但从测试开发的视角上解决研发效能问题，就是一个比较新的课题。这些年我看了很多关于效能的文章，也思考了很多，一个重要的观点就是“在整个研发周期的视角上做效能”（这里的整个研发周期，包括需求评审、系分、开发、测分、测试、回归、灰度、上线、运维等），或者说的直白一点就是“跳出测试做效能”。
以我们自己团队为例，我们团队的开发测试人数比是5:1(这个比例会因业务特点和阶段而异)，在每个版本的开发测试周期比7:3；所以基本上可以理解为开发测试的工作量比为：(7*5) : (3*1) = 35:3。因此无论如何解决测试的效率，在大团队看来，其意义都不会超过10%。如果真的想大幅度提升效率，就要解决全流程的问题，而不是测试内部的效率问题。“测试左移和测试右移”是非常好的指导思想，但在不同发展阶段的团队，可以左右移动的程度是不同的。即便是非常成熟的技术团队，通过这样的方式来进行的周期压缩也是有极限的，而这个极限就是对线上问题的容忍度。
我刚开始做研发效能，觉得是一个很虚的概念，其主要原因是成果很难度量，甚至一度觉得“效能做得好就是把自己作做没”。其实研发效能也是有的定义的：持续交付价值的能力，也就是要做好三件事“可持续”、“有价值”，“高能力”。下图是关于研发效能的整体思考。
有价值
做效能首先要考虑清楚价值是什么，如何度量，是否性价比足够高。度量“效能”价值最容易量化的指标就是“时间”。所以效能就是更快的给客户提供价值。从我们自己的业务场景上看，客户关注的两个指标“快速的业务上线”和“持续的线上稳定”（这两个指标应该是绝大多数的互联网产品所追求的）。因此我认为，有价值的研发效能应该最终体现在两个指标上“线下的需求交付速度”和“线上的故障止血速度”。每当我制定某个效能相关的OKR，都会用这两个指标作为核心价值，以及作为ROI推演的重要依据。
虽然这两个指标的都是从时间角度上进行分析的，但其量纲不应该相同。通常情况下我们会用“人日”来衡量研发效能的成果。“人日”是偏向经营管理者视角的价值，而非业务视角的价值。用管理者视角去考虑就需要回答两个问题：a. 节省的人日成本是否远大于投入的成本（投资回报率） b. 当下是否还有“投资回报率高”的工作。所以，我建议做效能还是要克制，因为大部分情况下我们会发现“这个工具一年内的回报成本和投入成本基本相同”。如果是这样的，沉下心来做本职工作，只有躬身入局，才能知道哪里是流程上最频繁执行和最痛的卡点。也只有在工作主流程上，或者很多人都在执行的普遍链路上的效能提升，才是可以反应到“需求交付效率”上的提升。因此，我觉得更高层次的线下效能度量标准还是“需求吞吐率”和“单位价值的研发周期”。而在线上，是分秒必争的，这里就是“客户普遍执行的链路”。因此针对线上止血的效率提升，应该是在XXXX场景，从原来的10分钟优化到3分钟。在线上的效能提升就不会按照人日和投入产出成本来衡量，而是要看故障影响面，缩短时间以及发生概率来评估其成果。
想明白了价值方向和价值度量，就可以识别出团队的效能需要做哪些事，以及如何去有策略的进行展开。下图是2020年客如云技术部在研发效能上识别出来的卡点和针对行治理方案。以及如何将这些方案作用在研发效能价值的两个方向。是否“有价值”是做效能的出发点，同时也为两外两个特性提供输入。为可持续提供数据输入，为有能力提供需求输入。
可持续
之前听过阿里云研发效能团队的一个分享，对“可持续”有一个很现实的案例。“通过临时突击加班换来的需求吞吐率提升不能算为研发效能的提升”。可持续所描述的就是，一个团队长期的作战能力，是一个需要滚动优化的指标。“研发过程质量”可以作为持续优化的度量标准。这件事情，确实是利人利己；在这几年我们技术团队的过程质量有明显的提升，测试开发同学的工作心情都有了显著好转。
过程质量最大的难点在于，如何制定一个大家信服并愿意遵守的规则和标准。而我的答案也很简答，就是寻求老板的帮助，有幸的是，在这几年碰到的开发TL都有着比较高的质量意识，积极配合我们开展工作。过程质量是自上而下的，如果遇到阻力，可以使用“权威”（请开发老板来帮忙横向拉通）和“社会认同”（让配合度高的TL参与进来，感染其他团队）两种策略来解决。明确了标准后，我们团队做了三步：a. 指标度量口径宣讲和公示基线(维护指标权威和认可度)。b. 红黑排行，推动最后几名进入达标线(利用面子意识，快速拉高水位)。c. 月度小红旗，表彰优秀团队(利用好胜心，持续牵引不腐化)。有一段时间我在想测试开发在过程质量这里面到底起了什么样的作用？后来我发现，过程质量的内涵不是达成指标还是“职业素养”培养。所以测试开发在这里面更多的还是通过一些手段和方法，牵引大团队在质量意识和职业素养上不断提升。
这些年做过程质量也走过一些弯路，其中我觉得最具代表性的就是“过度度量”。在内网上关于过程质量的度量指标有很多，稍微梳理一下就有几十个。最开始的时候，我们基本上统计了可以拿到的所有数据，绘制成了一个大盘。但最后，真正落实下来的只有一个指标：千行代码缺陷率。事后我也进行了反思，为什么多维数据的效果反而不如关键有效的数据：a. “破窗效应”，一个团队如果绝大多数指标都没有达标，那么就会选择摆烂，从而失去完成目标的动力。b. “上有政策、下有对策”，指标过多很难一下子满足，会出现虚假的数据，从而导致指标失去权威。c. “舍本逐末”，大家无法发现指标背后带来关联业务价值，降低任务优先级。其实每个团队所处的阶段不同，其追求的目标应该有所差异。面向当前团队痛点和研发效能的目标才是圈选考核指标的方式。下图是2023年，客如云技术团队在过程质量上选取的几个指标和达成效果。（比较有争议的是，我们没有去考察单元测试覆盖率和有效性；因为我觉得单测对职业素养的要求会更高，下一个阶段也许是不错的选择）
高能力
研发效能最终表现的是一种能力，无论是需求吞吐的还是线上恢复的。能力的提升主要靠两种手段：1. 熟能生巧 2. 科技生产力。举个例子，小的时候看过一个电视节目《状元360》，里面有一期是讲数钱的。一方是有多年会计经验的“卖油翁”，一方是有加载最新科技的验钞机；在多轮较量中互有胜负。在完成目标的效果上，熟练和科技没有什么差异。主要的不同点在于“能力复制成本”。一个资深的会计需要几十年的积累，但是学会使用一台验钞机可能只需要一天。因此一个团队的研发效能提升，往往是一个技术创新带来的变革。而这也就是测试开发所谓“效能工具”的出发点。
这些年了解过很多效能工具的设计思想，在这方面确实要佩服阿里测试开发同学的想象力和实践能力。我自己也做过一些尝试。很遗憾，我没有一款“仰望星空”的产品，反倒是“脚踏实地”的工具反响不错（这里的仰望星空指的是很有创造力的产品，脚踏实地指的是手动到自动的简单封装）。因此以我目前的认知：性价比最高的效能工具是面向有效价值的流程沉淀。就是从手动->半自动->自动的一个过程。比如说：a. 从登陆机器查询日志，到日志的集中采集和一站式查询。b. 全链路的数据库排查异常数据，到一站式的订单过程展示。c. 手动回归用例，到自动化回归。效能工具的一大误区在于“脱离业务做工具”，失去业务导向直接的后果就是应用方不明确，从而累计的效果也不明显。因此效能工具应该是自下而上的。也就是需要在工作中，不断发现卡点和可优化的点，进行针对性优化。只有面向的群体大，使用的频率高最终效果才大。
在工作中常遇到的卡点，也是影响技术团队的效能的几个关键性成本：反复成本、重复成本、合作成本。如果你发现一件事总是反反复复（比如提测总是不过，总是需要反复几次）；如果你发现一件事你总是重复执行（比如说构造一个订单、排查一类问题）；如果你发现在合作中总是因为一类问题频繁沟通（比如id转换，关联业务排查）；那这也许就是可以优化的方向。
前些年做效能工具的成就感来自于“从无到有”实现了某个功能的个人喜悦，这些年成就感来源于产生价值和他人依赖。就如“个人成长”篇所提到的。重复“实践”并不是成长，“价值->客户”才是一个成长层次的终点。近几年，看到了越来越多的效能工具走向了不在维护和下线，心中也越发感慨。我坚信，每一个工具的作者都视如己出，希望可以持续维护，但业务价值和广泛依赖可能才是持续运行下去的驱动力。看过南门大佬的文章，“把复杂留给自己，把简单留给别人”，所说的大概如此，只有使用者认可工具带来的福利，工具才能长期走下去。
研发效能是一个持续性的课题，道阻且长。“我很庆幸当时决定离开自己的村庄，低头攀登一座座高山。我有时也会抬头仰望，期盼一个一飞冲天的变革，带领我们走向新的世界”。虽然我选择“脚踏实地”，但我坚信终会有一个“仰望星空”的产品引发效能的革命。
《稳定性》
想必每一个从事稳定性的同学对2023年10月、11月都会有印象。“语雀崩了”，“淘宝崩了”，“钉钉崩了”，“闲鱼崩了”，“夸克崩了”，“阿里云崩了”，“b站崩了”，“淘宝又崩了”，“支付宝会员崩了”，“爱奇艺崩了”，“崩了崩了我也崩了”；这个就是11月份微博热搜上关于互联网产品的主要报道了。这些信息的背后，其实一定程度上反映了稳定性对一款产品的重要性，用户是敏锐的，尤其是我们做toB业务的。我也是最近一年才开始负责团队的稳定性的，其实测试开发负责稳定性还是一个不错的方向，a. 质量和稳定性有比较高的关联性 b. 质量团队是横向团队，没有评估意识 c. 测试开发会做很多预案，可以用在线上应急 d. 质量团队可以产出面向业务的价值。但测试开发做稳定性挑战也很大，a. 线上代码并不是测试开发写的和维护的 b. 线上变更的权限不全 c. 专业度和权威的建立难。
这一年做稳定性，感触很多。一者是真的难，有太多的不确定性在里面。真的是如履薄冰，与其他的OKR目标不同，稳定性不到财年的最后一刻都不能算完成，而其他的目标可以循序渐进，一点点实现既定目标。再者是很欣慰，团队的开发和测试都很配合。有的时候应急脾气比较暴躁，大家也是包容和体谅；也没有挑战我的安排，都按部就班的去执行。压力山大的同时，我也看到了一双双在支撑着我的手。对于稳定性，我的认知是浅显的，这一年我在思考两件事：“稳定性的重点”，“稳定性的度量”。
运气与文化
《深入理解分布式缓存：原理与实践》中提到分布式的初衷就是使用一堆不太稳定的廉价机器，突破单台机器的性能极限。可见不稳定其实是分布式系统固有的缺陷，也因此才有了后来的CAP、BASE等理论。解决这些不稳定的手段就是使用更加稳定的机器、多活、主备等；而这些手段基本上都是需要用“钱堆起来”。近一段时间的重大故障，归根到底其实有一大部分都是配置降低导致的；如果都有planB，业容灾能力将会极大的提升。每个团队都需要在稳定性和成本之间找到一个平衡，寻找平衡的过程就是一个刀口舔血的过程，所以稳定性某种程度上讲是跟运气相关的。
既然是靠运气，那稳定性还要做什么？稳定性我们可以做的其实是一种文化。“稳定性第一优先级”，是很多人都听过的口号，这其实也是一种文化建设。在参与了我们团队几年的故障复盘后，我发现60%左右的问题是人为导致并且可以避免的。稳定性面前其实不存在技术上的瓶颈，难的是持之以恒的决心和永不松懈态度。这一年，在主管和开发TL的支持下，我们做了几件事：
1.高保群：报警分层（快速解决噪声大，主动发现率低和相应慢的问题）。每个业务模块创建高保群，高保群报警每天次数小于3，每条报警1min响应并群中回复原因和后续action。经过一周左右的时间就可以完成报警的降噪和心智的培养。
2.发布群：变更监督（解决不规范变更，和上下游变更通知不全的问题）。在大团队统一发布群，变更将时间、原因、影响面、灰度时间、发布时间、关注人等报备出来。在全局关注的情况下，减少误操作和红线行为。
3.系统owner群：风险周知（同步一些隐藏机制和风险，减少相同错误重复发生）。推行应用保障方案，同步集团重大故障原因，中间件抖动。
4.大促值班群：高度重视（同步大促各系统和业务状态），节假日的值班容易产生惰性，需要定时发送状态来互相提醒和陪伴。
测试开发做稳定性，更多的还是文化建设。庆幸的是主管可以支持并积极参，甚至在群中帮忙at同学；庆幸的是研发TL高度配合，甚至第一时间作出反映；庆幸的是每个开发、测试同学都愿意时刻警惕，甚至牺牲假期。而很多时候测试同学所需要的“开发认可的专业度和权威”，不止来自于扎实的实力信赖，也来自于艰辛付出的感动。
以我目前的认知，做稳定性即需要拼运气，也需要造文化。“尽人事，听天命”，一个是增加对故障事件的兜底行为、一个是降低故障事件发生的概率。这大概就是测试开发做稳定性的重点。
薛定谔的稳定性
稳定性的价值毋庸置疑，但“做稳定性这件事的价值”几度让我陷入迷茫。如果线上一直很稳定，没有故障发生，那如何证明做稳定性这件事的价值，是不是不投入也可以如此。那如果线上出了故障，证明稳定性没有做好，又如何证明其价值。“薛定谔的稳定性”，到底应不应该“打开这个箱子”？我想这个问题的本质还是“稳定性度量”的问题。
常规的稳定性度量是事后的，如SLA、故障数、资损数值。只有知道了这个财年不可用时间之后，才能知道全年SLA是多少。而在过程中没有度量手段，导致迷茫。因此稳定性是否有一个面向过程的度量手段，去指导优化？我们目前还在该方向探索。可以分享几个思路：
- 理论SLA：相信很多团队的SLA目标是拍着胸脯承诺的，也是拍着脑袋决定的😅；SLA 4个9 应该是一个行业标准和稳定性级别，作为目标对于很多团队来说过于理想（不排除一些成熟度很高的团队）。因为SLA是有一个理论值的，这个理论值是可以一层一层算出来的。把这个SLA认为是故障不出现的概率(一年内可使用的时间/总时间，也就是一年内故障不出现的概率)，举几个例子：
而如果有备用方案或者双活机制的，则不应该完全受依赖系统的可用率影响，而是看执行预案所需时间对应的高可用演算值。比如 执行A通道切换B通道的时间是5分钟，A通道的SLA是99.995%99.995%，那么在有主备的情况下可用率是
所以，一个业务上，所有系统的理论SLA都是可以计算出来的。一个业务场景(比如说下单)，它的SLA应该是链路上所有应用的SLA最小值（取短板）。事实上，按照理论如下算法，很多业务链路的不到99.9%99.9%。
- 资损敞口：资损和可用率一样，不到财年底并不清楚今年资损了多少金额，资金平衡的程度到了什么阶段。我们团队的资损OKR已经连续两年是0资损了，并且都做到了，但滞后的度量总让我觉得是一种“薛定谔行为”。其实一个业务的资损敞口我认为也是可以计算的：
将团队中的所有和资损相关的核对规则梳理出来，然后每一条规则通过每天的报警次数乘该场景的平均金额最后除以规则采样率来算出，这个规则的资损敞口。
讲道理这个值可以反映团队的资损情况，其中报警数反映了对核对报警的噪音情况，采样率反映的是核对的成熟化程度。我觉得在核对方面，做多不难，做少反而比较难。拿我们团队为例，核对规则越来越多，但大家的关注力度却没有增加。持续维护规则的有效性和用更小的采样率达到相同的精细度才是核对的挑战。
- 全域依赖系数：依赖治理是稳定性的重要课题，但治理的速度甚至没有腐化的速度快。以至于依赖治理这个项目一直处于“按下葫芦，起了瓢”的状态，也很难度量专项在完成进度和水平。于是我们从鹰眼实时采集数据，做了如下的全域依赖关系图。每个节点是一个应用，每一条连线是有方向的，箭头方向表示依赖方向，线也是有权重的，权重就是qps。于是就得到了下面这样，有向加权图。图中线越多，说明依赖关系越复杂；线的权重越大，说明依赖关系就越强。于是我们可以用一下的表达式来计算全域依赖系数：
计算出全域所有应用对外依赖的权重和，与当日订单的订单量比值。如果这个值在下降，说明整体依赖在变弱。常用的手段如：解耦不必要依赖(减少e数量)，使用近端缓存(降低e的值)都是可以降低整体全域依赖系数的。
以上几个稳定性度量的指标都是连续的、事前的；通过这样的指标可以牵引团队逐渐走向更加稳定。现在“也许我们不用打开盒子就知道猫的状态了”。每个团队根据各自的阶段会有各式各样的指标来呈现过程的稳定性，甚至使用一套计算标准也很难用绝对值的大小来进行横向的比较。而测试开发可以做的，就是持续推进这些指标的优化，直到“稳定性和成本平衡”的那个点。
稳定性的历史上出现过非常多的耀眼方案，容灾、多活等等；这些能力为我们底层的基础组建提供了强有力的保障。测试开发做的稳定性更多的还是在业务层面，用更少的资源提供更高的保障；需要的不是“核弹”级别的武器，而是以少胜多的策略。曾经我也带着技术人的追求，想过要建立无懈可击的防御；而到现在，我反到相信点滴的进步和细枝末节的优化。甚至我希望我的团队和对口的技术团队在稳定性的态度上，也可以如此。“人之所以变强大，不是守着自尊心，而是抛下自尊心的时候”。希望有一天我可以自信的写下SLA 4个9和0资损。
《团队管理》
这几年，承蒙几个主管的信任，我的团队规模一直在变大，从参加基养班的时候2个人到50人，用了不到2年时间。相比于内心的成就感，压力大才是最真切的体会。而压力的主要来源是：认知层面的匮乏。所以在这里，我能记录下来的不是管理的经验，而是认知层面的变化。辅导->协调->成就(动词)。
在团队规模小于10个人的时候，我认为核心的工作是辅导。告诉同学测试是“测”和“试”。测就是要客观的反馈当前系统和团队的状态，真实的表达和呈现。“试”就是走常规的和不常规的路径，完成对系统的分支验证。那时我的认知是，更好的完成主管分配的任务。
在团队规模小于30人的时候，我认为核心的工作是协调。测试开发的30人对口的开发团队已经有200人左右了。在业务中心变动和需求紧急度调整的时候，可以协调好团队的分配，更好的支撑业务的发展了落地。那时我的认知是，产生1+1>2的合力。
在团队规模在50人左右的时候，我认为核心的工作是成就，成就团队和成就他人。
成就团队
“诚惶诚恐”应该是我刚接手这个团队的时候，最真实的感受了。而这本质的原因，应该是从原来汇报给测试老板转变成汇报给开发老板了。这里面的区别是，原来需要证明一件事有价值，现在需要证明一个团队有价值。难的并不是开发老板不理解测试开发的价值，而是作为测试leader需要在意识上进行转变，“从养自己到养团队”了。
我当下认为，测试开发团队的价值层次分为三层。功能保障->团队价值->业务价值。功能保障主要包括：功能测试、自动化、压测、核对等。团队价值包括：赋能团队、技术、产品、运营等，提升团队影响力、认同感、效率。业务：提升产品力，用户体验等。其中功能保障应该是测试开发传统意义上的本质工作，绝大多数同学都是擅长和清晰的。“团队价值”反映的是测试团队和研发团队在合作模式的问题，说的直白一点是“寄生”还是“共生”。我见过很多团队的合作模式更像研发附属品，在技术方案和线上应急等没有话语权，这样的测试团队产出我感觉有点类似于寄生在研发团队的价值产出；也是测试开发团队相对初级的一种形式存在。测试团队的话语权来自于对技术团队赋能的效果，就如研发效能章节所说，如果在研发过程中有很多能力是测试团队提供的，那必然会产生信赖。“业务价值”反映的是测试团队在业务上的助力，业务的售卖中，到底有多少因为测试团队而不同。比如说对用户体验的坚守，使用合理和有效的度量指标牵引产品力提升。比如，通过建立答疑和问题处理能力，来缩短客户问题解决周期。
成就团队的主要体现就是让团队在进步和发展，就是跟随业务的发展和技术团队的成熟度，不断调整三个价值层次的占比。
成就他人
每次进行团队盘点，或者新财年规划的时候，我都会告诉自己：“让每个同学在这里可以开心、有收获的工作”。但一到中期，就会发现“事与愿违”。这件事有点像填数独，要把合适的同学放在合适的位置（既要考虑兴趣、又要考虑能力）。相比于填数独还有一些难度，数独是可以改的、不断的回溯来寻找答案，但工作分配的修改成本很大。一旦改变，影响的不仅仅是项目进度、也影响同学们的信心和耐心。
我现在的想法是，从“给事找人”到“给人找事”。每个同学按照成长的路径所说的，应该属于 认知->实践->价值->客户 重的某一个阶段。通过这个财年完成某一件事来实现阶段的突破。
已经完成价值体现或者客户价值输出的，需要换一个更大影响力和挑战性的任务和工作。
还在实践提升熟练度阶段的，需要继续在当前岗位积累和沉淀，逐渐从量变到质变。
已经实践出成果的，需要帮忙推动分享和影响力打造，让更多的客户了解和使用起来。
所以只需要调整那些已经到了新的循环的同学，给予更大的责任和要求即可。而其他同学则需要不断指导和给予支持。我希望每一个团队同学在阿里都至少做成一件事，也就是走过至少一个成长路径。而所谓的成就他人，也就是从旁观者的角度推动这个过程。
还记得刚接手现在团队跟大家说的话，“让我们做更好的团队，也做更好的自己”。以我目前的认知，技术TL的悲哀是纯管理；所以管理的难点在于 成就团队、成就他人的同时，没有忘记成就自己。
岗位发展
我经常会想“测试开发岗位”的核心竞争力是什么。结合我这几年的经历，我觉得我越来越做的不是测试开发做的事(手动测试变少了)，但也觉得越来做的是测试开发做的事了(与团队质量和稳定性相关变多了)。而其本质思考就是：测试团队终究是一个成本部门，还是要面向团队和业务寻找立足点。在技术团队中会有很多适合测试开发做的工作，而每个节点的优化对线上质量的保障都是有直接或者间接的帮助。如果这个按照这个思路，我认为测试开发这个岗位是有竞争力的，像一个游击团队，是不是有更强更快的适配能力和发现解决问题的能力就成为了关键。“牛逼的测试啥都懂”，可能所表达的就是这个意思。
“妄谈终局”，我认为在接下来的一段时间，测试岗位的竞争力应该体现在以下几个方面：
1.业务质量，可以深耕业务，测试对业务的理解深入度要求很高。有多年某个业务领域的测试经验，可以快速识别漏洞和风险。
2.测试中台，支撑多条业务线的质量保障和效能提升。如自动化、过程度量、监控、应急能力等。
3.效率工程，从整个过程提升效率的能力，可以让团队吞吐率大幅提升。如google的多套灰度的能力等。
所以，我希望团队的同学以及我自己，可以几个方向上不断的提升，来提升所谓的“竞争力”。
我在阿里的生涯还在继续，从事测试开发这个工作也将会继续。希望再过几年，看到这篇文章，会有新的认知，感觉到文章观点的稚嫩；以及感叹一声“年轻真好”！
来源｜阿里云开发者公众号
作者｜御田
