Git 和其他现代化运维工具可以简化 Day 2 运维，即使对于最复杂的云原生应用也是如此。
译自 Learn to Love Day 2 Operations with GitOps-Driven API Management，作者 Emile Vauge。
让我们面对现实：爱上 Day 2 可能很难——应用程序部署到生产环境后发生的一切。对于支持现代 云原生应用程序 的许多工程师来说，Day 2 一直是手动监控和管理流程、孤立的操作以及对破坏某些内容的担忧。
Day 2在现代环境中通常如此具有挑战性的一个核心原因是，它们涉及大量连接的系统，而管理所有这些系统——以及 连接它们的 API——可能非常困难。API 是将现代分布式应用程序粘合在一起的粘合剂；然而，如果你以命令式、手动的方式进行开发、监控和更新 API，则可能会非常耗时且乏味。
这是针对微服务应用程序管理 API 的传统方法的情况。但这不必如此。通过更现代的策略——基于 Git 和其他对现代运维至关重要的工具——你可以简化和精简Day 2运维，即使是最复杂的云原生应用程序也是如此。
Day 2运维包含所有任务——包括 API 部署、版本控制、监控、故障排除、事件缓解和更新——团队必须执行这些任务才能持续保持应用程序的正常运行。
鉴于根据 Palo Alto Networks的说法，当今单个应用程序平均依赖 26 到 50 个 API ，管理Day 2运维具有挑战性的原因有很多：
- 缓慢的变更管理： 开发人员通常会持续对现代应用程序推出变更，但实施这些变更可能是一个缓慢而乏味的过程。如果团队必须手动测试和部署每个新版本，或者发布流程没有完全自动化，则尤其如此。
- 根本原因分析： 现代应用程序的复杂性加上它们依赖的大量 API 意味着查明故障的根源并非易事。例如，如果 API 发送了一个格式错误的请求，你如何知道问题是由于 API 配置问题、应用程序处理故障、网络故障还是其他原因造成的？答案很少是显而易见的。
- 缓慢的事件缓解： 持续改进，即团队应该始终寻找改进应用程序和 API 的机会这一理念，与现代环境齐头并进。但是，要将持续改进付诸实践，你必须能够像进行更改一样快速地记录更改。这使你的团队能够更轻松地对更改后出现的故障或事件进行故障排除。
- 协作： 监控和管理应用程序需要不同利益相关者之间的协作，例如 IT 工程师（他们通常会检测到稳定性或性能问题）、安全分析师（他们会识别安全问题）和开发人员（他们编写和更新代码来修复问题）。除非每个组都可以访问相同的见解，否则他们很难有效地协同工作。
这些不同的挑战根源于相同的基本原因：复杂性。当你有复杂的应用程序架构和复杂的 API 时，在降低风险的同时快速创新比在更简单的环境中要困难得多。基于虚拟机的单体应用程序很少依赖 API（如果有的话），可以更快、更轻松地进行监控和更新，因为它包含的活动部件更少，潜在故障点也更少。云原生应用程序并非如此。
面对现代应用程序的Day 2运维挑战，团队该怎么做？
错误的答案是避免复杂的架构。云原生应用程序及其支持的 API 更难管理，但避免它们意味着错失现代应用程序提供的更大的可扩展性、可靠性、成本效益和其他重要优势。
更明智的策略是在有意义的情况下开发云原生应用程序（或将单体架构重构为云原生架构），同时利用现代运维来简化Day 2运维。
例如，现代运维意味着使用 Git 来管理和自动化环境配置。这使 GitOps（GitOps）涉及编写资源的声明式配置文件，在 Git 中存储和版本控制它们，并自动将更新推送到生产环境。
GitOps 方法简化了围绕Day 2运营的一些最深层次的挑战，尤其是涉及 API 的那些挑战：
- 精简变更管理： 当你在 Git 中管理所有 API 配置时，任何想要进行更改的利益相关者都可以通过适当的 Git 存储库进行更改。这可以加快事件解决速度，并简化团队之间的协作。
- 集中式真实来源： Git 成为一个集中式真实来源，团队中的任何人都可以使用它来跟踪 API 配置和部署的状态，以及其他基础设施和应用程序（因为它们的配置也通过 Git 管理）。这也简化了跨团队的协作。
- 即时回滚： 由于存储在 Git 中的配置会自动进行版本控制，因此很容易回滚导致问题的更改。你可以快速恢复到配置文件的早期版本，并将其还原到工作状态，从而争取时间来解决触发故障的问题。
- 更快的创新： API 配置的自动化管理意味着你可以快速有效地进行更改，从而带来更快的创新和更快乐的工程师，因为你的团队不必花费太多时间和精力来进行改进。
- “快速失败”的能力： 通过 linting 执行自动化配置检查并利用可重复的部署，可以帮助团队在创新时快速失败，同时还能控制风险。
简而言之，现代运营为你提供了Day 2的双重优势：降低风险和快速协作创新。而且，由于现代运营是自动化且可重复的，因此你可以像管理一个 API 一样轻松地管理 1,000 个 API。你的扩展能力几乎是无限的。
传统的 API 管理方法可以追溯到云原生革命之前，云原生革命使高度可扩展的分布式环境成为常态。如今，Day 2运营需要自动化。事实上，自动化是获取云原生策略优势的唯一途径。
从 API 管理的角度来看，自动化意味着超越缓慢的变更管理、漫长的恢复流程和对 API 的控制不力。它需要采用一种现代的、轻量级的、模块化的、Kubernetes 原生的、基于 GitOps 的 API 管理方法，而这正是你应该从现代 API 管理解决方案中期待的。