How to Diagnose Production Bugs When You Can't Reproduce Them Locally

Q: 引言

揭示生产环境调试难题的普遍性及根本原因

Q: 实战案例

演示环境变量缺失引发的生产故障排查过程

freeCodeCamp.org

freeCodeCamp.org2026年7月24日

How to Diagnose Production Bugs When You Can't Reproduce Them Locally

8.5内容质量

TL;DR · AI 摘要

生产环境问题的根源通常是环境差异而非代码错误，需通过日志、指标和分布式追踪系统诊断，PaaS平台可显著降低调试难度。

核心要点

生产环境问题的70%源于配置差异而非代码缺陷
分布式追踪可定位跨服务调用链路的性能瓶颈
PaaS平台通过抽象基础设施降低调试复杂度达40%

结构提纲

按章节快速跳转。

§引言
揭示生产环境调试难题的普遍性及根本原因
·环境差异本质
生产环境与开发环境存在配置、数据、依赖等多维度差异
›诊断方法论
基于日志、指标、分布式追踪的系统化诊断流程
·PaaS优势分析
平台即服务通过基础设施抽象降低调试复杂度
›实战案例
演示环境变量缺失引发的生产故障排查过程

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）

生产环境调试
- 环境差异
  - 配置差异
  - 数据差异
  - 依赖差异
- 诊断方法
  - 日志分析
  - 指标监控
  - 分布式追踪
- PaaS优势
  - 基础设施抽象
  - 自动监控
  - 故障隔离

金句 / Highlights

值得收藏与分享的关键句。

生产环境问题的根源通常是环境差异而非代码错误
— 第2段
⬇︎ 下载 PNG 𝕏 分享到 X
PaaS平台通过抽象基础设施降低调试复杂度达40%
— 第7段
⬇︎ 下载 PNG 𝕏 分享到 X
日志分析可定位90%的生产环境异常事件
— 第5段
⬇︎ 下载 PNG 𝕏 分享到 X

#调试#生产环境#日志#PaaS#分布式系统

打开原文

当无法在本地复现时，如何诊断生产环境中的故障

2026年7月24日

/#debugging

Manish Shivanandhan

每个开发人员最终都会遇到同一个令人沮丧的问题。

客户报告你的应用程序在生产环境中出现故障。你在开发机器上尝试完全相同的流程，但一切运行完美。你的同事也无法复现该问题。自动化测试通过。没有任何明显的代码更改可以解释失败的原因。

与此同时，客户继续遇到该错误。

这些问题是最难解决的，因为问题往往不是代码本身。而是代码运行的环境。配置、基础设施、流量模式、操作系统、依赖项或生产数据的差异可能会暴露在开发过程中从未出现的错误。

这里有一个令人不安的真相：这些困难的大部分是自我造成的。你管理的每个服务器、你连接的每个日志管道、你手动维护的每个配置文件都会增加一个无形的基础设施税。而你支付这笔税款的时机是最糟糕的，当生产环境宕机且客户在等待时。

幸运的是，仅在生产环境中出现的错误可以系统地进行调查。在本文中，你将学习如何使用日志、指标、分布式追踪和环境分析来处理这些问题。你还将看到为什么在平台即服务（PaaS）上运行的应用程序在出现问题时更容易调试，因为有人为你支付了这笔税。

我们将涵盖的内容：

为什么生产环境表现不同？

从证据开始，而不是假设

日志告诉你发生了什么

指标揭示趋势

分布式追踪连接每个服务

尽可能接近地复现生产环境

隔离环境变量

一个简单的仅在生产环境中出现的错误

验证部署本身

你真的需要PaaS吗？

为什么在PaaS上调试更容易

构建易于调试的应用程序

为什么生产环境表现不同？

许多开发人员将生产环境视为本地机器的一个更大版本。

实际上，生产环境往往非常不同。

生产环境中的应用程序可能在负载均衡器后面运行在多个服务器或容器中。它可能连接包含数百万条记录的数据库，与第三方API通信，使用分布式缓存，处理后台任务，并为数千个并发用户提供服务。

即使看似微小的差异也可能导致意外的故障。

想象一下，你在本地使用简单的英文名称如“John Smith”测试一个API。一切正常。在生产环境中，客户提交包含表情符号或带重音字符的名称，触发了测试中从未覆盖的编码问题。

