在第二次世界大战期间，一位名叫亚伯拉罕·沃尔德研究了一个问题–根据从任务中返回的飞机和他们的子弹穿刺模式，找出在飞机上添加装甲的位置。显而易见和被接受的想法是，子弹代表了飞机的问题区域。沃尔德指出，问题区域实际上并不是这些区域，因为这些飞机幸存了下来。他发现失踪的飞机有未知的数据，表明还存在其他问题。事实上，幸存飞机的模式显示了那些没有问题的区域。
作者：McGeddon本人的作品，CC by-SA 4.0，Https://commons.wikimedia.org/w/index.php?curid=53081927
在可观察性的新兴世界中，我们经常被告知要这样做；我们选择的反应仅仅是基于幸存下来的数据。简而言之，仅仅监测你在环境中所知道的事情就会使你陷入偏见。工具正在呈现新的视图和级别的信息，在编排、微服务和混合云的世界中都是有用的。但它们是否足够完整？他们给了你你真正需要的信息吗？
根据阿瑟·柯南·道尔爵士的角色夏洛克·福尔摩斯你看，但你没有观察“(波希米亚的丑闻)。欢迎来到生存偏差预测的结论是基于幸存者，而不是全体居民。
在过去的几年里，我们看到体系结构的复杂性与抽象的拓展。我们的单片应用程序正在成为云本机应用程序。我们的单线程、三层环境正在变得庞大、弹性和更复杂的微服务体系结构。
这是因为我们拥抱技术的方式发生了变化。我们已经采用了大量的抽象来处理这种进化。
我们生活在一个有很多主人的世界里。我们可以变成多云。我们的服务使用不同的编程语言编写，并使用不同的框架。我们一直在扩展，有弹性的计算和无界数据需求。
把Kubernetes当作一块。Kubernetes是容器编排方面的领先企业，在我们复杂的集装箱化应用程序中大量使用，在公共云中占主导地位，并不断扩展其功能。但是，由于抽象的简单性，也带来了一些挑战：
- 用于跟踪的多个抽象层：容器、荚、集群、节点、命名空间等。
- 短暂的持续时间：容器在几秒钟内上下旋转。
- 动态工作负载放置：它到底在哪里？
除了这些挑战之外，Docker容器、底层应用程序服务、第三方服务和通信协议的不同结构也会变得更加激烈。这反过来意味着我们在监控分布式服务的端到端性能方面面临挑战。由于我们的复杂性，通常不可能手动映射请求在应用程序中的路径。
同样，可以观测到的遥测数据量也不稀奇，每天可以突破几百兆字节的界限。度量聚合是高效率的，但它仍然需要添加标记、类别和底层基础结构信息，以便快速识别基本原因，从而导致相应的高基数。分布式跟踪可以生成数十个跨度，平均每个请求大约为8个。所以，假设一个简单的电子商务站点每秒生成500个请求。这给了我们4K的跨度，每一个都有非常重要的数据，特别是当涉及到离群点和我们所不知道的独特事件时。
这是一个信号到噪声的问题，每一点噪声都是一个重要的信号。就在这一点上，我们开始看到生存偏差潜入我们的可观测范围的选择。
至少在理论上有减少噪音的方法。我们可以通过采样过滤遥测数据。采用带通方法可以减小传输集合体。我们可能需要处理数字信号中的量化噪声(但这是极不可能的)。
这些都遭受同样的问题，一个假设，你扔掉的是噪音。在微服务、请求驱动的应用程序中，所有这些都不是噪音.因此，只要应用任何减少数据的方法，它就能减少数据。这使得我们很难找到我们依赖于可观测技术来发现的条件，未知的未知数。
对于一些分布式跟踪工具，答案是抽样。他们看5%或10%的痕迹，盲目丢弃其他(基于头部的抽样)。其他人则更聪明，等待跟踪完成，然后分析跟踪以获得有趣的细节，选择发送给您感兴趣的跟踪(基于尾部的抽样)。但是，如果可观察性的目标是发现、识别和解决未知的未知数，那么观察发送给你的内容是一种固有的偏见。
您仍然希望识别异常值，但是现在您已经拥有了所有的数据，无论是好的还是坏的。你不是根据你的幸存者来做决定，你可以找出弱点并加以改进。你可以设定有意义的基线，识别真正的异常，并保持你的飞机飞行。
否则，如何为请求构建有意义的服务地图？当您没有所有数据时，如何跟踪历史数据趋势？
“但是等等，”我听到你说。“不管怎么说，我的指标不是都告诉我了吗？”
答案变得复杂起来。如果在分析前进行随机抽样，特别是使用跟踪数据，则红色(比率、误差、持续时间)数字无效。您再次运行的系统仅仅是基于您所看到的，而忽略了您未知的未知数。
情况还会更糟。在飞机的例子中，对弹孔图案的最初反应是在这些子弹密集的斑点上增加更多的盔甲，从而使它更有可能存活下来。然而，这种盔甲会使飞机变慢，可能更笨重，因此也就不太可能存活下来。接受生存偏见会导致相反的结果。
现在以我们的飞机为例红色仪表盘。在我们抽样的方法中，我们将得到持续时间度量的当前正态曲线分布。我们会想念异常点，P95或P99异常值。我们的仪表板看起来会很棒，但我们的客户会不高兴(至少在某些时候)。
即使我们有一个完整的度量集合，缺乏完整的底层数据也是有问题的。采取同样的方法，我们现在能够看到非常偶然的高峰的持续时间。我们的度量标准可能会提醒我们某些事情出了问题。这可能是一个离群点，所以现在的问题是，“我们的抽样方法记录了这一痕迹吗？”还是像未来的本德一样查找检查官5上的文件却发现它根本不存在。即使你的智能抽样确实保持了这个异常值，你将如何将它与当时围绕它的活动进行比较，或者对客户及其相关基础设施的请求的正常进展呢？
真的，答案很简单。依赖于将所有数据以实时、高效的方式提供给您的工具。这避免了误导性数据和不完整数据的陷阱。这些数据，通过您选择的仪表板，无论是基于红色的，还是您自己的自定义概念，都可以提供您的应用程序和环境的完整视图，并具有深入探究潜在原因的能力。简而言之，您可以确定哪些是重要的，哪些是您想知道的，而不是简单地获取工具提供者认为对您可能重要的数据。
在第二次世界大战期间，一位名叫亚伯拉罕·沃尔德研究了一个问题–根据从任务中返回的飞机和他们的子弹穿刺模式，找出在飞机上添加装甲的位置。显而易见和被接受的想法是，子弹代表了飞机的问题区域。沃尔德指出，问题区域实际上并不是这些区域，因为这些飞机幸存了下来。他发现失踪的飞机有未知的数据，表明还存在其他问题。事实上，幸存飞机的模式显示了那些没有问题的区域。
作者：McGeddon本人的作品，CC by-SA 4.0，Https://commons.wikimedia.org/w/index.php?curid=53081927
在可观察性的新兴世界中，我们经常被告知要这样做；我们选择的反应仅仅是基于幸存下来的数据。简而言之，仅仅监测你在环境中所知道的事情就会使你陷入偏见。工具正在呈现新的视图和级别的信息，在编排、微服务和混合云的世界中都是有用的。但它们是否足够完整？他们给了你你真正需要的信息吗？
根据阿瑟·柯南·道尔爵士的角色夏洛克·福尔摩斯你看，但你没有观察“(波希米亚的丑闻)。欢迎来到生存偏差预测的结论是基于幸存者，而不是全体居民。
在过去的几年里，我们看到体系结构的复杂性与抽象的拓展。我们的单片应用程序正在成为云本机应用程序。我们的单线程、三层环境正在变得庞大、弹性和更复杂的微服务体系结构。
但有一件事已经很清楚了。抽象使我们的生活在一些重要的方面变得“简单”。然而，抽象也使我们的应用程序和环境在需要的时候更难挖掘。总之,是海龟一直往下走.
这是因为我们拥抱技术的方式发生了变化。我们已经采用了大量的抽象来处理这种进化。
我们生活在一个有很多主人的世界里。我们可以变成多云。我们的服务使用不同的编程语言编写，并使用不同的框架。我们一直在扩展，有弹性的计算和无界数据需求。
把Kubernetes当作一块。Kubernetes是容器编排方面的领先企业，在我们复杂的集装箱化应用程序中大量使用，在公共云中占主导地位，并不断扩展其功能。但是，由于抽象的简单性，也带来了一些挑战：
- 用于跟踪的多个抽象层：容器、荚、集群、节点、命名空间等。
- 短暂的持续时间：容器在几秒钟内上下旋转。
- 动态工作负载放置：它到底在哪里？
除了这些挑战之外，Docker容器、底层应用程序服务、第三方服务和通信协议的不同结构也会变得更加激烈。这反过来意味着我们在监控分布式服务的端到端性能方面面临挑战。由于我们的复杂性，通常不可能手动映射请求在应用程序中的路径。
同样，可以观测到的遥测数据量也不稀奇，每天可以突破几百兆字节的界限。度量聚合是高效率的，但它仍然需要添加标记、类别和底层基础结构信息，以便快速识别基本原因，从而导致相应的高基数。分布式跟踪可以生成数十个跨度，平均每个请求大约为8个。所以，假设一个简单的电子商务站点每秒生成500个请求。这给了我们4K的跨度，每一个都有非常重要的数据，特别是当涉及到离群点和我们所不知道的独特事件时。
这是一个信号到噪声的问题，每一点噪声都是一个重要的信号。就在这一点上，我们开始看到生存偏差潜入我们的可观测范围的选择。
至少在理论上有减少噪音的方法。我们可以通过采样过滤遥测数据。采用带通方法可以减小传输集合体。我们可能需要处理数字信号中的量化噪声(但这是极不可能的)。
这些都遭受同样的问题，一个假设，你扔掉的是噪音。在微服务、请求驱动的应用程序中，所有这些都不是噪音.因此，只要应用任何减少数据的方法，它就能减少数据。这使得我们很难找到我们依赖于可观测技术来发现的条件，未知的未知数。
对于一些分布式跟踪工具，答案是抽样。他们看5%或10%的痕迹，盲目丢弃其他(基于头部的抽样)。其他人则更聪明，等待跟踪完成，然后分析跟踪以获得有趣的细节，选择发送给您感兴趣的跟踪(基于尾部的抽样)。但是，如果可观察性的目标是发现、识别和解决未知的未知数，那么观察发送给你的内容是一种固有的偏见。
您仍然希望识别异常值，但是现在您已经拥有了所有的数据，无论是好的还是坏的。你不是根据你的幸存者来做决定，你可以找出弱点并加以改进。你可以设定有意义的基线，识别真正的异常，并保持你的飞机飞行。
否则，如何为请求构建有意义的服务地图？当您没有所有数据时，如何跟踪历史数据趋势？
“但是等等，”我听到你说。“不管怎么说，我的指标不是都告诉我了吗？”
答案变得复杂起来。如果在分析前进行随机抽样，特别是使用跟踪数据，则红色(比率、误差、持续时间)数字无效。您再次运行的系统仅仅是基于您所看到的，而忽略了您未知的未知数。
情况还会更糟。在飞机的例子中，对弹孔图案的最初反应是在这些子弹密集的斑点上增加更多的盔甲，从而使它更有可能存活下来。然而，这种盔甲会使飞机变慢，可能更笨重，因此也就不太可能存活下来。接受生存偏见会导致相反的结果。
现在以我们的飞机为例红色仪表盘。在我们抽样的方法中，我们将得到持续时间度量的当前正态曲线分布。我们会想念异常点，P95或P99异常值。我们的仪表板看起来会很棒，但我们的客户会不高兴(至少在某些时候)。
即使我们有一个完整的度量集合，缺乏完整的底层数据也是有问题的。采取同样的方法，我们现在能够看到非常偶然的高峰的持续时间。我们的度量标准可能会提醒我们某些事情出了问题。这可能是一个离群点，所以现在的问题是，“我们的抽样方法记录了这一痕迹吗？”还是像未来的本德一样查找检查官5上的文件却发现它根本不存在。即使你的智能抽样确实保持了这个异常值，你将如何将它与当时围绕它的活动进行比较，或者对客户及其相关基础设施的请求的正常进展呢？
真的，答案很简单。依赖于将所有数据以实时、高效的方式提供给您的工具。这避免了误导性数据和不完整数据的陷阱。这些数据，通过您选择的仪表板，无论是基于红色的，还是您自己的自定义概念，都可以提供您的应用程序和环境的完整视图，并具有深入探究潜在原因的能力。简而言之，您可以确定哪些是重要的，哪些是您想知道的，而不是简单地获取工具提供者认为对您可能重要的数据。
所以，检查一下你的可观测性技术。确保你不只是收到你的系统是如何工作的部分图片。请注意，生存偏见确实存在，而且非常容易陷入其中，因为您看到的数据可以很容易地支持您的初步结论。确保您得到的是无偏见的可观测数据，并保持您的应用程序‘飞行’。
