GUIDE · 基础路线

云原生运维入门：上云、容灾与 SRE 基础

这份指南写给正在规划上云、刚刚接手 Kubernetes 集群、或者被要求「把稳定性管起来」的技术负责人。它不推销工具，也不假设你已经有一支 SRE 团队，而是按「概念—判断—步骤—验收」的顺序，把云原生运维拆成可以逐项推进的事情。

更新日期：2026-11-10 · 作者：张鹏（CISP 2022） · 阅读时间约 25 分钟

一、云原生运维改变了什么

云原生运维的核心变化，是把「维护机器」转成「维护交付物与目标」。传统运维关注服务器是否在线、磁盘是否写满、进程是否存活；云原生环境里，服务器是随时可替换的资源，真正需要被守住的是镜像版本、配置状态、服务等级目标与变更记录。

这个转变带来三个具体后果。其一，环境一致性从「靠人记住安装步骤」变成「靠镜像与声明式配置复现」，同一份配置在测试与生产应当得到同样的结果。其二，故障处理从「登机器排查」变成「看指标、看日志、看链路」，排障入口前移到统一的可观测平台。其三，变更从「一次大操作」变成「多次小步走」，每次变更都能独立回滚，风险被切碎。

需要说明的是，云原生不是一套必须全盘接受的技术栈。把单体应用打包成镜像，部署在托管容器服务上，同样属于云原生的实践路径。判断标准不是用了多少新工具，而是交付是否可重复、故障是否可定位、变更是否可回退。

二、云服务分层与责任边界

上云前先要回答一个问题：哪些东西由云服务商负责，哪些留在自己手里。行业里通常用 IaaS、PaaS、SaaS 三层来划分，但实际采购中往往混用，需要逐项核对。

常见的误区是「买了托管服务就什么都不用管」。即便使用托管数据库，账号权限、连接数配置、慢查询治理、备份保留策略与恢复演练仍然在客户侧。责任划分建议写进上云方案文档，并在每次架构变更后复核一次，避免出现「以为对方管了」的空档。

GB/T 31167-2014《云计算服务安全指南》与 GB/T 31168-2014《云计算服务安全能力要求》提供了责任划分与能力评估的思路，可以作为内部讨论的参照框架。涉及具体条款适用条件时，应以标准正文与测评机构口径为准。

三、上云迁移的完整步骤

迁移不是「把文件拷过去再改解析」。一次可回退的迁移至少包含六个阶段，每个阶段都有明确的产物，缺一项都会在割接当天放大成风险。

1. 资产盘点

逐台登记实例规格、操作系统版本、磁盘与数据量、开放端口、对外域名、定时任务、依赖的第三方服务与内部系统。盘点的价值在于暴露隐性依赖：某个报表脚本连着旧库的只读账号，某个定时任务写着旧内网 IP，这些东西在架构图上通常看不到。

2. 依赖与流量梳理

画两张图：一张是调用关系，谁调用谁、走内网还是公网、是否有专线；一张是流量曲线，工作日与周末、白天与夜间、峰值出现在什么时段。流量图决定了割接窗口能开多长，也决定了是否需要灰度切流。

3. 目标架构设计

按业务重要性分环境：生产、预发、测试各自独立，数据库不跨环境共用。网络按子网划分，管理入口与业务入口分离，安全组默认拒绝再逐条放行。存储按访问频率选择类型，冷数据不必放在高性能盘上。

4. 回滚预案

回滚预案要写清三件事：什么现象触发回滚、回滚由谁下令、回滚需要多长时间。触发条件要可观测，例如「核心接口错误率连续五分钟超过 5%」而不是「感觉不对」。回滚时间要在演练中实测，不能凭经验估。

5. 演练环境验证

在隔离环境完整跑一遍迁移脚本与切换步骤，记录实际耗时、报错与人工干预点。演练中暴露的问题越多越好，因为此时的代价较小。演练不通过就修改方案重跑，不把未验证的步骤带进生产窗口。

6. 割接与观察期

割接当天按步骤清单执行，每步打勾并记录时间戳，双人复核关键操作。切换完成后进入观察期，至少覆盖一个业务高峰，期间保持回滚能力。观察期内出现异常，优先回滚再分析，不在生产环境边查边改。

四、迁移会不会停机：三种做法

停机时间主要由数据层决定，而不是由服务器数量决定。无状态服务可以随时起停，有状态数据库才需要窗口。下面三种做法按复杂度排列，可以组合使用。