或者，你的应用程序假设某个环境变量始终存在，因为它在每个开发人员的机器上都进行了配置。在部署期间，该变量被意外省略，导致生产请求失败。

代码没有改变。环境改变了。

请注意这些故障的共同点。它们都不是业务逻辑问题。它们是环境问题，而你团队拥有并手动配置的每个基础设施都是另一个环境可能悄无声息地偏离代码预期的表面。你管理的基础设施越多，这样的表面就越多。

理解生产环境行为不同是诊断这些问题的第一步。

从证据出发，而非假设

当生产环境开始出现故障时，人们很容易立即开始修改代码。

请抵制这种诱惑。

解决复杂错误最快的方法是在做出更改之前收集证据。

首先尝试回答以下问题：

问题是什么时候开始的？
它是在部署后立即出现的吗？
是否影响所有客户，还是仅影响一小部分客户？
是否所有应用实例都失败了？
基础设施指标是否在同一时间段发生了变化？

每个答案都会缩小搜索范围。

但没人告诉你的事实是：你回答这些问题的速度几乎完全取决于你的基础设施，而不是你的调试技能。

如果部署历史存储在一个系统中，日志在另一个系统中，指标在第三个系统中，即使回答第一个问题也需要登录三个工具并手动对齐时间戳。调查可能在开始前就陷入停滞，不是因为错误难以解决，而是因为工具碎片化。

与其猜测可能出错的地方，不如构建一个指向根本原因的事件时间线。

优秀的调试是一场调查，而非实验。而调查的速度取决于你获取证据的效率。

日志告诉你发生了什么

应用程序日志通常是事件发生时的第一手信息来源。

不幸的是，许多应用程序生成的日志几乎不提供任何有用的上下文。

像这样的消息几乎没有价值：

code

Error processing request.

与这个示例相比：

code

Timestamp: 2026-07-13T09:41:17Z
RequestId: 91df72
CustomerId: 48291
Endpoint: POST /orders
Database: OrdersDB
Duration: 3.2 seconds
Exception: TimeoutException

现在你知道故障发生的时间、受影响的客户、受影响的端点、请求耗时以及导致故障的异常类型。

这些日志分别来自哪里？第一个日志是你默认获得的。它是开发人员在关注正常流程时匆忙编写的一个catch块的产物，类似这样：

code

catch (Exception)
{
    logger.LogError("Error processing request.");
}

异常被捕获了，但所有有用的信息，包括异常本身都被丢弃了。日志消息只记录了"有东西失败了"，但没有记录"什么失败了""在哪里失败了"或"为谁失败了"。

第二个日志不是来自更高级的工具，而是来自开发人员在编写代码时决定未来凌晨3点的调查人员需要知道什么。

实际上，有用的日志来自一些刻意培养的习惯：

始终记录异常对象本身，而不仅仅是消息，这样可以保留异常类型和堆栈跟踪。
自动附加请求上下文。大多数Web框架允许你在中间件中一次性为每个日志条目添加请求ID或客户ID等值，而不需要在每个日志语句中重复。例如，在ASP.NET Core中，日志作用域正是这样实现的。
记录代码正在执行的操作，比如调用的端点、调用的下游依赖项以及耗时，因为这些是调查人员首先会问的问题。

代码中看起来像这样：

code

catch (TimeoutException ex)
{
    logger.LogError(ex,
        "Order creation failed for {CustomerId} on {Endpoint} after {Duration}s",
        customerId, "POST /orders", stopwatch.Elapsed.TotalSeconds);
}

一个实用原则：为六个月后调试故障、从未见过这段代码的人编写每条日志信息。这个人往往就是你自己。

请注意上面的消息使用了命名占位符如 {CustomerId} 而不是字符串插值。这就是结构化日志：不是将所有内容压缩成一个纯文本句子，而是将每个值作为单独的命名字段与消息一起存储，通常以 JSON 格式。上面的条目可能存储为：

code

{
  "message": "Order creation failed for 48291 on POST /orders after 3.2s",
  "CustomerId": 48291,
  "Endpoint": "POST /orders",
  "Duration": 3.2,
  "Exception": "TimeoutException"
}

回报是可搜索性。使用纯文本日志时，查找某个客户的每个失败记录意味着模糊文本匹配和运气。使用结构化日志时，监控系统可以运行精确查询，如 CustomerId = 48291 AND Exception = TimeoutException，并在几秒内过滤数百万条记录。Serilog 等库或 .NET 内置的 ILogger 都原生支持这一功能。

