如果您打算有目的地允许 bug 进入生产环境，那么您需要确保您的团队拥有正确的工具来快速修复这些 bug

每天‬分享‬最新‬软件‬开发‬，Devops，敏捷‬，测试‬以及‬项目‬管理‬最新‬，最热门‬的‬文章‬，每天‬花‬3分钟‬学习‬何乐而不为‬，希望‬大家‬点赞‬，加‬关注‬，你的‬支持‬是我‬最大‬的‬动力‬。

在一个左移的世界里，有一个日益增长的运动: 右移。我最近参加了一个小组讨论，小组成员(来自这个领域的科技公司)就此展开了辩论，甚至坚持认为，权利的转移实际上会让你为客户提供更多价值。然后，当他们陈述他们的论点时，有一件事变得很清楚: 为了在没有重大风险的情况下右移，您需要对整个应用程序堆栈进行广泛的可观察性。

Shifting Left vs. Shifting Right

首先，向左或向右移动意味着什么？好吧，左移运动来自于一个我们已经知道了很多年的事情: 如果你更早地发现了一个问题，那么修复它的成本就会更低。这个想法是为了鼓励您的开发人员进行广泛的测试，在多级预生产环境中验证功能，并在发布到生产环境之前尽可能捕获每个问题。

专家小组有一个简单而明显的理由来支持正确的转变: 无论你在发布产品之前做了多少测试，你总是会有活的 bug。那就正常点。让人们习惯于在生产环境中快速发现和解决 bug。这与混沌工程的想法相似。“有目的地”制造问题，这样团队就能在下午3点而不是凌晨3点很好地解决问题。

现在，我不会说教你的队伍是该左转还是右转。实际上，就像所有的工程学一样，这取决于。有一些东西应该尽早找到——还有一些东西在较低的环境中很难找到，需要对测试数据进行大量投资，等等。但也有一些，可以找到和修复非常迅速，最小的客户中断生产。这与适当的发布计划、特性标志以及设置客户期望相结合——意味着向生产环境发布 bug 并不一定是一场危机。

然而，要想成功地向右转移，你需要能够快速地解决问题。为了快速解决问题，你需要可观察性。

要成功地向右移动，你需要可观察性

也就是说，如果您打算有目的地允许 bug 进入生产环境，那么您需要确保您的团队拥有正确的工具来快速修复这些 bug。所以，让我再假设一下: 无论你是故意试图改正错误，还是不小心部署了 bug，难道你不希望你的团队拥有所有他们需要的数据，首先检测出确实存在问题，然后确切地找出问题所在吗？可观测性正是如此。

我们如何成功地解决生产中的问题？

对于许多公司来说，生产过程中的故障排除问题是非常混乱的。运营团队“拥有”生产系统，但他们通常没有真正解决生产问题的微妙信息。在最好的情况下，问题是以前发生过或存在于运行手册中的问题，运营团队可以自己解决它。在最坏的情况下，以及在运作最差的团队中，运营团队呼叫待命工程师，他们登录电话，抱怨被“如此微不足道的事情”吵醒，解决问题，然后回去睡觉，肩膀上扛着一块芯片，抱怨自己一开始就被吵醒了。

一个解决方案是让工程师拥有随叫随到的轮换——毕竟，他们是正在生产中运行的软件的专家。我原则上同意这一点，但这并不总是可行的——有时候，软件有太多的层次或组件，让这么多人随时待命是不可行的。其他时候，工程师实际上无法看到生产数据，至少在没有其他团队(比如金融或医疗行业)严格监督的情况下是如此。然而，在其他时候，出于我们的良好意愿，周围没有人是这个特定应用程序的专家——在一个关键的系统中，我们迫不及待地想找到这个人。

我的解决方案，正如你可能已经猜到的: 可观察性！但是，还有更多的事情要做: 通过从工程部到操作部或任何在生产中拥有应用程序的团队的标准交接，让每个人都有能力调试系统。这种切换应该包括所有内容，从正在部署的组件所做的事情，到输入和输出、已知的错误处理、依赖关系、需求等等。通过所有这些，您可以为您的应用程序提出一个仔细的可观察性计划——一旦您有了这个计划，您就不需要了解应用程序的复杂业务逻辑，以便对许多类型的问题进行故障排除。