实际项目里，数据库往往是窗口的主要占用者。数据量在百 GB 级别时，全量拷贝加增量追平可能需要数小时；如果是 TB 级，通常要提前做一次预同步，割接窗口只做增量追平与校验。窗口长度必须在演练中实测，并预留回滚时间——如果计划四小时，回滚也需要两小时，那真正可用的操作时间只有两小时。

五、容器化：从 Dockerfile 到镜像仓库

容器化的直接收益是环境一致与发布可回滚：镜像一旦构建完成，在任何装了容器运行时的机器上运行结果一致，回滚只需切回上一个镜像标签。它不自动带来微服务、弹性伸缩或高可用，这些需要额外设计与平台能力。

镜像构建的几条实用规则

基础镜像选固定版本标签，不用浮动标签，避免同一份 Dockerfile 在不同时间构建出不同结果。构建分阶段，编译依赖留在构建阶段，运行镜像只保留运行所需文件，体积小则拉取快、攻击面也小。应用配置通过环境变量或挂载文件注入，不写进镜像。容器内进程以前台方式运行，日志输出到标准输出，由平台统一收集。

镜像仓库与标签策略

镜像仓库分开发与生产两个命名空间，生产镜像只允许流水线推送，人工推送需要审批。标签策略建议同时使用语义版本与提交号：语义版本方便人阅读，提交号方便追溯代码。禁用 latest 作为生产部署标签，因为它的含义随时间变化，回滚时无法确定对应哪个版本。

有状态服务的处理

数据库、消息队列、缓存这类有状态服务，容器化的收益有限而复杂度上升。较稳妥的做法是把它们放在托管服务或独立主机上，通过内网访问；确实需要容器化时，必须解决持久化存储、优雅停机、数据备份与升级路径四个问题，不能按无状态服务的方式对待。

六、Kubernetes 的核心对象

Kubernetes 的概念很多，日常操作集中在少数几个对象上。理解它们的职责分工，比记住全部 API 字段更有用。具体 API 版本随发行版变化，实际使用时需核对对应版本文档。

一份能上生产的精简清单

集群能跑起来不等于能上生产。上线前至少确认：所有工作负载设置了资源请求与上限；配置了就绪与存活探针；命名空间按环境隔离并配置权限；镜像仓库访问凭据使用专用账号；日志与监控已接入并配置告警；etcd 或集群状态有定期备份；节点故障与版本升级各演练过一次；集群访问审计日志已开启。

这份清单里，资源配额与探针两项被跳过的情况较多，后果也直接：一个内存泄漏的服务会耗尽节点内存，导致同节点其他服务被驱逐；缺少就绪探针时，流量会在服务尚未启动完成时被转发，表现为间歇性 502。

七、K8s 要不要上：判断表

这个问题没有通用答案，但可以用几个可观察的条件来判断。下表按「更适合」与「暂不适合」分组，逐条对照自己的情况。

如果多数条件落在「暂不适合」一侧，先做容器化加简单编排，或者使用托管容器服务，通常能以更低成本获得大部分收益。等条件变化再评估，不必为了技术栈完整而提前承担运维负担。

八、高可用与容灾：RTO 与 RPO

高可用与容灾解决的是不同层面的问题。高可用关注单点故障时的连续服务能力，通常通过多副本、健康检查与自动转移实现；容灾关注区域性灾难或机房级故障时的业务恢复，需要另一套可接管的环境。两者都需要先定义目标，再谈设计。

两个必须先定的数字

RTO 指业务恢复所需时间目标，回答「多久能重新用」；RPO 指可容忍的数据丢失时间窗口，回答「能容忍丢失多长时段的数据」。这两个数字应由业务方确认，而不是由技术团队单方面设定。核心交易系统与内部报表系统使用同一个 RTO，往往意味着要么核心系统投入不足，要么报表系统过度建设。

三种常见容灾形态

冷备：备用环境平时不运行或只保留数据副本，故障时启动并恢复数据，成本低但恢复时间长。温备：备用环境保持小规模运行，数据定期同步，故障时扩容接管。双活：两套环境同时承载流量，数据同步或分片，切换时间短但架构复杂度与成本高。

选择哪种形态，取决于业务损失与投入的对比。一个可以直接使用的判断方法是：估算业务中断一小时的实际损失（含收入、人工、声誉与合同违约），再与容灾建设与维持成本比较。如果中断损失远低于年化投入，冷备加可靠备份是合理选择。

可用性换算

