绩效考核表模式_现代企业绩效分析反模式

绩效考核表模式

定义绩效分析

“绩效分析”有很多定义，但我认为最有用的定义之一是：

一种测量驱动的方法，用于了解应用程序在负载下的行为。

此定义的优点在于，它引起对测量的关注，这是整个过程的关键，并且通过简单的扩展，还引起对统计和数据分析的关注，因为这对性能工程师而言很重要。

更进一步，它有助于将性能分析定位为一项基本的经验活动，类似于具有输入和输出的实验科学。

然后，可以将这些输出构成具有定量答案的问题，例如：

如果有10个客户，系统是否有足够的内存来应对？

客户从应用程序中看到的平均响应时间是多少？

该分布的其余部分是什么样的？

与我们的竞争对手相比如何？

在这种表述中，这些最佳实践所表达的性能比科学更重要。 从根本上说是定量的，与业务活动有直接关系的活动。

但是，尽管具有这些属性，但在即使是众所周知的最佳实践也落后于从业者实际的状态下，绩效通常会受到影响。

有许多不同的模型可以解释这一点，但是Carey Flichel在精湛的文章“为什么开发人员不断做出错误的技术选择”中提供了一种有趣的可能性。

在帖子中，Carey特别指出了导致开发人员做出错误选择的五个主要原因：

• 无聊
• 恢复（如果您是英国人，则为“简历”）
• 同辈压力
• 缺乏对现有系统的了解
• 误解/不存在的问题

在本文中，我们介绍了企业平台中一些最常见的性能分析反模式，并尝试根据Carey列举的基本原因来表达它们。 导致以下问题的特定示例摘自Java生态系统，但类似的说法适用于许多其他类型的企业系统。

每个基本原因都对应于一些常见的认知偏见。 例如， Boredom和Resume Padding都源自逃避开发人员在日常工作中使用的现有技术的渴望，以及他们对美好明天的渴望。

反模式以下面的样式和格式呈现，应该使人想起“四人帮”，当然也要像Brown等人开创的反模式格式。

反模式目录

分心于闪亮

描述

最新或最酷的技术通常是第一个调整目标

范例注释

即将到来的麻烦-我们需要深入研究

现实

• 这只是黑暗中的一枪
• 开发人员并不真正了解新技术

根本原因

• 无聊
• 恢复填充

讨论区

这种反模式最常见于年轻的团队。 他们渴望证明自己或避免束缚于他们认为的“旧式”系统，因此经常倡导更新的“更热门”技术-巧合的是，这些技术恰恰可以带来薪水的上涨。任何新角色。

因此，对于任何性能问题，合乎逻辑的潜意识结论就是首先要看一下新技术-毕竟，对新技术的理解不正确，所以换一双新的眼睛会有所帮助，对吧？

决议案

• 衡量以确定瓶颈的实际位置
• 确保围绕新组件进行充分的日志记录

分心的简单

描述

首先将系统最简单的部分作为目标

范例注释

让我们从我们了解的部分入手

现实

• 开发人员了解如何调整（仅？）系统的那部分

根本原因

• 缺乏对现有系统的了解

讨论区

这种反模式的双重特征是“分散注意力”，它经常出现在一个更老的，更成熟的团队中，该团队可能更习惯于维护/保持点亮状态。 如果他们的应用程序最近被合并或与较新的技术配对，则团队可能会感到胆怯或不想使用新系统。

在这种情况下，开发人员可能只对系统中那些熟悉的部分进行概要分析，从而希望他们能够实现期望的目标而不会超出其舒适范围，从而可能会感到更自在。

特别值得注意的是，这两个前两个反模式都是由对未知数的React所驱动的。 在“由闪亮的注意力分散”中，这表现为开发人员（或团队）渴望学习更多并获得优势的愿望-本质上是进攻性游戏。 相比之下，“分散注意力”是一种防御React-扮演熟悉的人，而不是使用可能具有威胁性的新技术。

决议案

• 衡量以确定瓶颈的实际位置
• 如果问题不熟悉，请向领域专家寻求帮助

UAT是我的桌面

描述

UAT环境与PROD明显不同

范例注释

完整的UAT环境太昂贵了

现实

• 由环境差异引起的停机几乎总是比其他几箱贵

根本原因

• 误解/不存在的问题

讨论区

UAT是我的Desktop的源于与我们以前所见不同的认知偏见。 这种偏见坚持认为，进行某种类型的UAT一定要比什么都不做要好。 不幸的是，这种希望从根本上误解了企业环境的复杂性。 为了使任何有意义的推断都可行，UAT环境必须像生产一样。

在现代的自适应环境中，运行时子系统将充分利用可用资源。 如果这些与目标部署有很大不同，则它们将在不同的情况下做出不同的决定-使得我们充满希望的推断充其量是徒劳的。

决议案

• 跟踪与客户流失相关的停机成本和机会成本
• 在与PROD相同的UAT环境中进行投资
• 在大多数情况下，第一笔的成本远远超过第二笔的成本

类似于PROD的数据很难

描述

UAT中的数据看起来像PROD

范例注释

保持PROD和UAT同步太难了

现实

• UAT中的数据必须类似于PROD，才能获得准确的结果

根本原因

• 缺乏对现有系统的了解

讨论区

这种反模式也陷入了“某事总比没有好”的陷阱。 想法是，即使是过时且无代表性的数据，也要比不进行测试更好。

和以前一样，这是一条极其危险的推理路线。 大规模地测试某些东西 （即使不是PROD数据）可以揭示系统测试中的缺陷和遗漏，但它却提供了一种错误的安全感。