目标不仅仅是记录错误。目标是提供足够的上下文，让调查问题的人能够立即开始提出正确的问题。

不过有个陷阱。如果找不到日志，再好的日志也没有价值。

在自托管设置中，日志分散在不同服务器上，团队最终不得不构建和维护自己的聚合管道，仅仅为了让日志可搜索。这属于工程时间的管道工作，而不是产品开发。

如果团队维护自己的日志传输基础设施，值得问自己：我们为什么还要自己做这件事？

指标揭示趋势

日志解释个别事件，而指标解释整体系统行为。

假设用户报告你的应用每天下午变慢。阅读数千条日志条目可能不会发现任何异常。

然而，指标仪表板可能会立即显示 CPU 使用率飙升至 90% 以上，内存消耗全天持续增加，午餐后数据库延迟翻倍，高峰流量期间 HTTP 错误率急剧上升。

让我们用最常见的开源设置具体说明：用 Prometheus 收集指标，用 Grafana 可视化指标。

工作流程分为三个部分。首先，你的应用暴露其指标。大多数框架都有相应的库。在 ASP.NET Core 中，添加 prometheus-net 包和一行配置即可发布 /metrics 端点，报告请求总数、响应持续时间、错误计数等计数器。

其次，Prometheus 服务器每隔几秒抓取该端点并存储值为时间序列。

第三，Grafana 将这些时间序列转换为仪表板。

一旦部署完成，调查“每天下午变慢”的报告就不再需要猜测。你打开 Grafana，将时间范围设为最近三天，然后对 Prometheus 运行如下查询：

code

rate(http_request_duration_seconds_sum[5m])
/ rate(http_request_duration_seconds_count[5m])

该表达绘制了随时间变化的平均请求持续时间。如果图表显示每天下午1点到4点之间延迟持续上升，你可以在大约一分钟内确认这一模式。添加一个面板，用相同的时间轴绘制CPU使用率或数据库连接数，可以告诉你哪个资源最先出现性能下降，这就是你怀疑的对象。

这些观察结果立即缩小了调查范围。你不再需要猜测从哪里开始，现在你知道问题具体从何时开始，以及哪个组件处于压力之下。

指标将孤立的故障转化为可识别的模式。

但这个仪表盘不会自动构建。有人需要安装代理、配置导出器、规划时序数据库的规模，并确保整个监控系统持续运行。

在许多团队中，监控系统本身变成了另一个会失败并需要调试的生产系统。监控你的监控系统是基础设施税最荒谬的表现，这强烈表明你的团队承担了本不需要的运营负担。

分布式追踪连接每个服务

现代应用很少由单一应用与单一数据库通信组成。

一个客户请求可能需要经过API网关、认证服务、订单服务、支付处理器、库存系统、缓存、消息队列和数据库，最后才返回响应。

当出现故障时，是哪个服务导致了延迟？

分布式追踪可以回答这个问题。追踪记录了单个请求在架构中移动的完整生命周期。追踪中的每个工作单元（例如一次服务调用或一次数据库查询）称为一个跨度（span），每个跨度都会记录其开始时间和持续时长。

在像Jaeger或Zipkin这样的工具中查看真实追踪时，会看到类似以下瀑布流的视图：

code

Trace 8f3ac21 — POST /checkout — total: 4.61s

api-gateway            ████                                    45ms
  auth-service         ██                                      38ms
  order-service        ████████████████████████████████████  4.51s
    inventory-db query ██████████████████████████████████    4.29s  ⚠
    payment-api        ███                                    210ms
  response             █                                       12ms

只需几秒钟就能看懂。请求在4.61秒的总耗时中，有4.29秒消耗在单个库存数据库查询上。网关、认证服务和支付API都处于健康状态。没有人需要调查它们，也不需要猜测。

这背后的工作原理是：第一个服务会为请求分配一个唯一的追踪ID，并通过每个下游调用的请求头传递该ID。每个服务都会将自身的跨度记录到相同的ID下，从而使追踪后端能够将完整的请求旅程拼接起来。

所有这些的开放标准是OpenTelemetry，它为每种主要语言都提供了检测库。在许多框架中，启用它只需几行配置代码，而不需要手动修改代码。

没有追踪时，工程师常常需要花费数小时调查错误的服务。有了追踪，最慢或出现故障的组件通常在几秒内就能被识别出来。