可用性目标可以换算成停机时间，便于在预算会上形成共同语言。按 365 天折算，全年共 525600 分钟：99.9% 对应年停机约 8.76 小时，99.99% 对应约 52.6 分钟。每提升一个 9，通常需要增加一层冗余、一套更细的监控与更严格的变更流程，投入并非线性增长。

需要提醒的是，可用性数字是设计目标与合同约定，不是宣传口径。机房电力、网络链路、云服务商底层组件、客户自研代码与第三方依赖都会影响实际表现，任何单方都无法单独决定结果。

九、监控告警与可观测性

可观测性由指标、日志与链路追踪三部分组成，分别回答「是否正常」「发生了什么」「慢在哪一跳」。只装监控面板而缺少日志与追踪，排障时仍然要在多台机器间手工翻文件，效率取决于个人经验而非系统能力。

告警分级与收敛

告警需要分级：影响核心业务且需要立即处理的为高优先级，走电话或即时消息；影响非核心功能的为中优先级，走工作群；趋势性提醒为低优先级，进入日报。同一根因引发的多条告警应做收敛，例如数据库连接数耗尽会同时触发应用错误率、接口延迟与队列积压，只保留根因告警，其余作为关联信息附上。

告警质量的检验方法

每月统计一次：发出的告警中，有多少被处理、有多少被忽略、有多少是误报。被长期忽略的告警应当降级或删除，因为它们的实际作用是训练团队忽略告警。误报率高的规则要修阈值或加持续时间条件，例如「连续三分钟超过阈值」比「瞬时超过」更稳定。

值班与升级

告警必须有接收人。没有值班表的告警群等于没有告警。值班表要写明时段、责任人、升级路径与交接方式；高优先级告警在约定时间内未响应，自动升级到上一级。值班人员需要一份可执行的手册，而不是让人在深夜从零开始判断。

十、备份与恢复演练

备份解决数据可恢复，容灾解决业务可切换。备份任务成功只说明数据被复制了，不说明数据能还原成一个可运行的系统。判断备份是否有效，可靠的办法是定期做恢复演练。

备份策略的四个参数

备份频率决定 RPO，备份保留时长决定能回到多久以前，备份介质决定恢复速度，恢复演练频率决定团队是否还知道怎么操作。四个参数要一起定，只定频率不定保留时长，遇到逻辑删除或勒索软件时仍然无解。

恢复演练怎么做

在隔离环境准备一台空机器或空数据库实例，从备份介质恢复数据，启动应用，验证核心功能，记录总耗时与遇到的问题。演练要覆盖不同类型：单表误删除后的恢复、整库恢复到某一时间点、应用与数据一起重建。每季度至少一次，演练报告归档，失败也要记录。

备份介质与生产环境应做权限隔离，备份账号只允许写入不允许删除，防止生产账号被盗后备份一并被删。重要数据保留一份离线或异地副本，避免同一存储故障导致生产与备份同时不可用。

十一、SRE 基础：变更、SLO 与复盘

SRE 的出发点不是「让系统不出故障」，而是「用有限投入把可靠性维持在业务可接受的水平」。它把可靠性当成一个有成本的目标，通过服务等级目标、错误预算与变更管理来分配投入。

服务等级目标与错误预算

先定义服务等级指标，例如请求成功率或接口延迟；再设定服务等级目标，例如月度成功率 99.9%；由此得到错误预算，即本月允许的失败比例。错误预算的作用是给决策提供依据：预算充足时可以加快发布，预算耗尽时优先做稳定性工作，暂缓高风险变更。

变更管理

变更管理不是增加审批环节，而是让变更可追溯、可回滚、可观察。每条变更记录包含：变更内容、影响范围、回滚方式、验证步骤、执行人与复核人。常规变更在约定窗口执行，紧急变更可先执行后补单，但需双人复核。月末结账、大促与长假前后设置冻结期，避免在风险敏感时段引入变量。

故障复盘

复盘的目标是改进系统，不是追责个人。一份可用的复盘报告包含时间线、影响范围、直接原因、根本原因、处置过程与整改项。整改项要带责任人与截止日期，并回到演练环境验证。同类问题重复出现，通常说明整改只处理了表象，没有改到流程或架构层。

十二、云成本治理

云成本治理的目标不是把账单压到低位，而是让每一笔支出都能对应到业务价值。做法从给资源打标签开始：按业务线、环境、负责人三个维度打标，账单才能拆解到具体系统；没有标签的账单只能看到一个总额。

