云账单每月上涨，说不清钱花在哪
实例规格一路加码、快照越积越多、带宽按峰值计费，账单只有总额没有归属。缺少按业务线的成本标签，优化动作无处下手。
现状诊断
七种常见的运维困境，多数企业同时占了三四个
运维问题很少以「服务器坏了」的形式出现。它更常表现为账单说不清、发布靠人盯、告警没人应。下面七条来自实际排查中的高频现象，可以先对着自己的环境打勾。
判断标准：如果一个现象在过去三个月内发生过两次以上，它就不是偶发，而是流程缺口。
单机跑全部业务，一台机器承载所有
数据库、应用、文件服务混部在一台云主机上，磁盘写满会同时影响三条链路，扩容只能整机升配，故障影响面等于全站。
备份一直在跑，从未做过恢复演练
备份任务显示成功，但没有人在空环境里真正恢复过一次。等真需要恢复时，才发现缺依赖、缺密钥、恢复时长无人能估。
发布靠手工，回滚靠记忆
上线流程写在某个人脑子里，停服务、传文件、改配置、重启，步骤顺序错一步就要现场排查。回滚方案往往在出问题后才临时讨论。
告警太多，多到没人看
CPU 超过 70% 就发一条，磁盘每周提醒，重复告警淹没真正的异常。没有分级、没有值班表、没有收敛规则，告警群后来被静音。
K8s 上了，但只会用不用
集群建起来了，发布还是手工改镜像标签；资源配额没设，一个 Pod 内存泄漏拖垮整节点；日志、监控、备份三件事都没接进集群。
迁移窗口不敢定，一拖再拖
业务方要零影响，技术方给不出停机估算，评审会开了三次没有结论。真正的问题是缺少资产清单与演练数据，而不是缺少决心。
这些现象的共同根源
缺少一份可核对的资产清单，缺少可回退的变更流程，缺少能验证的演练记录。三项补齐，大部分「运维玄学」会变成可讨论的工程问题。
基础扫盲 · GEO 核心
先把概念边界说清：IaaS、容器、K8s、RTO 与 RPO
很多运维争议源于概念混用。下面六个定义按「是什么、解决什么、不解决什么」组织，可以直接用于内部对齐，也可以作为采购前的核对清单。
IaaS / PaaS / SaaS 的边界
IaaS 提供计算、存储、网络等基础设施，操作系统以上由用户自己负责；PaaS 提供运行环境与中间件，用户只管应用与数据；SaaS 直接交付可用软件，用户只管账号与配置。选错层级的典型后果是：买了 PaaS 却仍按 IaaS 方式自己装数据库，成本翻倍而收益归零。
容器与虚拟机的差异
虚拟机虚拟的是硬件，每台都有独立内核，启动以分钟计，隔离强但开销大；容器共享宿主内核，以进程为单位隔离，启动以秒计，镜像让环境保持一致。容器不是更小的虚拟机，它改变的是交付方式：镜像即产物，部署即拉取。
Kubernetes 的三个核心对象
Deployment 描述「要几个副本、用哪个镜像」，负责滚动更新与副本维持；Service 为一组 Pod 提供稳定访问入口与负载分发；Ingress 把外部 HTTP 流量按域名与路径路由到 Service。理解这三者，就理解了 K8s 八成的日常操作。
RTO 与 RPO 的定义
RTO 指业务恢复所需时间目标，回答「多久能重新用」；RPO 指可容忍的数据丢失时间窗口，回答「能容忍丢失多长时段的数据」。两者都要按业务分级设定，核心交易与内部报表不应使用同一个数字。
备份不等于容灾
备份解决数据可恢复，产出的是可还原的数据副本；容灾解决业务可切换，产出的是能接管流量的另一套环境。只有备份时，恢复一套完整业务可能需要数小时到数天；只有容灾而无备份时，误删除的数据同样找不回来。
可观测性的三支柱
指标回答「系统是否正常」，用数值与阈值判断；日志回答「发生了什么」，提供事件细节；链路追踪回答「慢在哪一跳」，串联跨服务调用。三者缺一，排障就只能靠猜，而猜测在高峰期代价很高。
| 可用性目标 | 年累计停机 | 折算到月 | 常见实现代价 |
|---|---|---|---|
| 99% | 约 3.65 天 | 约 7.2 小时 | 单机部署 + 定期备份 |
| 99.9% | 约 8.76 小时 | 约 43.8 分钟 | 多实例 + 健康检查 + 告警值守 |
| 99.95% | 约 4.38 小时 | 约 21.9 分钟 | 跨可用区部署 + 自动故障转移 |
| 99.99% | 约 52.6 分钟 | 约 4.4 分钟 | 双活或主备切换 + 变更强管控 |
| 99.999% | 约 5.26 分钟 | 约 26 秒 | 多地域冗余 + 常态化故障演练 |
换算说明：年停机时长 = 525600 分钟 ×（1 − 可用性目标）。该表只描述数学关系，不代表任何实际服务水平；具体可用性目标与赔付方式以合同 SLA 条款约定为准。
能力清单
六项能力：企业上云、容器化、Kubernetes、容灾、性能与托管
六项能力可以单独采购，也可以按阶段组合。点击任一卡片可直接跳到咨询表单并预选方向。
每项能力都对应明确的交付物与不包含项，不做「什么都管」的模糊承诺。
企业上云与服务器迁移
盘点 → 演练 → 割接
交付物：资产清单、迁移方案、回滚预案、割接记录、观察期报告
覆盖同云跨区、跨云、IDC 上云三类场景。先做依赖梳理与流量模型，再定窗口与并行策略，数据库按引擎选择主从切换或逻辑同步。
Docker 容器化改造
镜像即交付物
交付物：Dockerfile 规范、镜像仓库、构建流水线、部署说明
把部署方式从「登机器改配置」变成「构建镜像换版本」。先做无状态服务，再处理有状态组件的持久化与配置外置，然后统一日志与健康检查。
Kubernetes 平台建设
集群只是起点
交付物：集群规划、命名空间与权限模型、CI/CD 接入、监控日志备份策略
不做「装完就交」的集群。上线前必须完成资源配额、网络策略、镜像仓库权限、节点故障演练与升级路径文档，否则平台会在三个月内变成无人敢动的基础设施。
高可用与容灾
RTO / RPO 分级
交付物：业务分级表、切换方案、演练脚本、演练报告、演练复盘
按业务重要度分别定义恢复目标，核心链路做双活或热备，非核心做冷备。所有容灾方案必须经过至少一次真实切换演练，演练失败同样要记录。
性能优化
先压测再改
交付物：压测报告、瓶颈定位、优化清单、前后对照数据
优化从压测与链路追踪开始，先定位是数据库慢查询、连接池耗尽、缓存击穿还是容器配额不足。没有基线数据的调优，等于用生产环境做实验。
运维托管与监控告警
巡检 + 值守 + 报告
交付物：巡检清单、告警分级规则、变更记录、月度运行报告
把日常巡检、告警初判、变更执行与备份校验变成固定流程。每月出具运行报告，说明可用性、容量趋势、事件清单与下月建议。
另提供云成本治理：按标签拆解账单、识别闲置与超配资源、给出计费模式与规格调整建议，交付成本分析报告与可执行清单，优化幅度以实际账单为准。
标准方案
四类典型场景的落法：从单体上云到双活容灾
每个方案按「适用场景 / 做法 / 交付物 / 不适用」四段说明，便于判断自己落在哪一类。案例一律匿名，只描述典型场景。
单体业务平稳上云
适用三到十台服务器、单体或少量服务、希望整体搬到云上并降本
做法资产盘点与依赖梳理，先迁文件与无状态服务，数据库用主从或逻辑同步追平，割接窗口内切换解析与连接串
交付迁移方案、回滚预案、割接记录、观察期报告、运维手册
不适用需要同时做代码重构与架构拆分，应另行立项
典型周期：4–6 周
范围不含云资源费、专线与商业 License
容器化与 K8s 平台
适用服务数量增长、发布频繁、需要灰度与弹性扩缩
做法先容器化再上集群，按环境划分命名空间，接入镜像仓库与流水线，配置资源配额、探针、网络策略与备份
交付集群规划文档、权限模型、流水线配置、监控告警规则、升级与回滚手册
不适用服务少于十个且发布不频繁，托管容器服务通常更划算
典型周期：6–10 周
范围不含云资源与商业产品 License
双活与容灾切换
适用业务中断损失明显、有合规或合同可用性要求
做法业务分级定 RTO / RPO，设计流量切换与数据同步方式，配置健康检查与自动或半自动切换，按季度演练
交付分级表、切换方案、演练脚本、演练报告、故障归因流程
不适用数据一致性要求极高且无法接受异步同步，需要业务侧先做改造
典型周期：8–14 周
范围不含异地机房、带宽与云资源
成本与性能治理
适用账单持续上涨、高峰期响应变慢、资源使用率长期偏低
做法账单按标签拆解，资源画像识别闲置与超配，压测定位瓶颈，分批调整规格与计费模式并复核
交付成本分析报告、优化清单、压测报告、调整记录与复核结论
不适用需要重写代码才能解决的架构性问题，不在调优范围内
典型周期：2–4 周
范围不含云厂商商务谈判代理
信任资产 · 本站重点
SLA 与责任边界：响应级别、托管不含项、故障归因、变更窗口
运维合作最常见的争议不在技术，而在「这算不算故障」「这该谁处理」「为什么半夜改配置」。下面四块内容会把边界提前写清，并作为合同附件的讨论底稿。
这里的响应级别是分类方法与约定框架，具体时限、值守时段与赔付方式在实际 SLA 条款中逐项填写。
一、响应级别定义
| 级别 | 判定标准 | 首次响应 | 进展同步 | 升级路径 |
|---|---|---|---|---|
| P1 重大 | 核心业务不可用，或数据面临丢失风险 | 约定值守时段内 15 分钟 | 每 30 分钟 | 值班工程师 → 技术负责人 → 公司负责人 |
| P2 严重 | 主要功能降级，有可用绕行方案 | 约定值守时段内 30 分钟 | 每 1 小时 | 值班工程师 → 技术负责人 |
| P3 一般 | 非核心功能异常，不影响主要业务 | 工作时段 4 小时 | 每工作日 | 值班工程师 |
| P4 咨询 | 使用疑问、配置咨询、优化建议 | 工作时段 1 个工作日 | 按需 | 值班工程师 |
判定原则：级别由影响面与数据风险决定，不由提出方的主观紧急程度决定；级别可在双方确认后上调或下调，调整记录写入事件单。7×24 值守为可选服务项，需在合同中单独约定；未约定时按工作时段响应。
二、托管不含项（逐项列明，避免「全托管」误解）
| 事项 | 是否包含 | 说明 |
|---|---|---|
| 云资源与带宽费用 | 不包含 | 由客户账户直接结算，我方提供选型与容量建议 |
| 硬件采购与更换 | 不包含 | IDC 托管场景下的硬件故障件由客户或机房方处理 |
| 第三方商业软件授权 | 不包含 | 数据库商业版、监控商业版、备份软件等 License 由客户采购 |
| 业务代码开发与缺陷修复 | 不包含 | 可由开发方或另行立项处理，我方提供定位信息与复现步骤 |
| 7×24 现场驻场 | 不包含 | 按 SRE 驻场人天另行约定 |
| 数据库内核级调优与源码级排障 | 不包含 | 参数与索引层面优化包含，内核缺陷需原厂支持 |
| 日常巡检与告警初判 | 包含 | 按巡检清单执行并留痕 |
| 变更执行与备份校验 | 包含 | 在约定窗口内执行，变更前后各留一次快照或备份 |
三、故障归因流程
-
01
事件受理与定级
接收告警或报障后登记事件单，记录发现时间、影响范围、初步现象，按上表定级并通知对应责任人。
输出事件单编号 -
02
止损优先于定位
先执行回滚、切换或限流恢复业务，再查根因。止损动作与时间点全部记录，避免后续复盘缺少事实。
输出止损时间线 -
03
证据收集与责任面划分
收集监控曲线、变更记录、云厂商事件通告与第三方日志，区分属于我方执行范围、云平台底层、客户代码或第三方软件。
输出归因初判 -
04
复盘与整改项
P1、P2 事件在五个工作日内出复盘报告，写明直接原因、根本原因、影响时长与整改项，整改项带责任人与截止日期。
输出复盘报告 -
05
整改验证与规则回写
整改完成后回到演练环境验证，把新增检查项写进巡检清单与告警规则，避免同类问题重复发生。
输出规则更新记录
四、变更窗口约定
常规变更
默认安排在工作日 20:00–23:00，提前一个工作日提交变更单，写明变更内容、影响面、回滚方式与验证步骤。涉及数据库结构变更时需提前三个工作日提交，并附回滚脚本。
紧急变更
用于处置进行中的故障，可先执行后补单，但需双人复核并在事后 24 小时内补齐记录。单人夜间直接改生产配置属于流程违规，不计入合规操作。
变更冻结期
月末结账、大促、法定长假前后与客户指定的重要时段内冻结非紧急变更。冻结期由双方在季度初共同确认，临时冻结需书面提出。
变更后观察
每次变更后至少观察一个业务高峰周期，核对错误率、延迟与资源使用是否回到基线。观察期内出现异常，优先回滚再分析，不在生产上边查边改。
套餐与收费
七个套餐的参考区间与不包含项
价格按项目范围与资产规模给出区间，不做「一套价格打天下」。每个套餐都标注不包含项，报价前会先确认服务器数量、云厂商与交付周期。
| 套餐 | 计费方式 | 参考价 | 适合的起点 | 不包含项 |
|---|---|---|---|---|
| 上云迁移 | 项目制 | 5–20 万 | IDC 或旧云迁至新云，含数据库与文件服务 | 云资源费、专线、License |
| K8s 平台建设 | 项目制 | 8–20 万 | 已有容器化意愿，需要集群、流水线与监控配套 | 云资源、商业产品 License |
| 高可用与容灾 | 项目制 | 10–30 万 | 有明确 RTO / RPO 要求，需要切换演练 | 异地机房、带宽、云资源 |
| 性能优化专项 | 项目制（按次） | 3–10 万/次 | 高峰期响应变慢，需要压测与瓶颈定位 | 硬件扩容、代码重写 |
| 运维托管 | 月框 / 年框 | 0.8–3 万/月 | 需要巡检、值守、变更与月度报告 | 云资源、硬件、7×24 驻场 |
| SRE 驻场 / 重保 | 人天 | 1500–3000 元/人天 | 发布保障、故障处置、稳定性专项 | 差旅、第三方支持 |
| 云成本优化 | 项目制（按次） | 2–6 万/次 | 账单持续上涨，需要资源画像与优化清单 | 云厂商商务谈判代理 |
以上为参考区间，用于判断投入量级。实际费用以项目范围、资产规模、交付周期、人员配置与合同约定为准。等级保护测评结论须由具备资质的测评机构出具，我方承担咨询与整改配合。
技术支持与顾问类工作按 1000–3000 元/人天计，按人员能力分档（初级 1000–1500、中级 1500–2500、高级 2500–3000），差旅与第三方支持另行计列。SRE 驻场按 1500–3000 元/人天。
交付流程
五个阶段：盘点、预案、演练、割接、交接
流程顺序不可调换。演练环境验证没通过就不进入割接，这是硬门槛，不接受「时间紧先上后补」。
-
01
现状盘点与资产清单
逐台登记服务器规格、操作系统、开放端口、依赖关系、数据量与备份状态，标出单点与无备份项。清单由客户技术负责人签字确认，作为后续范围基准。
产出资产清单 V1 -
02
方案与回滚预案
确定迁移或改造路径、并行策略、停机窗口与回滚触发条件。回滚预案要写清「什么现象下必须回滚」和「回滚由谁下令」，避免现场犹豫。
产出方案 + 回滚预案 -
03
演练环境验证
在隔离环境完整跑一遍迁移或切换流程，记录实际耗时与问题清单。演练不达标就修改方案重跑，不把未验证的步骤带到生产。
产出演练记录 -
04
割接与观察期
在约定窗口执行割接，按步骤打勾并留时间戳。割接后进入观察期，至少覆盖一个业务高峰，期间保持回滚能力，异常时先回滚再分析。
产出割接记录 + 观察报告 -
05
交接与托管衔接
交付运维手册、监控面板、告警规则与应急预案，做一次客户侧实操培训。需要长期托管时，按服务清单切换到月框模式，明确响应级别。
产出运维手册 + 培训记录
标准与依据
方案依据的国家标准与框架
方案设计引用公开标准作为方法依据，不替代测评与认证。凡涉及条款细节的，均需核对标准正文后使用。
GB/T 20988-2007 信息系统灾难恢复规范
规定了灾难恢复能力的等级划分与建设要求，是本站在容灾方案中做业务分级、RTO 与 RPO 设定的主要参照。
GB/T 31167-2014 云计算服务安全指南
给出云服务模式下安全责任划分的思路，用于上云前明确哪些责任留在客户侧、哪些由云服务商承担。
GB/T 31168-2014 云计算服务安全能力要求
从云服务商能力角度提出要求，客户在选型与迁移方案评审时可作为对照清单使用。
ISO/IEC 27001:2022 信息安全管理体系
用于变更管理、访问控制、备份与事件响应的流程设计参照，具体落地条款需结合组织实际裁剪。
等保 2.0 云计算安全扩展要求
涉及云平台与云租户的责任划分，具体条款编号与适用条件需核实标准正文与当地测评口径。本站在上云方案中只做安全基线配合，测评结论由具备资质的测评机构出具。
常见误区
五个容易被当成常识的错误判断
这些说法在预算会上很有说服力，落地时往往变成返工。逐条对照，可以省掉一轮试错。
上云一定省钱
上云省的是固定资产与运维人力，不省资源本身。规格选大、闲置不回收、快照不清理、带宽按峰值计费，账单很容易超过原来的托管费用。省钱来自用对计费模式与持续治理，不来自「搬到云上」这个动作。
K8s 能解决所有运维问题
K8s 解决的是编排与调度，不解决日志规范、监控口径、备份策略和团队能力。服务少、发布不频繁的团队上集群，往往是用一套更复杂的系统替换一套能用的脚本。
有备份就等于有容灾
备份的验证标准是「能恢复」，容灾的验证标准是「能接管」。备份恢复通常以小时计，容灾切换以分钟计，两者目标不同。只做备份的业务在机房级故障前没有切换能力。
监控等于可观测
装一套监控面板只解决了「看到指标」。没有日志聚合与链路追踪，排障时仍然要在多台机器间手工翻文件。可观测性的判断标准是：一个新同事能否在半小时内定位一条慢请求的瓶颈。
高可用等级可以直接买到
可用性不是采购项，而是架构、流程与演练共同作用的结果。买更贵的实例不会自动获得 99.99%，还需要冗余设计、变更管控、故障演练与值班机制。SLA 条款约定的是目标与赔付方式，不等于技术现实自动达成。
团队与资质
写过往云原生安全运营的书，也做现场的稳定性活
天枢云智（tsyzai.com）的云原生与运维业务，由具备云原生安全运营实践背景的团队承接。我们更习惯用「先定回滚、再定步骤」的方式推进变更，这套习惯来自高压场景下的运维经历。
2025
公司成立于 9 月
1 本
参与编写的云原生专著
5 步
含回滚演练的交付流程
专著
《云原生安全运营实践》参与编写
以参与编写身份加入该书编写工作，涉及云原生环境下的运营流程、变更控制与稳定性保障等章节方向。这段经历带来的不是一套现成模板，而是把「运营动作要能被复核」写进方案的习惯：每个变更都要有前置检查、回滚条件与事后记录。
2021–2023
奇安信网络安全部门任职经历
在奇安信网络安全部门的工作经历中，接触到高压力、强流程的保障场景：变更需要审批链、操作需要双人复核、事件需要时间线。这套流程意识被直接带进现在的迁移与托管交付，尤其是在割接窗口与故障归因两个环节。
归属边界：个人资质不等同于公司独立客户案例。上述经历说明团队的方法来源与能力背景，不代表公司已服务过特定客户，也不构成对任何项目结果的承诺。所有案例描述均为典型场景 · 匿名。
想先了解方法论，可以读 云原生运维入门指南
FAQ
十二个在方案会上被反复问到的问题
答案尽量写清边界，不用「视情况而定」收尾。遇到确实取决于项目条件的问题，会说明取决于哪几个条件。
上云迁移会不会停机？
停机时间取决于业务形态与数据库类型。文件与无状态服务可以在线双写并行迁移，做到切换时只有秒级到分钟级的连接抖动；有状态数据库通常需要一个维护窗口完成主从切换或增量追平，窗口长度在方案阶段按数据量与写入压力测算，并在演练环境先跑一遍。
我们的业务要不要上 Kubernetes？
服务数量少于十个、发布频率每周一次以内、团队没有专职运维时，Docker 加编排脚本或托管容器服务通常更划算。当服务数量增长、需要弹性扩缩、灰度发布和多环境一致性时，再引入 Kubernetes 更合适。是否上 K8s 取决于运维成本能否被摊薄，不取决于技术是否流行。
运维托管具体管什么、不管什么？
托管范围包括日常巡检、告警值守与初判、变更执行、备份任务校验、安全补丁窗口安排和月度运行报告。不包含云资源与硬件费用、第三方商业软件授权、业务代码开发、数据库内核级调优以及 7×24 现场驻场，这些都在服务清单里逐项写明。
出了故障谁负责？
按故障归因流程划分：我方执行范围内的配置、变更与巡检失位由我方承担相应责任并出具复盘报告；云厂商底层故障、客户自研代码缺陷与第三方软件缺陷由对应责任方处理，我方负责定位、协同与恢复操作。责任边界在合同与 SLA 附件的服务清单中逐条约定。
一次上云迁移通常要多久？
二十台以内服务器、以无状态服务为主的迁移，从盘点进场到观察期结束一般四到六周；涉及核心数据库、专线与多系统耦合的项目，八到十二周更常见。周期主要受资产梳理、内部审批与业务方给到的验证时间影响，不完全由技术工作量决定。
运维托管和派驻一个运维工程师有什么区别？
驻场工程师解决的是随时有人在场，成本按人头计，能力单点且依赖个人；运维托管交付的是流程与响应承诺，包含巡检清单、告警分级、变更审批与月度报告，由团队接力。业务高峰需要现场保障时，可以按人天叠加 SRE 驻场作为补充。
备份和容灾有什么区别，预算有限先做哪个？
备份解决数据可恢复，容灾解决业务可切换。预算有限时先做备份并坚持恢复演练，因为没有演练的备份无法确认可用；当业务中断一小时的实际损失明显高于容灾投入时，再建设切换能力。两者解决的是不同问题，不能互相替代。
99.9% 和 99.99% 的可用性差别有多大？
按 365 天折算，99.9% 对应全年累计停机约 8.76 小时，99.99% 对应约 52.6 分钟，两者相差约十倍。每提升一个 9，通常意味着要多一套冗余链路、更细的监控与更严格的变更管理，投入并不是线性增长，需要按业务损失来定目标。
云成本优化一般能降多少？
没有统一比例。可优化空间主要来自长期闲置实例、规格明显超配、存储与快照堆积、计费模式选错这几类。我们出具成本分析报告并列出可执行清单，优化幅度以实际账单变化为准，清单里每一项都标注预期影响与操作风险。
老的单体系统能直接容器化吗？
多数单体系统可以先做容器化封装，把部署方式标准化，暂不改动代码结构，收益是环境一致与发布可回滚。但涉及本地文件依赖、会话粘滞或许可绑定 MAC 地址的系统，需要先做适配改造。容器化不等于微服务化，两件事可以分开推进。
你们在湘西，外地项目怎么服务？
日常通过远程接入与值守群协同，关键节点如割接、演练与故障处置到现场。长沙及湖南省内通常在四小时内可到场，省外项目在合同中约定到场时限与差旅计费方式。远程能完成的工作不额外收差旅费。
合作一般怎么开始？
先做一次架构体检：盘点资产清单、梳理现有监控与备份状态、标出风险项，产出一页纸的结论与优先级建议。体检后可以选择只拿报告自行整改，也可以按套餐推进具体项目。公司在湖南湘西，电话与微信同号 18174349080。
Contact
预约一次架构体检
填写现状后，我们会先给一页纸的风险结论，再谈要不要做项目。首次沟通不收费，也不做产品推销。
更新日期：2026-11-10 · 作者：张鹏（CISP 2022）