---
document_type: "operation_doc"
service: "MOMENTRY_CORE"
title: "運維紀錄規範培訓材料"
date: "2026-03-27"
version: "V1.0"
status: "active"
owner: "Warren"
created_by: "OpenCode"
tags:
  - "運維紀錄規範培訓材料"
ai_query_hints:
  - "查詢 運維紀錄規範培訓材料 的內容"
  - "運維紀錄規範培訓材料 的主要目的是什麼？"
  - "如何操作或實施 運維紀錄規範培訓材料？"
---

# 運維紀錄規範培訓材料

| 項目 | 內容 |
|------|------|
| 培訓對象 | 全體運維團隊成員、技術負責人 |
| 培訓時長 | 30-45 分鐘 |
| 培訓方式 | 團隊會議、自主學習 |
| 文件版本 | V1.0 |
| 建立時間 | 2026-03-27 |

---

## 版本歷史

| 版本 | 日期 | 目的 | 操作人 | 工具/模型 |
|------|------|------|--------|-----------|
| V1.0 | 2026-03-27 | 創建培訓材料 | OpenCode | deepseek-reasoner |

---

## 培訓目標

完成本培訓後，學員能夠：
1. 理解新的運維紀錄規範的重要性
2. 正確使用各類文件模板
3. 遵循事件處理標準流程
4. 管理文件生命周期
5. 有效協作處理運維事件

---

## 第一部分：規範概述

### 1.1 為什麼需要新規範？

**現有問題**：
- 文件分散，難以查找
- 格式不一，信息不全
- 缺乏標準處理流程
- 經驗難以傳承

**新規範帶來的好處**：
- 統一文件組織結構
- 標準化信息記錄
- 明確處理時限和責任
- 完整的知識管理

### 1.2 核心概念

**四大文件類型**：
1. **事件報告 (Incident Reports)** - 記錄具體問題和處理過程
2. **根本原因分析 (RCA)** - 深入分析問題根源
3. **變更紀錄 (Change Records)** - 記錄系統變更和配置更新
4. **維護計畫 (Maintenance Plans)** - 規劃定期維護活動

**文件生命周期**：
```
新創建 → [類型/_active/] → 處理完成 → [類型/_completed/] → 超過保留期限 → [類型/_archived/]
```

**AI 優化**：生命周期狀態變更可自動觸發文件移動和通知。

---

## 第二部分：目錄結構與文件組織

### 2.1 主目錄結構

```
docs/maintenance_records/
├── rca/                  # 根本原因分析
│   ├── _active/         # 進行中 RCA
│   ├── _completed/      # 已完成 RCA
│   └── _archived/       # 已歸檔 RCA
├── incidents/           # 事件報告
│   ├── _active/         # 進行中事件
│   ├── _completed/      # 已完成事件
│   └── _archived/       # 已歸檔事件
├── changes/             # 變更紀錄
│   ├── _active/         # 進行中變更
│   ├── _completed/      # 已完成變更
│   └── _archived/       # 已歸檔變更
├── plans/               # 維護計畫
│   ├── _active/         # 進行中計畫
│   ├── _completed/      # 已完成計畫
│   └── _archived/       # 已歸檔計畫
├── templates/           # 文件模板
└── reviews/             # 審核報告
```

**AI 優化設計**: 此目錄結構支持 AI Agent 高效查詢和自動化文件移動。

### 2.2 文件命名規範

**命名格式**：
```
{前綴}_{服務}_{問題簡述}_{日期}.md
```

**前綴對照表**：
| 前綴 | 用途 | 範例 |
|------|------|------|
| `RCA_` | 根本原因分析 | `RCA_WORDPRESS_TIMEOUT_2026_03_27.md` |
| `INCIDENT_` | 事件報告 | `INCIDENT_DATABASE_CONNECTION_2026_03_26.md` |
| `CHANGE_` | 變更紀錄 | `CHANGE_API_ENDPOINT_2026_03_25.md` |
| `MAINTENANCE_` | 維護計畫 | `MAINTENANCE_MONTHLY_2026_04.md` |

### 2.3 實戰練習：命名測試

將以下描述轉換為正確文件名：
1. 2026年3月28日發現的 PostgreSQL 連接超時事件
2. 2026年4月計劃的每月維護
3. 2026年3月29日進行的 n8n API 端點變更

