仅仅几年前，云计算还被誉为应对任何网络威胁或性能问题的"万能药"。许多人被"永远在线"的梦想所吸引，为了托管服务的便利性而放弃了精细化控制。
近年来，我们中的许多人（通常是通过艰难的经历）了解到，公共云服务提供商并不能免受攻击和SaaS服务中断的影响，他们躲在共同责任模式的保护伞下。为了在当今的威胁环境中保持运营、竞争力和韧性，团队必须摆脱对SaaS提供商的依赖，真正理解网络韧性的含义。
仅在2024年，流行的DevOps SaaS平台——如GitHub、Jira或Azure DevOps——总共经历了502次事故，导致性能下降和服务中断总计超过4755小时。结论很明确：将源代码、开发元数据和工作流项目委托给"大厂"并不能让企业免受停机时间和随之而来的财务损失的影响。
根据GitProtect发布的《2024年CISO DevOps威胁指南》报告，领先的云DevOps服务遭受了48次关键和重大事故。将此与我们即将发布的2025年版报告（通过分析官方提供商和第三方通信编写）进行比较，我们可以看到同比增长69%，总计156次关键和重大事故！
服务性能下降的总时间从2024年的4755小时跃升至2025年的超过9255小时。无论是完全停机、登录失败还是响应迟缓，这些中断正在成为日常运营的持续威胁。
共同责任模式是企业与SaaS提供商之间的常见协议，提供商负责其云基础设施，但企业负责其中的数据，包括源代码存储库、元数据、问题或其他任何内容。尽管一些提供商可能会在数据恢复方面提供帮助，但这种帮助的性质和范围并不总是明确的。最终，企业承担最终责任。
此外，共同责任条款也可能适用于使用本地备份功能在提供商云中进行的备份。一些提供商明确表示，企业无法使用此类备份来恢复某些类型的更改（如故意删除），这让企业暴露在风险中。
底线是：没有DevOps SaaS提供商在合同上有义务保护或恢复企业的数据。
在没有多层数据保护策略的情况下依赖本地DevOps云备份正变得越来越危险。
首先，在与生产环境相同的基础设施内备份代码会创建单点故障。每个人都知道不要把所有鸡蛋放在一个篮子里的谚语。例如，如果Atlassian的Jira宕机，生产和备份数据可能都无法访问，除非SaaS提供商实现了适当隔离的配置。
本地DevOps云备份是基本期望，但孤立来看，它们并不是万能药。企业可能面临的其他问题包括：
恢复限制：如前所述，本地备份可能仅限于SaaS提供商精确定义的恢复场景。因此，企业将无法恢复数据，或者最多需要与提供商协商才能获得真正的帮助。
缺乏灵活性：本地备份机制通常不提供备份和恢复的粒度。因此，如果只丢失了项目的单个分支，企业需要恢复所有内容，浪费时间和资源。
数据缺口：鉴于存储库的动态特性（新的拉取/合并/推送请求）或Jira的工作项，本地备份机制存在创建数据缺口的风险，这在恢复期间会出现问题。
结论？来自SaaS提供商的本地备份已经不够了，进一步加剧了SaaS韧性的神话。
虽然备受瞩目的网络攻击抓住了头条新闻，但依赖SaaS云的公司的日常现实是，服务中断造成了重大的财务和运营损害。研究表明，停机时间远不止是技术不便——它会侵蚀收入、生产力和客户信任等。
对于云优先的组织，上游SaaS提供商的停机可能转化为数十万甚至数百万美元的损失。
信息技术智能咨询调查发现，90%的中大型公司每小时停机成本超过30万美元。对于大型企业来说，情况变得更加严重。财富1000强公司可能面临每小时100万至500万美元以上的停机成本。
其他来源也一致引用了高停机成本。例如，在Uptime Institute的《2024年年度中断分析》中，超过一半的受访者报告他们最近一次严重中断的成本超过10万美元，而16%的人引用了超过100万美元的金额。
有一件事是肯定的：停机成本已经很高，而且每年都在上升。虽然企业可以承受（但仍然痛苦），但它们可能严重影响较小软件供应商的财务，甚至导致它们完全关闭。
SaaS云提供商的故障可能会瘫痪研发（R&D）甚至整个业务活动。特别是当企业严重依赖云时，将其视为协调运营的"中央神经系统"。云优先可能很方便，但如果云着火了，企业也在燃烧。
从技术角度看其如何影响企业：
源代码控制管理冻结——开发人员无法将拉取请求推送到远程git存储库，管理员或高级人员无法运行检查、审查或接受它们。
工作流混乱——如果像Jira这样的任务管理SaaS失败，团队无法访问项目和问题，没有人知道接下来该做什么。
无法访问依赖项——例如，如果GitHub Packages或Azure Artifacts不工作，使用依赖项的应用程序功能也将无法工作。
知识源丢失——团队无法访问问题和wiki来咨询信息、检查事实或优先考虑错误。
测试停止——如果像GitHub Actions或Azure Pipelines这样的测试编排器模块宕机，测试和验证阶段就会中断。
其他（身份验证失败、没有集中通信等）
正如所见，影响可能是巨大的，以多种方式扰乱业务。
这种瘫痪可能导致项目失败或延迟，影响组织的客户或合作伙伴。这种信任的侵蚀反过来可能导致声誉损失，转化为真正的财务成本。
如果企业是在苛刻的服务级别协议（SLA）下创建应用程序的软件供应商，停机可能意味着真正的问题。它可能会暂停关键发布或面向客户错误的热修复。许多SLA要求在4-8小时内进行这些修复。未能满足这些"解决时间"通常会导致合同罚款，增加中断的总成本。
在中断期间承受满足截止日期压力的情况下，团队经常转向影子IT——在没有IT监督的情况下使用未经授权的软件或变通方法。这可能包括通过Slack或个人电子邮件共享代码片段、机密信息或凭据。
这种做法是极不可取的，原因如下：
潜在的代码和专有技术泄露，
潜在的知识产权损失，
在代码中创建漏洞（一旦第三方拦截），
在环境中创建漏洞（如果用户也共享凭据）。
隐藏的威胁？组织可能在停机实际发生很久之后就已经受到威胁。这又是另一个成本，不是吗？
特别是当企业属于受监管行业时，必须确保业务运营各个领域的合规性，包括数据保护。
SaaS停机（以及其他灾难性事件如意外数据删除）可能暴露措施不足，对企业而言，这可能意味着审计失败、认证失败甚至额外成本。本地备份可能不足以涵盖每个恢复场景。
提醒一下，备份数据的义务在许多法规和行业标准中都有定义：
NI2指令第21条，领域：业务连续性，如备份管理和灾难恢复，以及危机管理。
ISO 27001标准附录A中定义的A.8.13（信息备份）控制。
SOC2下的信任服务标准（TSC），如可用性（A1.2）、安全性（CC7.1）。
为了提高对影响上游SaaS提供商的停机事件的免疫力，企业需要从被动转向主动。需要一个B计划。
真正的可用性不是关于系统是否故障，而是关于能多快恢复并恢复正常业务。这就是为什么企业的有效韧性策略应该包括：
频繁和全面的备份，不仅涵盖源代码或问题，还包括配置和元数据。数据应该允许快速在本地（如使用Azure DevOps Server或Bitbucket Data Center等自托管解决方案）或与竞争云供应商重新创建设置，使用交叉恢复功能。
不依赖单一云供应商基础设施的不可变和隔离存储。最安全的选择是确保复制备份，遵循流行的3-2-1备份规则，即在2个不同位置保留3个单独副本，将1个副本存储在异地。设置适合项目生命周期和需求的最佳数据保留也是个好主意。
理解跨服务、API和环境依赖关系的集成恢复编排，能够快速恢复，避免组织混乱。
持续测试恢复流程，避免让备份成为另一个风险。
明确定义的备份关键绩效指标，如恢复时间目标（RTO）和恢复点目标（RPO），以了解灾难后需要多少时间恢复以及多久备份一次SaaS数据以防止丢失。
强大的备份和恢复解决方案可以成为企业对抗SaaS停机韧性策略的支柱。同时，它可以为云存储的存储库或项目带来额外的便利和安全性。作为奖励可以获得：
迁移/合并SaaS环境——使用备份工具，可以迁移到不同的SaaS提供商或云区域；在重组、合并、部门移动等情况下，还可以合并存储库或Jira实例。
沙盒环境——可以使用备份副本快速创建沙盒环境来测试新集成、配置更改等。
合规性的保留和归档——将备份工具与存储结合，可以远远超越SaaS提供商的保留期。还可以归档遗留存储库或Jira项目而不丢失对它们的访问权限。这样，可以在节省SaaS空间的同时仍然访问历史数据。
选择性恢复——可以立即修复分支或几个Jira问题的意外或恶意删除，节省时间并保持敏捷性。
存储主权——可以实施本地部署，最珍贵的数据（专有技术、知识产权、客户和合作伙伴的个人信息）永远不会离开基础设施。
还有更多。
DevOps SaaS平台——就像任何IT环境一样——无法为企业提供100%的安全性和正常运行时间。如果想要专注于创新而不是未来的停机救火，精心规划的韧性策略是必须的。
GitProtect团队可以在这方面提供帮助。凭借在备份行业超过15年的经验以及对SaaS和DevSecOps的独特专注，可以共同制定最有利于企业特定需求的优化策略。访问GitProtect.io，了解产品，并联系专家讨论用例，个性化设置，并有效保护最珍贵的资产。
Q&A
Q1：什么是共同责任模式？它对企业有什么影响？
A：共同责任模式是企业与SaaS提供商之间的常见协议，提供商负责云基础设施，企业负责其中的数据。这意味着没有DevOps SaaS提供商在合同上有义务保护或恢复企业的数据，企业承担最终责任。
Q2：SaaS服务中断会造成多大的经济损失？
A：停机成本非常高昂。90%的中大型公司每小时停机成本超过30万美元，财富1000强公司可能面临每小时100万至500万美元的损失。超过一半的企业报告最近一次严重中断成本超过10万美元。
Q3：如何建立有效的SaaS韧性策略？
A：有效策略应包括：频繁全面的备份覆盖代码、配置和元数据；不可变和隔离的存储遵循3-2-1备份规则；集成恢复编排理解跨服务依赖；持续测试恢复流程；明确定义RTO和RPO等关键指标。
热门跟贴