作者 | 蒋帆
“摩尔定律”的暂时终结与《性能之巅》的复活
《性能之巅（第二版）Systems Performance: Enterprise and the Cloud》中文版在去年重装上市，作为一本砖头书，辗转于Solaris、Netflix、Intel的性能分析专家 Brandon Gregg 带来了许多基于最新实践经验的性能检测方法和工具使用建议。
与此同时，这次发布的第二版还引入了Linux社区在eBPF等可观测性技术迭代下的最新进展，我们可以看到在追求无尽的算力增长的态势随着制程工艺和产能的艰难爬升逐渐遇到了瓶颈，过去两年贪婪地享受着逐年翻倍的晶体管数与总线速率以及廉价能源的程序员们终于意识到了可（内）持（卷）续发展的必然性，开始更多地站在计算机体系结构的视角看待我们的架构设计、算法、数据架构，观察其是否充分利用好了底层的能力和资源。
开发者“都应该”知道的延时数字
https://colin-scott.github.io/personal_website/research/interactive_latency.html
从性能分析的黄金60秒到“持续性能看护”工程
与其他非功能性需求（譬如安全）不同，性能分析的契机，除了来自成本中心对硬件开销的警告，可能也因为其常常影响到用户体验，而遭到用户的投诉，尤其是突如其来的性能劣化降级，常常是伴随着大量用户增长的喜悦中的梦魇。
Brandon在Netflix期间，一直在负责性能问题处理的工作，因此他总结了一些自己在工作中提升效率的常见手段，其中“黄金60秒”就代表了他在观察各级别系统性能指标的核心步骤。
从平均负载、到上下文切换频率、再到IO、网络性能指标，黄金60秒所涵盖的系统性能指标实际上表达了工作负载的近期利用率，当出现资源瓶颈时，往往会引发性能降级甚至雪崩性的问题。
但是这样的分析方式，往往需要依赖大量的专家经验，以及运维人员对系统设计的熟知程度，尽管我们认为DevOps应该具有对系统架构的深刻认识，但是这在很多企业仍然是一种较为困难的场景，7x24小时运维团队并非对开发者所熟知的系统架构那么熟悉，而性能调优更需要对细致的软件运作原理有较为深刻的认识，这对于需要保证系统稳定运行的运维团队来说，无疑增加了负担，因此我们也看到性能优化常常作为一种非功能性的需求，经由生产环境的用户反馈或是在运维团队的降本增效会议中被强调，这也非常有意思地体现出性能相关责任的边界模糊特点。
在一些客户场景下，我们也看到另一个方向的探索，我们可以称之为“持续性能看护”，这项活动常常与另一个更抽象的概念“架构守护”有着异曲同工的执行形式。性能数据的量化指标，成为每个产品在研发测试各环节的关键门槛，它就像测试覆盖率、测试bug报告单，被内建到了开发者熟悉的环节，这有些类似过去我们在谈论软件质量问题时，常常提到的“质量左移”、“在持续集成中加入UT如何帮助质量提升”。
持续地使用高强度的压测用例对产品进行性能方面的数据标定，可以帮助开发团队时刻了解产品的资源使用情况，这种方式，既可以对后续产品演进的架构方向提出要求和规约，也可以为硬件采购计划提供量化指标支撑。
作为一种新形式的性能优化工程实践，我们建议每个企业都可以考虑构建自己的性能指标库，并持续跟踪研发环节产品各版本的性能趋势，这可以大大节约由于过晚进行性能优化，导致的技术回撤甚至影响发布后的用户体验。
性能看护过程，持续对性能劣化问题点进行及时报告
性能优化专家系统的崛起
伴随着硬件资源瓶颈的日益凸显，持续对产品进行性能优化成了继续维持产品生命周期、迭代与发展新品类的一条路径。
我们在一些客户现场，正观察到一个有趣的现象，积累了大量性能优化经验的专家正逐渐成为团队的明星，因为这一知识的积累，需要具备众多技术栈的扎实经验，并且熟知各类可互相替换组件的性能特性与适用场景，尤其是与硬件或嵌入式软件相关的应用场景，性能优化专家也成为了各个产品线争抢的竞争性资源，成为性能专家的路线常常需要常年的学习与总结，需要广阔的视野和深入系统实现细节和算法原理的研究性能力。因此如何更好地协助性能专家服务更多的产品，如何提升性能优化的效率，以及如何把这些知识经验以更低的成本传授给一线的开发团队，便成为了性能优化体系建设过程中的关键问题。
此外，随着对复杂系统认知的不断升级，我们也看到通过知识库积累可以产生一些可以参考的性能分析的方法路径，我们将这些分析方法过程总结成知识图谱，并对新手产生足够的指引，并通过性能可观测性平台，形成更加顺畅的体验。
使用性能分析图谱的方式来积累分析方法与经验
积累性能优化方面的思路，我们也总结了一些分析优化模式，这些经验可以大大加速我们在观察系统整体性能并制定出方案的效率。
6个常见的性能反模式与优化方向
关于性能工程平台流程方法的构建，我们也与一些存储、通信、车载等领域的客户开展了试点项目，通过逐层递进的分析流程，我们看到一个类似IDE的多功能集成环境，它可能包括了我们在前面提到的观测手段与工具，高亮并及时提醒性能劣化的问题点，并提供可参考的优化建议，可能未来会成为性能分析工具的一种常见形式。
使用集成分析环境承载性能分析过程，进行系统性能逐层递进地分析
非功能性系统工程实践的下一阶段
随着功能性需求的长期积累，大量功能堆砌过程中缺乏对非功能性问题的关注和专项设计，导致量变引起质变，最终形成质量和性能差异。越来越多的复杂遗留系统中，性能问题或稳定性问题得以集中暴露。这并非单纯的质量管理缺失所致，而是复杂系统中积累大量业务上下文的结果。这些问题给开发团队带来了许多负担，也为工程实践领域带来了机遇。相信越来越多的复杂系统开发者将会逐渐重视这个领域，形成更优秀的工程方法或工具，帮助我们更好地驾驭复杂系统。