可观测性计划如何帮助您更有效地排除故障

让我们来看一个典型的3层应用程序和一个缓存层示例:

交接信息:

Web 应用程序客户端与 Web 应用程序服务器对话Web 应用程序服务器与Web App 网络应用客户端和缓存-除非它不能与缓存对话，它直接进入数据库Cache 与 Web 应用程序服务器和数据库进行对话

当然，还有更多的故事。例如，实际的基础设施可能看起来像这样:

顺便说一句，您的工程团队可能不知道这个功能模型和基础设施数据流模型之间的区别——他们的应用程序在部署到这样的环境中时可能根本无法工作——所以首先要确保基础设施规划和评审是 SDLC 的一部分。

看看基础设施图，成功的交接还需要很多东西:

客户端依赖于 DNS 提供程序、 CDN 和负载均衡器CDN 和负载平衡器都需要将会话持久化到正确的 Web App Server假设缓存是本地的，但是数据库需要保持一致，因此它们可以跨云区域复制示例: 可观测性工作策略

这个简单的示例已经变得越来越复杂了——但是让我们为我们的应用程序提出一个可观察性策略。在这个示例中，我们添加了一个蓝点来表示每个监视点:

我们可能希望确保客户端的环境正常工作-他们的笔记本电脑能够执行客户端应用程序，到达 DNS 服务器等。端点可观测性或者Real User Monitoring 真正的用户监控 解决方案可以帮助解决这个问题我们希望确保第三方服务能够按照需要运行，所以也许一些 DNS 验证测试和一系列区域 CDN 测试将确保它们在不同的云区域之间得到适当的平衡。这些相同的测试可以用来确保云区域本身正常工作，或者我们可以为每个区域添加专门的测试来确保对于我们的每个服务器端组件，我们需要观察输入和输出。我们可以连接到负载平衡器，确保它在服务器之间分散负载。我们可以确保它返回一个200 OK 甚至一个样例查询结果。每个网络服务器都是一样的。缓存也是一样——我们可以确保它已经启动并运行，但是缓存功能也正常工作——也许可以两次查询数据并查看响应头以确保它来自缓存。对于直接测试数据库也是如此(响应头不应该说它来自缓存)在这里，我们可以得到我们需要的任何复杂的东西——也许应用程序可以在发出特定的 API 调用时返回指标。我们可能希望这个应用程序返回自定义指标-它通过特定的关键区域需要多长时间。如果请求发送一个特殊的“魔术”头，我们可以为每个请求执行此操作，或者我们可以通过 API 返回汇总指标如果网络基础设施比这更复杂，我们可能需要添加一些3-4层(路由，数据包级别)监视最后，因为我们知道数据库需要彼此通信以同步它们的数据，所以我们可以设置跨区域测试跨区域测试 在网络层和应用程序层，以确保它们之间有连接性和高吞吐量更好的(可观测性)分辨率导致更快的(事件)分辨率

如果我们看上面的图片，有很多蓝点。这才是重点。您需要有尽可能多的数据，以便您的应用程序具有完全的可观察性！如果删除其中任何一个，那么现在您就不太确定潜在的问题出在哪里了。

为了说明这一点，这里有一张和上面一样的图片，但是分辨率较低。你不知道发生了什么！当您只监视应用程序本身时就会发生这种情况。也许你能分辨出它是上升还是下降，但是你对细节没有任何可见性。

我们可以继续添加更多的点，以获得更好的分辨率，但是让我们看看即使使用这个相对简单的策略，我们已经取得了什么成就:

通过在“正常”时间运行这些测试，我们确定了基线。现在我们知道了每个组件需要多长时间，它的错误率是多少，等等，我们可以为这些基线创建 SLO，这样如果性能下降，我们就会得到通知，并确切地知道哪里出错了如果出现问题，从客户机和各个基础设施组件的有利位置，我们可以获得完全的360度可见性。我们可以立即确定问题的具体部分

突然之间，有了这样一个适当的交接，事故调用就会更少、更短——如果确实需要升级到工程部，问题已经缩小了，所以解决起来要快得多。如果你要正确的转变，这就是方法。如果你不这样做，你仍然会有生产问题-所以仍然要确保你有一个适当的工程交接。参与其中的每个人都会因此而更快乐。