第 0 天/第 1 天/第 2 天：云时代的软件生命周期
在当今的专业 IT 媒体中有一个非常突出的话题，那就是在软件生命周期中的“第 0 天/第 1 天/第 2 天”。在演讲和会议讲话当中，通常着重于使软件开发过程有效且易于管理，为此，有必要明确定义所使用的概念。通常，如果直观地理解基本术语“ 第 0 天 （ Day 0 ） / 第 1 天 （ Day 1 ） / 第 2 天 （ Day 2 ） ”，这在谈论软件生命周期时可能会引起一些歧义。因此，我决定更准确地定义它们，以展示软件开发的整个过程以及它们在实际项目中的使用方式。这篇简短的博客文章提供了“天”的定义，这些“天”被理解为软件生命周期的各个阶段。它还描述了云如何改变了有关软件开发和维护过程的传统思维方式。毕竟，正如《RightScale 2019 云状态报告》所确认的那样，我们正处于“云时代”。该报告解释说，有 94％ 的调查受访者正在使用云（私有云或公有云）。因此，闲话少说，让我们探讨一下“天”和云如何结合在一起。
“天”究竟是什么？
在 IT 中，术语“第 0 天/第 1 天/第 2 天”指的是软件生命周期的不同阶段。用军事术语来说，“第 0 天”是训练的第一天，新兵进入训练阶段。在软件开发中，它代表设计阶段，在此阶段中指定项目需求并确定解决方案的体系结构。
“第 1 天”涉及开发和部署在“第 0 天”阶段设计的软件。在此阶段，我们不仅创建应用程序本身，还创建应用程序的基础设施、网络、外部服务，并实现所有部分的初始配置。
“第 2 天”是产品出厂或交付给客户的时间。在这里，大部分工作都集中在维护、监控和优化系统上。分析系统的行为并做出正确的反应至关重要，因为所产生的反馈循环将一直持续到应用程序生命周期结束为止。
在云时代之前的日子里，这些阶段是分别处理的，彼此之间没有重叠。今天，情况已不再如此。让我们看一下所有这些如何应用于现代应用程序的生命周期。
第 0 天：无聊但必不可少
第 0 天经常被忽略，因为它可能很无聊，但这并不会降低其重要性。成功的软件产品是经过全面规划和设计过程的结果。必须仔细计划系统或应用程序的体系结构以及启动和运行所需的资源（CPU、存储空间、RAM）。其次，你应该定义可衡量的里程碑，以实现项目目标。每个里程碑应有一个准确的日期。这有助于衡量项目的进度，并确定你是否延迟了计划运行。所有项目时间估算都应基于概率，而不仅仅是按最佳情况预估。进行计划时，最好添加缓冲余量，因为意外事件甚至可能使精心策划的计划陷入困境。测试阶段也起着重要的作用，也应该包括在初始项目计划中。这些是基本要求，它们在“云时代”中同以往一样重要。
尽管如此，在计算资源的第 0 天计划中，云还是改变了两件事。由于云可以在项目的任何地方获得不同的资源或新资源（CPU、存储空间、RAM），因此比本地基础设施要容易得多。因此，可以避免在计划阶段犯下的一些错误。另一方面，在计划阶段对特定云供应商的承诺可能会在以后导致供应商锁定。这可能会花费你的金钱，并且需要时间来进行更改，因此选择云供应商时要明智一些。
其次，正如我们当前在向云的迁移中观察到的那样，与运维相关的工作依旧保持不变，但不再专注于基础设施。现在，正是软件在推动着自动化和价值。
第 1 天：实现创意的阶段
对于开发人员和项目负责人而言，第 1 天绝对是最有趣的阶段。最初的设计得以实现，并根据项目的规范创建了基础设施。为了成为真正的云原生，必须遵守最佳实践。可以遵循诸如 十二要素应用程序方法 （ Twelve-Factor Apps methodology ） 之类的准则。此外，使用云端意味着你应该遵循重要的 DevOps 惯例：持续集成/持续交付（如果你想了解有关 CI/CD 的更多信息，请参阅我们的博客文章）。
云为我们带来了从传统方法到软件开发的重要变化：将第一行代码拼凑在一起以进行概念验证后，应用程序即开始运行。你可以从持续集成实践开始，以测试你的应用程序的健全性，但是你很快会让企业迈入到持续交付。在开发应用程序时，我们开始引入一些运维元素，尤其是在使用多个环境的情况下。注意这些运维要素将使维护团队在维护阶段（第 2 天）的工作更加轻松。
在第 1 天期间可以使用几种工具。可以将它们按解决的问题分组。这个列表的顶部应提及“ 基础设施即代码 （ Infrastructure-as-a-code ） ”（IaaC）。 IaaC 就像应用程序或代码一样管理运维环境。这种方法允许将 DevOps 最佳实践（包括版本控制、虚拟化测试和持续监视）应用于驱动基础设施的代码。这里有很多工具可供我们使用，例如 Terraform、Ansible 或 Puppet 等。第二类工具与容器的自动化部署和管理的容器编排系统有关。Kubernetes 及其实现（例如 Google Kubernetes Engine 和亚马逊的 Elastic Kubernetes Service）至关重要。最后，还有诸如 Jenkins、Zuul 和 CircleCI 之类的 CI/CD 系统，可帮助工程师自动化软件的构建、测试以及交付或部署。
第 2 天：日常运维环节
一旦软件准备就绪，它就会上线，客户开始使用它。第 2 天始于此，并引入了包括软件维护和客户支持在内的各个元素。该软件本身将不断发展，以适应不断变化的需求和客户需求。在第 2 天期间，主要重点是建立反馈循环。我们监控该应用程序的工作方式，收集用户反馈并将其发送给开发团队，该团队将在产品中实施该应用程序并发布新版本。军事术语“ 观察-导向-决定-行动 （ Observe-Orient-Decide-Act ） ”（OODA）恰当地抓住了这一阶段发生的事情。
- 观察：从监视系统获取信息（资源使用情况和指标，应用程序性能监控）。
- 导向：执行问题的根本原因分析。
- 决定：找到解决问题的方法。
- 行动：实施解决方案。
与战斗中一样，该循环不断重复。
监控程序基于 服务水平协议 （ Service Level Agreement ） （SLA）中定义的要求。 SLA 基于 服务水平目标 （ Service Level Objectives ） （SLO），代表我们的 服务水平指标 （ Service Level Indicators ） （SLI）的状态。自动化和监控是解决第 2 天职责的关键。
有几种工具可帮助完成第 2 天的工作。 应用程序性能监控 （ Application Performance Monitoring ） （APM）类软件可以帮助 IT 管理员监控应用程序性能，从而提供高质量的用户体验。在这里，我们可以点名 Datadog、Dynatrace、SignalFX 或 Nutanix Xi Epoch。 还有一些自动化和编排工具，例如 Ansible 或 Kubernetes，可帮助管理应用程序环境。你可能已经注意到，这些工具的应用与第 1 天的工作重叠。最后，工单系统（例如 Servicedesk 或 Zendesk）可以处理客户服务，使用户可以报告故障以及与他们正在运行的应用程序有关的问题。
云将改变游戏规则
在前云时代，这些阶段之间的分隔清晰可见，但是今天，随着云的日常运行，事物在不断变化。使用云和现代软件开发实践，可以更轻松地处理软件生命周期中不断变化的要求。持续集成/持续开发方法使我们能够动态响应客户反馈并实时改进应用程序，而无需等待主要版本进行改进。
基于云和原生云的软件中的 DevOps 实践有助于实现 向左移动 （ shift left ） （LCTT 译注：环节前置的意思），这意味着传统上一直保留到最后的步骤现在可以更快地执行。除此以外，这导致第 1 天和第 2 天现在相互重叠。此外，传统软件开发的最大痛点在于从第 1 天到第 2 天的过渡：从开发人员到运维人员的过渡。现在，DevOps 展示了如何解决此问题：及早启动流程，并使流程一直运行到应用程序生命周期结束。最后但同样重要的是，工具链正在完善，这使得执行第 1 天的任务和适应第 2 天的更改成为可能。 可以根据我们的需求对所使用的工具进行建模，并且过程中涉及的每个人都可以使用同一套工具。