**答案**：
1. `INCIDENT_POSTGRESQL_CONNECTION_TIMEOUT_2026_03_28.md`
2. `MAINTENANCE_MONTHLY_2026_04.md`
3. `CHANGE_N8N_API_ENDPOINT_2026_03_29.md`

---

## 第三部分：模板使用指南

### 3.1 可用模板

| 模板 | 用途 | 位置 |
|------|------|------|
| `TEMPLATE_INCIDENT.md` | 事件報告 | `templates/TEMPLATE_INCIDENT.md` |
| `TEMPLATE_RCA.md` | 根本原因分析 | `templates/TEMPLATE_RCA.md` |
| `TEMPLATE_CHANGE.md` | 變更紀錄 | `templates/TEMPLATE_CHANGE.md` |
| `TEMPLATE_MAINTENANCE.md` | 維護計畫 | `templates/TEMPLATE_MAINTENANCE.md` |

### 3.2 創建新文件的標準流程

**步驟 1：選擇模板**
```bash
# 事件報告示例
cp docs_v1.0/OPERATIONS/maintenance_records/templates/TEMPLATE_INCIDENT.md \
   docs/maintenance_records/incidents/_active/INCIDENT_<服務>_<問題>_$(date +%Y_%m_%d).md
```

**步驟 2：填寫基本信息**
- 報告者、報告時間
- 嚴重等級 (P0-P4)
- 當前狀態 (⏳🔍🔧✅📁)
- 受影響服務
- 負責人

**步驟 3：詳細描述**
- 問題現象
- 影響範圍
- 重現步驟
- 相關日誌

**步驟 4：定期更新**
- 按事件等級要求更新頻率
- 記錄所有處理步驟
- 更新狀態標記

### 3.3 模板填寫示範

**事件報告頂部信息表示例**：
```markdown
| 項目 | 內容 |
|------|------|
| 報告者 | 張三 |
| 報告時間 | 2026-03-27 14:30 |
| 嚴重等級 | P2 |
| 當前狀態 | 🔍 調查中 |
| 受影響服務 | PostgreSQL, API 服務 |
| 負責人 | 李四 |
```

**嚴重等級選擇指南**：
- **P0**：網站完全無法訪問，立即處理！
- **P1**：主要功能不可用，2小時內處理
- **P2**：次要功能問題，4小時內處理
- **P3**：輕微問題，工作日內處理
- **P4**：諮詢建議，3工作日內回應

---

## 第四部分：事件處理流程

### 4.1 完整流程圖

```
事件檢測 → 報告創建 → 等級評估 → 調查處理 → 解決驗證 → 文件歸檔
    ↓          ↓          ↓          ↓          ↓          ↓
監控警報   使用模板   P0-P4評估  狀態更新   RCA創建  生命周期管理
用戶報告   填寫信息   設定時限   定期溝通  經驗總結  定期清理
```

### 4.2 各等級處理要求

| 等級 | 開始處理時限 | 解決時限 | 狀態更新頻率 | 文件要求 |
|------|--------------|----------|--------------|----------|
| P0 | 立即 (5分鐘內) | 1小時 | 每15分鐘 | 必須 RCA |
| P1 | 2小時內 | 4小時 | 每30分鐘 | 建議 RCA |
| P2 | 4小時內 | 8小時 | 每2小時 | 可選 RCA |
| P3 | 1工作日內 | 2工作日 | 每日 | 事件報告 |
| P4 | 3工作日內 | 5工作日 | 每週 | 簡單紀錄 |

### 4.3 角色與責任

**事件報告者**：
- 發現問題立即報告
- 創建初步事件報告
- 提供盡可能詳細的信息

**值班工程師**：
- 接收事件報告
- 初步評估等級
- 分配負責人

**處理工程師**：
- 調查問題原因
- 實施解決方案
- 定期更新狀態

**技術負責人**：
- 確認事件等級
- 協調處理資源
- 審核解決方案

### 4.4 溝通與通知

**狀態更新模板**：
```markdown
事件：資料庫連接超時
狀態：🔧 處理中
進度：已確認是連接池配置問題，正在調整參數
預計解決時間：15:30
影響：API 響應緩慢，不影響核心功能
負責人：王五
```

