观察服务；不是服务器

互联网和宠物有着悠久的关系。它始于臭名昭著的 Pets.com。虽然不幸的是，业务崩溃了，经济也崩溃了，但它确立了在线的存在。经济复苏了，对互联网的需求也比以前更强烈了。为了在线开展业务，我们过去常常购买服务器硬件进行运营。我们以尊重的方式命名它们——动物、龙、星球大战、葡萄酒或电影角色。就像我们的宠物一样，我们照顾它们并了解它们的所有怪癖。快进到今天，基础设施再次被宠物淹没。这一次，我们交换的是宠物照片，而不是宠物用品。突然间，我们可以使用大量这些服务器。我们再也不能用宠物来命名它们，我们也不太关心它们能为我们做什么。无论一个失败，还有另一个等待接受负载。关闭整个工厂以在传送带上进行维护工作是不可接受的。同样，如果对软件的某些部分进行维护，则软件作为一个整体无法使用也是无法容忍的。因此，简单的解决方案是将软件拆分为更小的、独立的服务。它是一组端点吗？属于支付团队权限的端点组合还是为多个团队服务的共享组件？数据仓库，迎合 API 和计费团队 在分布式系统中，您甚至不知道存在的计算机故障可能导致您自己的计算机无法使用。

服务的定义体现在失败的定义上。软件模块的一个理想要求是它们应该是独立的并且不会失败而其他模块可能会失败，但实际上，大多数资源最终会级联/失败。一个理想的软件应该表现得几乎像一个人体。多个活动部件通过明确的通信合同独立运行，享有与软件所追求的相同程度的自由。失败的定义不是布尔值 Yes 或 No。相反，在某些东西被认为发生故障之前会有一段时间的性能下降。因此，为了使 KPI 最有效，应将它们作为一个整体来定义。示例：对于媒体流服务的 KPI，ProcessingLag 比 CPU 利用率更有效。以下是一些与服务类型相关的常见 KPI 示例。监控服务的关键性能指标的证明在于，最好的 KPI 和监控需要对故障进行最轻微的检查。但是，相反，它用于建立系统的其他损坏部分。代码与服务之间的一个公平区别是，服务只有在部署和运行时才有意义。因此，为继续驻留在 Github 中且从未部署过的软件建立服务级别目标将是徒劳的。同一服务的不同安装使用相同的 KPI，但具有不同的阈值。 KPI 允许将属于要观察的服务范围的所有组件和部件捆绑在一起。它使您不会有过分警告，这对实际健康状况几乎没有影响。

这是一个示例：凌晨 3 点消耗 100% 的磁盘可能会或可能不会可操作，具体取决于其对服务 KPI 的影响。例如，如果它是一个注销服务，并且 KPI 显示 99.999% 的可用性，尽管磁盘故障，它可以等到早上。实际指标与服务及其健康状况的这种相关性允许做出最基本的决定；下一个冲刺应该是面向功能还是稳定性？可靠性不是战时反应；这是和平时期的准备。这种准备是以功能开发为代价的。如果一个服务在一个多月的时间里可以无误地处理 99.99% 的请求，并且在 20 毫秒内没有错误，那么它可以为新功能提供一点创造力，这总是存在降低可靠性数字的风险。相反，性能太差的服务必须在新功能之前加强现有部署。一旦思维过程在影响下从服务器和组件转移到服务，当与依赖信息结合时，它可以解锁巨大的收益。它允许快速做出决策，因为在发生影响的情况下，随叫随到的元帅可以与合适的团队接洽。当这 9 个按分钟计算时，上下游服务的快速检测可以将平均检测时间 (MTTD) 降低到个位数分钟以下。在人们意识到之前，讨论从 DevOps 与代码或基础设施与测试转移到“支付提供商 X 正在降级，让我们禁用 UPI 以支持或卡以防止结账失败。”

这种能力提高了将新功能发布到产品中的敏捷性和信心。因此，下次当您看到 Kafka OfflinePartitionsCount 增加的警报时，只需通过询问哪些服务 KPI 受到影响以及影响程度来直接设置它们。在这种情况下，哪个主题的处理延迟增加了多少，最后，此警报会影响哪个服务的新鲜度？与实体业务相比，使软件业务如此成功的根本区别在于变化的速度。当您开始观察与消费者体验相关的每一个故障时，所有只是数据的东西都变成了可操作的知识。知识的力量和对早期未知事物的了解使我们能够自信而可靠地做出改变。只要产品不抱怨，您就不再关心底层组件的个性化。底层组件变成了牛，服务变成了你最关心的新宠物。这种对服务的无条件关怀是软件可靠性的关键！ Last9 是一个软件可靠性平台，允许您将软件视为服务优先。它鼓励您更多地关注服务 KPI，也称为服务水平指标 (SLI)，而不是分散为业务指标、性能指标或基础设施的单个指标。通过整体减少 MTTD 和警报疲劳，最终赢家是您的客户。我给你留下一个想象；下次您要在凌晨 3 点进行数据库更改时，想象一下能够在清楚了解该次要停机的所有影响有多大和影响的情况下执行迁移！