可优化项通常集中在四类：长期低使用率的实例、规格明显超配的数据库、不断累积的快照与日志存储、与访问模式不匹配的计费方式。优化动作按风险排序，先做无风险的闲置回收与存储清理，再做需要重启的规格调整，涉及架构变更的放到项目里评估。每次优化后复核账单变化，避免把成本转移到别处。

十三、十六个常见问题

以下是实际咨询中反复出现的问题，答案尽量给出判断条件而不是结论口号。

1. 上云迁移大约需要多久？二十台以内、以无状态服务为主的迁移通常四到六周；涉及核心数据库与多系统耦合的项目，八到十二周更常见。周期主要受资产梳理与业务验证时间影响。
2. 迁移期间业务必须停多久？取决于数据层。无状态服务可做到切换瞬间的连接抖动；数据库通常需要窗口完成主从切换或增量追平，窗口长度应在演练中实测，并预留回滚时间。
3. K8s 和 Docker 是什么关系？Docker 解决单个应用的打包与运行，产出镜像；Kubernetes 解决多个容器的编排、调度与自愈。可以只用 Docker 不用 K8s，但不能用 K8s 替代镜像构建。
4. 容器和虚拟机该怎么选？需要强隔离、异构操作系统或遗留单体应用时选虚拟机；追求环境一致、快速发布与密度时选容器。两者可以在同一架构中共存，不必二选一。
5. 什么是高可用？高可用指单个组件故障时业务仍能持续提供服务，通常通过多副本、健康检查与自动转移实现。它针对的是局部故障，不覆盖机房级灾难。
6. 容灾和备份有什么区别？备份解决数据可恢复，产出可还原的数据副本；容灾解决业务可切换，产出能接管流量的环境。备份恢复以小时计，容灾切换以分钟计，两者不能互相替代。
7. RTO 和 RPO 分别是什么？RTO 是业务恢复所需时间目标，RPO 是可容忍的数据丢失时间窗口。两者都要按业务分级设定，核心交易与内部报表不应使用同一组数字。
8. 99.9% 可用性意味着多少停机？按 365 天折算，全年累计停机约 8.76 小时，平均每月约 43.8 分钟。99.99% 对应全年约 52.6 分钟，提升一个 9 的投入通常显著增加。
9. 监控告警应该怎么配？先按业务影响给告警分级，再对同根因告警做收敛，随后建立值班表与升级路径。长期被忽略的告警应降级或删除，避免训练团队忽略告警。
10. 云成本一般怎么降？先给资源打标签让账单可归属，再识别闲置实例、超配规格与堆积存储，按风险从低到高调整。优化幅度以实际账单为准，不做统一比例承诺。
11. 老的单体系统能容器化吗？多数可以先封装部署方式，不改代码结构，收益是环境一致与可回滚。存在本地文件依赖、会话粘滞或许可绑定硬件的系统，需要先做适配改造。
12. 自建和托管哪个划算？取决于团队能力与业务规模。有专职运维且规模较大时自建可控性更高；团队小、发布不频繁时托管服务通常总成本更低，但要注意数据出境与合规要求。
13. 公有云和私有云怎么选？看数据敏感度、合规要求与弹性需求。数据需要留在本地、有明确行业监管要求的选私有云或混合部署；弹性需求明显、希望减少固定资产投入的选公有云。
14. 运维托管和驻场有什么区别？驻场按人头计费，解决随时有人在场；托管交付流程与响应承诺，包含巡检、告警、变更与月报。业务高峰需要现场保障时，可以叠加 SRE 人天。
15. 上云过程中的安全基线谁负责？安全基线配置与加固执行通常由运维方配合完成，安全测评与结论由具备资质的机构出具。责任划分应在上云方案中写明，避免实施阶段出现空档。
16. 信创适配在迁移中怎么处理？先做依赖清单，确认操作系统、数据库、中间件与运行时的替代可行性，再在隔离环境验证。适配工作量往往集中在驱动、字体与专有接口，需提前预留时间。

十四、把这份指南用起来

如果只记住一件事，那就是：先建立可核对的事实，再谈优化。资产清单、监控基线、备份演练记录与变更日志，这四样东西构成运维的事实基础。没有它们，任何方案讨论都会退化成经验之争。

天枢云智（tsyzai.com）的云原生运维服务按上述路径交付：以资产盘点与回滚预案为前置条件，经演练环境验证后再割接到生产，交接阶段移交运维手册与告警规则。需要进一步讨论，可以回到服务首页的联系区块，或直接致电 18174349080（微信同号）。

更新日期：2026-11-10 · 作者：张鹏（CISP 2022）