分类目录归档:架构和远方

SaaS 产品的定制路线和集成路线

最近有和一些做 SaaS 的技术负责人交流,原来专注于做线上 SaaS 业务,今年也开始开放了定制逻辑。

回想之前看到的艾瑞咨询 2024 年发布的《中国企业级 SaaS 行业研究报告》,SaaS 行业有如下的一些变化:

  1. 市场规模、增长预测和行业趋势

    • 2023 年中国企业级 SaaS 市场规模达到 888 亿元人民币,同比增长 13.0%。
    • 预计未来三年,市场规模的增速将稳定在 15%-20% 区间,复合增速约为 15%。
    • SaaS 行业正在经历关键转折点,由快速扩张向精细化运营转变。
    • 宏观经济放缓和资本退潮加速了市场的淘汰过程。
  2. AIGC 技术

    • AIGC 技术在 SaaS 行业的应用,特别是在医疗、人力资源、电商、设计等领域。
    • SaaS 厂商利用 AIGC 技术进行自然语言处理、文本和数据处理,提升服务能力。
    • AIGC 可能重塑 toB 市场未来,SaaS 行业迎来重估时刻。
  3. 企业实践

    • SaaS 在企业中的渗透率不断提升,大型企业倾向于定制集成,中型企业成为平台生态模式的主流应用群体。
    • SaaS 生成的底层逻辑从简单的流量互换转向更深层次的产品融合,集成和被集成可灵活
  4. 投融资情况

    • 投融资活动自 2019 年以来逐步下滑,显示出融资轮次后移的趋势。
    • 2023 年 SaaS 领域的天使轮和 A 轮融资占比回升,过亿元融资事件数量下滑。
    • 投资热度下滑,创业公司需要加强自我造血能力。
    • 行业垂直型厂商在融资轮次上更偏早期,显示出成长机会。
    • 投资机构关注 SaaS 模式的核心价值,重视企业健康度和垂直赛道成长性。

基于这此变化,不难看出,放开定制是一个不得已的选择,或者说是另一条在中国值得尝试的出路。

之前上过公司组织的《商战模拟》培训课,给我印象最深刻的是一切执行动作都需要先选择客户,选择市场

以 SaaS 为例,如果你选择是头部客户,大企业客户,那定制化需求会非常多;如果选择的是尾部客户,则 SaaS 公司面对的定制化需求就很少;而腰部客户的定制化需求介于两者之间。

而在中国做 SaaS 公司,定制是一个跨不过的点,当一个单几百万甚至上千万,需要定制功能,是做还是不做?

这里我觉得决策的点在于当前的公司状态,以及选择的客户,保持战略定力。

今天主要是聊一下头部客户的定制路线,和腰部客户的集成路线。

头部客户的定制路线

SaaS 公司选择头部客户的定制开发,这其实是企业成长过程中的一个重要机会。对于大型企业客户而言,标准化的 SaaS 产品无法完全满足他们个性化的业务需求。这时,SaaS 公司如果能够抓住机会,为客户提供深度定制化的解决方案,不仅可以带来可观的收入,更能建立深厚的合作关系,实现共同成长。