当系统上线并且使用模式不符合UAT数据所锚定的预期规范时，开发和操作团队很可能会发现自己由于UAT提供的热情洋溢而感到沾沾自喜，并且没有为可能在大规模生产发布后Swift采取的恐怖行动做好准备。

决议案

• 咨询数据领域专家并投资将PROD数据迁移回UAT的流程
• 为大规模发布做好充分的准备。
• 在可能的情况下，请有专门的“最坏情况”团队或工具（例如， Chaos Monkey ）

表演技巧（又名民俗调音）

描述

代码和参数更改被盲目地应用

范例注释

我在堆栈溢出中找到了这些很棒的技巧。 这改变了一切。

现实

• 开发人员不了解性能提示的上下文或基础，并且真正的影响未知

根本原因

• 缺乏对现有系统的了解
• 同辈压力

讨论区

性能提示是解决已知问题的方法-本质上是解决问题的解决方案。 它们具有保质期，并且通常使用期限很长-有人会提出一种解决方案，该解决方案会使笔尖在以后的软件或平台发行中毫无用处（最多）。

通常特别糟糕的性能建议来源之一是管理手册。 它们包含没有上下文的一般建议-律师经常坚持使用此建议和“建议的配置”，作为在起诉卖方时的另一道防线。

Java性能在特定的情况下发生，并且有很多影响因素。 如果我们剥离该上下文，那么由于执行环境的复杂性，剩下的几乎是无法推理的。

决议案

• 仅应用经过良好测试和理解的技术，这些技术会直接影响系统的最重要方面。

怪驴

描述

某些组件始终被确定为问题

范例注释

始终是JMS /Hibernate/ A_N_OTHER_LIB

现实

• 分析不足，无法得出此结论

根本原因

• 同辈压力
• 误解/不存在的问题

讨论区

这种反模式通常由管理层或企业来展示，因为在许多情况下，他们对技术堆栈没有完全的了解，因此正在通过模式匹配进行操作或具有未被承认的认知偏见。 但是，技术人员也很难摆脱这种反模式。

决议案

• 抵制寻求结论的压力
• 正常执行分析
• 与所有利益相关者交流分析结果（以尝试鼓励更准确地了解问题原因）。

小提琴与开关

描述

团队沉迷于JVM开关

范例注释

如果仅更改这些设置，我们将获得更好的性能

现实

• 团队不了解变更的影响

根本原因

• 缺乏对现有系统的了解
• 误解/不存在的问题

讨论区

JVM实际上有数百个开关-这提供了高度可配置的运行时，但是引起了极大的诱惑来利用所有这些可配置性。 这通常是一个错误-默认值和自我管理功能通常就足够了。 某些开关还以意想不到的方式彼此结合-盲目更改更加危险。

决议案

在对交换机进行任何更改之前：

• 在PROD中进行测量
• 在UAT中一次更改1个开关
• UAT测试变更
• 重新测试UAT
• 让某人重新检查您的推理

微基准测试

描述

调优工作集中在系统的某些非常底层的方面

范例注释

如果我们可以加快方法的调度时间...

现实

微观变化对整个系统的影响是完全未知的

根本原因

• 缺乏对现有系统的了解
• 误解/不存在的问题
• 恢复填充
• 同辈压力

讨论区

性能调优是一种统计活动，它依赖于高度特定的执行上下文。 这意味着大型系统通常比小型系统更容易进行基准测试-因为在大型系统中，大数定律对工程师有利，有助于纠正平台中影响单个事件的影响。

相比之下，我们越是专注于系统的单个方面，就越难解开构成复杂环境的单独子系统（例如，线程，GC，调度，JIT编译等）。平台（至少在Java / C＃情况下）。 这是很难做到的，并且统计信息的处理是敏感的，并且不是软件工程师在此过程中通常已经掌握的技能。 这样就很容易产生无法准确代表工程师认为他们正在进行基准测试的系统方面的行为的数字。

不幸的是，这种趋势倾向于与人类的偏见相结合，以查看模式，即使不存在任何模式。 总之，这些影响使我们想到了性能工程师，他们被糟糕的统计数据或控制不善深深地吸引住了–工程师热情地争辩性能基准或效果，而同行却无法复制。

决议案

• 除非知道自己有一个已知的用例，否则不要进行微基准测试。 并在您的同行的陪同下公开进行。
• 要做好很多准备，并要反复挑战自己的思想。

结论

为什么性能调整会获得这些反模式？ 调优过程会导致导致这种错误结论的认知偏见是什么呢？

这些问题的关键是要了解软件工程与其他工程学科在根本上是不同的。 在广泛的机械工程系统中，小零件的物理性质已广为人知，并且组成效应仅导致少量（通常是经过充分研究）的紧急行为。

软件是不同的。 我们构建的系统比人类在其他地方通常可以找到的系统复杂得多。 这不仅是因为我们使用非常简单的基本零件，还因为我们已经建立了使我们能够使用大量基本零件的工具。 不幸的是，（或者引人入胜，这取决于您的观点）随着软件变得越来越复杂，我们发现它具有高度新兴的性质。 这意味着随着我们的复杂性的增加，出现了意想不到的现象-正如我们在本文中所讨论的，并非所有人都是积极的。

致谢

特别感谢Martijn Verburg，Kirk Pepperdine，Trisha Gee和James Gough（及其他人）为我阐明（并在某些情况下命名）了这些反模式。

翻译自: https://www.infoq.com/articles/Performance-Analysis-Antipatterns/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

绩效考核表模式