增加组织人员缺失；黑苹果折腾

30-特战队周报/7-交付部署团队人力与协同建议.md

@@ -0,0 +1,162 @@
+# 交付部署组人力现状与建议汇报
+
+> **汇报日期**：2026年6月16日
+> **汇报人**：交付部署特战队
+
+---
+
+## 一、当前困境总览
+
+### 1.1 交付部署特战队"正在扛住"的工作
+
+目前团队 **3人**，正在尽力维持以下核心工作：
+
+| 工作板块 | 具体内容 | 当前状态 |
+|:---|:---|:---|
+| 项目交付部署（权重30%） | 外部项目的交付部署、版本升级 | ⚠️ 勉强维持，时效承诺压力大 |
+| 项目生命周期维护（权重30%） | 持续交付、故障排查、维护变更 | ⚠️ 疲于应付，只能做到"灭火式"响应 |
+| 研发环境维保（权重10%） | 研发环境故障修复、验收环境部署 | ⚠️ 基本维持 |
+| 院内资源维护（权重10%） | 研发工具链迁移、服务器信创改造 | ⚠️ 被动配合 |
+
+> [!WARNING]
+> 以上工作已经占据团队 **100%** 的时间。任何一项新增需求都会导致现有工作的延迟或质量下降。
+
+### 1.2 目前"无力完成"的重要工作
+
+以下是工作矩阵中明确要求、但当前团队确实无力推进的事项：
+
+| 工作板块 | 具体内容 | 缺失原因 |
+|:---|:---|:---|
+| **重点项目维保**（权重10%） | 重大演示/汇报/验收的 SRE 保障 | 无专职人员，缺乏可观测体系建设能力 |
+| **交付部署标准化** | 制定《部署说明书》、规范交付流程 | 无人力资源投入 |
+| **信创国产标准化** | 中移凌云信创及基础架构改造 | 需要专项攻坚，当前无法抽人 |
+| **视频流媒体标准化** | 视频流媒体模块的部署标准化 | 新增领域，无人有余力承接 |
+| **AI算法部署标准化** | GPU环境交付测试及标准化 | 无基础环境、无人有余力承接 |
+| **项目安全维护**（权重5%） | 基础组件漏洞修复、安全合规 | 耗时、无法标准化，无力承接 |
+| **集成支撑中心培训** | 制定培训计划、定期培训 | 极大增加自身负担 |
+
+> [!CAUTION]
+> **标准化工作的停滞会形成恶性循环**：越不做标准化 → 每次交付越依赖人工 → 人力越紧张 → 越没时间做标准化。这是当前最大的系统性风险。
+
+---
+
+## 二、未来面临的严峻挑战
+
+### 2.1 平台数量激增带来的工作量爆发
+
+```
+当前                                    未来（可预见）
+─────────────────────────────────────────────────────
+老行业平台                              老行业平台（持续维护）
+新飞服平台                              新飞服平台（持续维护）
+新监管平台                              新监管平台（持续维护）
+视频流媒体模块                          视频流媒体模块（持续维护）
+AI算法部署（勉强承接）                    AI算法部署（常态化）
+                                       ＋ 低空安防平台（新增）
+                                       ＋ 数据底座（新增）
+                                       ＋ 更多新平台...
+```
+
+> [!IMPORTANT]
+> 每新增一个平台，不仅意味着一次部署，更意味着该平台在其**整个生命周期**内的持续交付、版本升级、故障排查、安全合规等工作的永久性增加。**工作量是只增不减的。**
+
+### 2.2 集成支撑中心的结构性问题
+
+根据"**应接尽接**"原则，集成支撑中心将不参与我方项目交付。同时：
+- 集成支撑中心无法脱手交付，强依赖我方指导
+- 培训工作反而增加了我方的人力消耗
+- **净效果**：不仅没有减负，反而成为额外负担
+
+### 2.3 研发侧交付物不规范的连锁影响
+
+- 交付物形态不统一、配置不规范
+- 交付测试支持不足，部署容易出问题
+- 直接后果：每次交付都是"摸索式"作业，耗时成倍增长
+
+---
+
+## 三、人力结构现状与建议
+
+### 3.1 当前人力缺口分析
+
+| 项目 | 数据 |
+|:---|:---|
+| 研发团队总规模 | 监管平台45人 + 飞服平台24人 + 视频及算法17人 = **86人** |
+| 行业标准配比 | 研发:交付 = 10:1（甚至更低） |
+| 应有交付人员 | **9～12人** |
+| 当前实际人员 | **6人** |
+| **缺编人数** | **3～6人** |
+
+### 3.2 人力补充建议
+
+建议分 **两个阶段** 逐步补充人力：
+
+#### 第一阶段：紧急补充（建议增加 3人）
+
+| 序号 | 岗位方向 | 核心职责 | 优先级 |
+|:---|:---|:---|:---|
+| 1 | **交付部署工程师** | 分担日常交付部署与持续交付工作，释放特战队精力 | 🔴 最高 |
+| 2 | **AI/GPU部署工程师** | 承接AI算法部署，建立GPU测试环境及标准化流程 | 🔴 最高 |
+| 3 | **SRE 工程师** | 建设可观测体系，承接重点项目维保，系统稳定性保障 | 🟡 高 |
+
+#### 第二阶段：能力完善（建议再增加 2～3人）
+
+| 序号 | 岗位方向 | 核心职责 | 优先级 |
+|:---|:---|:---|:---|
+| 4 | **安全运维工程师** | 安全合规定制开发、漏洞修复，对接安全组需求 | 🟡 高 |
+| 5 | **项目运维工程师** | 负责交付生命周期内的项目维保工作，处理项目中的交付和运维需求 | 🟢 中 |
+
+> [!TIP]
+> 第一阶段补充完成后，团队达到 **9人**，可以基本覆盖工作矩阵中的核心职能。第二阶段完成后达到 **11～12人**，可以实现标准化和能力建设的良性循环。
+
+---
+
+## 四、交付部署特战队与重资产交付的协同关系
+
+
+### 4.1 两个小组的职能定位差异
+
+| 维度 | 交付部署特战队 | 重资产交付（监管交付支撑） |
+|:---|:---|:---|
+| **核心职能** | 软件平台的交付部署、持续交付、标准化建设 | 涉及硬件设备（监管设备、飞行器）的现场交付 |
+| **工作特点** | 远程为主、标准化导向、多平台覆盖 | 现场为主、项目制、重资产交付 |
+| **技术方向** | 云原生、K8s、中间件、CI/CD | 硬件集成、现场联调、设备部署 |
+| **服务对象** | 所有软件平台（飞服、监管、视频、AI等） | 所有需要重资产交付的项目 |
+
+### 4.2 协同建议
+
+建议明确 **"分工清晰、能力互补、资源共享"** 的协同模式：
+
+#### ① 明确分工边界
+
+- **特战队**：负责所有平台的**软件侧**交付部署、持续交付、标准化建设、SRE保障
+- **重资产交付**：负责涉及**硬件设备**的项目现场交付、联调、设备部署
+- **共同承担**：重大项目的联合保障
+
+#### ② 建立能力互补机制
+
+- 特战队向重资产交付团队输出**部署标准化能力**，降低重资产项目中软件部署的复杂度
+- 重资产交付团队向特战队反馈**现场交付经验**，帮助优化交付流程
+- 鼓励两组在不忙时进行**交叉培训**，培养"一专多能"型人才
+
+#### ③ 统一资源调配
+
+- 在人力紧张时，由副组长（特战队队长与B）协商进行**临时人力借调**
+- 建立**共享工单池**，按照技能标签匹配分配任务
+- 重大项目采用**联合作战**模式，由两位副组长共同制定作战方案
+
+---
+
+## 五、总结与行动建议
+
+| 优先级 | 建议事项 | 预期效果 |
+|:---|:---|:---|
+| 🔴 紧急 | 优先补充 3 名核心岗位人员 | 覆盖基础交付+AI部署+SRE三个关键缺口 |
+| 🔴 紧急 | 明确特战队与重资产交付的分工边界 | 消除内部协作模糊地带，提升效率 |
+| 🟡 重要 | 推动研发侧交付物标准化 | 从源头降低交付复杂度，减少重复劳动 |
+| 🟡 重要 | 建立集成支撑中心的自主交付能力 | 真正释放我方人力，而非增加培训负担 |
+| 🟢 长期 | 完成第二阶段人员补充 | 实现团队满编，具备标准化和能力建设的条件 |
+| 🟢 长期 | 建设可观测体系和自动化工具链 | 从"人工运维"向"工程化运维"转型 |
+
+> [!IMPORTANT]
+> **核心观点**：当前团队 6 人已处于超负荷运转状态，只能维持"灭火式"的基础交付。随着平台数量持续增加和新业务（AI算法、低空安防、数据底座等）即将上线，如果不在短期内完成人力补充和标准化建设，交付质量和响应时效将面临系统性崩溃的风险。建议尽快启动第一阶段的 3 人紧急补充。