在中国的大企业定制,特别是金融企业、国企等,更加的困难,常见的一些挑战如下:

  1. 部署环境差异大

    • 信创环境要求:随着国家对信息技术应用创新的重视,很多大企业都面临信创改造。这要求 SaaS 产品能适配国产芯片、操作系统、中间件等,并提供相应的兼容性测试报告。同时还要符合信创标准规范,对接国家认证平台。
    • 网络环境复杂:大企业分支机构遍布全国,网络环境千差万别。有的地区带宽不足,有的办公场所内外网隔离,还可能存在多个专有网络。SaaS 产品需要适应不同的网络状况,在保证性能的同时,还要做好异地多活、断网续传等机制。
  2. 安全要求高

    • 网络安全:大企业非常重视网络安全,要求 SaaS 产品提供全方位的防护。比如异常流量检测、DDoS攻击防御、蠕虫病毒查杀等。还要支持细粒度的访问控制和审计日志,对各种网络威胁做到实时预警、快速处置。
    • 应用安全:SaaS 产品自身也要做好安全防护,从代码级别进行安全审计,避免常见的注入、跨站、越权等漏洞。敏感数据要加密存储,访问要严格授权。要定期开展渗透测试,及时修复潜在风险。部署上要实现服务隔离,防止单点故障。
  3. 兼容与迁移

    • 兼容已有系统:大企业的 IT 系统往往经过多年积累,包含各种自研、外采的应用。SaaS 产品要尽量兼容原有系统,减少客户的改造成本。比如对接已有的单点登录、支持常见的数据交换格式、提供标准化的 API 接口等。
    • 平滑迁移数据:从原有系统迁移到 SaaS 平台,数据迁移是一个重要工作。需要做好数据清洗、格式转换、一致性校验等。迁移过程要尽量减少业务中断时间,必要时提供回滚机制。对于数据量大的情况,还要采用增量迁移等策略,平衡时间和成本。
  4. 定制化需求严重

    • 个性化开发:大企业各部门的业务差异很大,标准功能往往难以满足。SaaS 公司需要深入了解各种业务场景,量身定制个性化方案。在产品设计上要预留足够的灵活性和扩展点,便于快速响应定制需求。
    • 定制流程规范:定制开发往往涉及复杂的需求梳理、方案设计、项目实施等,需要有规范的流程把控。比如需求评审会、技术方案会、进度评估会等。要让甲乙双方形成统一的理解和预期,并全程跟踪需求的变化。
    • 定制成果积累:每个定制项目都包含大量的需求分析、技术方案、测试用例等成果。SaaS公司要注重积累这些知识财富,建立完善的知识库。优秀的方案要进行抽象和提炼,形成可复用的功能模型。这既能提升后续项目的交付效率,也能反哺标准产品的研发迭代。

这些挑战落到 SaaS 企业的定制交付团队,实际有如下的困难:

  1. 资源投入大。为头部客户进行定制开发,需要投入大量的人力、物力和时间,这对 SaaS 公司的资源配置提出了更高要求。

  2. 项目管理难度高。定制项目往往涉及复杂的业务逻辑和深度整合,对项目管理能力是一个考验。需要在控制成本、进度和质量间寻求平衡。

  3. 后期维护成本高。由于定制项目的个性化程度高,后期的运维和升级也更加复杂,需要投入专门的团队。

  4. 通用性不足,规模化困难。过度定制可能影响产品的通用性,不利于标准化和规模化发展。

所以在决定是否接受定制开发时,SaaS 公司需要审慎评估自身的能力和资源情况,平衡好短期收益和长期发展。头部客户的地位和资源固然重要,但盲目迎合可能会偏离初心,产品价值也会被稀释。

在做定制开发过程中,关键是要在满足大客户需求的同时,尽量保持 SaaS 产品的相对独立性,将部分定制功能抽象和沉淀下来,形成可复用的模块。这样既能交付项目,又能保证核心产品不断完善,实现可持续发展。定制开发应该成为锦上添花,而非翻越不可的高山。

从方法论的角度来看:高度的定制化,其实是高度的模块化。

腰部客户的集成路线

相比起大型企业的全量定制,腰部客户的需求往往没那么极端。他们追求的是性价比,希望用更低的成本获得符合自身业务场景的解决方案。这时,与第三方产品的集成就成了很好的选择。

SaaS 公司可以保持自己的产品专注度,通过开放 API 等方式,与行业内的各种产品无缝连接。这种去中心化、平台化的生态模式,能充分发挥各方优势,为客户提供一揽子服务,提升整体竞争力。

对腰部客户来说,与成熟 SaaS 产品的集成优势明显:

  1. 实施周期短,见效快:借助现有系统,企业可以快速上线新功能,满足业务变化。
  2. 使用成本更低:直接调用成熟的产品能力,无需额外的开发和运维投入。
  3. 升级更加便捷:随着 SaaS 产品的迭代,客户也能持续受益,保持业务创新。
  4. 专业性更强:每个产品各司其职,发挥自身专长,客户可获得最佳实践。

