18、云灾难恢复与DevOps文化助力软件高效交付

云灾难恢复与DevOps文化助力软件高效交付

1. 云灾难恢复

在云计算环境中，存在一些灾难性情况，例如云服务提供商倒闭或被收购后关闭。对于存储关键数据的SaaS应用，消费者应考虑请求提取数据。拥有数据虽不能让消费者迅速恢复系统运行，但可防止数据丢失，并能将数据加载到数据库进行查询。若SaaS供应商关闭且消费者无数据，除采取法律行动争取数据访问权或寄望供应商有资源提供数据外，别无他法。从风险缓解角度看，定期提取数据并归档是更安全的做法。

1.1 混合云灾难恢复

混合云为灾难恢复提供了独特方式。在混合云环境中，企业可在公共云和私有云之间分配工作负载。对于在公共云运行的工作负载，私有云可设为故障转移数据中心；对于在私有云运行的工作负载，公共云可作为故障转移数据中心。为实现这一点，公共云和私有云应尽可能利用相同的云服务。以下是几种混合云实现方式：
- 混合IaaS专有模式 ：假设专有公共云提供商是AWS，为保持公共云和私有云系统一致，需使用支持AWS API的私有云解决方案，如Eucalyptus。但Eucalyptus并非支持所有AWS API，因此应将需要故障转移的架构组件的AWS API限制为Eucalyptus支持的API。
- 混合IaaS开源模式 ：可利用开源IaaS解决方案，如OpenStack，在公共云和私有云都运行该软件。在此情况下，相同代码可在两个云环境运行，无需像Eucalyptus示例那样限制API使用。
- 混合PaaS模式 ：要实现PaaS在公共云和私有云之间的故障转移，需先选择私有PaaS。有多个开源和商业私有PaaS提供商，许多与OpenStack集成或正在集成，且能在AWS（或任何基础设施）上运行。不过，私有PaaS的缺点是云服务消费者仍需管理基础设施层、应用程序栈和PaaS软件。但如果需要在公共云和私有云之间进行故障转移，私有PaaS是唯一解决方案，因为公共PaaS无法在私有基础设施上运行。

1.2 AEA灾难恢复规划案例

Acme eAuctions（AEA）为进行灾难恢复设计，参考其业务架构图，为恢复时间目标（RTO）、恢复点目标（RPO）和架构各组件赋值。架构中最关键部分是买家服务，买家每无法购买产品一秒，AEA就会损失收入。其次是API层，API层故障时，外部合作伙伴无法访问系统。卖家服务是下一个关键组件，卖家服务故障时，无法发起新拍卖和更改现有拍卖，但买家仍可对活跃拍卖出价。业务流程中，支付卖家流程可能比其他服务停机时间长，且该服务由第三方解决方案处理，AEA无需在云中处理信用卡和支付。后端系统可停机时间最长。

最关键组件（买家服务、API、卖家服务）将设计为在多个活跃 - 活跃云环境中运行，AEA选择在公共云运行。这些关键组件需在云服务提供商的多个数据中心运行，每个数据中心都将服务作为活跃状态运行，流量将路由到离请求者最近的数据中心。若该数据中心不可用，流量将路由到下一个可用数据中心。AEA认为活跃 - 活跃热架构可提供高可用性和快速恢复时间。此外，AEA计划利用现有数据中心作为另一个故障转移数据中心，但实现该目标所需工作远超当前交付时间框架，因此将该任务列入待办事项并暂时列为低优先级。若公共云的活跃 - 活跃热解决方案未来无法满足AEA需求，可转向构建混合解决方案，使现有数据中心也可作为备份。后端系统采用更传统的数据备份和异地存储模式，有二级冷站点在灾难发生时恢复这些组件的服务。

以下是AEA灾难恢复规划的关键组件优先级表格：
| 关键组件 | 重要性描述 |
| ---- | ---- |
| 买家服务 | 最关键，买家无法购买产品会导致收入损失 |
| API层 | 次关键，故障时外部合作伙伴无法访问系统 |
| 卖家服务 | 较关键，故障时影响拍卖发起和更改，但不影响买家出价 |
| 支付卖家流程 | 相对不那么关键，由第三方处理，可停机时间较长 |
| 后端系统 | 可停机时间最长 |