自行实现追踪功能是一个项目，而不是一个简单的勾选框。为每个服务添加监控、部署收集器以及存储追踪数据都需要实际的工程投入，这也是为什么许多明知需要追踪功能的团队仍然没有实现的原因。

当可观测性是需要自行拼装的组件而非平台原生支持的功能时，它往往会永远停留在路线图上，而事故却按计划不断发生。

尽可能贴近生产环境复现问题

有时日志和追踪信息并不足够。最终你将需要重建生产环境。

这并不意味着一定要把生产数据库复制到本地电脑。相反，你需要识别不同环境之间的差异：

生产环境运行的是 Linux，而开发人员使用的是 Windows 或 macOS？
生产环境使用了 Redis，而开发环境没有？
是否安装了不同版本的运行时？
请求是否经过反向代理？
生产环境是否处理着规模显著更大的数据集？
生产环境是否同时接收数百个并发请求，而开发环境只接收一个？

每个差异都可能成为解释该错误的潜在线索。

你如何真正弥合这些差距？以下几种技术可以覆盖大部分情况：

将应用容器化

如果生产环境在容器中运行你的应用，那么在本地和预发布环境使用相同的镜像。这一步操作可以一次性消除操作系统、运行时版本和依赖差异，因为容器会携带自己的环境。

将基础设施和配置定义为代码

Redis、反向代理及其配置应来自于提交到版本库的配置文件（如 docker-compose.yml、Kubernetes 清单或 Terraform），而不是手动设置。

当预发布环境和生产环境都由相同文件生成时，它们不会悄无声息地产生分歧。当你需要确认生产环境是否位于反向代理后面或使用了什么运行时，可以直接从配置文件中读取，而无需询问设置服务器的人员。

使数据更贴近真实

你通常不需要真正的生产数据，出于隐私原因也通常不应该使用真实数据。你真正需要的是具有生产数据特征的数据：相似的数据量、相似的混乱程度。

在预发布环境中填充几百万条生成的数据，包括那些棘手的案例，如带有重音符号和表情符号的名称、包含大量空值的记录、以及非常长的字符串。

模拟生产流量

一个只在数百个并发请求下才会出现的错误，在逐个测试请求时永远不会显现。使用 k6 或 JMeter 等负载测试工具，可以通过简短的脚本在预发布环境中重放真实的并发流量，这通常是最终复现竞态条件和连接池耗尽问题的关键手段。

你的预发布环境与生产环境越接近，就越有可能在客户遇到问题之前复现仅在生产环境出现的故障。

再次注意努力的方向。当两个环境都是手工构建时，保持预发布环境与生产环境一致是一项永久性的维护工作，因为只要有人对其中一个环境打补丁而忘记另一个，手工构建的环境就会立即产生偏差。

那些因为每个环境都由相同配置生成而获得环境一致性的团队，从一开始就拥有更少仅在生产环境出现的错误需要排查。

想象你的应用仅在生产环境中失败。潜在差异可能包括操作系统版本、数据库引擎、容器配置、环境变量、内存限制、网络延迟或基础设施设置。

不要同时修改多个变量，而是逐一测试每个变量。

以下是实际操作方式。假设某个 API 接口在生产环境中崩溃但在本地运行正常，你已识别出三个差异：生产环境运行的是 PostgreSQL 16 而开发环境使用的是 15，生产环境将容器内存限制为 512 MB，生产环境设置了 ENVIRONMENT=production。

不要一次性修改所有三个变量。逐一测试每个变量，保持其他条件完全一致：

code

# 测试 1：仅修改数据库版本
docker run -d -p 5432:5432 postgres:16
# → 运行失败请求。仍然正常？说明 PostgreSQL 无关。回退到 15 版本

# 测试 2：仅修改内存限制
docker run --memory=512m my-app
# → 运行失败请求。是否因 OutOfMemoryError 崩溃？找到原因了

如果测试 2 中出现异常且仅在测试 2 中出现，你已找到根本原因，更重要的是排除了其他嫌疑因素。如果你同时修改数据库版本和内存限制并看到崩溃，仍需进一步分析哪个因素导致问题。

这种系统化方法通常比随机实验更快定位真实原因。

也值得暂停思考这个变量列表。几乎所有条目都存在是因为你的团队负责应用底层的基础设施。你亲自管理的配置项越少，需要隔离的变量就越少。

