Odysseas Lamtzidis 2021-04-26
众所周知，“开发”（Dev）与“运维”（Ops）之间的界限已经变得模糊。传统上，系统管理员（sysadmin）负责维护系统的可靠运行，例如保障性能和安全；而开发人员则专注于软件的构建、编码和部署。
如今，随着企业 IT 环境日益复杂，这两种角色几乎已合二为一。为了应对不断增长的基础设施需求，开发团队和运维团队意识到，他们不能再各自为政、孤立运作——这直接催生了现代 DevOps 的演进。尽管如此，开发与运维这两项职能对业务连续性仍然至关重要。如果组织不能充分满足开发人员和运维人员的需求，就将在竞争中处于极大劣势。
DevOps 的融合及其不断演变的角色，并不在于招聘技能最全面的开发人员，或通过增加人手来解决新出现的挑战，而在于将现有团队真正凝聚在一起。然而，即便许多公司已经完成了这种文化转型，开发人员仍常常被繁琐的系统所拖累，耗费大量时间，丧失创造自由。为了避免这些瓶颈和潜在的职业倦怠，DevOps 团队可以实施若干最佳实践，使基础设施管理变得更加轻松、直观。
这一切最终都归结于 DevOps 团队的监控能力——这种能力能够为所有技术团队成员（包括那些过去通常无需关注组织 IT 基础设施健康状况的成员）提供可操作的洞察。
细粒度可见性至关重要
当正确实施时，基础设施监控可分为两大类：被动式监控（reactive）和主动式监控（proactive）。两者对于确保系统以最高效率运行都不可或缺。只有当所有可用的计算资源都被充分使用、监控并分析时，才能实现这种峰值效率，从而推动业务目标的达成。这些目标可能包括网站的可用性（或正常运行时间），也可能涉及某个功能的响应时间。DevOps 团队之所以应追求峰值效率，是为了识别最优的资源分配方案：如果过度采购计算资源，就会浪费未使用的算力，导致不必要的成本增加；反之，如果资源采购不足，则可能导致业务目标无法实现，造成经济损失。例如，研究表明，网站每宕机一秒，就会有一定比例的用户流失。
被动式基础设施监控侧重于测量和跟踪应用程序运行所依赖的最基本要素，并研究应用程序与其底层生态系统之间的关系，以便在问题发生时及时响应。这项工作可能较为繁琐，但对保障关键业务成果至关重要。
主动式基础设施监控则是 DevOps 专业人士更希望投入时间的方向。由于被动式监控聚焦于问题发生后的响应，主动式监控则使 DevOps 人员能够在问题实际发生前就发现其根本原因。通过预测或监控历史问题的征兆，团队可以在生产系统进一步受损之前加以解决。
DevOps 团队应监控的关键基础设施指标包括：随机存取存储器（RAM）、中央处理器（CPU）、网络和存储——这些对应用程序的正常行为都至关重要。通过密切监控这些方面，开发人员可以更深入地理解其应用程序的基本行为，并据此决定运行该应用所需的基础设施配置。否则，成本很容易失控，尤其是在弹性部署环境中——开发者并非购买具有特定硬件属性的虚拟机（VM），而是使用可自动伸缩的抽象资源。
开发人员常常会突然发现，他们的应用程序表现不如预期，或因设计缺陷而消耗了比预想更多的资源。这种情况会显著推高成本，特别是在弹性部署场景下尤为明显。
著名性能工程师 Brendan Gregg 提出了多种从 Linux 系统获取核心指标的方法，并以此构建了他称之为 USE 方法（Utilization, Saturation, Errors）的性能分析框架。更有洞察力的 DevOps 从业者会注意到，USE 方法与 Google 站点可靠性工程师（SRE）提出的 监控四大黄金信号（Latency, Traffic, Errors, Saturation）具有共通之处——后者在极具影响力的《Google SRE 手册》中首次提出。
例如，在监控 CPU 时，开发人员可参考以下信号：
- 延迟（Latency）：CPU 调度延迟
- 流量（Traffic）：CPU 利用率
- 错误（Errors）：CPU 相关错误（例如故障 CPU 的数量）
- 饱和度（Saturation）：运行队列长度
无论团队选择哪些指标用于被动式或主动式基础设施监控，关键在于为 DevOps 团队提供对其应用程序性能的真实、细粒度的洞察，并辅以数据支持其判断。
让监控无缝集成
在产品早期迭代阶段，开发团队往往承担了大部分运维工作（颇具讽刺意味，不是吗？）。尽管他们可能会在基础设施搭建或部署选项决策时得到 DevOps 或 SRE 专业人员的协助，但最终仍由开发人员负责监控其应用程序，并确保其满足业务目标。因此，简单易用的工具能显著提升生产力——因为开发人员无需纠结于监控工具本身的复杂性，而可以专注于应用程序本身的复杂逻辑。如果你本身就是一名开发者，你很可能深有体会：你希望花尽可能少的时间去配置监控工具（如告警和功能设置），以便把精力集中在编写代码和开发应用功能上。
尽管“零配置”监控工具颇具吸引力，但开发人员应意识到，他们的系统需要具备高度的可定制性，并能轻松集成到现有工具链中。选择与现有流程良好集成的工具，能让开发工作变得更加轻松。在这方面，在持续集成/持续交付（CI/CD）流水线中加入对应用程序的压力测试和负载测试将大有裨益。通过将监控解决方案作为 CI/CD 的一部分，用户可以设置告警，在测试失败时通知流水线。例如，当 RAM 消耗超过某一阈值时，即可触发告警。
总体而言，行业正朝着更高程度的抽象化发展，并普遍认识到：用户并不希望事无巨细地手动配置监控工具的所有细节。易用性和良好的用户体验/用户界面（UX/UI）设计重新成为监控领域的重要考量因素，以体现这一理念。如今的基础设施工具比 20 年前友好得多，这意味着即使是初级 DevOps 工程师或开发人员也能轻松上手。监控整个技术栈已不再是高级工程师的专属技能。市场上涌现的新工具不仅提供了合理的默认配置，而且几乎无需额外设置，就能提供对基础设施系统的全面洞察。从这个角度看，系统越“有主见”（opinionated），就越能替用户做出决策，从而减轻用户的负担。
为确保 DevOps 团队能够达成业务目标，采用那些易于使用、快速部署且维护成本低的监控工具具有明显优势。这类工具不仅让开发与运维真正融为一体，还能确保 DevOps 团队对所用基础设施拥有细粒度的可视性，并根据实际情况灵活采取被动响应或主动预防措施。