集成可以分为三个层次:

  1. 轻度集成

    • 集成方式:轻度集成主要基于双方现有的 API 接口,进行基础的功能连接,例如单点登录(SSO)和相对标准化的点对点数据交换。
    • 适用场景:这种集成通常不需要大量的定制开发,适用于功能相对独立、不需要深层次交互的场景。
    • 优点:快速实施,成本低,风险小,易于管理和维护。
    • 不足:功能集成有限,可能无法满足复杂的业务需求,且数据和流程的整合程度较低。
  2. 中度集成

    • 集成方式:中度集成利用集成工具进行跨系统的业务流程和审批流程集成,将不同系统的数据整合到统一的数据看板中进行集中展示和分析。
    • 适用场景:这种集成层次需要更多的协调和数据同步,适用于需要跨系统视图和报告的业务场景。例如,CRM 系统与 ERP 系统的集成,以实现销售和库存管理的协同。
    • 优点:提供更全面的业务视图和流程自动化,增强数据一致性和流程效率。
    • 不足:集成复杂性增加,需要更多的技术投入;可能需要解决数据一致性和系统集成的技术难题。
  3. 重度集成

    • 集成方式:重度集成涉及双方产品在技术和业务层面的深度融合,可能包括账号体系打通、消息体系打通,以及基于深度数据集成满足更复杂的业务流程需求。
    • 适用场景:这种集成层次要求双方在产品开发和业务流程上有更深层次的合作,适用于需要高度协同和定制化的业务场景。
    • 优点:能够实现高度个性化和优化的业务流程;提供更深层次的业务洞察和自动化。
    • 不足:高度集成可能导致技术依赖和复杂性;成本和风险较高,需要专业团队进行维护。

每个集成层次都有其特定的应用场景和需求,SaaS 厂商在选择集成深度时需要考虑产品特性、客户需求、技术能力以及资源投入等因素。随着集成深度的增加,厂商能够提供更加丰富和个性化的服务,但同时也可能面临更高的技术挑战和成本投入。

从企业数字化的角度来看,轻度集成有助于企业快速实现基本的数字化功能,适合初期探索和小型项目;中度集成可以提高企业的运营效率,通过流程和数据的整合,实现更高效的业务管理;重度集成为企业提供了深度定制化的解决方案,有助于构建复杂的业务生态系统,但同时也要求企业具备相应的技术能力和管理水平。

从 SaaS 企业的角度出发:

在产品层面需要需要明确定位,兼顾灵活性和把控节奏

  • 明确定位:SaaS 企业首先要明确自身的产品定位和核心价值,究竟是要做通用型平台,还是聚焦特定领域的专业解决方案。这决定了后续的集成策略和生态布局。
  • 兼顾灵活性:产品在设计之初就要考虑到集成的需求,要预留足够的接口和扩展点。既要保证产品的专业性和完整性,又要兼顾灵活性和可集成性。
  • 把控节奏:产品规划要统筹兼顾,协调好自研和集成的节奏。自研核心功能来保证竞争力,同时也要联合优质合作伙伴,快速完善产品矩阵,满足市场多元化需求。

在技术架构层面需要保持架构开放,制定集成标准以及实现集成工具

  • 架构开放:SaaS 平台要采用开放式的技术架构,基于微服务、容器化等先进理念,实现松耦合、高内聚。要开放丰富的 API,涵盖数据接口、功能接口、流程接口等,便于第三方应用的灵活集成。
  • 集成标准:要制定清晰的集成标准和规范,包括接口定义、安全认证、数据格式等。既要满足通用性,又要兼顾特殊场景。标准要随技术发展持续演进,保持与行业主流的同步性。
  • 集成工具:要提供配套的集成开发工具包,帮助合作伙伴快速完成适配。比如API管理平台、开发者社区、在线调试工具等。还可提供低代码开发平台,降低集成门槛。

在客户服务层面,为不同层次的集成提供针对性的服务

  • 轻度集成:要提供清晰的集成文档和开发指南,帮助客户快速上手。通过在线支持、社区互助等方式,及时解决客户的问题。提供基本的监控功能,帮助客户掌握集成应用的运行状况。
  • 中度集成:除文档支持外,还要提供架构咨询、最佳实践等服务,帮助客户优化集成方案。协助客户进行数据迁移、流程整合等工作。建立预警机制,主动发现并解决潜在的集成问题。
  • 重度集成:要组建专业的集成服务团队,提供端到端的咨询、实施、优化等服务。与客户形成长期的战略合作关系,深入理解客户业务,持续优化集成方案。提供定制化的 SLA,保障关键业务系统的高可用性。

对于 SaaS 企业来说,腰部客户的集成是一个循序渐进的过程。站在客户的角度,理解不同业务场景下的集成需求,匹配相应的产品能力和服务支持。

小结

当下,SaaS 行业正在经历关键转折点,由快速扩张向精细化运营转变。宏观经济放缓和资本退潮加速了市场的淘汰过程。

肖总说:「行情好的时候你们就是人力资源,行情不好的时候,你们就是人力成本

这其实对于 SaaS 行业来说是一个逆境。

