RMDC系统设计文档 整体转换为SKILL

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

@@ -0,0 +1,125 @@
+剑哥，秉承能够充分发挥自身能力为部门发展，提供研发团队、部门协同流畅性，提高市场交付支撑效率的出发点。
+
+在此斗胆提出自己一点小小的看法与建议，叨扰剑哥，还望能够查阅指正！
+
+## 工作传承
+
+先从软件开发模式讲起，传统时代（刀耕火种）的软件开发，就是前端、后端、运维一起上，就像是镰刀割麦子、弯腰插麦子，这在小农经济时代是可以的，但是人肉推进模式终究是效率很低下，人员损耗率很高，无法应对现在高达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多个项目需要维护，安全问题维护、版本升级、运行环境清理等）