ProjectAGiPrompt/12-交付特战队/1-原始文档.md

剑哥，秉承能够充分发挥自身能力为部门发展，提供研发团队、部门协同流畅性，提高市场交付支撑效率的出发点。

在此斗胆提出自己一点小小的看法与建议，叨扰剑哥，还望能够查阅指正！

工作传承

先从软件开发模式讲起，传统时代（刀耕火种）的软件开发，就是前端、后端、运维一起上，就像是镰刀割麦子、弯腰插麦子，这在小农经济时代是可以的，但是人肉推进模式终究是效率很低下，人员损耗率很高，无法应对现在高达50个以上的市场化项目的拓展、交付、维护。

自动2013年云计算时代，15年之后云原生时代之后，开发进入现代农业机械化时代，大型联合收割机可以进行高效、自动化的作业，是传统小农种植不可比拟的效率及规模。

想到实现农业机械化时代，需要应用到大量的云原生的技术和方法。国内外大型互联网团队均有基础架构（设施）研发团队，用以研制大型生产机械，这部分现在的组织架构是很欠缺的。

从20年入职成研院以来，入职的目标即为基础架构（设施）研发团队，但是项目初期阶段，市场化项目规模不大，研发大型农业机械的成本极高，投入产出比不高，小农经济更有性价比。但是现在到了关键时候，市场项目过多，传统小农模式已经到了崩溃的边缘，要么就是海量人力的投入，要么就需要研制大型农业机械，迈入现代化农业生产阶段！

现有架构存在的问题

像我23年给你提过的一样，组织架构需要交付部署（由于技术支撑团队不承接此部分工作）团队，职责、权责清晰。

交付部署

1. 在之前云平台的架构里面，交付部署明明重要，却没有单独的职责分配
2. 飞行服务组承担 飞行服务、监管平台的交付部署工作
3. 监管平台貌似很害怕我和雪波不给他们部署？我搞不懂这种思想产生的原因
   1. 实际我们不抗拒监管部署，因为对我们来说都是一样的。不满的是职责、权责不清，我们是打黑工的角色
   2. 可能是极力想隐藏我和雪波的关键工作角色（虽然工作内容价值不高，但是交付环节很重要）

项目维护

1. 随着市场化项目的增多，项目的售后维护工作日渐增多
2. 主要是安全漏洞修复问题
   1. 服务器漏洞（基线漏洞）：全部是我和雪波去修复，占用大量的时间，成果非常不好
   2. 代码漏洞（渗透漏洞）：需要由开发人员修复，我和雪波去部署更新。
3. 定制化开发-持续交付部署
   1. 由于现在定制化项目太多，持续交付部署持续进行，部署环节割裂耗时很长【后文重点优化】，虽然我已经优化了锄头镰刀，但是小农模式下人力还是要被耗死
   2. 还有伴发的很多问题，如安全、审计问题

基础环境维护

研发环境维护

1. 无职责、权责分配
2. 存在280台以上的服务器，没有时间进行日常的维护保养工作，
3. 经常性的主机故障导致演示平台崩溃，
4. 由于部署时间过早，架构老旧，旧演示平台运行极度卡顿

演示DEMO环境维护

1. 无职责、权责分配
2. 研发人员没有研发环境使用，研发效率极度底下
3. 监管组同事因为我和雪波还在极力维护演示环境，居然直接拿演示DEMO环境开发

重大事故

1. 25年春节大年三十，演示DEMO环境崩溃，主机故障无法恢复
2. 一群人拉了一堆群，聊了各种问题，显得很热闹
3. 实际还是我和波哥 将DEMO环境整体迁移，重新部署才恢复正常

基础架构平台开发

小农经济不具备此部分的工作，只能抽空进行镰刀、锄头的优化工作。

权责、职责不分、混乱