2. DevOps文化助力软件交付

DevOps是一种相对较新且常被误解的概念。很多人将DevOps视为一种IT角色，即开发者和系统管理员的混合体。但实际上，DevOps并非一个团队或角色，而是一种文化转变，是关于软件开发和发布的新思维方式。DevOps运动旨在打破部门壁垒，促进开发、运营、质量保证、产品和管理之间的沟通与协作。

2.1 DevOps思维的发展

2009年，首届DevOps Days会议在比利时举行，受John Allspaw和Paul Hammond的演讲“10 Deploys per Day: Dev and Ops Cooperation at Flickr”启发，多位从业者聚集讨论如何在开发者和运营人员之间创建更具协作性的文化。会议参与者在Twitter上使用#DevOps标签讨论会议，随着全球各地举办更多DevOps Days会议，该话题获得越来越多支持，最终该标签成为这一新兴运动的名称。

DevOps运动源于从业者处理脆弱系统的挫折感。由于软件在各部门独立开发，不同团队之间沟通不畅，系统变得脆弱。开发者常缺乏高效工作所需的环境和工具，运营团队则常接收未经充分沟通的软件进行支持。部署过程复杂且易出错，导致发布周期变长，风险增加。这些脆弱系统积累了大量技术债务，使系统维护难度随每次发布增加。

脆弱系统导致非计划工作增加，资源从计划工作转移到非计划工作，影响项目进度和交付日期。为缓解日期延误风险，开发者被迫采取捷径，这通常导致架构不合理、安全和可维护性等非功能需求延迟，以及其他关键稳定性功能缺失，进而产生更多技术债务，形成恶性循环，导致质量、可靠性、士气和客户满意度随时间下降。

为打破这种恶性循环，DevOps运动采用系统思维方法。早期创新者提出CAMS概念，即文化、自动化、测量和共享。DevOps的目标不是招聘开发和运营方面的超人专家，而是以开发、运营和质量保证需求相互关联且需协作的思维构建系统。在DevOps文化中，每个人对整个系统负责，有共同使命和激励机制，对交付和质量负责。

DevOps思维可归结为以下四个原则：
1. 理解工作流程。
2. 始终寻求提高流程效率。
3. 不向下游传递缺陷。
4. 深入理解系统。

这些原则适用于整个团队，团队成员应全面理解系统流程，主动寻找改进流程和消除浪费的方法，从上到下理解整个系统。此外，团队必须确保缺陷不会长期存在，因为缺陷存在时间越长，修复成本和复杂度越高，会导致未来出现非计划工作。

为实现软件从概念到开发再到发布的高效流程，团队应关注以下六种实践：
1. 自动化基础设施
2. 自动化部署
3. 设计功能开关
4. 测量
5. 监控
6. 快速实验和失败

以下是DevOps实践流程的mermaid流程图：

graph LR
    A[自动化基础设施] --> B[自动化部署]
    B --> C[设计功能开关]
    C --> D[测量]
    D --> E[监控]
    E --> F[快速实验和失败]

2.2 具体DevOps实践

• 自动化基础设施 ：云计算的一大优势是可通过API抽象基础设施，使我们能将基础设施视为代码。由于基础设施的配置和取消配置可通过脚本实现，没有理由不自动化环境创建。最佳实践是确保每个以完整代码集结束的冲刺也包含相应环境。通过执行此策略，冲刺中的用户故事应包含必要的开发、运营和质量保证要求。通过将代码及其测试框架与环境一起交付，可大大提高工作流程效率。

在过去，代码交付后会被交给质量保证团队，再由质量保证团队交给运营团队创建合适环境。由于各部门之间缺乏协作和沟通，运营团队需进行大量来回会议、电话和电子邮件沟通，手动创建正确环境，这常导致瓶颈和环境问题。而且，代码首次在新环境中运行时，常引入项目生命周期后期的新错误。发现后期错误会导致团队优先处理关键错误，将其他错误放入待办事项，可能永远无法解决。

