项目作品 / 存储平台化 · 全业务升级平台与管理面
STORAGE PLATFORM · UPGRADE ORCHESTRATION & MANAGEMENT CONSOLE
升级按流程走， 不靠人救场。
存储平台化 · 全业务升级平台与管理面
存储系统由多个业务服务组成，运行在不同的底座系统上，部署在客户的服务器上，服务之间有依赖关系。建平台之前，升级全靠手动部署：最多用一个脚本拉起一批服务，哪个出问题就处理哪个。这种方式灵活，但每次升级的质量取决于操作人员对脚本是否熟悉、现场救场能力强不强。日常管理操作也长期依赖研发和运维在命令行中完成，低效且难以维护。2024–2025 年我负责这两项平台化建设：先是对象存储管理平台（2024.11–2025.01），然后是全业务服务升级平台（2025.03–2025.05）。
- Go
- MySQL
- Redis
- Python / FastAPI
- AMIS
- 分层架构
01 / CONTEXT
项目背景
存储系统由多个业务服务组成，运行在不同的底座系统上，部署在客户的服务器上，服务之间有依赖关系。建平台之前，升级全靠手动部署：最多用一个脚本拉起一批服务，哪个出问题就处理哪个。这种方式灵活，但每次升级的质量取决于操作人员对脚本是否熟悉、现场救场能力强不强。日常管理操作也长期依赖研发和运维在命令行中完成，低效且难以维护。2024–2025 年我负责这两项平台化建设：先是对象存储管理平台（2024.11–2025.01），然后是全业务服务升级平台（2025.03–2025.05）。
为存储系统建设两套平台：一套把各业务服务的升级与回滚变成规范、可追溯的标准流程，一套把命令行运维换成可视化管理面。两套平台均在约 3 个月内从 0 到 1 交付。
02 / CHALLENGES
核心问题
升级质量依赖个人经验
手动部署、脚本批量拉起、出了问题现场处理：结果取决于操作人员的熟练度和救场能力，过程也无从追溯。
服务多、依赖杂、底座不一
各业务服务的部署方式、依赖顺序和运行底座各不相同，为每个服务、每种底座单独写脚本既慢又容易出错。
升级要平滑，失败要能退
升级期间要保障业务连续；一旦失败，必须能回到已知良好的状态。
管理面依赖命令行
日常管理操作分散在各个命令行接口里，效率低、门槛高，也难以维护和迭代。
03 / SOLUTION
方案设计与关键工程实践
01 · 规范化、可追溯的升级流程
按服务依赖把升级拆成定义清晰的标准步骤，每一步的执行结果都有记录、可追溯，失败时按记录回滚；重复的步骤交给流程稳定执行，而不是依赖操作人员的临场发挥。
02 · 服务元数据抽象
把服务的部署方式、依赖关系和版本信息抽象为统一的元数据，升级编排基于元数据组合，而不是逐个服务写脚本。
03 · 分层兼容不同底座
编排逻辑与底座适配分层，接入新底座只需补适配层，编排逻辑不变。
04 · 前后端分离的管理面
管理平台采用 FastAPI + AMIS 前后端分离；后台松耦合对接多套底层服务组件，迭代互不牵连。
04 / ARCHITECTURE
关键机制示意
本项目来自企业任职期间的研发工作。这里用抽象结构图说明升级编排与管理面的分层方式，不展示雇主的内部界面、源码或真实部署拓扑。
05 / OUTCOMES
工程成果
- 两套平台各约 3 个月从 0 到 1 交付
- 升级从手动部署变为标准化、可追溯的流程
- 管理操作从命令行迁移到可视化平台
交付周期按项目实际起止时间计算。运维效率的提升暂未量化；实测中最耗时的环节反而是升级包经隔离网络传到客户服务器（约 40 分钟），而不是平台内的编排执行，升级后的验证测试目前仍以人工为主。
06 / OWNERSHIP
我的工作与贡献
- 负责升级平台从业务调研、方案设计、开发、自测、测试到发布的全流程。
- 设计服务元数据模型与可扩展的服务组合逻辑，统一管理服务的部署与依赖。
- 负责对象存储管理平台的前后端设计与实现，包括前端页面和后台方案。
- 以松耦合方式对接多套底层服务组件，替代原有的命令行操作。
07 / REFLECTION
技术与产品思考
平台化的价值不在界面，而在于把散落在人脑和脚本里的知识沉淀成数据：服务是什么、依赖谁、怎么升级、怎么回退。元数据模型建对了，升级编排和管理面都只是建在它之上的不同视图。