**通知要求**：
- P0：立即通知所有相關人員（即時通訊+電話）
- P1：1小時內通知技術團隊+管理層
- P2：2小時內通知技術團隊
- P3：工作日內通知相關工程師
- P4：無需緊急通知

---

## 第五部分：文件生命周期管理

### 5.1 狀態流轉

```
新創建 → ⏳ 待處理 → 🔍 調查中 → 🔧 處理中 → ✅ 已解決 → 📁 已關閉 → 🗄️ 已歸檔
         (新報告)   (開始調查)   (實施解決)   (問題解決)   (驗證完成)   (超過保留期)
```

### 5.2 目錄移動規則

| 狀態 | 所在目錄 | 處理要求 |
|------|----------|----------|
| ⏳🔍🔧 | `_active/` | 定期更新進度 |
| ✅ | `_completed/` | 最終驗證和簽核 |
| 📁🗄️ | `_archived/` | 只讀，供歷史參考 |

**操作命令**：
```bash
# 完成處理後移動文件
mv docs/maintenance_records/incidents/_active/INCIDENT_*.md \
   docs/maintenance_records/incidents/_completed/
```

### 5.3 保留政策

| 文件類型 | 活躍期 | 完成保留期 | 總保留期 |
|----------|--------|------------|----------|
| RCA 文件 | P0: 7天<br>P1: 14天<br>P2-4: 30天 | 30天 | 2年 |
| 事件報告 | P0: 3天<br>P1: 7天<br>P2-4: 14天 | 30天 | 1年 |
| 變更紀錄 | 實施期間 | 90天 | 3年 |
| 維護計畫 | 計畫期間 | 30天 | 1年 |

---

## 第六部分：實戰演練

### 6.1 演練場景：網站響應緩慢

**場景描述**：
- 時間：2026-03-27 10:00
- 問題：網站首頁響應時間超過5秒
- 影響：所有用戶訪問體驗下降
- 發現方式：監控警報

**演練任務**：
1. 創建事件報告文件
2. 評估嚴重等級
3. 填寫基本信息
4. 模擬狀態更新
5. 完成事件關閉

**參考步驟**：
```bash
# 1. 創建文件
cp templates/TEMPLATE_INCIDENT.md \
   incidents/_active/INCIDENT_WEB_SLOW_RESPONSE_2026_03_27.md

# 2. 填寫信息
# - 報告者：你的名字
# - 嚴重等級：P2（影響體驗但不影響功能）
# - 狀態：🔍 調查中
# - 受影響服務：Web服務器、資料庫

# 3. 調查更新
# - 檢查服務器資源使用率
# - 分析資料庫查詢性能
# - 更新狀態為 🔧 處理中

# 4. 解決問題
# - 優化慢查詢
# - 增加緩存
# - 更新狀態為 ✅ 已解決

# 5. 移動文件
mv incidents/_active/INCIDENT_WEB_* incidents/_completed/
```

### 6.2 演練場景：資料庫備份失敗

**場景描述**：
- 時間：2026-03-28 02:00
- 問題：夜間自動備份失敗
- 影響：無立即影響，但有數據風險
- 發現方式：監控警報

**演練任務**：
1. 決定是否需要創建 RCA
2. 如需 RCA，創建文件並分析根本原因
3. 制定預防措施

---

## 第七部分：常見問題解答

### Q1：什麼情況下需要創建 RCA？
- 所有 P0 事件必須創建 RCA
- P1 事件建議創建 RCA
- 重複發生的問題（無論等級）
- 有學習價值的任何事件

### Q2：如果我不確定事件等級怎麼辦？
- 先按較高等級處理（寧嚴勿鬆）
- 與值班工程師或技術負責人確認
- 記錄不確定的原因
- 後續可調整等級

### Q3：模板中的某些欄位我不知道怎麼填？
- 盡可能填寫已知信息
- 標記為「待確認」或「調查中」
- 後續調查後補充
- 重要欄位：報告者、時間、問題描述

### Q4：文件應該存放在哪個目錄？
- 新創建：`_active/`
- 處理中：`_active/`（更新狀態）
- 已完成：`_completed/`
- 超過保留期：`_archived/`

### Q5：如何查找歷史事件記錄？
```bash
# 查找特定服務的事件
find docs/maintenance_records -name "*POSTGRESQL*" -type f

# 查找某日期後的事件
find docs/maintenance_records -name "*2026_03_*" -type f

# 查找進行中事件
find docs/maintenance_records/_active -name "*.md" -type f
```

