什么是性能工程？( 二 ) _性能工程

融入性能并不容易
即便是软件性能比以往任何时候都更重要，但想要顺利地把性能融入研发工作流，却并不是件容易的事。
首先，现有的成熟研发流程中，性能往往被忽视。
正如前文提到的，现有研发流程一般只会在测试阶段安排少量性能测试内容，而其他各研发环节都没有对性能形成固定的认识。
设计阶段，架构师通常会基于自身的经验和知识，进行一定程度的性能考量，但大都不会输出完整的性能建模方案和验证方法。
开发阶段，程序员也是在完成业务开发之余，零散的写一些性能相关的代码，且不太可能提供完整的性能测试用例。
测试阶段，虽然有性能测试，但是否覆盖了关键性能路径？测试方法是否存在偏颇？也是一笔糊涂账。抓紧测完按时上线永远是第一位。

文章插图

上述流程现状实际上是把性能问题推到了 Day2 。测试阶段发现性能问题已经很迟，而倘若上线后再出性能故障，一定会大动干戈，伤筋动骨，甚至要调整架构。习惯了“性能后置”，想要打破现有流程，引入新的环节，对已经形成思维定式的研发团队实在是很不容易。
其次，性能优化非常依赖专家经验，难以规模化。
性能问题是复杂且多样的，其场景可能介于 Cynifin 框架中 Complicated 和 Complex 之间，需要通过对问题审慎的分析和对系统深入的洞察才有可能找到正确的优化路径。

文章插图

性能优化的实施者不仅需要对被分析系统的整体架构和关键业务路径有清晰的认识，还要掌握系统层面的基础知识和原理，以及各种性能分析工具的使用。此外，为了提升定位问题和寻找优化方向的成功率，性能优化方法和理论以及大量的实践经验也不可或缺。
以上要求对一般的研发人员来说挑战极大，因此实际当中遇到性能问题往往需要依赖性能专家和领域专家的共同努力，但面对多种多样的性能问题，专家资源往往“捉襟见肘”，增加时间成本的同时也难以规模化推进性能改进。
再次，孤立工具给研发人员造成了极高的认知负载。
正因专家资源的稀缺性，性能优化通常会首先由研发人员尝试介入。实施优化的前提是数据收集和问题分析，即便是如今的可观测系统越来越强大，但在进行性能分析和系统剖析时大都还是会依赖外部采集分析工具。
然而，现实是不同的编程语言、技术框架、中间件和操作系统都有自己的一套实用工具，这些工具之间的使用存在差异，关注点与数据格式也不尽相同。对各种工具的熟悉和使用存在可观的成本与学习负担，也导致对人员能力的特殊需求。

文章插图
图源：_linux Performance Observability Tools
有过分析性能问题经验的人都知道，选择并使用数种工具，在众多的运行结果中进行数据关联来寻找问题踪迹，是性能分析和优化工作的日常。由于数据缺少关联性，展现形式也不够直观，使得这类分析工作存在巨大的认知负载。对大多数应用开发者来说，这种高认知负载导致了在性能优化工作上的巨大负担。
落地工程化方法——性能工程
基于前面提到的在实施性能优化过程中的问题和挑战，我们期望通过设计、构建工具链和研发工作流，来落地称为 “性能工程” 的工程化方法，以实现标准化和规模化的系统性能持续改善及守护。
为了明确这种工程化方案的内涵以更好的指导工程落地，我们尝试定义性能工程的目标：
DevPerfOps：构建性能工程反馈闭环【什么是性能工程？】
为了改变研发工作流中忽视性能的现状，通过在完整 DevOps 流中引入性能工程改造点，以实现嵌入性能工程的研发工作流反馈闭环。