那条标题挂出来之后我被同行问得最多的一句是Sealos到底是什么东西能把运维团队从12个人缩到3个人我理解大家为什么这么惊讶。12到3这个数字听起来像在讲故事甚至像是在吓唬人。但作为那个被HR半开玩笑问“要不要给自己也转个岗”的CTO我今天想把这次迁移的完整过程、裁撤逻辑和踩过的坑一次性讲清楚。先说结论人确实少了但业务没垮系统也没比以前更脆弱。核心原因不是Sealos能“吃掉”多少运维岗位而是它把大量重复性、低价值、依赖人肉盯守的运维工作变成了平台能力和研发自助能力。这篇文章不是软文也不打算劝每个人都上这套方案。我只想把我自己经历过的决策过程、迁移节奏、团队重塑和失败经验记录下来给正在纠结“要不要引入云原生平台”“运维团队要不要缩编”的人一个参考样本。1. 为什么会走到迁移这一步12个人每天都在忙什么1.1 团队规模的真相人不少但产出很虚很多管理者只看“12个人”这个数字觉得运维投入很充足系统应该很稳。但你真把这12个人摊开看就会发现绝大多数精力都消耗在救火和重复劳动上。我当时把我们团队的日常工作做了一次统计结果非常扎心。每天有两个人长期盯告警群和控制台一有告警就人手确认“是不是误报”还有两个人在写部署脚本和Ansible playbook改一套环境配置往往要跑半天发布日更是全员待命研发把安装包传上来运维手动更新镜像、手动改配置、手动重启整个流程没有版本控制也没有标准化日志回滚全靠经验和运气。数据库那边还有两个专职的人维护着几十套MySQL、PostgreSQL和Redis实例日常做备份、清理慢日志、处理主从延迟一旦出问题就是半夜被叫醒。剩下的人有的管机房设备有的对接业务部门接需求有的处理工单和资源申请。我算了一笔账真正花在容量规划、根因分析、系统架构改进这些高价值工作上的时间可能不到团队总工时的两成。这不是这12个人不努力而是传统运维模式的组织结构决定了他们只能这么做。告警响了必须有人看工单来了必须有人接环境变了必须有人改脚本。只要这些机制还在人再多也只是让救火的速度快一点并不能让火苗变得更少。1.2 为什么是Sealos而不是自建PaaS或云全家桶在决定引入Sealos之前我其实认真对比过几条路基于Kubernetes自建一套PaaS、直接用云厂商全家桶、采购商业PaaS平台还有最后选择的Sealos这类云原生操作系统路线。自建PaaS是技术团队很容易产生冲动的一条路觉得K8s都能搭再封装一层也不是不行。但冷静下来想一个内部PaaS要包含应用管理、发布流水线、网关、监控告警、数据库服务、存储管理、权限体系这套东西真正成熟至少要两三年持续投入。我们团队当时最缺的就是时间。云厂商全家桶的吸引力在于托管服务多但一旦深度绑定私有化交付、混合云场景和成本控制都会变得被动这对我们这类既有线上SaaS又有企业私有化部署需求的公司来说不是最优解。商业PaaS又存在闭源、定制难和许可证成本的问题。Sealos进入视野是因为它的定位和传统PaaS不太一样。它更像一个把基础设施包起来的操作系统底层编排还是Kubernetes但把集群管理、应用商店、数据库、对象存储、网关、监控告警这些组件统一封装。它对运维人员更友好的一点是不是让你上来就面对一堆裸露的YAML和自定义资源定义而是可以通过控制台和命令行完成集群搭建、组件安装、应用部署这些事情。对我们来说这是一种介于“纯自建”和“全托管”之间的平衡点。1.3 迁移之前我先回答了自己三个问题决定动手之前我在管理层面前给自己立了几个规矩也是后来验证方向时反复用的标准。第一个问题是系统能不能在迁移期间保持业务稳定。红线是核心业务不能出现长时间中断数据绝对不能丢。这不是口号而是决定迁移顺序的前提。第二个问题是研发团队是否愿意改变工作习惯。如果平台做得再漂亮研发还是习惯找运维“帮我发一下”那平台只是一个新的工单入口人力根本压不下来。第三个问题是投入产出比能不能算过账。迁移需要时间、需要采购或部署资源我需要用一个可量化的框架向董事会解释为什么前期投入是值得的。当时我们定下的目标是这样的每月需要运维人工介入的告警数量下降80%发布耗时从小时级降到分钟级数据库和中间件交付从按周计变成按分钟计研发自助完成日常发布和回滚。这些目标没有被一个季度之内全部完成但回头看正是因为有这些可衡量的目标才没让迁移变成一场“为了上云而上云”的运动。2. 迁移过程是怎么拆解的先动哪里后动哪里2.1 先拿低风险业务试水把路径跑通很多运维体系改造失败的共同原因是想一口气把生产环境全部切换过去结果出了问题时连回退都不敢做。我们当时定了一个原则先拿低风险业务试水把整套流程在非关键系统上完整跑通再逐步扩大范围。第一批迁移的是内部OA、报表平台和一两个访问量很低的内部工具。这些系统挂了最多被同事抱怨两句不会造成收入损失。我让团队在测试环境把Sealos集群搭起来先在上面部署了一套和生产环境相同版本的报表系统然后把发布流程、监控接入、日志采集、备份恢复这些环节全部演练了一遍。等测试环境稳定运行两周后才把真实业务切过去。做这个阶段的目的有两个。一是积累平台操作经验让运维同事知道某个组件出问题时应该去哪里看日志、怎么重建服务二是让研发体验一下“自助发布”是什么感觉而不是继续把发布请求塞给运维。等到内部工具连续发布十几次都没有出问题之后团队对平台的信任才初步建立起来。这个阶段看起来进度慢但它是整个迁移最值得花时间的一步。2.2 把基础设施和可观测性一次性重做过了试水阶段我们开始处理最底层的东西多环境基础设施纳管和可观测性链路重建。以前我们每个环境都是一批独立虚拟机生产、预发、测试环境之间的配置经常不一致。这次迁移统一以Kubernetes集群作为底座再通过Sealos的控制台把各个集群纳管起来。我们按业务域划分了命名空间在Ingress网关层统一了域名和证书管理存储类全部按性能和容量需求重新划分。原来应用日志散落在各台服务器的目录里查问题经常要登录服务器用grep翻文件新的体系里所有日志统一采集到日志平台通过标签检索研发自己就能看到自己服务的运行状态。监控告警链路也做了整合原来每个系统各搞一套监控规则重复且口径不一现在全部以统一指标为基础按照服务等级和SLO重新梳理了告警规则。这部分工作技术难度并不是最大的真正难的是推动各个业务线把日志格式和指标口径统一起来。有些老系统的日志原本就是自由格式解析规则很难写。我们用了将近三周时间配合各业务研发调整关键路径上的日志输出才勉强把可观测性链路跑通。但这一步做完之后后续很多问题的定位效率都提高了靠人登录服务器排查故障的历史也逐渐成为过去。2.3 发布链路从“人肉传包”变成“研发自助”当基础设施和可观测性稳定之后我们开始动发布链路。之前研发提上线申请运维根据文档手工部署整个过程不可控因素很多。我们把发布系统接入了Sealos的应用管理能力研发在平台上选择自己要发布的应用构建流水线跑完后流水线自动更新镜像并触发滚动发布。回滚是这次改造里最受欢迎的功能。以前回滚需要运维手工切换镜像标签、重新执行部署脚本运气不好还要改数据库连接配置。现在发布系统会记录历史版本研发在界面上点一下就能回到上一个稳定版本。灰度发布也顺手做了针对部分核心应用可以先把流量切到新版本的一小部分验证通过后再全量放开。这里必须说清楚权限模型。我们给研发开放了自助发布入口但不意味着所有操作都不受控。普通研发只能在自己所属命名空间内操作发布配置变更仍然需要走审批流涉及数据库连接、网关规则、集群配置的部分仍然由保留的运维同学统一负责。这个分寸拿捏很重要如果一开始就把权限全放开后面大概率会出安全事故。2.4 数据库和中间件迁移最险的一段路应用发布可以靠平台能力快速搬过去数据库和中间件却没办法一键迁移。这是我们整个项目里风险最高的环节也是耗时最长的环节。MySQL、PostgreSQL、Redis一共几十套实例逐一做高可用改造和数据迁移。每个实例的迁移流程基本是这样先在Sealos平台上创建一套配置相同的高可用实例做一次全量备份并在新实例上恢复然后开启增量同步追平数据等到主从延迟归零后再切换连接。切换窗口选在流量低点业务侧配合调整数据库连接地址验证核心链路没问题后观察一天再清理老实例。Redis相对简单因为大部分数据是可重建的缓存只要提前预热并切换即可。有几个细节特别容易翻车。一是定时任务有些老系统在数据库服务器上直接挂了crontab迁移后没人记得这回事数据同步和报表任务就断了二是数据库账号权限新实例只迁移了业务主账号忘记迁移各种内部工具需要的只读账号结果BI系统第二天就报错三是慢查询新实例的硬件和配置不一样个别SQL的执行计划变了性能反而下降。这些都是靠迁移后的持续观察才发现的所以数据库迁移一定不能只盯着切换那一下要预留足够长的观察窗口。3. 12个人是怎么变成3个人的岗位消融的真实过程3.1 原先12个人的分工最后被谁接走了很多人听到“从12个人缩到3个人”时第一反应是公司把人裁了。实际情况不完全是这样有一部分人的工作确实被平台替代了也有一部分人通过内部转岗去了更合适的岗位。我把原来的分工和去向整理过一张表这里贴出来供参考。原岗位职责人员数量被什么机制替代后续去向告警值守与监控确认2人统一告警平台、分级别通知、自动汇总转岗研发效能或应用开发环境交付与脚本维护2人Sealos模板化部署、基础设施代码化2人转岗应用研发发布支持与版本回滚2人研发自助发布、灰度回滚1人转岗业务研发1人离职数据库日常维护2人平台高可用数据库、备份自动化保留1人1人转售后技术支持网络与硬件设备维护1人基础设施向云原生底座收拢转岗行政IT支持工单处理与业务需求对接2人自助资源申请、费用账单报表转岗各业务线技术支持值班负责人与统筹1人SLO机制、平台稳定性Owner保留至平台运维核心岗这个表格并不是说“平台替代了多少人”而是说这些人的时间被大量低价值工作占据。当平台把这些工作接管后团队结构自然就需要重新设计。3.2 留下来的3个人正在干什么现在团队里保留的3个人分工比之前的12个人清晰得多。我不觉得我们是在硬撑反而是以前那种“人多但都在救火”的状态才让人心里发虚。第一个人负责平台与基础设施。他管的是Sealos集群本身、节点的生命周期、存储类、网络策略、网关和证书管理。日常工作是处理集群升级、节点资源饱和度、存储容量规划以及和云厂商或机房那边的对接。他不需要去管业务应用里某个Pod为什么起不来那是研发自助应该解决的事情。第二个人负责稳定性与可靠性工程。他盯的是SLO、告警降噪、容量预测、备份恢复演练、故障复盘。每次出现线上事故由他牵头写时间线、定位根因、跟踪改进项。他会定期做一次全集群的故障演练确保当数据库节点挂掉、某个可用区不可用时系统确实能自愈。第三个人负责效能与成本治理。他管资源申请规范、成本账单、命名空间配额以及给研发团队做平台使用培训。每个月的云资源和服务器成本账单由他分析哪些业务资源利用率低、哪些项目应该降配都由他推动。三个人同时也在互相备份。任何一个人休假另外两个都能接手他的核心职责因为日常操作已经收敛到平台控制台和标准流程里不再依赖某个人的绝活和记忆。3.3 团队变小之后工作方式有哪些变化团队人少之后最大的变化是工作节奏从“被动响应”变成了“主动治理”。以前是等告警响了、等研发来求助现在每天早上第一件事是看统一的运维仪表盘了解隔夜发布情况、告警汇总、资源账单和SLO达成率。与研发的协作方式也变了。以前研发做一次上线要跟运维反复沟通环境、端口、依赖、日志目录这些事情。现在研发在平台自助创建应用填好镜像地址、资源配额和环境变量流水线自动构建发布。他们遇到问题也是先在日志平台查自己的服务解决不了才找运维而且找到运维时通常已经带着明确的错误日志和信息效率完全不同。这个变化需要研发团队配合适应。我们专门写了平台使用手册还组织了几次培训把“常见问题排查”“发布回滚操作”“日志检索方式”做成视频和文档。事实证明工具和文档是同等重要的。如果没有培训和文档研发仍然会把运维当成客服团伙人员的压力就会变得很大。4. 迁移踩过的坑以及如果重来我会怎么排顺序4.1 五个真实的坑和对应解法迁移过程并不顺利我挑五个印象最深的坑来写每个坑后面都附了我们现在的解法。第一个坑是存储权限没有提前做规划。应用迁到K8s之后本身用的是持久化存储但NFS和云盘在权限模型上跟原来服务器目录不完全一致导致不少应用启动时报“权限不足”。我们当时排查到凌晨最后通过统一调整StorageClass的权限映射才解决。现在的做法是任何应用迁移之前运维必须先确认存储挂载方式和目录权限不允许应用自己随便挂。第二个坑是数据库迁移只顾着搬数据忘了搬“周围的配置”。老数据库里其实有很多隐藏资产定时任务、存储过程、只读账号、自定义函数。这些内容平时没人觉得重要切换之后业务报表、后台任务全都出问题。从那以后我们给数据库迁移清单里加了一条必须审计任务、权限和函数不允许只迁表结构。第三个坑是告警规则接入太猛。统一监控平台上线后我们一开始把所有规则全接入工作群结果是每天上百条消息真正需要人处理的没几条。大家很快就麻了重要告警反而被淹没。后来我们把告警做了分级P0级直接电话加高优通知P1级才进工作群其他级别汇总成日报彻底解决了告警疲劳问题。第四个坑是研发自助发布权限放得太开。有个研发在本地没有进行完整回归测试直接把代码推到发布分支流水线触发发布后影响了一小批用户。虽然很快就回滚了但这个事故给我们提了个醒自助不等于不受约束。现在我们的发布系统强制做了环境校验、单测门禁和自动冒烟测试并预留了版本审批节点。第五个坑是自动伸缩策略配置不合理。我们在部分应用上启用了基于CPU的自动伸缩理论上说流量升高就扩容流量下降就缩容。但第一次流量突增时自动伸缩的反应速度没有跟上副本数被拉满后资源又不够反而引起了一系列连锁问题。现在的做法是给每个伸缩策略设置合理的最大副本上限和冷却时间并针对核心业务做更保守的最小资源预留。4.2 一个更稳健的迁移顺序参考如果让我重来一次我会把整个顺序调整得更稳妥。当前的推荐顺序是这样的第一步先搭好Sealos集群和统一权限模型这个底座不解决后面所有迁移都是空中楼阁第二步迁移内部工具类低风险应用目的是跑通流程、建立团队信心第三步统一日志、监控和告警链路先把可观测性做好再大量迁移业务否则出了问题连定位问题的工具都没有。第四步才迁移外部业务应用并且要分批进行不要在一个窗口期内塞太多系统第五步把数据库和中间件放到独立窗口处理不跟应用发布混在一起宁可慢一点也要保证数据不出问题最后一步才是成本治理和自动伸缩优化因为这时候资源用量和流量特征已经清晰了做出来的策略才靠谱。我当时是把数据库和应用迁移混在一起推进的这在节奏上其实非常冒险。现在回想如果某个核心库在切换时出现数据不一致影响面会非常大。所以我把这个顺序写在这里算是我自己复盘之后觉得更安全的路径。4.3 关于运维岗位我的一点观察经常有运维同学问我你们团队人少了是不是说明运维这个岗位快没了。我的想法正好相反。运维工作没有消失但它的定义确实变了。以前一个“合格运维”的标志是会Linux常用命令、会写Shell脚本、会搭Nginx和MySQL、会看系统负载。这些能力在今天依然重要但它们更像是基本功已经不足以支撑一个岗位的价值了。平台替代掉的是大量手工操作和重复巡检但平台本身也需要人维护也需要人根据业务特点设计SLO、做容量规划、治理成本、分析故障根因。我给出一个比较实际的建议运维工程师如果还在主力写手工脚本、人肉盯监控那确实要担心被平台替代但如果开始接触Kubernetes、可观测性、混沌工程、成本分析这些方向反而会因为平台化而放大价值。我在迁移前给团队说过一句话宁可让平台帮我们做80%的重复事也要让人去做那20%真正的“高杠杆事”。最后说一点现在的日常我每天早上的第一件事已经不是看工作群里有没有告警了而是打开平台看一眼隔夜发布汇总、SLO达成率和资源账单。从12个人到3个人对我个人最大的改变不是团队人数而是我终于有精力去思考运维到底应该为业务提供什么价值而不是每天疲于应付各种救火任务。如果你也正在做平台化迁移的决策我的建议不是“立刻去上某个工具”而是先用一个月记录你团队每天都在做什么你会发现值得被自动化接管的工作比你想象中多得多。 Sealos云原生平台：运维团队从12人减至3人的实战复盘
那条标题挂出来之后我被同行问得最多的一句是Sealos到底是什么东西能把运维团队从12个人缩到3个人我理解大家为什么这么惊讶。12到3这个数字听起来像在讲故事甚至像是在吓唬人。但作为那个被HR半开玩笑问“要不要给自己也转个岗”的CTO我今天想把这次迁移的完整过程、裁撤逻辑和踩过的坑一次性讲清楚。先说结论人确实少了但业务没垮系统也没比以前更脆弱。核心原因不是Sealos能“吃掉”多少运维岗位而是它把大量重复性、低价值、依赖人肉盯守的运维工作变成了平台能力和研发自助能力。这篇文章不是软文也不打算劝每个人都上这套方案。我只想把我自己经历过的决策过程、迁移节奏、团队重塑和失败经验记录下来给正在纠结“要不要引入云原生平台”“运维团队要不要缩编”的人一个参考样本。1. 为什么会走到迁移这一步12个人每天都在忙什么1.1 团队规模的真相人不少但产出很虚很多管理者只看“12个人”这个数字觉得运维投入很充足系统应该很稳。但你真把这12个人摊开看就会发现绝大多数精力都消耗在救火和重复劳动上。我当时把我们团队的日常工作做了一次统计结果非常扎心。每天有两个人长期盯告警群和控制台一有告警就人手确认“是不是误报”还有两个人在写部署脚本和Ansible playbook改一套环境配置往往要跑半天发布日更是全员待命研发把安装包传上来运维手动更新镜像、手动改配置、手动重启整个流程没有版本控制也没有标准化日志回滚全靠经验和运气。数据库那边还有两个专职的人维护着几十套MySQL、PostgreSQL和Redis实例日常做备份、清理慢日志、处理主从延迟一旦出问题就是半夜被叫醒。剩下的人有的管机房设备有的对接业务部门接需求有的处理工单和资源申请。我算了一笔账真正花在容量规划、根因分析、系统架构改进这些高价值工作上的时间可能不到团队总工时的两成。这不是这12个人不努力而是传统运维模式的组织结构决定了他们只能这么做。告警响了必须有人看工单来了必须有人接环境变了必须有人改脚本。只要这些机制还在人再多也只是让救火的速度快一点并不能让火苗变得更少。1.2 为什么是Sealos而不是自建PaaS或云全家桶在决定引入Sealos之前我其实认真对比过几条路基于Kubernetes自建一套PaaS、直接用云厂商全家桶、采购商业PaaS平台还有最后选择的Sealos这类云原生操作系统路线。自建PaaS是技术团队很容易产生冲动的一条路觉得K8s都能搭再封装一层也不是不行。但冷静下来想一个内部PaaS要包含应用管理、发布流水线、网关、监控告警、数据库服务、存储管理、权限体系这套东西真正成熟至少要两三年持续投入。我们团队当时最缺的就是时间。云厂商全家桶的吸引力在于托管服务多但一旦深度绑定私有化交付、混合云场景和成本控制都会变得被动这对我们这类既有线上SaaS又有企业私有化部署需求的公司来说不是最优解。商业PaaS又存在闭源、定制难和许可证成本的问题。Sealos进入视野是因为它的定位和传统PaaS不太一样。它更像一个把基础设施包起来的操作系统底层编排还是Kubernetes但把集群管理、应用商店、数据库、对象存储、网关、监控告警这些组件统一封装。它对运维人员更友好的一点是不是让你上来就面对一堆裸露的YAML和自定义资源定义而是可以通过控制台和命令行完成集群搭建、组件安装、应用部署这些事情。对我们来说这是一种介于“纯自建”和“全托管”之间的平衡点。1.3 迁移之前我先回答了自己三个问题决定动手之前我在管理层面前给自己立了几个规矩也是后来验证方向时反复用的标准。第一个问题是系统能不能在迁移期间保持业务稳定。红线是核心业务不能出现长时间中断数据绝对不能丢。这不是口号而是决定迁移顺序的前提。第二个问题是研发团队是否愿意改变工作习惯。如果平台做得再漂亮研发还是习惯找运维“帮我发一下”那平台只是一个新的工单入口人力根本压不下来。第三个问题是投入产出比能不能算过账。迁移需要时间、需要采购或部署资源我需要用一个可量化的框架向董事会解释为什么前期投入是值得的。当时我们定下的目标是这样的每月需要运维人工介入的告警数量下降80%发布耗时从小时级降到分钟级数据库和中间件交付从按周计变成按分钟计研发自助完成日常发布和回滚。这些目标没有被一个季度之内全部完成但回头看正是因为有这些可衡量的目标才没让迁移变成一场“为了上云而上云”的运动。2. 迁移过程是怎么拆解的先动哪里后动哪里2.1 先拿低风险业务试水把路径跑通很多运维体系改造失败的共同原因是想一口气把生产环境全部切换过去结果出了问题时连回退都不敢做。我们当时定了一个原则先拿低风险业务试水把整套流程在非关键系统上完整跑通再逐步扩大范围。第一批迁移的是内部OA、报表平台和一两个访问量很低的内部工具。这些系统挂了最多被同事抱怨两句不会造成收入损失。我让团队在测试环境把Sealos集群搭起来先在上面部署了一套和生产环境相同版本的报表系统然后把发布流程、监控接入、日志采集、备份恢复这些环节全部演练了一遍。等测试环境稳定运行两周后才把真实业务切过去。做这个阶段的目的有两个。一是积累平台操作经验让运维同事知道某个组件出问题时应该去哪里看日志、怎么重建服务二是让研发体验一下“自助发布”是什么感觉而不是继续把发布请求塞给运维。等到内部工具连续发布十几次都没有出问题之后团队对平台的信任才初步建立起来。这个阶段看起来进度慢但它是整个迁移最值得花时间的一步。2.2 把基础设施和可观测性一次性重做过了试水阶段我们开始处理最底层的东西多环境基础设施纳管和可观测性链路重建。以前我们每个环境都是一批独立虚拟机生产、预发、测试环境之间的配置经常不一致。这次迁移统一以Kubernetes集群作为底座再通过Sealos的控制台把各个集群纳管起来。我们按业务域划分了命名空间在Ingress网关层统一了域名和证书管理存储类全部按性能和容量需求重新划分。原来应用日志散落在各台服务器的目录里查问题经常要登录服务器用grep翻文件新的体系里所有日志统一采集到日志平台通过标签检索研发自己就能看到自己服务的运行状态。监控告警链路也做了整合原来每个系统各搞一套监控规则重复且口径不一现在全部以统一指标为基础按照服务等级和SLO重新梳理了告警规则。这部分工作技术难度并不是最大的真正难的是推动各个业务线把日志格式和指标口径统一起来。有些老系统的日志原本就是自由格式解析规则很难写。我们用了将近三周时间配合各业务研发调整关键路径上的日志输出才勉强把可观测性链路跑通。但这一步做完之后后续很多问题的定位效率都提高了靠人登录服务器排查故障的历史也逐渐成为过去。2.3 发布链路从“人肉传包”变成“研发自助”当基础设施和可观测性稳定之后我们开始动发布链路。之前研发提上线申请运维根据文档手工部署整个过程不可控因素很多。我们把发布系统接入了Sealos的应用管理能力研发在平台上选择自己要发布的应用构建流水线跑完后流水线自动更新镜像并触发滚动发布。回滚是这次改造里最受欢迎的功能。以前回滚需要运维手工切换镜像标签、重新执行部署脚本运气不好还要改数据库连接配置。现在发布系统会记录历史版本研发在界面上点一下就能回到上一个稳定版本。灰度发布也顺手做了针对部分核心应用可以先把流量切到新版本的一小部分验证通过后再全量放开。这里必须说清楚权限模型。我们给研发开放了自助发布入口但不意味着所有操作都不受控。普通研发只能在自己所属命名空间内操作发布配置变更仍然需要走审批流涉及数据库连接、网关规则、集群配置的部分仍然由保留的运维同学统一负责。这个分寸拿捏很重要如果一开始就把权限全放开后面大概率会出安全事故。2.4 数据库和中间件迁移最险的一段路应用发布可以靠平台能力快速搬过去数据库和中间件却没办法一键迁移。这是我们整个项目里风险最高的环节也是耗时最长的环节。MySQL、PostgreSQL、Redis一共几十套实例逐一做高可用改造和数据迁移。每个实例的迁移流程基本是这样先在Sealos平台上创建一套配置相同的高可用实例做一次全量备份并在新实例上恢复然后开启增量同步追平数据等到主从延迟归零后再切换连接。切换窗口选在流量低点业务侧配合调整数据库连接地址验证核心链路没问题后观察一天再清理老实例。Redis相对简单因为大部分数据是可重建的缓存只要提前预热并切换即可。有几个细节特别容易翻车。一是定时任务有些老系统在数据库服务器上直接挂了crontab迁移后没人记得这回事数据同步和报表任务就断了二是数据库账号权限新实例只迁移了业务主账号忘记迁移各种内部工具需要的只读账号结果BI系统第二天就报错三是慢查询新实例的硬件和配置不一样个别SQL的执行计划变了性能反而下降。这些都是靠迁移后的持续观察才发现的所以数据库迁移一定不能只盯着切换那一下要预留足够长的观察窗口。3. 12个人是怎么变成3个人的岗位消融的真实过程3.1 原先12个人的分工最后被谁接走了很多人听到“从12个人缩到3个人”时第一反应是公司把人裁了。实际情况不完全是这样有一部分人的工作确实被平台替代了也有一部分人通过内部转岗去了更合适的岗位。我把原来的分工和去向整理过一张表这里贴出来供参考。原岗位职责人员数量被什么机制替代后续去向告警值守与监控确认2人统一告警平台、分级别通知、自动汇总转岗研发效能或应用开发环境交付与脚本维护2人Sealos模板化部署、基础设施代码化2人转岗应用研发发布支持与版本回滚2人研发自助发布、灰度回滚1人转岗业务研发1人离职数据库日常维护2人平台高可用数据库、备份自动化保留1人1人转售后技术支持网络与硬件设备维护1人基础设施向云原生底座收拢转岗行政IT支持工单处理与业务需求对接2人自助资源申请、费用账单报表转岗各业务线技术支持值班负责人与统筹1人SLO机制、平台稳定性Owner保留至平台运维核心岗这个表格并不是说“平台替代了多少人”而是说这些人的时间被大量低价值工作占据。当平台把这些工作接管后团队结构自然就需要重新设计。3.2 留下来的3个人正在干什么现在团队里保留的3个人分工比之前的12个人清晰得多。我不觉得我们是在硬撑反而是以前那种“人多但都在救火”的状态才让人心里发虚。第一个人负责平台与基础设施。他管的是Sealos集群本身、节点的生命周期、存储类、网络策略、网关和证书管理。日常工作是处理集群升级、节点资源饱和度、存储容量规划以及和云厂商或机房那边的对接。他不需要去管业务应用里某个Pod为什么起不来那是研发自助应该解决的事情。第二个人负责稳定性与可靠性工程。他盯的是SLO、告警降噪、容量预测、备份恢复演练、故障复盘。每次出现线上事故由他牵头写时间线、定位根因、跟踪改进项。他会定期做一次全集群的故障演练确保当数据库节点挂掉、某个可用区不可用时系统确实能自愈。第三个人负责效能与成本治理。他管资源申请规范、成本账单、命名空间配额以及给研发团队做平台使用培训。每个月的云资源和服务器成本账单由他分析哪些业务资源利用率低、哪些项目应该降配都由他推动。三个人同时也在互相备份。任何一个人休假另外两个都能接手他的核心职责因为日常操作已经收敛到平台控制台和标准流程里不再依赖某个人的绝活和记忆。3.3 团队变小之后工作方式有哪些变化团队人少之后最大的变化是工作节奏从“被动响应”变成了“主动治理”。以前是等告警响了、等研发来求助现在每天早上第一件事是看统一的运维仪表盘了解隔夜发布情况、告警汇总、资源账单和SLO达成率。与研发的协作方式也变了。以前研发做一次上线要跟运维反复沟通环境、端口、依赖、日志目录这些事情。现在研发在平台自助创建应用填好镜像地址、资源配额和环境变量流水线自动构建发布。他们遇到问题也是先在日志平台查自己的服务解决不了才找运维而且找到运维时通常已经带着明确的错误日志和信息效率完全不同。这个变化需要研发团队配合适应。我们专门写了平台使用手册还组织了几次培训把“常见问题排查”“发布回滚操作”“日志检索方式”做成视频和文档。事实证明工具和文档是同等重要的。如果没有培训和文档研发仍然会把运维当成客服团伙人员的压力就会变得很大。4. 迁移踩过的坑以及如果重来我会怎么排顺序4.1 五个真实的坑和对应解法迁移过程并不顺利我挑五个印象最深的坑来写每个坑后面都附了我们现在的解法。第一个坑是存储权限没有提前做规划。应用迁到K8s之后本身用的是持久化存储但NFS和云盘在权限模型上跟原来服务器目录不完全一致导致不少应用启动时报“权限不足”。我们当时排查到凌晨最后通过统一调整StorageClass的权限映射才解决。现在的做法是任何应用迁移之前运维必须先确认存储挂载方式和目录权限不允许应用自己随便挂。第二个坑是数据库迁移只顾着搬数据忘了搬“周围的配置”。老数据库里其实有很多隐藏资产定时任务、存储过程、只读账号、自定义函数。这些内容平时没人觉得重要切换之后业务报表、后台任务全都出问题。从那以后我们给数据库迁移清单里加了一条必须审计任务、权限和函数不允许只迁表结构。第三个坑是告警规则接入太猛。统一监控平台上线后我们一开始把所有规则全接入工作群结果是每天上百条消息真正需要人处理的没几条。大家很快就麻了重要告警反而被淹没。后来我们把告警做了分级P0级直接电话加高优通知P1级才进工作群其他级别汇总成日报彻底解决了告警疲劳问题。第四个坑是研发自助发布权限放得太开。有个研发在本地没有进行完整回归测试直接把代码推到发布分支流水线触发发布后影响了一小批用户。虽然很快就回滚了但这个事故给我们提了个醒自助不等于不受约束。现在我们的发布系统强制做了环境校验、单测门禁和自动冒烟测试并预留了版本审批节点。第五个坑是自动伸缩策略配置不合理。我们在部分应用上启用了基于CPU的自动伸缩理论上说流量升高就扩容流量下降就缩容。但第一次流量突增时自动伸缩的反应速度没有跟上副本数被拉满后资源又不够反而引起了一系列连锁问题。现在的做法是给每个伸缩策略设置合理的最大副本上限和冷却时间并针对核心业务做更保守的最小资源预留。4.2 一个更稳健的迁移顺序参考如果让我重来一次我会把整个顺序调整得更稳妥。当前的推荐顺序是这样的第一步先搭好Sealos集群和统一权限模型这个底座不解决后面所有迁移都是空中楼阁第二步迁移内部工具类低风险应用目的是跑通流程、建立团队信心第三步统一日志、监控和告警链路先把可观测性做好再大量迁移业务否则出了问题连定位问题的工具都没有。第四步才迁移外部业务应用并且要分批进行不要在一个窗口期内塞太多系统第五步把数据库和中间件放到独立窗口处理不跟应用发布混在一起宁可慢一点也要保证数据不出问题最后一步才是成本治理和自动伸缩优化因为这时候资源用量和流量特征已经清晰了做出来的策略才靠谱。我当时是把数据库和应用迁移混在一起推进的这在节奏上其实非常冒险。现在回想如果某个核心库在切换时出现数据不一致影响面会非常大。所以我把这个顺序写在这里算是我自己复盘之后觉得更安全的路径。4.3 关于运维岗位我的一点观察经常有运维同学问我你们团队人少了是不是说明运维这个岗位快没了。我的想法正好相反。运维工作没有消失但它的定义确实变了。以前一个“合格运维”的标志是会Linux常用命令、会写Shell脚本、会搭Nginx和MySQL、会看系统负载。这些能力在今天依然重要但它们更像是基本功已经不足以支撑一个岗位的价值了。平台替代掉的是大量手工操作和重复巡检但平台本身也需要人维护也需要人根据业务特点设计SLO、做容量规划、治理成本、分析故障根因。我给出一个比较实际的建议运维工程师如果还在主力写手工脚本、人肉盯监控那确实要担心被平台替代但如果开始接触Kubernetes、可观测性、混沌工程、成本分析这些方向反而会因为平台化而放大价值。我在迁移前给团队说过一句话宁可让平台帮我们做80%的重复事也要让人去做那20%真正的“高杠杆事”。最后说一点现在的日常我每天早上的第一件事已经不是看工作群里有没有告警了而是打开平台看一眼隔夜发布汇总、SLO达成率和资源账单。从12个人到3个人对我个人最大的改变不是团队人数而是我终于有精力去思考运维到底应该为业务提供什么价值而不是每天疲于应付各种救火任务。如果你也正在做平台化迁移的决策我的建议不是“立刻去上某个工具”而是先用一个月记录你团队每天都在做什么你会发现值得被自动化接管的工作比你想象中多得多。