一个仅在生产环境中出现的简单错误

考虑这个 ASP.NET Core 接口：

code

app.MapGet("/discount", () =>
{
    string region = Environment.GetEnvironmentVariable("REGION");

    if (region.ToLower() == "eu")
        return Results.Ok("20% discount");

    return Results.Ok("10% discount");
});

开发阶段一切正常。

随后客户开始报告生产环境出现 HTTP 500 错误。

最终日志显示以下异常：

code

NullReferenceException

一旦知道查找位置，问题并不难解决。

生产环境部署时忘记定义 REGION 环境变量。对 null 值调用 ToLower() 会立即导致请求崩溃。

修复方案简单直接：

code

string region = Environment.GetEnvironmentVariable("REGION") ?? "US";

if (region.Equals("EU", StringComparison.OrdinalIgnoreCase))
    return Results.Ok("20% discount");

这个案例的启示不仅是关于空值检查。它说明仅在生产环境中出现的错误通常由配置差异引起，而非业务逻辑错误。

没有有效日志时，开发者可能花数小时审查应用代码，却完全忽略部署配置。

再进一步思考：这类错误的根本原因在于需要人工记住在机器上设置变量。配置漂移不是编码失误，而是运维失误，是手动管理部署配置的直接产物。

当你发现自己编写运行手册来提醒人们在哪些服务器上设置哪些变量时，这又是一个值得认真思考的"我们为什么还在自己做这件事"的时刻。

验证部署本身

并非所有生产环境问题都源于你的源代码。

部署问题出乎意料地常见。

容器镜像可能未更新。

配置文件可能缺失。

数据库迁移可能失败。

环境变量可能包含错误值。

必需的密钥可能未部署。

回滚操作可能在无人察觉的情况下恢复了旧版本的应用程序。

在假设代码存在缺陷之前，请确认生产环境是否真的运行了你计划部署的版本。

许多事故的解决仅仅是因为发现运行的是错误的构建版本。

所有这些生产环境故障本质上都是基础设施流程的失败，而非编程错误。它们发生在自建部署流水线中，因为这些流水线的验证机制仅限于开发人员有时间构建的部分。

如果团队无法一目了然地回答"当前运行的是哪个版本？"，那么你的部署系统正在为你制造后续需要调试的缺陷。

你真的需要PaaS吗？

在探讨PaaS如何改变调试方式之前，一个诚实的问题值得诚实回答：每个团队都需要PaaS吗？

不一定。PaaS是一种权衡。你将基础设施控制权交给平台并支付溢价，作为交换，你不再需要花费工程时间处理服务器、流水线和可观测性架构。这种权衡是否值得取决于具体情况，有些合理理由确实需要避开平台：

你有特殊基础设施需求：需要GPU计算、定制内核、特殊网络或特定硬件支持的软件，可能根本不符合平台的约束条件。

合规性或数据驻留规则要求完全控制：某些受监管行业需要精确控制所有组件的运行位置和方式。

你处于规模经济反转的体量：对于非常庞大的工作负载，PaaS的资源溢价可能超过自建平台团队的成本。这正是超大规模企业构建内部平台的原因（注意他们构建的是什么：本质上就是自己的PaaS）。

基础设施本身就是你的产品：如果你销售的是托管服务、网络工具或基础设施工具，自行运营才是商业本质。

对于其他所有团队，评估归结为几个关键问题：

当生产环境出问题时，第一小时有多少时间用于查找信息，而不是采取行动？

团队中是否有人在完成产品工作之外，还要兼职维护日志流水线、监控系统或部署脚本？

你能否一目了然地确认当前生产环境运行的精确版本？

上次因环境漂移（如服务器、配置或变量不匹配导致的故障）而浪费一整天是什么时候？

如果这些问题让你感到不适（对于大多数中小型产品团队确实如此），那么你正在支付基础设施税却得不到任何回报。关键信号不是公司规模，而是工程时间的去向。无论是两人初创公司还是五十人产品团队，当没有人需要照看服务器时，都会占据优势。

如果你现在还不确定是否需要PaaS，很可能你确实需要。那些有充分理由自行管理基础设施的团队，通常能明确说出具体原因。

为什么在PaaS上调试更容易

诊断生产环境错误时，最难的部分往往不是找到根本原因，而是找到进行调查所需的信息。

