如果您是技术项目经理 (TPM)、软件开发经理 (SDM) 或技术领域的经理，您应该会在即将到来的面试中遇到一系列技术问题。最好的问题是开放式问题，它们可以缩小到多个层次，以评估候选人在各个技术领域的知识深度。

我看到许多技术经理被问到的一个常见问题是：

您公司的网站加载速度很慢。调查根本原因并提出解决方案以减轻或修复问题。

这个问题没有单一的最佳答案，但有许多很好的实际场景可以与面试官讨论：

1. 澄清问题

首先，检查网站并确认它实际上真的很慢！可帮助您更好地理解问题的可能原因：

• 您网站的加载时间SLA（服务级别协议）是多少？也许它看起来并不慢，但加载时间超过了 SLA。

• 网站是否通常很慢或某些特定模块（如客户评级）的加载时间比预期的要长？

• 它是一直缓慢还是在特定时间段内缓慢？（例如仅在工作时间）？

• 所有设备（台式机、手机、平板电脑等）都慢吗？

• 对于来自不同地理位置的用户来说，速度慢吗？

你可以在上面的列表中添加更多。根据以上任何一个问题的答案，高延迟的根源可能不同。

2. 日志/指标

澄清问题后，开始检查日志和指标是一个很好的做法。指标可以让您更深入地了解网站的服务状态。

CPU 使用率、内存消耗、磁盘 I/O、服务器上的请求率、数据库响应延迟和缓存命中/未命中数是最应该开始观察的热门指标。

您还可以检查服务器日志以查看某些服务器是否指示故障或确认某些特定请求是否导致问题。

3. 最近的提交

根据我的经验，除非基础设施陈旧或维护不善，否则很少发生硬件故障。此外，可以快速发现和修复与硬件相关的事件。

大多数新问题是由使用模式的意外变化（例如，请求数量的突然增加）或“BAD COMMITS”引起的！

检查事件的开始时间并确认它不接近最近的部署时间。如果是这样，请检查最近版本中的提交并评估是否有可能导致延迟。

4. 前端模块

如果网站前端组件繁重或操作复杂，请排查高延迟是否是前端造成的。有时，图像、js 和 CSS 文件等资源需要很长时间才能加载。以下是一些可能的改进：

• 减少资源的大小：调整图像大小、缩小 js 文件并删除未使用的代码。

• 缓存大的、经常使用的资源，不用每次加载网站都去“源站”下载资源。内容交付网络 ( CDN ) 非常适合缓存频繁请求的资源，以减少地理位置分散的客户端的下载时间。

（左）单服务器分发与（右）CDN 分发方案

许多在线服务（例如 Google PageSpeed Insights）可以识别您网站上的前端问题以及改进建议。

5. 后端服务器

高延迟可能是由 Web 服务器和其他后端服务引起的。设计良好的架构应该有警报并自动替换不健康的服务器（如果在 VM 上运行）。

确保问题实际上出在服务器上，而不是出在服务器运行的应用服务上。例如，如果是应用服务导致内存泄漏，即使您更换/重新启动服务器，稍后也会再次出现该问题。

一个常见的情况是服务器上的负载高于服务器容限，导致处理请求的延迟增加。如果您使用单个服务器，请考虑在“负载均衡器”后添加更多服务器以将负载分配到多台机器上。

如果一天中的特定时间出现高负载，请提前计划并在高负载期间添加更多机器。如果负载模式是意外的，一种选择是使用自动缩放来根据传入的负载自动放大或缩小。

如果您的服务收到大量相同的请求，并且您可以容忍短时间内可能出现的不一致（最终一致性），请考虑在您的服务器前添加缓存。

6. 外部服务

有时，您的服务运行良好，但必须等待从外部依赖项获得响应（例如，外部服务处理目录详细信息，而您的在线商店必须等待在网站上显示商品详细信息）。

在这种情况下，除非外部服务所有者与您合作进行一些调整，否则您无能为力。如果条件允许，另一种选择是为外部服务响应添加缓存。此外，请考虑对其他服务进行异步调用，以避免不必要的等待响应。

7. 数据库

数据库是系统的关键部分，如果不能在系统架构中有效使用，可能会导致许多问题。当涉及到高延迟时，可以根据根本原因提出可能的解决方案：

• 扩展：在 No-SQL 数据库上，您可以水平扩展（添加更多节点）。在 SQL 上，您可以垂直扩展（将数据库服务放在更强大的服务器上）。

• 分片：如果数据模型允许，您可以将数据库分成更小的部分，并将每个部分存储在单独的机器上。例如，您可能将北美、欧洲和亚洲用户的个人资料信息存储在不同的数据库中。

• 副本：另一种选择是添加副本（数据库的副本），以便可以在副本之间分配负载，而不是轰炸单个实例。在常见情况下，每次写入都会填充到所有副本，但读取查询可以转到任何副本。一个例子是在每个地理位置上都有副本，以便每个读取请求都转到地理位置最近的数据库。

• 缓存：如果数据不经常更改，减少数据库负载和响应延迟的一个很好的可能解决方案是使用内存缓存，如Redis。

• 处理慢查询：**来自应用程序的复杂和慢速查询会导致高延迟。例如，如果查询需要多个表连接，则会导致数据库服务器上的巨大负载并增加整体延迟。评估查询的执行时间，并评估您是否可以通过添加更多索引、使用更简单的查询甚至重新设计数据模型来改进频繁复杂的查询。

• 连接池：可能有大量未使用的数据库连接。设计良好的连接池有助于重用空闲连接并避免为数据库创建新连接。

如何避免类似情况？

一个很好的后续问题是如何避免将来再次发生类似情况。您可以考虑的一些可能选项包括：

• 提前计划：如果您正在开展活动或预计网站上的负载会很高，您可以在为时已晚之前进行预先计划和扩展。在亚马逊，对于 Prime 会员日和黑色星期五等重大活动，我们会提前几个月计划。

• 添加指标/警报：尝试添加与服务运行状况相关的指标/警报，以便立即发现任何问题。

• 添加自动回滚：添加自动回滚机制，以便在部署后出现问题时立即回滚可能有害的版本。

• 运行负载/性能测试：偶尔在您的服务上运行负载和性能测试，以发现您的架构或服务的潜在问题，例如内存泄漏。

• 添加更多自动化测试：增加服务的测试覆盖率，以减少错误提交未被发现的可能性。单元测试、集成测试、端到端测试等可以帮助您实现这一目标。