冯唐说面对逆境:看脚下,不断行,莫存顺逆

《微信背后的产品观》中张小龙给了研发同学 3 点建议

一直说要把《微信背后的产品观》这本书看完,一直没顾得上,这次临时出差到厦门的路上带上了,动车上的时间把书看完了,去的时候看了一遍,回的时候看了一遍,看完,写下这篇文章。

这本与其说是书,不如说是演讲实录。书的内容来源自张小龙在 2012 年的那次著名的 8 小时演讲,2016 年被整理成书稿,在 2021 年决定出版。好的内容是经得起时间考验的,在 9 年之后出版,在 12 年后的今天来看也不过时,甚至部分观点会刷新我们的一些认知。

以下是我在读这本书的过程感受比较强烈的三个观点或建议。

1 如果解决方案非常复杂,一定是问题错了。

这是从一个开发能力很强很全面的在朋友圈抱怨:「觉得微信的代码越来越复杂了,开始搞不定了」,张小龙在下面评论说:「如果一个问题的解决方案太复杂,一定是问题本身错了。事实上就是这样子的。

一个好的问题不应该导致解决方案太复杂。

从研发的角度来看,引申出来有 3 点:

1. 如果解决方案非常复杂,一定是问题错了或者是需求有问题

很多时候,我们在面对一个问题时,容易陷入复杂的解决方案中或者限入为了解决问题而解决问题。但其实当一个解决方案变得非常复杂时,我们应该反思问题的提法是否正确,需求是否是真正的需求。一个好的问题应该能够用一个相对简洁优雅的方案去解决。

陷入困境时我们要学会换个角度或者跳出问题来思考问题。当感到解决方案过于复杂时,不妨退一步问问自己,是不是对需求或问题有误解,有没有更本质更简单的诉求。化繁为简,用简单的方法解决问题,是一种智慧。

2. 优秀的工程师其实可以帮助产品经理矫正需求

产品经理提出的需求,研发同学往往会无条件去满足。但优秀的工程师,应该具备产品思维,有能力去审视和质疑需求背后的逻辑,去引导产品经理矫正需求。

一味地满足需求,只会让产品变得复杂和庞大。优秀的工程师应该成为产品经理的思想伙伴,而不仅仅是执行者。在开发过程中提出合理化建议,做有价值的事,把控产品的定位和走向,这是更高境界的工程师素养。

3. 写代码只是其次,思考和讨论产品也是重要的工作

作为研发同学,不能把自己局限在写代码上。思考产品,了解用户,参与需求讨论,才能真正驱动产品的进步。

代码只是工具,而洞察需求,理解人性,思考产品形态,决定产品体验,这些应该是每一个研发同学的内功。要把自己的视野拓展到产品层面,主动去思考为什么做这个功能、用户会喜欢吗、还能怎么改进体验。唯有这样,才能成为真正优秀的工程师。

2 抽象方能化繁为简

这个观点应该是大部分场景下面,研发同学都认同的。

当面对大量繁杂的需求时,与其逐一满足,不如试图提炼出其中的共性和本质,将之抽象为更少量、更高层次的需求。这个过程就是「抽象」。

以订阅内容为例,如果把各类内容提供方(如企业、个人、媒体等)的形形色色的诉求都一一满足,系统必然会变得非常复杂。但若能抽象出一个统一的账号体系和内容载体,就能用一套接口来服务各方,大大简化了系统。

抽象的层次越高,派生出的子需求就越多。比如将 100 个需求抽象、归纳为 10 个,甚至 1 个,则原本的 100 个需求都可以被这 10 个或 1 个「母需求」所覆盖。

要做好抽象,关键是要找准需求的共性、本质之处,即所谓的不变量,而非沉陷于各自差异化的细枝末节。唯有升维思考,才能在更高层次上对繁复的事物进行归纳和简化。

通过「以简御繁」「归一化」的抽象思路,可以大大降低系统复杂度,提升开发和管理效率。同时让产品对用户更加友好,使用更加简单统一。

这种化繁为简的抽象思维,是一种非常重要的思考方式和设计原则,对于管理大型复杂系统、满足多元需求有重要指导意义。不仅开发人员要掌握,其他非技术人员也很有必要学习这种思维方式。

3 改变旧世界的意愿

在书中,改变旧世界的意愿是在气质篇的第一篇,从其定义上更多的是一些日常记录的点。

