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