运营团队应授权开发人员以受控方式创建自己的环境。提供自助服务基础设施是提高开发流程效率的另一种方式，但缺乏适当治理时，自助服务可能导致混乱、环境不一致、成本未优化等问题。正确实现自助服务配置的方法是创建标准的机器映像集，具有适当访问权限的人员可按需请求。这些机器映像代表安装了所有适当安全控制、策略和标准软件包的标准机器。例如，开发人员可从开发或质量保证环境的标准机器映像集中选择运行Ruby的Web服务器、运行NGINX的应用服务器、运行MySQL的数据库服务器等。开发人员无需配置这些环境，只需请求映像和相应目标环境，环境将在几分钟内自动配置完成。这是基础设施即服务（IaaS）模型中自助服务配置的工作方式。在平台即服务（PaaS）模型中，具有适当访问权限的开发人员可使用PaaS用户界面在非生产环境中执行相同的自助服务功能。
- 自动化部署 ：自动化部署是提高软件开发流程效率的关键任务。许多公司已完善自动化部署，实现每天多次部署。为实现自动化部署，代码、配置文件和环境脚本应共享单个存储库，这使团队可编写部署流程脚本，同时执行构建和相应环境配置。自动化部署减少了部署周期，因为消除了人为错误因素。更快、更高质量的部署使团队能够更频繁、更有信心地部署，更频繁的部署导致变更集更小，降低了失败风险。

在过去，部署是繁琐的手动过程，依赖特定人员的知识，过程不可重复，部署常安排在深夜或清晨，且部署出现问题后需紧急修复。由于部署困难且易出错，团队因担心破坏生产系统而减少部署频率。自动化部署旨在解决所有这些问题，使部署变得简单，任何具有适当权限的人只需选择版本和环境并点击按钮即可部署软件。一些掌握自动化技术的公司要求新员工在入职第一天在非生产环境中进行部署作为培训的一部分。
- 设计功能开关 ：现代部署方法的一个新趋势是使用功能开关。功能开关允许功能开启、关闭或仅对特定用户组可用。这有几个好处。首先，如果某个功能出现问题，部署后可快速关闭该功能，使其他已部署功能继续在生产环境中运行，为团队争取时间修复问题并在方便时重新部署该功能。这比团队匆忙修复生产问题或撤销整个版本更安全。其次，功能开关可用于让特定用户组在生产环境中测试功能。例如，虚构的拍卖公司Acme eAuctions推出新拍卖功能，允许主持现场拍卖的人激活网络摄像头让出价客户看到她。通过功能开关和相应用户组设置，该功能可仅为员工开启，让他们在生产环境中进行模拟拍卖，测试性能和用户体验。若测试可接受，可选择在特定地理区域进行公测，收集客户反馈后再向所有用户推出。
- 测量、监控和实验 ：通过利用功能开关，可进行A/B测试等实验，收集系统和用户信息。例如，产品经理认为某些用户的注册流程过于复杂，想测试新的简单注册表单。通过功能开关和配置，新注册页面可配置为每请求一次注册页面就显示一次，以便团队比较新注册页面和现有注册页面的用户指标。也可在特定地理区域、特定时间段、特定浏览器或设备上测试功能。

功能开关还可用于在生产环境中针对实际生产负载测试功能。功能可针对测试组或在特定位置进行公测，启用后可密切监控，收集足够数据或检测到问题时关闭功能。DevOps文化鼓励这种实验，“快速失败”是DevOps中常用的短语。通过一键自动化基础设施和部署以及功能开关的可配置性，团队可快速实验、学习和调整，从而获得更好的产品和更满意的客户。
- 持续集成和持续交付 ：持续集成（CI）是每次代码提交时构建和测试应用程序的实践，无论变更大小，开发者都应养成提交工作的习惯。持续交付（CD）在CI基础上更进一步，除了构建和测试，还增加了自动化测试和自动化部署。CD通过确保在整个生命周期而不是在后期进行测试来提高软件质量。此外，若构建过程中任何自动化测试失败，构建过程将失败，这可防止缺陷引入构建，提高系统整体质量。通过利用CD，可获得始终可工作的软件，每个成功集成到构建中的变更都成为发布候选版本的一部分。