在「改变旧世界的意愿」这一点上,张小龙提到了自己:「对于对iPhone5的唯一期待是,像iPad(3G)一样,不支持电话功能。这样,我少了电话费,但你可以用kik跟我短信,用 googlevoice跟我通话,用 facetime 跟我视频。」

做一个产品,意愿是很重要的。我们有没有去一个改变旧世界的意愿

作为一个研发团队的管理者,改变旧世界的意愿是一个团队管理中的核心逻辑。上次和小帅聊天,也有聊到我们在团队管理岗上,我们始终应该改变点什么

「改变旧世界」的意愿,本质上是一种创新驱动和价值追求。它意味着不满足于现状,主动去探索和尝试新的可能性,并以之来重塑既有的产品形态、技术架构乃至商业模式。这种意愿需要从管理者开始,成为团队的共识和愿景,并指引技术决策和项目实践的方向。

技术管理者需要与团队一起,去思考如何用技术的力量去创造更多的附加价值,解决用户和业务的痛点。要审视自己的产品定位和技术路线,看是否还有优化和颠覆的空间。同时要放眼行业前沿和未来趋势,去探索下一个风口和变革点。唯有确立了明确的变革方向和价值诉求,才能凝聚共识,激发动力。

事实上,很多时候阻碍我们「改变旧世界」的,恰恰是技术和架构层面的「旧世界」。长期累积下来的历史债务,割裂的系统,低效的架构,过时的技术栈,都成为了创新的桎梏。团队往往需要耗费大量时间和精力在修修补补和「打补丁」上,而无暇去思考和实现变革。

这就需要技术管理者下定决心,带领团队去正视和解决技术债务。要客观评估既有系统的健康度,识别出最急需重构和升级的部分。同时要重新思考整个技术架构,看如何通过解耦、重构、引入新技术等手段,来提升系统的灵活性、可扩展性和创新友好度。只有在架构层面打好基础,才能为变革扫清障碍。

除了对技术、架构、债务的改变,「改变旧世界」的意愿,还需要适配研发团队的现状和组织形态。如果团队长期处于产品需求的压力之下,缺乏思考和探索的时间;如果组织过于层级化和官僚化,创新的想法很难被听到和采纳;如果绩效考核过于短视和功利,大家不愿承担变革的风险,那么这种意愿就很难真正落地。

技术管理者需要为团队争取一定的自主权和探索空间。在项目排期和任务分配上,要预留出一定比例的「创新时间」或者技术时间,鼓励大家尝试新的 idea。同时要优化组织架构和流程,让信息和想法能够更顺畅地在团队中流动,减少决策链路,提升反应速度。绩效评估也要将创新和长期价值纳入考量,为「改变」提供合理的回报。

从技术管理者自身来说,站在产品和技术实现交汇的点上,对产品的认知和对实现细节的认知让研发管理可以更高效,更合理的决策技术方案和产品规划,从而更好地引领技术团队实现产品价值和商业目标。

作为管理者,要具备产品视角和技术视角的双重思维,一方面深入了解业务需求和用户痛点,另一方面洞悉技术方案的可行性和优劣。要善于在两个视角之间切换和权衡,找到既能满足需求,又能控制成本和风险的平衡点。也要能跳出具体实现,从更宏观的层面去思考技术战略和产品演进路径,看清下一步的发力点和布局方向。

在具体的实践过程中,技术管理者需要深入了解产品需求的来龙去脉。不能仅停留在需求文档上,而要主动与产品经理甚至客户沟通,理解需求背后的业务逻辑、用户痛点和产品价值。唯有对需求有了全面的认知,才能在技术选型、架构设计、任务拆分等环节做出正确的决策。

同时,技术管理者要对技术实现有足够的了解。这并不意味着要事无巨细地参与到每一行代码中,而是要对关键技术难点、潜在风险、优化方向等有把握。要与技术骨干保持频繁的讨论,时刻掌握开发进度和问题。只有将宏观的需求理解和微观的实现细节结合起来,才能站在全局的高度去调配资源、优化流程、控制质量。

管理者要营造产品和研发的良性互动。鼓励研发团队主动了解业务,引导产品经理关注技术价值,提倡双方同理共情、互相成就。打造一种「产品驱动研发,研发反哺产品」的良性循环,激发团队斗志,凝聚团队向心力。

小结

以书中提到的微信 4.0.1 和 4.2 发布时的文案作为本篇文章的结尾:

