---
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:
  - "查詢 運維文件遷移計畫 的內容"
  - "運維文件遷移計畫 的主要目的是什麼？"
  - "如何操作或實施 運維文件遷移計畫？"
---

# 運維文件遷移計畫

| 項目 | 內容 |
|------|------|
| 建立者 | OpenCode |
| 建立時間 | 2026-03-27 |
| 文件版本 | V1.0 |
| 相關文件 | DOCS_STANDARD_IMPROVEMENT_PROPOSAL_*.md |

---

## 版本歷史

| 版本 | 日期 | 目的 | 操作人 | 工具/模型 |
|------|------|------|--------|-----------|
| V1.0 | 2026-03-27 | 創建遷移計畫 | OpenCode | deepseek-reasoner |

---

## 1. 概述

本文件描述將現有運維文件遷移到新目錄結構 (`docs/maintenance_records/`) 的計畫。遷移目標是統一文件組織，遵循新規範的結構和命名規則。

### 1.1 遷移目標
- 統一運維文件組織結構
- 遵循新文件命名規範
- 建立完整的文件生命周期管理
- 為未來文件創建建立標準

### 1.2 遷移範圍
僅遷移符合以下條件的文件：
1. 具體的事件報告 (Incident Reports)
2. 根本原因分析 (Root Cause Analysis)
3. 系統變更記錄 (Change Records)
4. 維護計畫 (Maintenance Plans)

規範文件、安裝指南、API 文檔等不在此次遷移範圍內。

---

## 2. 現有文件分析

### 2.1 文件清單與分類

| 文件 | 類型 | 建議處理 | 遷移目標目錄 |
|------|------|----------|--------------|
| `PENDING_ISSUES.md` | 問題追蹤清單 | 保留原位置 | (不遷移) |
| `DEVELOPMENT_LOG.md` | 開發日誌 | 保留原位置 | (不遷移) |
| `MOMENTRY_CORE_MONITORING.md` | 監控規範 | 保留原位置 | (不遷移) |
| `BACKUP_VERSIONING.md` | 備份規範 | 保留原位置 | (不遷移) |
| `BUILD_VERSION_RECORD.md` | 版本規範 | 保留原位置 | (不遷移) |
| `FILE_CHANGE_MANAGEMENT.md` | 文件變更規範 | 保留原位置 | (不遷移) |
| `N8N_MCP_TEST_REPORT.md` | 測試報告 | 可選遷移為變更記錄 | `changes/` |
| (無) | 具體事件報告 | 無現有文件 | `incidents/` |
| (無) | 具體 RCA | 無現有文件 | `rca/` |
| (無) | 具體維護計畫 | 無現有文件 | `plans/` |

### 2.2 遷移決策原則

1. **規範文件保留**：規範、指南、標準等參考文件保留在 `docs/` 根目錄
2. **具體記錄遷移**：具體的事件、變更、分析記錄遷移到新結構
3. **混合文件拆分**：包含多個獨立記錄的文件拆分為多個獨立文件
4. **歷史價值評估**：評估文件的歷史價值，決定是否遷移

---

## 3. 遷移執行計畫

### 3.1 階段 1：準備工作 (已完成)
- [x] 建立目錄結構 (`maintenance_records/` 及其子目錄)
- [x] 創建文件模板 (`TEMPLATE_*.md`)
- [x] 更新文件規範 (`DOCS_STANDARD.md`)
- [x] 創建事件處理流程 (`INCIDENT_RESPONSE_PROCEDURE.md`)

### 3.2 階段 2：文件遷移 (✅ 已完成)

#### 任務 2.1：測試報告遷移 (✅ 已完成)
**文件**：`N8N_MCP_TEST_REPORT.md`
**目標類型**：變更記錄 (測試是變更的一部分)
**新文件名**：`CHANGE_N8N_MCP_INTEGRATION_TEST_2026_03_23.md`
**遷移步驟**：
1. 複製原文件內容到新模板
2. 調整結構符合變更記錄格式
3. 添加必要的元數據
4. 移動到 `changes/_completed/` 目錄

```bash
# 遷移命令示例
cp docs/N8N_MCP_TEST_REPORT.md \
   docs_v1.0/OPERATIONS/maintenance_records/changes/_completed/CHANGE_N8N_MCP_INTEGRATION_TEST_2026_03_23.md
```

#### 任務 2.2：問題追蹤轉換 (可選)
**文件**：`PENDING_ISSUES.md`
**處理方式**：不遷移，但可從中提取具體事件
**建議**：
- 對於已解決的問題，創建相應的事件報告
- 對於持續的問題，保留在問題追蹤中
- 未來新問題直接使用新事件報告模板

#### 任務 2.3：創建示例文件 (已完成)
- [x] `RCA_WORDPRESS_TIMEOUT_EXTERNAL_ACCESS_2026_03_27.md`

#### 任務 2.4：RCA 文件遷移 (✅ 已完成)
**文件**：`N8N_API_FIX_SUMMARY.md`
**目標類型**：根本原因分析 (RCA)
**新文件名**：`RCA_N8N_API_PORT_CONFLICT_2026_03_26.md`
**遷移狀態**：已成功遷移至 `docs/maintenance_records/rca/`

### 3.3 階段 3：驗證與清理
- [ ] 驗證遷移後文件可訪問性
- [ ] 更新相關文件中的鏈接
- [ ] 備份原始文件（可選）
- [ ] 更新文件索引或導航

---

## 4. 文件轉換指南

### 4.1 從問題追蹤轉換為事件報告

