下载掌阅APP，畅读海量书库
立即打开
到目前为止，我们已经定义了可观测性并说明了它与传统监控的区别。我们阐述了传统监控工具在管理现代化分布式系统时的一些局限性，以及可观测性如何解决这些问题。但传统世界和现代世界之间仍然存在很大的演进鸿沟。那么，在没有可观测性的情况下试图扩展现代系统会发生什么？
在本章中，我们将使用真实的案例，研究传统监控和架构的局限性，以及为什么在扩展现代应用时需要新的方法。本书合著者Charity Majors将分享她在Parse公司从没有可观测性的系统扩展中获得的经验教训。这个故事将由她本人来介绍给大家。
你好，亲爱的读者。我是Charity，我从17岁起就入了行。当时，我在爱达荷大学配置服务器和编写shell脚本。我记得许多著名监控系统的诞生和传播：Big Brother、Nagios、RRDtool和Cacti、Ganglia、Zabbix以及Prometheus。我用过其中的大部分，而不是全部。在对应的时代，它们非常有用。一旦我掌握了TSDB及其接口，每个系统问题就突然看起来像时间序列“锤子”对付的“钉子”：设置阈值，监控，冲洗，然后重复。
在我的职业生涯中，我的目标是成为现有软件工程师团队的第一个（或者第一批）基础设施工程师，以帮助他们的产品成熟到上线发布。我多次做出决策，要构建相关系统来最好地了解生产系统中正在发生的事情。
这就是我在Parse公司所做的。Parse是一种移动后端即服务（MBaaS）的平台，为移动应用程序开发人员提供服务于他们应用程序的各种后端API能力和存储能力。我们的平台启用了用户管理、推送通知以及与社交网络服务集成等功能。2012年，当我加入团队时，Parse仍在测试阶段。当时，公司正在使用一些Amazon CloudWatch，不知何故，收到了5个不同系统的告警。我选择改用Icinga/Nagios和Ganglia，因为这些是我最熟悉的工具。
Parse是一个有趣的团队，因为它在许多方面都非常领先（2013年被Facebook收购）。在“微服务”这个名称出现并被人人推崇之前，我们就有了微服务架构。我们使用MongoDB作为数据存储，并与它一起成长：开始时，还只是2.0版本，每个副本集只有一个锁。我们一直用Ruby on Rails进行开发，而且必须用猴子补丁（monkey patch）来让Rails支持多个数据库分片。
我们有复杂的多租户架构和共享租户池。在早期阶段，团队只考虑更快的开发速度，这就是全部。
我想在这里停下来强调，先关注开发速度是正确的做法。当然因为这个决定，我们做出了许多早期选择，后来不得不进行重构。但大多数初创公司不会因为选择错误的工具而失败。我们需要明确一点：大多数初创公司确实失败了。他们失败是因为他们的产品没有需求、他们找不到适合的产品/市场、客户不喜欢他们创造的东西或者时机不对等。选择一个使用MongoDB和Ruby on Rails的堆栈，使我们能足够快地进入市场，从而让客户感到高兴，尽快为产品付费。
大约在Facebook收购Parse时，我们托管了6万多个移动应用程序。两年半后，当我离开Facebook时，我们托管了100多万个移动应用程序。但早在2012年我第一次加入时，崩溃问题就开始显现了。
Parse在我加入几个月后正式推出。我们的流量翻了一番，再一番，又一番。我们是 Hacker News 的宠儿，每当关于我们的帖子出现在那里时，我们都会收到大量新用户的注册。
2012年8月，我们的一个托管应用程序首次进入iTunes Store的前10名。该应用程序正在推广一支来自挪威的死亡金属乐队。乐队使用这款应用程序进行直播。对于乐队来说，时间点在晚上；对于Parse来说，这是黎明的崩溃。每次乐队直播时，Parse都会在几秒钟内倒下。我们遇到了系统扩容的问题。
一开始，很难弄清楚我们的服务发生了什么。诊断对于我们来说非常具有挑战性，因为受共享租户模式影响，每当一些地方变得缓慢时，一切都变得缓慢，即使这与任何导致问题发生的原因无关。
解决这一系列问题需要进行大量的反复修补。我们必须提高MongoDB数据库管理技能。最后，经过大量工作，我们找到了问题的根源。为了缓解未来再次出现同样的问题，我们编写了工具，允许技术有选择地限制特定的应用程序，或实时优化重写性能不良的查询。我们还为这支挪威死亡金属乐队的用户ID生成了自定义的Ganglia仪表盘，以便将来我们可以迅速判断是否要归咎于运行故障。
虽然解决这个问题很难，但我们最终掌握了方法。我们都集体松了一口气，然而这只是开始。
Parse使移动应用程序开发人员可以轻松更新应用程序并将其快速上架到应用商店。这个平台很受欢迎！开发人员喜欢这种体验。所以，日复一日，他们坚持这么做。很快，我们看到新的Parse托管的应用程序，每周几次飙升到iTunes Store或Android Market的前列。这些应用程序会做一些事情，例如使用我们推送通知、保存游戏状态、执行复杂的地理位置查询——负载完全不可预测。在白天或晚上的任何时候，数百万个设备通知都被倾倒到Parse平台上，没有任何预警。
就在那时，团队开始意识到当时选择的架构、一直使用的语言及工具有许多根本缺陷。在此需要重申：每个选择都是正确的做法。产品很快就进入了市场，找到了自己的市场定位，并且交付了。现在，我们必须弄清楚如何成长到下一阶段。
我来描述当时做出的一些决定，以及其在现在这个规模上所产生的影响。当API请求进来时，它们是经过负载均衡的，并转发给了被称为Unicorns的Ruby on Rails HTTP工作池。我们的系统部署在Amazon Web Services（AWS）中，所有的Amazon EC2实例都托管了一个Unicorns主进程，这将复制出数十个Unicorns子进程，然后它们自己处理API请求。这个Unicorns被配置为保持一个Socket向多个后端开放，这些后端包括用于访问内部用户数据的MySQL、用于访问推送通知的Redis、用于访问存储用户定义的应用程序数据的MongoDB、用于调用在容器服务器端执行用户提供的代码的Cloud Code、用于Parse分析的Apache Cassandra等。
这里需要着重注意的是，Ruby不是多线程语言。因此，API工作池是一个固定池。每当任何一个后端在满足请求方面稍微慢一点时，工作池就会饱和并将新的请求加入待处理请求。每当后端变得非常慢（或完全没有响应）时，工作池就会在几秒钟内填满——Parse的所有请求都会变得很慢。
起初，我们通过过度提高配置实例的规格来解决这个问题：Unicorns在正常稳定状态下以20%的利用率运行。这种方法使我们能够应对相对可控的访问暴涨。但与此同时，我们也做出了痛苦的决定，即放弃Ruby on Rails，然后用Go进行完全重写。我们意识到，摆脱这个“地狱”的唯一方法是采用支持多线程的语言。我们花了两年多的时间来重写之前花了一年时间编写的代码。与此同时，在这个“流血”边缘，我们尝试了现在看来并不适合现代系统的所有传统操作方式。
在Parse，这是一个特别残酷的时期。我们有一个经验丰富的运维工程团队在做所有“正确的事情”。我们发现，我们所知道的一切最佳实践都源于使用传统方法，根本无法解决现代分布式微服务时代的问题。
在Parse，我们全力以赴地将基础设施代码化。我们有一个涉及Nagios检测、PagerDuty告警和Ganglia指标的复杂系统。我们有数以万计的Ganglia图表和指标。但这些工具让我们失望了，因为只有当我们已经知道问题会是什么时——当知道哪些阈值是好的，在哪里需要检测问题时——它们才有价值。
例如，如果我们能预测诊断问题所需的自定义指标，那么当我们知道需要精心策划和制作哪些仪表盘时，TSDB图表便是有价值的。当我们很清楚自己在寻找什么时，如果记得提前记录正确的内容，并知道要搜索的正确正则表达式，那么我们的日志工具就很有价值。当问题表现为正在寻找的十大问题查询、故障用户或故障端点之一时，应用程序性能管理（APM）工具就很棒。
但有很多问题，这些解决方案无法帮助我们解决。在这种情况下，上一代工具存在以下不足：
・ 每隔一天，就会有一位全新的用户飙升到其中一家移动应用程序商店的前10名。
・ 来自前10名列表中确定的任何用户的负载都不是网站崩溃的原因。
・ 慢查询列表都只是问题的症状，而不是原因（例如，由于一系列微小的写入操作，读取查询变得很慢，这些写入使得锁整体饱和，但其实每个独立的查询都能很快返回）。
・ 我们需要帮助，以便确保网站的整体可靠性达到99.9%，但这0.1%并不是平均分配给所有用户的。0.1%意味着只有一个分片被100%损坏，而这个分片恰好有可能是一家拥有数十亿美元资产的著名娱乐公司的所有数据。
・ 每天都可能会出现一个新的机器人账户，并做一些会导致MySQL主服务器整体系统饱和的行为。
这些类型的问题都与上一代问题截然不同：并不是传统监控所需要解决的问题。这些工具是为一个“可以提前预知问题”占主导地位的世界而建造的。在那个时候，生产软件系统拥有“应用程序”（它的所有功能和复杂性都包含在一个地方）和“数据库”。但现在，扩展意味着我们将这些整体应用程序分裂成了许多不同租户使用的许多服务。我们把数据库分裂成了各种各样的存储系统。
包括Parse在内的许多公司，其商业模式由产品变成了平台。我们邀请用户运行他们认为适合在我们的托管服务上运行的任何代码，也邀请他们运行他们认为需要针对托管数据库运行的任何查询。但这么做会导致我们突然丧失对系统的控制，继而导致在市场上损失大量金钱。
在这个服务即平台的时代，客户喜欢我们让平台变得更加强大。这一驱动力彻底改变了软件行业。对于为这套平台提供动力的底层系统的维护人员来说，这意味着一切的困难都变得巨大且呈指数级增长——不仅难以操作和管理，而且更难理解。
我们是如何走到这一步的，这个行业是什么时候在一夜之间发生变化的？让我们看看造成这种巨大变化的各种小迭代。
回到互联网时代的早期，首先有“应用程序”和“数据库”。它们很容易理解。它们要么能运行，要么不能运行；要么慢，要么不慢。我们必须监控它们的动态和可接受的响应阈值。
这项任务并不总是那么简单。但是，在操作上，这是直截了当的。在相当长的一段时间里，我们甚至以建设极简的框架为中心。最受欢迎的架构模式是LAMP堆栈：Linux、Apache、MySQL以及PHP或Python。你以前可能听过这个，我觉得现在有义务再说一遍：如果你可以使用LAMP堆栈（或同等方案）解决问题，那么你可能应该这样做。
在构建系统服务时，第一条规则是不要增加不必要的复杂性。你应该仔细识别需要解决的问题，并且只解决这些问题。仔细考虑你需要保持开放的选项，并保持这些选项开放。因此，大多数时候，你应该选择“无聊”的技术（https://mcfunley.com/choose-boring-technology）。不要把“无聊”和“坏”混为一谈。无聊的技术只是意味着它的边缘情况和失败场景对于大多数人来说很好理解。
然而，为了满足当今用户的需求，我们中越来越多的人发现，我们需要解决的许多问题已经无法通过不起眼而全能的LAMP堆栈来解决了。这受到多种原因的影响，实际情况也可能如此：你可能有更高的可靠性需求，需要LAMP堆栈无法提供的弹性能力；也许你有太多或者太复杂的数据，LAMP堆栈无法很好地提供服务。通常，在规模、可靠性或速度方面达到了简单架构模型的边缘，这就驱使我们分割、分区或复制堆栈。
管理代码的方式也很重要。在更大或更复杂的环境中，共享代码库会产生组织管理上的压力，从而推动技术变革。拆分代码库可以创建更清晰的所有权区域（areas of ownership），如果每个人都为一个大应用（The One Big App）贡献力量，组织便能够更快、更自主地前进。
这些及更多未提及类型的需求是推动系统架构现代化转变的一部分，这些转变现在看起来都是清晰明了的。在技术层面，这些转变包括如下几个主要影响：
・ 从一个分解到多个。
・ 需要各种数据存储，从一个数据库到多个存储系统。
・ 从单体应用程序迁移到许多较小的微服务。
・ 各种基础设施类型从“大铁”服务器转向容器、函数、无服务器和其他临时的弹性资源。
这些技术变化在人力和组织层面也产生了强大的连锁反应：我们的系统开发运维过程本身也是一种团队管理技术。这些社会层面的变化（及其相关的反馈回路）所带来的复杂性推动了系统的进一步变化和我们相应思考方式的转变。
考虑一下在LAMP堆栈最受欢迎的时期，我们认为与计算时代相关的一些流行的社会品质。运维和开发团队之间存在很高的组织障碍，代码的发布常常会卡在那堵部门墙上。众所周知，运维团队拒绝对生产系统进行更改。部署更改会导致不可预测的行为，这通常会导致停机。因此，他们将防止开发人员直接接触生产环境，开发人员将无法密切关注系统在正常运行时的表现。在这种“玻璃城堡”方法中，部署冻结是保持生产服务稳定的常用方法。
在LAMP堆栈时代，这种生产保护方法也并非完全错误。当时，生产系统中的大部分混乱确实是在引入不良代码时造成的。当部署新代码时，效果几乎是两极的：网站能运行或者不能运行（也许，有时如果你运气不好，它有第三种状态，即莫名其妙地缓慢）。
当时很少有系统架构（今天很常见）用以控制处理不良代码所导致的故障。没有所谓的优雅的服务降级能力。如果开发人员向一个小的、看似微不足道的系统组件（例如，导出功能）引入错误，那么每次有人使用它时，它都可能会造成整个系统崩溃。没有可用的机制来暂时禁用那些看起来微不足道的子模块。当服务的其余部分不受影响时，不可能只为了上线修复一个损坏的子模块。一些团队会试图将这种颗粒控制添加到他们的单体系统中。但这条路是如此令人担忧和艰难，我相信大多数人是不愿意尝试的。
无论如何，大量的这种单体系统变得越来越大。随着越来越多的人尝试在同一条路径上合作，事务锁的竞争、成本上限和动态资源需求等问题相继登场。团队所面临的各种问题逐渐出现。单体系统很快被分解成分布式系统，随着这种转变，产生了二阶效应：
・ 服务可用性的简单二元（up/down）转移到复杂的动态可用性，存在任意数量的部分故障或无法启用的可用性。
・ 生产环境的代码部署从相对简单的传统部署方式转变为渐进式交付。
・ 立即改变代码路径并上线的部署转移到升级方案，其中代码部署与功能发布（通过功能标志）解耦。
・ 在生产环境中运行一个当前版本的应用程序转变为在生产环境中提供多个应用版本。
・ 从让内部运维团队管理基础设施转变为部分关键基础设施组件由其他公司的其他团队通过API的方式提供，而开发人员甚至可能无法直接访问这些基础设施。
・ 在分布式世界中，对以前遇到的已知故障进行告警和故障排查的监控系统已变得严重不足，以前从未遇到过（可能再也不会遇到）的未知故障将会频繁发生。
渐进式交付（progressive delivery）一词由RedMonk联合创始人James Governor创造，指的是一揽子与受控的部分代码部署或对生产进行的更改有关的技能和技术（例如，金丝雀发布、功能标志、蓝绿部署和滚动部署）。
管理LAMP堆栈等单体系统所需的工具和技术对于运行现代系统完全无效。在一个“大爆炸”（“big bang”）版本中部署应用程序的系统管理方式与微服务大不相同。在微服务中，应用程序通常逐个上线，代码部署不一定释放全部功能，因为无须部署就可以通过功能标志启用或禁用代码。
同样，在一个分布式世界中，预发环境的系统变得不像以前那么有用或可靠了。即使是单体系统，将生产环境的问题复现到预发环境上也总是很困难的。现在，在一个分布式的世界里，这更是不可能的。这意味着调试和检查在预发环境中变得无效，我们已经转向要求在生产环境中完成这些任务的模式。
系统的技术方式和团队文化是相互关联的。团队在使用各种技术时的表现也受团队的管理文化表现的影响。
此外，这些转变是完全相关的，以至于不可能在它们之间划出清晰的界限。上一节中描述的许多技术转变影响了团队如何重组和改变，以更好地执行技术实践。
在这个领域，团队行为必然会发生改变。向现代分布式系统的变革还带来了三阶（third-order）效应，改变了工程师与生产环境的关系：
・ 对于所有服务的目标用户来说，不能认为他们都拥有一样的用户体验。在新模型中，服务的不同用户可能会以不同的方式通过系统路由，使用不同的组件，产生差异巨大的体验。
・ 在生产环境中寻找系统条件超过已知阈值的边缘情况的监控告警会产生大量假阳性、假阴性和毫无意义的噪声。告警已转向触发告警较少的模式，仅关注直接影响用户体验的症状。
・ 调试器已经不能再附加到一个特定的运行时上了。一次服务请求现在需要跨越网络，跨越多个运行时，通常还会引起多次请求。
・ 需要手动补救，且可以在运维手册中定义的已知重复性故障不再是常态。故障处理模式开始转变为可以自动恢复已知重复性故障的模式。无法自动恢复并因此触发告警的故障可能意味着工程师将面临一个新问题。
这些三级信号意味着，焦点正在发生巨大的引力转移，从前期生产的重要性转移到熟悉生产的重要性。传统上，在代码投入生产之前强化代码并确保其安全性的做法开始被认为是限制性的，有些甚至是徒劳的。测试驱动开发和针对预发环境运行测试仍然有用。但它们永远无法复现该代码在生产中使用时的疯狂和不可预测的性质。
作为开发人员，我们都有一个固定数量的周期来完成我们的工作。传统方法的局限性在于，它首先关注预生产硬化。任何注意力的剩余部分，如果存在的话，都会集中在生产系统上。如果我们想在生产中建立可靠的服务，就必须扭转这种顺序。
在现代系统中，我们必须首先将大部分的注意力和工具集中在生产系统上，剩余的注意力应用于模拟系统和预生产系统。预发系统很有价值，但它本质上是次要的。
预发系统不是生产系统。它们永远无法复现生产中发生的事情。预生产系统的无菌实验室环境永远无法模拟你服务的真实付费用户在现实世界中测试代码的相同条件。然而，许多团队仍然将生产视为一座“易碎的玻璃城堡”。
工程团队必须认识到生产系统的价值并调整优先级，继而做出相应的改变。这些团队由于面对缺少工具、没有可见性以及可观测性低于标准的生产系统，所以无法将生产环境视为主要的关注点。他们会继续将生产视为一个脆弱的环境，犹豫不决——无法看到潜在问题，就本能舒适地回滚部署——这都是因为他们缺乏控制措施来进行小调整、调优设置、略微降级服务或针对他们密切关注的问题进行逐步改善。
向现代系统的技术变革也带来了团队组织的变革，这意味着工程团队必须改变他们与生产系统的关系。不改变这种关系的团队将会持续严重地遭受不这样做的痛苦。在现代系统中，生产早已不再是“易碎的玻璃城堡”，越早改变这种观念，负责这些系统的团队的生活品质，以及使用这些系统的客户的体验就会越早得到改善。
在Parse，当我们努力快速扩大业务时，我们不得不相当痛苦地经历这些变化。但这些变化并没有在一夜之间发生。我们只知道我们的传统习俗。就我个人而言，我一直在遵循以前在其他公司多次使用的众所周知的生产系统管理路径。
当新问题发生时，就像挪威死亡金属乐队一样，我会深入研究并进行大量调查，直到问题的根源被发现。我的团队会对过程进行复盘来剖析问题，编写运维手册来指导自己未来如何处理同样的问题，制作一个便于下次及时发现该问题的自定义仪表盘（或两个），然后继续前进，通过上面的行动认为这个问题已经解决了。
这种模式非常适合单体应用，那里很少有真正的新问题。在Parse的早期，它运作良好。但这种模式对现代系统完全无效，在现代系统中，真正的新问题可能是最主要会遇到的问题。一旦我们开始每天遇到一连串截然不同的问题，这种方法的无效性就变得不可否认。在这种设定下，我们花在重新选择、创建运维手册和制作自定义仪表盘上的所有时间都是浪费的。我们再也不会看到同样的问题了。
这种传统方法的现实是，其中大部分都在依靠猜测。面向系统时，我变得非常擅长猜测可能出了什么问题，以至于感觉几乎毫不费力。我直觉上与我的系统保持一致。我可以盯着一组复杂的仪表盘，并自信地告诉我的团队“问题出在Redis上”，即使Redis在屏幕上没有显示。我为这种技术直觉感到自豪。很有趣！我觉得自己像个英雄。
我想强调软件行业存在“英雄”文化的这一方面。在LAMP堆栈时代运维的单体系统中，最后手段的故障定位者通常是在那里工作时间最长的人，因为他从头开始构建系统。资历最高的工程师是升级的最终点。他们的脑海中拥有最多的故障痛苦记忆和最大的宕机原因清单，他们是不可避免地冲进来拯救那一天的人。
因此，这些英雄也永远无法享受真正的假期。我记得我在夏威夷度蜜月，凌晨3点被电话骚扰，因为MongoDB以某种方式删除了Parse的API服务。我的老板，首席技术官，通常是背锅侠。但网站停机了，而且已经停机了一个多小时，没有人能弄明白为什么。所以他们打电话给我。是的，我抱怨了。但是，在内心深处，我暗自感觉很棒，因为我被需要，我是必要的人。
如果你曾经随时待命管理生产系统，那么你可能会理解这种模式。英雄文化太可怕了。这对公司不好。这也对“英雄”不好（会导致极其严重的倦怠）。对于每一个后来加入的工程师来说，这是非常令人沮丧的，他们觉得除非有一个更高级的工程师离开，否则他们永远不可能成为“最好”的故障定位者。这种模式完全没有必要。但最重要的是，它不能大规模扩展。
在Parse，为了应对规模化的挑战，需要重新投入之前使用旧方法解决新问题而浪费的宝贵时间。我们当时拥有的许多工具以及软件行业仍然依赖的工具都面向模式匹配。具体而言，它们旨在帮助专家级和经验丰富的工程师将之前遇到的问题与同一主题的新问题进行匹配。我从未质疑过这一点，因为这是我们拥有的最好的技术和工艺。
在Facebook于2013年收购Parse后，我发现了Scuba，这是Facebook用于大规模实时分析的数据管理系统。这个快速、可扩展、无属性的内存数据库可以每秒写入数百万行（事件）。它完全将实时数据存储在内存中，并在处理查询时跨数百台服务器进行聚合。我对它的体验感到很糟糕。我认为Scuba给人一种非常丑陋甚至充满敌意的用户体验。但有一件事做得非常好，这永久性地改变了我对系统进行故障排查的方法：在无限高基数的维度上近乎实时地对数据进行切片。
我们开始将一些应用程序遥测数据集发送到Scuba，并开始试验其分析能力。我们发现新问题根源所花费的时间急剧下降。以前，使用传统的模式匹配方法，我们需要几天时间（或者可能永远不会）来了解正在发生的事情。通过实时分析，可以沿着任何高基数的维度进行切片和切块，该时间下降到仅为几分钟，甚至几秒钟。
我们可以从症状开始，沿着“面包屑的轨迹”找到解决方案，从而调查一个新问题，无论它会出现在哪里，也无论这是否是我们第一次遇到这个问题。为了解决这个问题，我们不必熟悉此问题出现的原因。相反，我们现在有了一种可分析和可重复的方法来提出问题，获得答案，并使用这些答案来问下一个问题，直到我们找到问题的根源。对生产中的问题进行故障排查意味着从数据开始，坚持不懈地采取一个又一个有条不紊的步骤，直到我们找到解决方案。
这种新发现的能力不可逆转地改变了我们的做法。我们现在拥有了数据和方法，每个人都可以在一个共享工具中看到和访问，而不是依赖于复杂的知识，以及被锁在单个工程师心里的、团队无法访问的停机目录。对于团队来说，这意味着我们可以跟随彼此的脚步，追寻彼此的道路，并理解其他人的想法。这种能力使我们摆脱了对用于模式匹配的工具的依赖。
使用指标和传统监控工具，我们可以很容易地看到性能飙升或注意到可能正在出现的问题。但是，这些工具不允许我们任意地从堆栈中分割、切分和挖掘，以确定问题的根源，或查看错误之间的相关性，而我们没有其他可能的方法来发现这些错误。这些工具还要求我们在调查新问题之前预测哪些数据可能很有价值（就好像我们知道在新问题出现之前我们需要问哪些问题一样）。类似地，使用日志记录工具时，我们必须记住提前记录任何有用的东西，并确切知道当这与调查相关时要搜索什么。使用APM工具，我们可以很快看到工具供应商预测的最有用的问题，但当新问题成为常态时，这种情况收效甚微。
一旦做了范式转变，最好的故障定位者就不再是在那里工作时间最长的人了。最好的故障定位者成了我们新的分析工具使用者中最好奇、最坚持、最有素养的人。这有效地使对我们的系统及其工程师共享的智慧的访问大众化。
通过将每个问题都视为新问题来处理，我们可以确定在生产过程中出现问题时真正发生了什么，而不是简单地将其与最近的类似问题进行模式匹配。这使得对给传统方法带来最大挑战的系统进行有效故障定位成为可能。
我们现在可以快速有效地诊断以下问题：
・ 跨越多个运行时的微服务和请求。
・ 面对多种存储系统，不需要每个系统的专业知识。
・ 多租户和运行时服务器端代码和查询；我们可以轻松地深入了解个人用户体验，以确切了解发生了什么。
即使我们剩下的少量单体系统使用了无聊的技术，但所有可能的问题都被很好地理解了，我们仍然获得了一些收获。我们不一定会发现任何新的东西，但结果是我们能够更快、更自信地发布软件。
在Parse，个人提升最快的途径是学习如何使用可观测的系统。通过在适当的抽象级别收集应用程序遥测数据，围绕用户体验进行聚合，并能够实时分析，我们获得了神奇的见解。一旦我们有能力提出任何问题，链路追踪每一个步骤，并通过观测应用程序的输出来了解任何内部系统状态，我们就消除了传统工具的局限性。一旦有了可观测性，我们就能够使自己的实践现代化。
这个故事来自我在Parse的工作经历，说明了组织如何以及为什么要从传统的工具和监控方法过渡到使用现代分布式系统和可观测性来扩展其实践。2015年，在Facebook宣布关闭Parse托管服务之前不久，我离开了Facebook。从那时起，随着软件行业转向采用类似技术，我和我的团队在管理现代分布式系统时面临的许多问题才变得更加普遍。
Liz、George和我相信，这种转变解释了可观测性背后的热情及其受欢迎程度的上升。可观测性是规模越来越大的现代系统中普遍存在的问题的解决方案。在后续章节中，我们将探索可观测性带来的许多方面，包括影响和好处等。