很喜欢这句话:如你所知,微信不只是一个聊天工具;如你所见,微信,是一个生活方式。

你曾经在微博上虚掷光阴
如今又在微信里蹉跎岁月
你以为通过手机就连接了世界,
其实只是躲在屏幕后面获取了安全感。
是时候放下手机,和朋友面对面了!
如若不能,试试微信视频通话
少发微信,多和朋友见见面!

备份之道:企业如何构筑防灾屏障

2017 年 1 月 31 日晚上,GitLab.com 运维人员在深夜进行数据库维护时,由于疲劳操作失误,使用 rm -rf 命令错误地删除了约300GB的生产环境数据。在意识到错误并尝试恢复时,只有 4.5GB 的数据得以保留。GitLab.com 官方在 2 月 1 日凌晨 1 点左右完成了数据恢复,网站恢复正常访问。恢复过程中使用的是故障发生前 6 个小时的备份数据,因此在这 6 个小时内的数据丢失。尽管 GitLab.com 声称拥有五重备份机制,包括常规备份、自动同步、LVM 快照、Azure 备份和 S3 备份,但在这次事件中,所有备份均未能有效防止数据丢失。

2023 年 10 月 23 日,语雀服务出现了一次重大故障,中断时间超过 7 小时。具体来说,这次故障的起因是在执行系统升级操作期间,新的运维升级工具出现了 bug,导致华东地区生产环境的存储服务器被误下线。由于存储系统使用的机器类别过于陈旧,无法直接将其上线,这导致了恢复过程时间延长。尽管语雀的工程师们立刻进行了恢复工作,但由于数据量大,恢复方案有限,恢复过程耗时 4 小时,数据检验耗时耗时 2 小时。

在这些个案例中我们看到了什么问题?

备份不可用,恢复方案有限,恢复备份数据长,数据丢失等等,有点平时说起来很强大很完善,真有大事就扛不住了。

所以,今天聊聊备份,不局限于数据备份。

作为一名从业多年的老兵,我们深知备份的重要性,它事关系统的安全、业务的连续性和数据的完整性,可以说是任何系统不可或缺的一部分。

行业内有一句话:「备份不做,日子甭过

1 为什么需要备份

我们为什么需要去做备份呢?主要有以下几点原因:

1.保证数据安全:在信息时代,数据已经成为企业和个人最宝贵的资产之一。而各种硬件故障、人为错误、网络攻击、自然灾害等都可能导致数据丢失或损坏。定期备份数据,可以最大限度地降低数据丢失的风险,即使遇到问题,也可以从备份中恢复数据,将损失降到最低。

2.防范风险,确保业务连续性:对于企业来说,IT 系统的可用性直接关系到业务的正常运转。一旦关键系统发生故障,没有可用的备份,就可能导致业务中断,带来巨大的经济损失和声誉影响。而有了完善的备份和灾备机制,即使发生故障,也可以快速恢复系统,确保业务连续性。

3.满足合规性要求:在某些行业,比如金融、医疗、政府部门等,由于涉及敏感数据和关键业务,往往有严格的合规性要求,需要有完善的备份存档机制。定期备份数据、留存备份一定时间都是合规性的硬性规定。没有备份,可能面临违规处罚的风险。

4.提高竞争力:在当今数字化时代,数据已经成为企业的核心竞争力。拥有完善的备份和容灾能力,意味着企业能够更好地保护和利用数据,从数据中提炼价值,增强市场竞争力。同时,这种能力也能提升客户信任,赢得更多业务机会。比如信息产品安全等级资格认证三级认证需要:本地备份与恢复+异地数据实时备份+本地业务高可用

2 备份什么

看到备份这个词,马上能想到的就是数据备份,数据库备份这些,这些固然重要,但如果你作为一个企业的技术负责人所考虑的备份就不仅仅是这些了,以下是常见的需要备份的内容。

2.1 业务数据

业务数据是备份的重中之重。

对企业来说,最需要备份的就是各种业务数据:

  1. 数据库:销售数据、客户数据、财务数据……这些数据通常存储在 Oracle、MySQL 等数据库中,是企业的核心资产,必须优先备份。如果用的是云数据库,云数据库虽然有一定的冗余,但我们仍需有自己备份数据逻辑。
  2. 文件数据:合同、报表、设计图、多媒体素材等形式多样的非结构化数据,也包含了大量的业务信息,切不可轻视。
  3. 应用数据:ERP、CRM、OA 等业务系统中的数据,与业务流程紧密相关,也需要专门备份。

