译者 | 崔皓
大多数组织都在努力改变他们的文化，尽管过程布满靳棘但他们仍在探寻成功的方法。往往他们并不了解自己的系统。
谷歌最近的Accelerate State of DevOps报告发现，超过26%的开发团队被认为是 "精英执行者"。这个数字比2018年的18%有所上升。根据DORA（DevOps研究和评估）指标，精英人才每天执行多次软件部署，发布的准备时间和恢复服务的时间在一小时以内，并将其发布失败率保持在15%以下。
与低绩效者相比，精英绩效者的部署频率高与前者973倍，准备时间快6750倍，部署失败率降低3倍以上。当出现问题时，精英们能够以比低绩效者快6570倍的速度恢复。
在笔者的职业生涯中，曾与不少如此出色的人共事。大多数组织都在努力改变他们的文化，尽管过程布满靳棘但他们仍在探寻成功的方法。往往他们并不了解自己的系统。
知道精英团队具有哪些特质，以及这些特质如何影响生产力是很重要的。上述指标没有告诉我们这些精英团队是如何实现这些成果的，以及如何让较差的团队演变成精英团队的。虽然知道了什么成功，但开发人员和工程经理更希望了解如何做才能提升自己的能力。
对于那些进行流程升级的组织而言，在市场竞争中进行加速创新变得更容易。今天成功的组织建立了高度可观察的系统，并在开发过程中使用这种可观察性来提高整体速度。想想看，测试驱动的开发是立体的。
在这篇文章中，笔者将就成为精英人才的最重要见解描述如下：
1、过程能力：精英们的秘密
笔者在IT职业生涯的早期，是一名实施CMMI（能力成熟度模型集成）的讲师和顾问。在堂课上，有一个相当古怪的工程师，他几乎在每一个话题上都会“硬刚”。
尽管笔者想把他从课上赶出去，但最终决定与他共同授课，并在课堂上分享他的经验。这门课成为笔者最难忘的课程之一，并促进了职业生涯中最有影响力的友谊。那段时间，他们两位经常辩论很长时间，分享彼此的经验，同时给双方不小的思想碰撞。
课程的最后一天，他带来了一本《工业自动化标准手册》的副本。在1986年版的书中，他强调了一句话："测量过程能力"，并加了一个手写的说明，说："这就是你需要知道的一切"。这句话在过去30年中一直是正确的。
表现优异的公司在流程工程方面有很强的文化。流程工程包括设计和实施将原材料——客户需求和软件工程能力--转化为业务产品的流程。精英企业在定义、测量和改进流程方面表现出色。每一项都对过程很重要：好的设计和好的规范定义了应用程序在生产中应有的样子；指标、监控和现在的可观察性有助于衡量实际应用程序与设计之间的差距；利用这种反馈让新的功能或重构代码以改善应用程序。
有一个单一的指标可以用来衡量过程与设计的匹配度，就是过程能力。它是对客户需求（客户的声音）和过程的实际表现（过程的声音）之间差异性进行衡量。它可以表示如下：
规格宽度是规格中定义过程指标的上界（USL）和下界（LSL）之间的差异。过程宽度是指除生产过程外的那个相同的差值。
因此，对于任何指标，都要定义规范的上限和下限，并评估这些指标违反限制的频率。这听起来很熟悉吗？它应该是。看看任何SRE的服务水平指标（Sli）和目标，你会发现错误预算和burndown的想法是源于Cp。另外，因为这个过程的重点是提高流程的质量和效率，这意味着我们应该考虑数据质量和样本集的大小。
我们可以参考控制理论——现代可观察性的基础，来帮助我们设计流程，并指导良好的编码实践来支持这些流程。我们在Cp中测量的指标是根据它们的一致性来评估的，或者说它们在定义的性能走廊（可接受值的范围）内保持得如何。例如，对于一个微服务架构，我们希望黄金信号在我们的性能走廊内是可预测的。
图1.用规格下限和上限表示的公制系列的例子
我们希望API响应时间与客户体验（CX）相关联。如果响应时间到处都是，如果难以辨别调用的速度，那么就不可能知道CX是好是坏。因此，至关重要的是要避免懒惰的编码，如getAll()类型的语句，这类语句会让调用充斥着不可预测的大量数据。相反，可以利用分页来控制结果集，这样做就可以创建一个可预测的API。发现正在进行过多的调用，就可以预先异步获取更多的数据，或者选择改变用户界面，以便通过排队的方式处理大量的请求，并在处理后返回。下次你在设计服务的时候问问自己这些问题。
- 为确保良好的用户体验所需的响应时间是多少？也许API必须在250ms以内响应，或者不超过500ms。
- 哪些上游或下游的依赖性会破坏性能？能克服它们吗？
- 将如何设计代码以表现出确定性的行为？是否有我们可以使用的标准或模式？
- 能否使用断路器或Stack Overflow上讨论的其他设计模式来处理故障状态，而不影响性能？
- 将使用API调用的哪些属性来得出指标，以确保对跟踪的实体进行同类分析和归类？比如分离POST、PUT、DELETE操作，了解哪些属性是导致代码路径选择的原因。
注：用来了解性能的属性越多，就越容易在变化发生时了解与之相关的偏差来源，从而提高Cp。
具有确定性的代码在规定负载下表现出可预测的响应时间。写得好的服务会随着时间和负载的增加而表现出一致的响应曲线。如果负载的增加超过了突破点，我们很可能会看到错误的高峰。
图2.负载增加时响应时间的曲棍球模式的例子
随着时间的推移，指标越平稳，越一致，直到突破点，就等于高Cp。
知道一个过程将可靠地产生指标值，并落在一个狭窄的走廊内（理想情况下，LSL和USL之间不超过两个或三个标准差），有助于计划想要的结果，并有助于更好地自动补救（通过AIOps和MLOps）。随着时间的推移，所做的与构建、测试和装运软件有关的一切，都应该提高Cp、可靠性和预测结果的能力。如果发现自己有大量的技术债务，或者团队因为新的功能需求而不得不宣布解散，那么对抗这种情况并摆脱债务的最好方法就是专注于提高流程能力。
为了提高流程的能力，你将希望在软件开发生命周期中收紧反馈回路。这意味着你要了解客户的声音，并能够持续地测量过程的声音。
以下是一份事情清单，它将帮助你集中精力从债务中挣脱出来。如果你没有深陷债务，它也是很好的预防措施，帮助你避免深陷技术债务。
- 尝试弄垮你的服务。了解你的服务的故障状态对于优化代码和创建基础设施至关重要。有一些客户仅仅通过研究弄垮自己服务的方式，就把服务的工作效率提高了300倍甚至更多。通过这种方式就了解每秒和每个节点的交易峰值吞吐量，以及集群有许多节点（或pod）时的扩展因素。然后再思考，你能优化代码以减少CPU上的时间吗？是否存在线程问题、单子问题或类加载问题导致线程等待？你是否在该使用异步的地方尽量使用异步调用？
- 为编写的API发布模拟。让你的下游生产者也这样做。模拟失败的状态，比如用mock来模拟缓慢的响应或没有响应，而不是依赖下游的系统。你会发现你不需要一个强大的环境来破坏你的服务，或者在做这件事的早期就暴露出许多问题。
- “浸泡”服务。利用断点测试来找到吞吐量的极限点，然后在这个吞吐量的极限点上缩减20%的负载，以这个缩减后的负载为基础，对系统进行长时间的负载测试。经过一段时间的浸泡测试，观察系统的可靠性，如果在此期间发现故障，就想办法解决。
- 识别金丝雀。利用金丝雀测试的这段时间定义几个关键指标，这些指标将准确地推断出服务的健康状况，它们的规格上限和下限是什么？当它们超出限制时，运行手册将是什么？
- 作为CI/CD管道的一部分，自动进行故障测试。不断地对你的代码进行实战测试。
- 使用峰值吞吐量来设定会话数量的上限。在达到这些阈值之前，要扩大规模。如果扩展失败，告诉用户系统忙，无法提供请求服务，这比提供低劣的体验要好得多。
- 对端到端堆栈进行混沌工程。如果x事件了如何处理？作为一个团队形成几个假设，并在锅里扔5美元给赢家。要有创造性，找到弱点并解决它们。在你如何运行你的堆栈中改进方案和理论，并庆祝发现。
- 消除工作队列。寻找所依赖的团队，是否存在的延迟，重组，是否可以采用小组/队的模式--做你必须做的，以尽可能地实现自我服务。分析流程，定义衡量标准，并设定OKRs，以便进行持续改进。
- 追踪做出决定所需的时间。是否需要几周的时间来决定某事？ 这些指标是否被持续测量？
- 找到重复的手工任务，然后将其自动化。减少重复劳作。
对服务测量设定9的数量（例如99.99%），并开始使用误差预算。换句话说，不要依赖平均数。相反，利用最高百分位数（TP）、直方图、以及超出中位数分布和规格限制的次数。把这些变成预算，当错误预算是健康的，就可以继续甚至加速生产。如果预算正在下降或低于可接受的水平，那么是时候放慢脚步，专注于稳定和减少风险。根据需要重构代码以减少异常值并提高可预测性。
Github上有一个伟大的项目，叫做OpenSLO，它通过使用SLOGen生成规则，将服务级别指标（SLI）和目标（SLO）声明为代码。这样做能够利用Terraform来部署SLI和SLO，并生成仪表盘、指标规则和警报阈值。Sumo Logic最近发布了与OpenSLO的完全集成，使客户能够对其服务进行自动化并保持一致的服务级别管理。这样一来，增强了服务部署的可靠性管理，并实现服务部署的自动化，这些动作会使你成为精英。
2、构建可观察的系统（避免事项）
精英人才利用可观察性技术和工具创建紧密的过程反馈循环。他们擅长建立和运营高度可观察的系统。这里使用的 "系统 "是很宽泛的。不仅是被部署的服务，还包括CI/CD管道、遥测管道和自动化的控制平面。此外，构建可观察的系统包括观察管理软件交付的过程和过程所采用的标准。总之，精英们能够以简洁、可靠和可预测的方式在软件开发生命周期中测量事物。他们有意使用最少的指标或数据点（简明）来接近可观察性，这些指标或数据点由一致的、高质量的数据（可靠）产生，最能代表过程的健康状况，并与问题有很强的关联性（可预测）。
为了在构建可观察系统时拥有最大的灵活性，在选择工具链、遥测代理、遥测管线或控制平面时，要寻找完全接受和支持开放标准的组件。开放源码和CNCF工具链在原生互操作性方面非常出色。请记住，CNCF上列出的一些供应商属于支持开放标准的灰色地带，但有专有的闭源代码，如他们收集遥测的代理。在选择专有供应商之前要仔细考虑，看看是否有开源的解决方案可以满足你的要求。没有开源的供应商提供的代理通常产生专有的数据集，只能从供应商的后端平台读取，让数据成为孤岛（供应商独家拥有数据）。这并不理想，因为团队被供应商锁定在独家数据上，而这些数据很难在更大的组织内普及。可观察性中的专有组件历来导致IT部门拥有许多不同的数据孤岛，限制了实体建模、机器学习和企业整体数字化转型的有效性。为了成为精英，企业应该尽其所能从源头上拥有他们的遥测数据，而不是以专有供应商代码的形式租赁。
通过利用像OpenTelemetry这样的开放标准，你永远不必担心供应商改变他们的许可模式，从而严重影响数据的民主化，就像一家APM供应商最近所做的那样。你的选择是，要么向他们支付更多的钱来访问你的数据，要么放弃他们的技术，这样做的话，就需要针对他们平台和自动化的时间重新设定成熟度。这就是为什么精英们选择利用OpenTelemetry，并与像Sumo Logic这样的供应商合作，接受选择与锁定的分析。寻找完全支持开放标准和工具链的供应商，而不是继续投资于或依赖封闭/专有代理或生态系统来收集你的遥测数据。
OpenTelemetry成功的另一个原因是，它是一个高度有主见的开源模式，对数据的存储、聚合或处理方式皆是如此。它简化/标准化了遥测采集，将所有的日志、指标、跟踪和事件统一为一种新型的复合（和高度丰富的）遥测流，并使复杂的处理和转换在采集器管道中发生。这些功能结合在一起，解决了IT领域的许多数据挑战，特别是在商业智能团队中，这些团队历来都在努力获取不可变的实时数据。
采用OpenTelemetry的开发团队受益最大的是拥有轻量级的API和可交互的SDK架构，这意味着不再依赖一个封闭的代理，不用担心技术债务问题。如果OpenTelemetry中需要一个错误或功能，它可以由开发者或行业中的任何人来修复或编写，而不是等待和依赖供应商的工程师组成的小团队。当最近的Log4J漏洞被公布并导致每个专有代理部署的大规模中断时，这一点尤其有利。对于OpenTelemetry来说，这几乎是无痛的。
传统的应用性能监控（APM）和可观察性工具建立在两到三个数据源的支柱上：主要是跟踪和度量，在很多情况下还有有限的日志记录。优秀的团队对他们的系统进行仪表化，将这三种类型的数据排放到一个统一的平台上，以达到最强的可观察性。虽然传统的APM供应商认为，你可以取消其中一个来源，或者严重依赖一个来源，但这三个来源在创建可观察系统方面都有其作用。
虽说传统APM万般好，但存在一个问题，它使团队捕获所有的东西，而不去考虑什么是重要的，主要是因为它不依赖于开发人员的输入。太多的数据获取并不考虑其目的，会导致效率低下。构建系统的目的是通过最有效的输出来可靠地推断内部状态，这就产生了与元数据中必要的丰富性深度相关的遥测数据，以满足设计结果。这导致了一种优化的状态，我们可以在更大的笛卡尔集合中利用更少的指标来驱动SLI，并通过SLO和burndown更有效地运作。
OpenTelemetry让你从四个来源收集数据：日志、指标、追踪和Span事件。
日志，简单的说，就是附加在文本文件或数据库中的带有时间戳的信息和审计跟踪。几十年来，APM供应商一直在淡化对日志的需求，声称专业的跟踪具有更大的价值。他们的论点是，追踪会捕捉到异常日志，而且结合用户会话来诊断追踪比分析一堆日志更容易。现实情况是，我们既需要原始日志，也需要跟踪记录。今天，随着组件的爆炸、堆栈的复杂性、变化率和攻击面的增加，专有代理比以往任何时候都处于不利地位，特别是如果他们的平台在日志聚合方面不健全。统一所有遥测数据意味着很容易从指标跳到相关的跟踪和日志，反之亦然。日志对于审计和合规性以及通过事情的顺序了解根本原因至关重要。如果在其他地方发生的事情间接地影响到一组追踪，怎么办？你仍然需要一个完整的查询语言和日志搜索引擎，以便在许多情况下有效地确定根本原因。与OpenTelemetry相比，专有的追踪工具受限于其专有的数据模型、后端平台，以及大多数简单事实。
指标是关于一个系统的时间序列数据的汇总。如果实施得当，它们是煤矿中的金丝雀：检测偏差最可靠的方法，然后可以在时间范围内和可用的元数据维度上与日志、追踪的ML相关。指标是伟大的，但当它们以统一的方式与日志和追踪相关联时，它们可以发挥巨大的作用。
日志捕捉的是系统运行的时间点，而追踪则是通过所有的组件和时刻来跟踪一个请求。由于度量标准聚集了一个系统所发出的数据，通过OpenTelemetry的跟踪，在整个系统中用跟踪和跨度ID来标记日志，使得搜索以及从跟踪ID返回顺序的日志变得简单。追踪也暴露了实际的代码路径，这对于跟踪依赖链和发现瓶颈或代码路径上的问题。追踪是非常有价值的，通过将追踪日志按其发出的顺序连接起来，使深度系统的日志分析变得平坦，这意味着日志分析仍然是线性的，而不是随着复杂性的增加和云应用的扩展而变得指数化。
OpenTelemerty还增加了第四个数据源。Span事件。从本质上讲，这相当于实现了对深度代码可见性，如堆栈跟踪或其他由框架或开发人员定义的事件。当异常被抛出时，在调用树中提供堆上对象的所有属性作为堆栈跟踪的一部分。这将简化找出那些难以分析的空指针异常，这些异常似乎从未在测试中出现过，但在生产中却困扰着我们。
如果你不熟悉OpenTelemetry，我强烈建议你熟悉它，并参与到工作小组中来，甚至对源代码做出贡献。
成功开发可观察系统的团队表现出以下特点：
- DevSecOps和业务分析是智能的、连续的、不可变的和实时的；数据是统一的和民主化的
- 整个组织使用通用的仪器库；元数据是一致的和声明性的
- 控制平面和遥测管线是一致的和声明性的
- 可观察性被干净地注释，工具化是用面向领域/面向方面的编程完成的。
- 监测健康/性能的指标是陈述性的
- 仪表盘、警报和警报阈值是声明性的，并随每次合并而部署。
- 控制平面根据规则评估输出，并验证金丝雀，扩大/缩小规模，智能回滚，很好地处理0级自动修复问题。
在很多DevOps和DevSecOps的子领域，如GitOps和零信任，精英们的表现都很成熟。价值流管理（VSM）和流量指标作为APM的新框架已经出现，并作为表达企业可靠性的一个集中方式。如果软件系统表现完美，但客户并不满意，那么这个过程并没有产生预期的结果。绘制和观察你的价值流是集中精力的一个好方法。
归根结底，成为一个精英人才意味着对高数据质量的痴迷，并更有效地利用MLOps。把所有这些数据集中（理想情况下），允许ML更有效地运作，并通过暴露这些高标准数据集之间的关系来关联更多的信号。分析在推理和维度分析方面越有效和可靠，对你从故障中恢复的速度的影响就越大。在构建可观察系统时，要强调收集什么数据，如何收集数据，以及为什么收集数据，这样你就可以向IT和业务利益相关者提供高价值的信息和知识。
3、可观察性驱动的开发
目前为止我们所讨论的一切都以这样或那样的方式成为可观察性驱动开发（ODD）基本原理的关键因素。ODD是将所有与可观察性有关的东西向左转移到开发的最早阶段。就像测试驱动开发强调在编写代码之前编写测试用例以提高质量和设计一样，ODD对于构建可观察系统也是如此：开发人员编写代码的目的是为了声明推断系统和流程的内部状态所需的输出和规范限制，无论是在组件层面还是整个系统。
在实践中，ODD也可以成为组织所需的强制功能，以规范用于建立可观察性的仪器框架、SDK和API，或者规范如何实现结构化日志、度量、跟踪和事件，最终满足需要这些数据的许多利益相关者的需求。通过ODD，本文所讨论的可观察性原则被有意和精确地编织到系统的结构中。
图3.用ODD扩展TDD
TDD在测试和设计之间建立了一个反馈回路，而ODD则扩大了反馈回路，确保功能的行为符合预期，改善部署流程，并向规划提供反馈。
我喜欢把ODD看作是一座桥梁，它跨越了历史上削弱了开发人员与生产关系的一条很深的鸿沟。ODD是指为开发人员（和企业）提供必要的工具（和流程），以便与生产环境建立紧密和一致的关系。在这样做的过程中，每个人都是赢家。
然而，ODD的最终目标是达到流程能力的水平，使你可以直接从开发到生产。在生产中进行测试对开发人员有许多好处。
- 业务部门、产品经理和开发人员可以通过假设更快地进行迭代。
- 与非生产环境相比，所产生的数据是最高质量的，非生产环境中的数据往往是假的，被洗过的，或者缺乏对生产的良好表述。
- DevOps团队提高了他们的自动化、向前失败、功能转换和回滚的能力。
- 生产测试将暴露出任何尚不具备能力的过程。
笔者最近采访了一家精品零售商的SRE，该公司在2021年的整个零售旺季都保持正常运营。他们是如何做到这一点的？
- 他们的工程团队可以自由地将代码推送到生产环境，只要他们的合并请求通过所有的检查。
- 服务是用可以被其他团队使用的模拟来编写的，所以各种故障模式可以在开发人员的笔记本电脑上测试，以了解下游的依赖性。
- 他们对管道中的代码进行自动化性能测试（使用过去专门用于暂存和较低环境的计算预算）。
- 这些性能测试做了很多事情，但也许最重要的是，他们一遍又一遍地颠覆他们的服务，在偏差中寻找统计学上相关的信号（想想六西格玛），同时针对新功能的响应时间评估吞吐量和饱和度，这也是对他们SLO的输入。
- 他们每周都会彻底销毁并重建他们的Kubernetes集群，这并不是因为他们必须这样做，而是因为这让他们在恢复过程中保持可靠和自信的能力。
- 他们利用日志和指标来满足所有的自动化需求，并利用追踪来优化客户体验和快速隔离故障域的问题。
- 他们的所有数据都被标记为特征级别。
- 如果他们的SLO预算低于可接受的水平，新功能的发布就会受到限制，变化也仅限于恢复服务水平。
- 他们根据九位数定律进行管理，并依靠百分位数和指数直方图来评估性能数据。
简而言之，他们在进入可观察性驱动开发的过程中，使他们沿途修复了许多流程，最终使他们能够从笔记本和IDE直接到生产中的代码。他们的工程师很少依赖其他团队而耽误工作，他们的管道很强大，在合并到生产之前对新代码做了很好的认证，现在他们每天都要做几百次。通过跟踪他们的数据集的众多维度，他们能够暴露出异常值，并深入了解一段时间内的行为和性能特征。这种高保真度使他们能够迅速发现回归，并在一个小时内恢复正常的操作。可观察性驱动的开发使他们成为精英的执行者。
原文链接：https://stackoverflow.blog/2022/10/12/how-observability-driven-development-creates-elite-performers/
译者介绍：
崔皓，51CTO社区编辑，资深架构师，拥有18年的软件开发和架构经验，10年分布式架构经验。