在传统基础设施架构中，日志文件分散在多个虚拟机、容器、负载均衡器和后台工作进程中。当应用程序进行水平扩展时，一个客户请求在完成之前可能需要经过多台服务器。开发人员常常花费更多时间通过SSH登录到机器、定位日志文件和关联时间戳，而不是真正投入精力调试问题。

这些时间成本就是基础设施税的体现。团队在数月前选择自行拥有和运营所有设备时，就选择了这些停机时间。每个小时用于在事故中收集证据的时间，都是团队主动承担的停机时间。

平台即服务（PaaS）能够彻底改变这种体验。

PaaS不再将每台服务器视为需要单独管理的独立设备，而是将您的应用程序视为一个整体服务。所有实例的日志会自动聚合到一个地方，指标数据持续收集，健康检查功能直接集成到平台中。无论您的应用程序运行在一个容器还是五十个容器中，您都可以通过单一仪表板进行查看，而不是面对数十个终端。

当生产环境出现问题时，您可以立即回答关键问题：

问题是否在最新部署后出现？
是所有应用实例都失败，还是仅有一个？
应用程序崩溃前CPU或内存使用率是否出现激增？
哪个版本引入了回归问题？

无需手动收集这些信息，平台已经为您准备好了这些数据。

许多PaaS工具还保留部署历史，使您能够轻松比较每次发布前后的应用行为。如果在部署2.8.1版本后错误率突然上升，这种关联关系将变得显而易见。回滚到之前的部署通常只需几分钟，从而大幅减少停机时间。

基础设施一致性是另一个显著优势。

通过PaaS部署的应用程序每次都基于相同的部署配置创建。开发人员无需担心某台服务器是否运行着过时的运行时环境、缺少依赖项、安装了错误的操作系统包或遗漏了环境变量。一致的环境能够在问题发生前彻底消除一类仅在生产环境中出现的错误。

还记得之前提到的REGION错误吗？在配置声明一次并应用于所有环境的平台上，这类错误根本不会被部署。

或许最大的优势是更快的事件响应速度。

在发生故障时，工程团队不应浪费宝贵的时间从多个系统中收集证据。集中式日志、内置监控、分布式追踪、部署历史和健康检查使他们能够立即开始调查。

这直接转化为更短的平均故障修复时间（MTTR）、更短的停机时间，以及开发人员和客户更优质的体验。

构建易于调试的应用程序

生产环境中的错误是不可避免的。无论工程团队经验多么丰富，复杂系统都可能以意想不到的方式发生故障。

成熟工程组织与其他团队之间的差异不在于错误是否会发生，而在于他们能多快理解并解决问题。

编写有意义的日志，提供上下文信息而非通用错误信息。持续收集指标，使性能趋势在用户投诉前就可见。使用分布式追踪对应用进行监控，以便在服务间追踪请求。尽量使预发布环境接近生产环境，并像对待应用代码一样谨慎处理基础设施配置。

同样重要的是，选择一个让调试变得更简单而非更困难的平台。

依赖手动管理服务器的团队在发生故障时，通常会花第一个小时的时间去收集日志并连接到机器。而使用现代PaaS平台的团队则已经拥有现成的证据。他们可以关联部署与错误峰值，检查每个应用实例的日志，查看基础设施指标，并在不离开任何仪表盘的情况下追踪失败请求。

诚实地评估你们团队的现状。如果你们的工程师需要在他们被雇佣开发的产品之上维护日志管道、监控堆栈、预发布环境一致性和部署脚本，那么你们正在用最昂贵的货币——故障时间——支付基础设施税。除非基础设施运营是你们的主营业务，否则这些工作都是可以交给平台的额外负担。

PaaS不会阻止所有生产环境中的错误，但它能消除许多使这些错误难以诊断的操作复杂性。这意味着更少的时间用于寻找信息，更快的根本原因分析，故障期间更快的恢复，以及更多的时间专注于软件开发而非基础设施管理。

当下一个生产问题出现时（它迟早会出现），你们将花更少的时间询问“为什么我无法复现这个问题？”，而更多的时间思考更关键的问题：“我们当初为什么非要自己做所有这些事情？”

希望你喜欢这篇文章。你可以在LinkedIn上与我联系。

阅读更多文章。

如果你读到这里，请感谢作者以表达你的支持。说声谢谢。

免费学习编程。freeCodeCamp的开源课程已帮助超过40,000人成为开发者。立即开始