2.2 系统数据

系统数据是保证业务连续性的关键

除了业务数据,我们还要备份各种系统层面的数据:

  1. 操作系统:Windows、Linux 的系统盘,包含了服务器的重要配置,一定要定期备份,特别有一些特殊的配置,最好是有一个内部的 DevOps 系统来承接。
  2. 虚拟机:很多业务系统部署在虚拟机上,备份整个虚拟机可以实现快速恢复,如果用的是云服务,境像的备份是一个标准操作。

2.3 配置数据

配置数据是还原系统的关键

系统的各种配置也需要备份,主要包括:

  1. 应用配置:各个业务系统的配置参数,如果丢失,恢复系统将非常困难。如果应用配置是存储在一个配置信息中,那就需要对这个系统做备份,包括上面的数据备份。
  2. 网络配置:交换机、路由器、防火墙等网络设备的配置,对维持业务连续性至关重要。
  3. 安全配置:防病毒、访问控制等安全系统的配置,攸关企业信息安全。

2.4 代码、文档和日志

代码、文档和日志主要是对研发团队来说的,对于软件企业或开发部门,代码和文档是核心资产,日志是问题定位,监控审计的利器:

  1. 源代码:软件的生命线,必须做好版本管理和备份。
  2. 开发文档:需求、设计、接口等文档,是沟通和维护的基础。
  3. 日志:系统和应用的各种日志数据,虽然不直接服务于业务,但对问题定位和事后审计很有价值
    1. 系统日志:记录了系统的运行状况和重大事件。
    2. 应用日志:反映了业务系统的运转细节和潜在问题。
    3. 审计日志:涉及敏感操作和数据访问,对合规和安全审计非常重要。

2.5 第三方服务

我们很多应用会调用第三方提供的服务,如支付、短信、社交登录、地图等。虽然这些服务由第三方负责运维,但作为调用方,我们也需要做一些防范:

  • 服务冗余:对于关键服务,不要依赖单一供应商,要有备选方案。比如支付可以同时接入支付宝和微信支付,短信可以同时使用两家供应商等。这样即使一家出问题,也可以快速切换。
  • 数据备份:有些第三方服务可能会存储我们的业务数据,比如客服系统中的客户对话记录。这部分数据最好在自己的系统中也保留一份,定期从第三方服务同步,这样即使第三方服务数据丢失,我们也不会受太大影响。
  • 接口契约:和第三方服务的调用要有明确的接口契约,包括接口规范、SLA等。这些内容要备份保存,一旦第三方服务变更接口或者停止服务,我们可以据此追究责任。
  • 替代预案:要评估每个第三方服务的可替代性,制定替代预案。一旦服务长时间不可用,我们要能够快速启动替代方案,比如临时切换到备用供应商,或者使用本地降级方案等。

除此之外,对于调用第三方服务的 API 密钥、账号密码等敏感信息,要安全备份,防止丢失。

以上就是企业需要备份的主要内容。当然,具体到每个企业,还要根据自身业务特点和 IT 架构来定制备份方案。我们需要全面梳理数据资产,评估数据的重要性和变更频率,搭建分层的备份体系。

3 如何备份

3.1 备份的 3-2-1 原则

在备份领域,有一个著名的 3-2-1 原则,包括:

  • 至少保留 3 个副本
  • 使用 2 种不同的存储介质
  • 将 1 个副本存放在异地

这个原则看似简单,却涵盖了备份的关键要点:

  • 多副本可以应对副本损坏的风险,是冗余的基本保证;
  • 多介质可规避单一介质故障的影响,比如同时使用磁盘和磁带;
  • 异地存放可以防范本地灾难,是灾备的必要手段。

在实践中,我们要根据数据的重要性和预算,灵活采用 3-2-1 原则。比如增加副本数量、类型,利用多个异地机房,甚至上云备份等。

3.2 备份的分类和技术