### Q6：如果多個事件相關聯怎麼辦？
- 在各文件中互相引用
- 使用「相關文件」章節
- 考慮創建綜合性 RCA
- 保持鏈接可追踪

---

## 第八部分：資源與支援

### 8.1 重要文件
| 文件 | 用途 | 位置 |
|------|------|------|
| `DOCS_STANDARD.md` | 文件創建規範 | `../DOCS_STANDARD.md` |
| `maintenance_records/README.md` | 目錄說明 | `./README.md` |
| `INCIDENT_RESPONSE_PROCEDURE.md` | 事件處理流程 | `../INCIDENT_RESPONSE_PROCEDURE.md` |
| `MIGRATION_PLAN.md` | 遷移計畫 | `./MIGRATION_PLAN.md` |

### 8.2 工具與腳本
```bash
# 快速創建事件報告
./scripts/create_incident.sh <服務> <問題>

# 檢查進行中事件
./scripts/check_active_incidents.sh

# 歸檔過期文件
./scripts/archive_old_files.sh
```

### 8.3 聯繫與支援
- **技術問題**：聯繫技術負責人
- **流程問題**：參考事件處理流程文件
- **文件問題**：更新文件規範提案
- **緊急支援**：團隊溝通工具頻道

### 8.4 培訓評估
**知識檢查**：
1. P1 事件的處理時限是多少？
2. 事件報告的標準文件名格式是什麼？
3. 什麼情況下需要將文件移動到 `_archived/`？
4. RCA 文件的總保留期是多久？

**實操考核**：
- 成功創建一個事件報告文件
- 正確評估事件等級
- 完成一次完整的狀態更新流程
- 將文件移動到正確的目錄

---

## 第九部分：下一步行動

### 9.1 立即行動
1. 瀏覽目錄結構熟悉文件位置
2. 閱讀相關規範文件
3. 嘗試創建一個測試事件報告

### 9.2 短期目標（1週內）
1. 在實際事件中使用新規範
2. 提供反饋建議
3. 參加團隊復盤會議

### 9.3 長期目標（1個月內）
1. 熟練掌握所有模板使用
2. 參與 RCA 分析工作
3. 協助培訓新成員

---

## 第十部分：反饋與改進

### 10.1 提供反饋
- 使用規範遇到的問題
- 模板需要改進的地方
- 流程不順暢的環節
- 新增功能建議

### 10.2 改進流程
1. 記錄問題或建議
2. 創建 `CHANGE_MAINTENANCE_PROCESS_*.md`
3. 提交審核
4. 實施改進

### 10.3 定期復盤
- 每週檢查事件處理效果
- 每月審查文件質量
- 每季度更新培訓材料

### 10.4 相關資源
- `AI_AGENT_DOCUMENTATION_GUIDE.md` - AI Agent 使用指南
- `INCIDENT_RESPONSE_PROCEDURE.md` - 事件處理標準程序
- `maintenance_records/README.md` - 維護紀錄目錄說明
- `DOCS_STANDARD_IMPROVEMENT_PROPOSAL_*.md` - 規範改善提案

### 10.5 AI 優化功能
- **YAML Frontmatter**: 所有模板包含結構化元數據，便於 AI Agent 解析
- **自動化工作流**: 支持狀態變更觸發文件移動和通知
- **標準化查詢**: 統一的查詢語法，便於搜索和分析
- **工具整合**: 可與監控系統、n8n 工作流集成

---

## 培訓完成確認

| 項目 | 內容 |
|------|------|
| 培訓日期 | (填寫實際培訓日期) |
| 培訓講師 | (填寫講師姓名) |
| 參與人員 | (列出參與人員) |

### 學員簽到

| 姓名 | 部門 | 簽字 | 日期 | 備註 |
|------|------|------|------|------|
| | | | | |
| | | | | |
| | | | | |

### 培訓效果評估

**請在培訓後填寫**：
1. 培訓內容清晰度：□ 很好 □ 好 □ 一般 □ 差
2. 實用性評估：□ 很實用 □ 實用 □ 一般 □ 不實用
3. 需要改進的地方：_________________________
4. 其他建議：_______________________________

> **注意**：本培訓材料會根據團隊反饋和規範更新定期修訂。