在过去，只需几分钟的错误修复通常需等待许多其他用户故事完成后才能打包成大版本发布。在这种模式下，软件在经过专门质量保证人员验证前被认为是不正确的。测试是开发后的一个阶段，质量责任由质量保证团队承担。开发者常为满足开发截止日期而向质量保证团队交付低质量代码，质量保证团队为按时将代码交付给运营团队发布软件，常不得不偷工减料完成测试，导致已知错误流入生产系统。这些错误会经过优先级排序，仅处理最关键的错误，以确保项目日期不被错过或进一步延误。

而在CD模式下，除非自动化测试表明软件有问题，否则软件被认为是正确的。质量是每个人的责任，测试贯穿整个生命周期。要成功使用持续交付运行项目，团队成员之间必须有高度的沟通和协作，以及信任和责任感。这正是DevOps运动所代表的文化类型。

虽然DevOps文化、持续集成和持续交付并非在云计算中构建软件的必需条件，但这三个概念源于创新从业者利用云计算的最大优势之一——基础设施即代码，并结合精益制造的一些成熟最佳实践。云计算的最大承诺之一是敏捷性，每个云服务模型都为我们提供了比以往更快推向市场的机会。但要实现这种敏捷性，不仅需要技术，还需要人员、流程和技术的结合。技术已经具备，人们阅读相关内容是为了学习如何利用这项惊人技术实现业务目标，但没有良好的流程，敏捷性将难以实现。例如，有一个客户构建了出色的云架构，改变了所在行业的业务格局，但随着公司从初创企业发展为大公司，未建立成熟的构建和部署流程，创建了名为“DevOps”的运营人员孤岛，开发者将代码交给质量保证团队，质量保证团队再交给DevOps团队，DevOps团队成为巨大瓶颈。该团队的目标是自动化构建和部署，但这并非共同责任，所有问题都落在该团队身上，只能逐步解决问题，最终导致大量错过截止日期、部署成功率低、质量差、客户不满和士气低落。尽管该公司的技术优于竞争对手，但IT内部的瓶颈使其无法通过快速添加更多功能来进一步区分市场。

综上所述，无论是云灾难恢复还是DevOps文化，对于企业在云计算环境中高效、可靠地交付软件都至关重要。企业应根据自身情况制定合适的灾难恢复计划，同时积极拥抱DevOps文化，提高软件开发和交付的效率与质量。

云灾难恢复与DevOps文化助力软件高效交付

3. 云灾难恢复与DevOps的关联及综合应用

云灾难恢复和DevOps文化看似是两个不同的领域，但实际上它们在提升企业软件交付的效率和可靠性方面有着紧密的联系。云灾难恢复为软件系统提供了应对突发情况的保障，确保在灾难发生时数据和服务的可用性；而DevOps文化则侧重于优化软件开发和部署的流程，提高软件的质量和交付速度。

3.1 云灾难恢复对DevOps的支持

云灾难恢复的措施可以为DevOps实践提供稳定的基础。例如，在持续集成和持续交付（CI/CD）过程中，如果没有可靠的灾难恢复机制，一旦出现云服务提供商故障等问题，可能会导致整个交付流程中断。通过定期提取数据并进行备份，以及利用混合云的故障转移能力，可以确保在遇到灾难时，CI/CD流程能够快速恢复，减少对项目进度的影响。

同时，云灾难恢复的规划也有助于DevOps团队更好地进行风险评估和管理。在设计DevOps流程时，考虑到可能的灾难情况，可以提前制定应对策略，如在自动化部署中设置备用环境，以确保在主环境出现问题时能够迅速切换到备用环境。

3.2 DevOps对云灾难恢复的优化

DevOps文化中的自动化和协作理念可以优化云灾难恢复的过程。自动化基础设施和部署可以使灾难恢复过程更加快速和准确。例如，通过自动化脚本可以在短时间内完成备用数据中心的启动和配置，减少人工干预带来的错误和延迟。