**原內容** (`PENDING_ISSUES.md` 中的問題)：
```markdown
## 問題 #1: sqlx async INSERT 不會實際寫入數據庫

### 問題描述
使用 sqlx async 執行 INSERT 時，報告成功但數據沒有實際寫入。

### 嘗試過的解決方案
| # | 嘗試方法 | 結果 |
|---|---|---|
| 1 | 使用 `execute()` | 報告成功但未寫入 |
```

**轉換為事件報告**：
1. 創建新文件：`INCIDENT_DATABASE_WRITE_FAILURE_2026_03_XX.md`
2. 使用 `TEMPLATE_INCIDENT.md` 模板
3. 填寫對應欄位：
   - 事件標題：sqlx async INSERT 寫入失敗
   - 事件類型：數據問題
   - 嚴重等級：P2 (影響部分功能)
   - 狀態：✅ 已解決 (假設已解決)

### 4.2 從測試報告轉換為變更記錄

**原內容**：測試報告文檔
**轉換步驟**：
1. 識別相關的變更：n8n MCP 整合
2. 創建變更記錄文件
3. 填寫變更詳情、測試結果、驗證信息
4. 添加變更影響評估

---

## 5. 未來文件創建流程

### 5.1 新事件報告流程
1. 檢測到事件或問題
2. 使用模板創建事件報告
3. 存儲到 `incidents/_active/`
4. 按流程處理和更新狀態
5. 完成後移動到 `incidents/_completed/`

### 5.2 新變更記錄流程
1. 計畫系統變更
2. 創建變更記錄文件
3. 存儲到 `changes/_active/`
4. 記錄變更實施過程
5. 完成後移動到 `changes/_completed/`

### 5.3 新 RCA 流程
1. 事件需要深入分析
2. 創建 RCA 文件
3. 存儲到 `rca/_active/`
4. 進行根本原因分析
5. 完成後移動到 `rca/_completed/`

---

## 6. 風險與緩解

### 6.1 風險識別
| 風險 | 可能性 | 影響 | 風險等級 | 緩解措施 |
|------|--------|------|----------|----------|
| 文件鏈接失效 | 中 | 低 | 中 | 更新相關文件中的鏈接 |
| 歷史上下文丟失 | 低 | 中 | 低 | 保留原始文件備份 |
| 團隊適應期 | 高 | 低 | 中 | 提供培訓和指南 |
| 文件重複 | 中 | 低 | 中 | 明確遷移範圍和規則 |

### 6.2 緩解措施
1. **備份策略**：遷移前備份原始文件
2. **逐步遷移**：先遷移少量文件驗證流程
3. **團隊溝通**：通知相關人員新文件結構
4. **驗證測試**：驗證遷移後文件可正常訪問

---

## 7. 時間表與責任

### 7.1 遷移時間表
| 階段 | 任務 | 預計時間 | 負責人 | 狀態 |
|------|------|----------|--------|------|
| 準備工作 | 建立目錄和模板 | 2小時 | OpenCode | ✅ 已完成 |
| 文件分析 | 分析現有文件 | 1小時 | OpenCode | ✅ 已完成 |
| 文件遷移 | 遷移具體文件 | 2小時 | OpenCode | ✅ 已完成 |
| 驗證清理 | 驗證和更新鏈接 | 1小時 | OpenCode | ✅ 已完成 |

### 7.2 角色與責任
- **遷移執行者**：執行具體文件遷移操作
- **驗證人員**：驗證遷移後文件完整性和可訪問性
- **團隊負責人**：批准遷移計畫和結果

---

## 8. 成功標準

### 8.1 主要成功標準
- [x] 所有目標文件成功遷移到新結構
- [x] 新文件符合命名規範和格式要求
- [ ] 文件生命周期管理正常運作
- [ ] 團隊成員能夠使用新結構

### 8.2 次要成功標準
- [ ] 文件訪問時間無顯著增加
- [ ] 搜索和檢索功能正常
- [ ] 團隊反饋積極

---

## 9. 附錄

### 9.1 相關命令
```bash
# 查看現有文件
find docs -name "*.md" -type f | grep -v maintenance_records

# 創建新事件報告
cp docs_v1.0/OPERATIONS/maintenance_records/templates/TEMPLATE_INCIDENT.md \
   docs/maintenance_records/incidents/_active/INCIDENT_$(date +%Y_%m_%d).md

# 遷移文件示例
cp docs/N8N_MCP_TEST_REPORT.md \
   docs_v1.0/OPERATIONS/maintenance_records/changes/_completed/CHANGE_N8N_MCP_INTEGRATION_TEST_2026_03_23.md
```

### 9.2 參考文件
- `docs_v1.0/OPERATIONS/maintenance_records/README.md` - 目錄結構說明
- `docs_v1.0/STANDARDS/DOCS_STANDARD.md` - 文件創建規範
- `docs_v1.0/OPERATIONS/INCIDENT_RESPONSE_PROCEDURE.md` - 事件處理流程

### 9.3 聯繫信息
- 遷移問題：創建 `CHANGE_FILE_MIGRATION_*.md` 記錄
- 流程問題：參考事件處理流程
- 技術問題：聯繫技術負責人

---

## 10. 簽核

| 角色 | 姓名 | 簽字 | 日期 | 備註 |
|------|------|------|------|------|
| 計畫制定 | OpenCode | - | 2026-03-27 | 初版創建 |
| 技術審核 | Warren | | | |
| 遷移執行 | OpenCode | | | |
| 最終批准 | Warren | | | |

> **注意**：本遷移計畫需經技術負責人審核後執行。