备份主要可以分为几类:

  1. 完全备份与增量备份

    1. 完全备份每次对整个数据集做一个完整的备份,优点是恢复简单,缺点是备份时间长、空间占用大
    2. 增量备份则是在上一次完全备份的基础上,只备份变化的数据,备份时间短,空间利用率高,但恢复时需要依次应用所有的增量包,略显复杂。
  2. 物理备份与逻辑备份

    1. 物理备份在底层复制数据文件,对文件系统/磁盘做快照,优点是简单高效,缺点是与平台/格式绑定,缺乏可读性。
    2. 逻辑备份是从上层应用备份数据,比如 SQL dump,优点是与存储解耦,可读性好,易于编辑和跨平台迁移,缺点是备份恢复速度慢。
  3. 冷备份、温备份与热备份:这主要是指备份过程对业务的影响程度。

    1. 冷备份需要暂停业务,关闭数据库,确保数据一致性,适用于允许一定业务中断窗口的场景。
    2. 温备份是在业务运行中备份,会有一定的性能影响,需要控制备份速度和资源占用。
    3. 热备份可以实时同步备份,几乎不影响业务,但实现起来最复杂,对软硬件要求也最高。

除了上述分类,备份领域还有很多技术手段,比如:

  • 复制:全量复制、增量复制、双向复制等
  • 连续数据保护 CDP:通过记录数据修改日志来连续备份
  • 去重:备份时过滤重复数据,节省存储空间
  • 压缩:减小备份的体积,传输和存储更高效

3.3 灾备预案与流程

除了备份技术本身,做好灾备还需要全局的规划。我们要制定完善的灾备预案与流程,主要包含:

  1. 灾备需求与目标设定:不同的系统有不同的可用性要求,核心系统当然需要更高的可用性。我们要评估每个系统的重要性,制定恰当的灾备目标,权衡投入产出。常见的指标有 RTO(恢复目标时间)和 RPO(恢复点目标),前者是最大恢复时长,后者是允许丢失的最大数据量。指标设定要务实,太低达不到,太高又成本太大。

  2. 编写灾备预案文档:灾备预案文档需要明确定义灾难等级、各种场景下的应急流程、通知上报机制、系统恢复步骤、人员角色分工、联系方式等各个细节。使得整个应急响应有章可循,文档要定期评审和更新。

  3. 灾备演练与测试:光有预案还不行,必须落到实处。要定期组织演练,模拟各种场景,让团队熟悉灾备流程。比如模拟机房断电、网络中断等场景,检查应急预案的可行性,评估 RTO、RPO 的达成情况。演练中发现的问题要及时修正预案或改进系统。

  4. 灾备监控和验证:除了演练,平时也要做好灾备系统的监控,确保灾备系统是随时可用的。比如监控备份的成功率、备份存储的容量使用率等,一旦发现异常要立即处理。

此外,我们还要定期做数据恢复验证,确保备份的数据确实是可用的。俗话说「备份是无用的,恢复才是关键」,定期做恢复测试是验证备份有效性的重要手段。

3.4 云灾备和异地多活

随着云计算的兴起,灾备也有了新的手段。很多公有云平台提供了灾备和备份服务,比如 AWS 的 S3、Glacier,阿里云的 HBR、OSS 等。将备份放到云上是个不错的选择,一是降低了本地存储的投入,二是借助了云的地理分布优势,备份天然就是多地域的。

此外,云平台还提供了跨可用区、跨地域的数据复制功能,以及多活架构支持。利用这些服务,可以打造「异地多活」的架构,也就是在多个地理位置部署服务,互为备份,同时对外提供服务。这样即便一个数据中心发生灾难,其他活跃的数据中心也可以无缝接管服务,实现了很高的可用性。当然,异地多活对技术水平要求极高,网络延迟、数据一致性都是不小的挑战。

4 备份的小结

总结来说,可以分为如下的几个点:

  1. 全面规划:灾备不是某个部分的事,而是一个系统工程,需要全局统筹规划。
  2. 分级备份:根据数据重要性分级备份,核心数据要更频繁备份,也要留存更长时间。
  3. 自动化:备份和恢复要尽可能自动化,减少人工操作可能带来的错误。
  4. 实时监控:对备份全程监控,确保备份连续性和及时发现问题。
  5. 定期演练:演练不可少,且要尽可能模拟真实场景,检验预案的有效性。
  6. 云灾备:合理利用云服务,可以显著提升灾备水平,但切忌过度依赖。
  7. 专人负责:安排专人负责灾备,统筹协调,并持续优化灾备体系。

备份灾备是一个复杂的课题,需要持续的投入和改进。做好灾备,并不一定能避免所有灾难,但可以最大限度地降低损失。它不是锦上添花,而是雪中送炭。对个人、对企业而言,灾备都是系统安全、可靠的基石,是我们必须重视、持之以恒去做好的功课。

备份之路,道阻且长。

以上