如何知道迁移过程是否有效
我们都会犯错。即使我们全心全意地开始微服务之旅，也必须接受如下的事情：
- 我们无法了解微服务所涉及到的所有内容
- 在某个时候，我们可能还会意识到，事情可能会失败
问题是：我们是否知道微服务是否有效？我们是否知道我们是否犯了错误？
根据我们希望实现的目标，我们应该尝试定义一些指标，并利用这些指标来跟踪并帮助我们回答如上的这些问题。我们将会简单探讨一些示例性的指标。但我想借此机会强调一个事实：此处，我们不仅仅只是在谈论定量指标。我们还需要考虑来自一线员工的定性反馈。
定量指标和定性指标可以为正在进行的上述评估工作提供信息。我们需要建立检查点，以便团队有时间思考自己是否朝着正确的方向前进。在这些检查点期间，不应该只是问自己“这有用吗？”，还应该问问自己“我们是否应该尝试其他方法呢？”
让我们来看一下如何组织这些检查点活动，以及一些我们可以跟踪的指标。
定期检查
无论是什么迁移，都必须在交付过程中留有一些时间以停下来反思，从而方便分析可用信息并确定是否需要更改方案。对于小型团队来说，这种反思可能是非正式的，或者可能是定期进行回顾。对于较大的工作计划，需要把类似的反思设定为定期的、明确的活动，例如：可以把交付活动的相关领导组织在一起，每月进行一次会议，以回顾事情的进展。
无论以怎样的频率停下来反思，也无论采用的形式有多正式（或非正式），我都建议反思要确保涵盖以下内容：
- 重新陈述我们期望迁移到微服务的目标。如果公司业务方向变了，那么我们的前进方向将不再有意义，那就停下来吧！
- 查看所有的现有量化指标，以确认我们是否取得进展。
- 寻求定性反馈——人们是否认为迁移仍然是有进展的。
- 决定今后要进行哪些更改。
定量指标
所选择的、用于跟踪进度的指标取决于要实现的目标。例如，如果目标是缩短产品的上市时间，则度量cycle time译注1、部署次数和故障率则很有意义。如果目标是尝试扩展应用程序以处理更多负载，那么报告最新的性能测试将是明智的。
老话说的好：考核什么，就能得到什么。因此，值得注意的是，指标可能很危险。度量标准可能会被无意或有意地进行计算。我想起了妻子告诉我的一家公司：她在这家公司上班，这家公司根据外部供应商关闭的服务单数量来度量供应商的服务，并根据这些结果给供应商付款。这会发生什么呢？即使问题没有解决，供应商也将关闭问题，取而代之的是让人们重新提交一个新的问题单。
有的指标可能很难在短时间内有量的变化。如果在微服务迁移的前几个月就看到cycle time译注1的大幅改善，我会感到惊讶。实际上，我更希望看到cycle time译注1会在迁移的初期变得更糟。因为团队需要不断适应新的工作方式，因此短期内对工作方式的变革通常会对生产效率产生负面影响。这就是为什么采取较小的增量变革如此重要的另一个原因：变化越小，潜在的负面影响就越小，并且一旦发生负面影响，可以更快地解决。
定性指标
... Software is made of feelings（软件是由情感构成的）
—Astrid Atkinson (@shinynew_oz)
无论定量指标的数据结果如何，软件还都是由人来构建的。把人的反馈引入到成功的度量中非常中要。
- 他们喜欢这个过程吗？
- 他们感到有授权了吗？
- 亦或是他们感到不知所措？
- 他们是否获得了承担新职责或掌握新技能所需的支持？
在向上级汇报类似的迁移的任何类型的定量指标打分时11，应该包括对团队氛围的检查。如果团队成员喜欢我们正在进行的变革，那就太好了！如果不是，那么我们可能需要做一些事情。忽略员工提供给我们的内容，而完全依靠定量指标会使我们陷入麻烦。
避免沉默成本谬误
需要关注沉没成本谬误。增加检查过程的目的是确保我们对变化保持客观的了解，同时希望该检查过程可以帮助我们避免陷入沉没成本的谬误。人们投入很多精力来用以前的方法做某事，即使有证据表明该方法已经行不通，人们仍然会保持沉默。此时，就产生了沉默成本谬误。有的时我们会为自己辩护：“随时会发生改变！”有的时候，我们可能会在组织内部投入大量政治资本以进行变革，以至于我们现在无法退缩。无论哪种方式，都是在论证——沉没成本谬误都与情感投资有关——我们沉迷于一种古老的思维方式，以至于我们不能放弃它。
以我的经验而言，赌注越大，赢面就越大，而出问题时也越难退出。沉没成本谬误也被称为协和式谬误译注2。协和式谬误的名称取自一个失败的项目，该项目是英国和法国政府斥巨资建造的超音速客机（Concorde: 协和飞机）。尽管所有证据表明该项目将永远无法带来财务收益，但越来越多的资金被注入到该项目。不论协和飞机在工程上取得了什么成功，它却从未成为可用的商业客运飞机。
如果每一步都很小，那么避免沉没成本谬误的陷阱就会变得容易。此时，改变方向更加容易。使用本节讨论的检查点机制来反映正在发生的事情。我们无需在出现问题的第一迹象时就退出或改变路线。但是无视我们正在收集的、关于引入的变革是否成功的（或其他方面的）证据，比一开始就不收集任何证据更愚蠢。
接受新的方法
拆解一个单体应用会涉及到很多变量，并且需要采取多种不同的途径和方法。讨论至此，我希望大家已经不会感到惊讶。可以肯定的是，并非所有事情都会顺利进行。对恢复所做的更改而言，我们需要持有开放的心态。可以尝试新的方法；或者有时仅让变更持续一段时间，以便我们可以了解变更所产生的影响。
如果我们尝试拥抱不断进取的文化，总是想尝试新的东西，那么在需要时改变方向就变得更加自然。如果您将变更或流程改进的概念弱化为离散的工作，而不是将其纳入我们所做的所有工作中，那么我们就有可能将其视为一次性的交易活动。完成这次工作就可以了！如若如此，这也意味着没有给我们带来更多的变化！这种思维会致使我们过几年就会发现自己已落后于所有竞争对手，同时在追赶的道路上还面临一座大山。
11. Yes, this has happened. It’s not all fun and games and Kubernetes.... ↩
译注1. 精益生产中的Cycle Time。生产线中的工序处理完成一个订单或上游制工序产成品所需要的时间，就是Cycle Time。生产线中的每道工序都有自己独立的Cycle Time，Cycle Time的长短取决于对应工序的生产能力。 ↩
译注2. 协和式谬误（concorde fallacy）是指在一种计划上花费了时间和能量，就要继续付出努力，直至完成。其中，付出的代价甚至超过得到的利益。 ↩