1. 出任何事情拉一群人，实际没有干活的
2. 监管平台成立交付支撑组
   1. 存在挂羊头卖狗肉的情况，前端开发全都挂进去
   2. 监管平台部署，5年的技术沉淀，龙卫根本干不来
   3. 最终还是袁雪波一个人默默承担了所有
   4. 即使有独立的小组，仍然无法支撑规模化的市场化项目部署工作
3. 还有 既然已经组织切分（分家了），监管平台交付部署的工作，后面我和袁雪波是接还是不接，管还是不管呢？

新的工作内容

从23年我向您提及至今，深感现在小农经济模式的巨大弊病与限制，研发人力耗损严重，规模化的市场化项目难以支撑与维系。

在一珂的授意与指挥下，我最近开启了大型联合收割机的研制工作

RMDC基础平台

1. 全称为Runtime Management & Development Operation Center，中文系统名称为 运行环境管理及开发运维中心
2. 本系统旨在解决日益繁多的跨公网市场化项目、众多开发环境、演示环境等运行环境的开发、监视、运维问题，提供一站式中心化的管理、控制、操作能力，具备权限控制、流程审批、审计追溯的功能特性。（类似于 一网统飞，此平台实现 中移凌云运行环境的 一网统管）
3. 重点功能介绍
   1. 交付物构建：能够一个界面实现从代码到项目交付物的产出
   2. 持续交付更新：能够实现全国任意项目的一键跨公网微服务升级更新
   3. 项目统一监控中心：可以查看全国任意项目的实时运行状态，提高系统稳定性
   4. 权限控制能力：实现谁提交的、谁审批的、谁更新的，如果出了问题均可以追责
   5. 项目信息控制：可以查看全国任意项目的详细部署信息，极大提高定制化开发效率
4. 效率提升评估
   1. 交付物构建：一次构建节约人力成本10分钟，平均每天构建150次，每天节约开发人员工时为25小时！
   2. 持续交付更新：一次更新节约人力成本15分钟，平均每个项目每年更新300次（雄安已经更新超过500次），市场化项目数量为25个计算，每年能够节约人力成本1875小时（8小时工作计算，达到234人天）。考虑到项目的驻点运维人员开支，大概率可以节约1.5个运维人员的年度成本！
   3. 项目信息控制：一次信息查找节约10分钟，平均每天查找15次以上，每天节约的开发人员工时为 2.5小时！

建议的组织架构

1. 充分考虑到职责、权责划分，公司也是综合部、 产品中心，研发中心、技术支撑中心
2. 提高部门团队研发效率，将研发从小农经济模式转向现代农业机械化时代
3. 去除很多组织架构上面的障碍
4. 斗胆给出一些部门组织架构的建议
   1. 将现有监管平台的交付支撑组拆解，形成独立于监管平台和飞行服务平台的组，类似于产品组，整体的架构图就形成为
   2. 行业组进行市场化拓展 对接产品组
   3. 产品组负责中移凌云产品打造，对接监管平台 飞行服务平台
   4. 最后是基础架构组（交付支撑组）用于为研发两个团队提供如下支撑工作
      1. 交付部署职责
      2. 项目售后维护职责
      3. 研发环境维护管理职责
      4. 演示DEMO环境维护管理职责
      5. 准生产、生产环境维护管理职责
      6. 基础架构平台开发职责（大型联合收割机）
   5. 基础架构组 人员清单
      1. 组长 任一珂
      2. 王子文
      3. 袁雪波
      4. 郑岩
      5. 郝昊
   6. 之前的工作模式就是这样的划分，现在可以明确职责、权责

平台基础架构 （软件开发中的话术，类似于平台运行的地基）

平台运行环境维护（DEMO环境 生产环境 研发环境等 280多台服务器 ）

交付部署 （项目第一次落地）

持续交付更新（定制化开发需要，每次更新很费时间）

项目售后维护 （50多个项目需要维护，安全问题维护、版本升级、运行环境清理等）