此外，DevOps强调的跨部门协作可以提高云灾难恢复的效率。开发、运营和质量保证团队之间的紧密沟通和协作，能够确保在灾难发生时，各个环节的人员都能迅速响应，共同解决问题。例如，开发团队可以提供技术支持，帮助运营团队快速恢复系统；质量保证团队可以对恢复后的系统进行测试，确保系统的稳定性和可靠性。

以下是云灾难恢复与DevOps关联的表格：
| 关联方面 | 云灾难恢复对DevOps的支持 | DevOps对云灾难恢复的优化 |
| ---- | ---- | ---- |
| 流程稳定性 | 提供稳定基础，确保CI/CD流程在灾难时可快速恢复 | 通过自动化和协作优化恢复过程，减少延迟 |
| 风险评估 | 有助于更好地进行风险评估和管理 | 在设计流程时提前考虑灾难应对策略 |
| 响应速度 | 保障在遇到灾难时交付流程的连续性 | 利用自动化脚本快速启动备用环境 |
| 团队协作 | 为跨部门协作提供场景和需求 | 促进开发、运营和质量保证团队紧密合作 |

4. 企业实施建议

对于企业来说，要充分发挥云灾难恢复和DevOps文化的优势，需要在多个方面进行努力。

4.1 制定全面的云灾难恢复计划

企业应根据自身的业务需求和风险承受能力，制定详细的云灾难恢复计划。这包括确定恢复时间目标（RTO）和恢复点目标（RPO），评估各个业务组件的重要性，以及选择合适的云服务提供商和灾难恢复方案。

在选择云服务提供商时，要考虑其可靠性、数据安全性和技术支持能力。同时，要定期对灾难恢复计划进行测试和更新，确保计划的有效性。

以下是制定云灾难恢复计划的步骤列表：
1. 评估业务需求和风险承受能力
2. 确定RTO和RPO
3. 评估业务组件的重要性
4. 选择合适的云服务提供商
5. 制定详细的灾难恢复方案
6. 定期测试和更新灾难恢复计划

4.2 培养DevOps文化

企业要积极培养DevOps文化，打破部门之间的壁垒，促进开发、运营、质量保证、产品和管理之间的沟通与协作。这可以通过组织培训、开展团队建设活动等方式来实现。

同时，要建立相应的绩效考核机制，激励员工积极参与DevOps实践。例如，将软件质量、交付速度和客户满意度等指标纳入绩效考核体系，鼓励员工共同追求卓越。

以下是培养DevOps文化的措施mermaid流程图：

graph LR
    A[组织培训] --> B[促进沟通协作]
    B --> C[开展团队建设活动]
    C --> D[建立绩效考核机制]
    D --> E[激励员工参与DevOps实践]

4.3 结合云灾难恢复和DevOps

企业应将云灾难恢复和DevOps结合起来，形成一个有机的整体。在制定DevOps流程时，要考虑到云灾难恢复的需求；在实施云灾难恢复计划时，要充分利用DevOps的自动化和协作优势。

例如，在自动化部署过程中，可以设置灾难恢复的触发条件和流程，确保在遇到问题时能够自动切换到备用环境。同时，通过DevOps的监控和测量工具，可以实时监测云灾难恢复的效果，及时发现和解决问题。

5. 总结

云灾难恢复和DevOps文化对于企业在云计算环境中实现高效、可靠的软件交付具有重要意义。云灾难恢复可以保障软件系统在面对灾难时的可用性和数据安全性，而DevOps文化则可以优化软件开发和部署的流程，提高软件的质量和交付速度。

企业应充分认识到云灾难恢复和DevOps的重要性，制定全面的云灾难恢复计划，积极培养DevOps文化，并将两者有机结合起来。通过这些措施，企业可以更好地应对云计算环境中的各种挑战，实现业务的持续发展和创新。在未来的发展中，随着云计算技术的不断进步和企业数字化转型的加速，云灾难恢复和DevOps文化将发挥更加重要的作用。