# 交付部署组人力现状与建议汇报

> **汇报日期**：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 人紧急补充。