DevOps

Playwright 教學手冊（企業級完整版） 版本：基於 Playwright v1.62.1（2026 年 7 月） 適用對象：資深工程師、SDET、QA Lead、DevOps 工程師、技術決策者 授權：Apache 2.0（Playwright 開源授權） 最後更新：2026-08-15 執行摘要（Executive Summary） Playwright 是 Microsoft 主導開發的開源瀏覽器自動化框架，自 2020 年首次發布以來，已成為端對端（E2E）測試領域成長最快的解決方案。根據 2026 年業界調查，Playwright 在新專案採用率已達 45.1%，首度超越 Selenium（22.1%）與 Cypress（14.4%），npm 週下載量突破 1,300 萬次，GitHub 星數超過 9.4 萬顆，反映其在測試社群的主流地位。 對企業而言，導入 Playwright 的核心價值在於三個面向： 降低維護成本：內建 Auto-wait 與 Web-First Assertions 機制，實測可減少約六成因時序問題（Race Condition）導致的 Flaky Test，顯著降低 SDET 團隊的除錯負擔。 降低基礎設施成本：原生支援跨瀏覽器（Chromium／Firefox／WebKit）與平行測試，無需額外部署 Selenium Grid 一類的叢集基礎設施，即可於 CI/CD 中橫向擴展。 加速 AI 導入測試流程：透過 Playwright MCP、Playwright CLI 與 Playwright Agents（Planner／Generator／Healer），企業可將 LLM Coding Agent 導入測試規劃、產生與自動修復流程，是目前主流測試框架中對 AI Agent 生態系整合最完整的方案。 本手冊以「企業級落地」為核心設計，涵蓋從系統架構設計、多環境配置、CI/CD 整合、安全合規到團隊導入的完整生命週期，適合作為 SDET / QA Lead 規劃導入策略、DevOps 工程師建置 Pipeline，以及技術決策者評估投資報酬率（ROI）的參考文件。內文所有版本標註（如 v1.60+）皆對應 Playwright 官方 Release Notes，讀者可據此判斷所屬環境的相容性。 ...

README 範本（README Template） 參照標準：GitHub Community Standards / Open Source Guides / Make a README 文件用途：提供專案的入口文件，讓開發者快速了解、安裝、使用與貢獻專案 適用階段：專案全生命週期（建立即應存在，持續維護） 📋 章節目錄 文件資訊 專案名稱與描述 徽章區（Badges） 快速開始 安裝指南 使用方式 API 參考 專案結構 貢獻指南 授權條款 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 README.md 位置 專案根目錄 格式 GitHub Flavored Markdown (GFM) 維護者 {姓名/團隊} 最後更新 {YYYY-MM-DD} 📖 使用說明 README.md 是專案的「門面」，通常是訪客看到的第一份文件 遵循 GitHub Community Standards 建議結構 內容需保持最新，過時的 README 比沒有 README 更糟 💡 範例 本範本以 HRMS 專案為例，展示完整 README 結構。 ...

運維手冊範本（Runbook） 參照標準：ITIL 4 Service Operation / ISO/IEC 20000-1:2018 第 8.5 節「Service delivery」 文件用途：提供系統日常維運、告警處理、故障排除的標準化操作程序 適用階段：營運維護階段（Operations & Maintenance） 📋 章節目錄 文件資訊 系統概述 常見操作程序 告警處理 故障排除決策樹 緊急聯絡人 SLA 與 SLO 維護窗口與排程作業 備份與還原 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 RB-{專案代碼}-{序號} 文件名稱 {系統名稱} 運維手冊 版本 v{主版本}.{次版本} 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 維護者 {姓名/團隊} 適用環境 Production / Staging / All 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 Runbook 為活文件，需隨系統變更持續更新 任何維運操作變更需同步更新本文件 建議每季審閱一次，確保內容與現況一致 💡 範例 項目 內容 文件編號 RB-HRM-001 文件名稱 HRMS 運維手冊 維護者 DevOps 團隊 — 周維運 適用環境 Production 2. 系統概述 📝 範本 2.1 系統架構 {架構圖 — 包含所有元件與連接關係} 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 {元件} {技術} {位置} {URL/IP} {說明} 2.3 相依服務 外部服務 用途 端點 擁有者 SLA {服務} {用途} {端點} {團隊} {SLA} 2.4 存取方式 環境 入口 認證方式 備註 {環境} {URL/方式} {認證} {備註} 📖 使用說明 系統概述幫助值班人員快速了解系統全貌 元件清單需包含所有運行中的服務（含背景 Worker、排程任務等） 相依服務標明擁有者，出問題時知道找誰 💡 範例 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 hrms-api .NET 8 Web API AKS hrms-prod ns https://hrms-api.internal:443 後端 API hrms-web React 18 + Nginx AKS hrms-prod ns https://hrms.company.com 前端 SPA hrms-worker .NET 8 Worker Service AKS hrms-prod ns N/A（內部處理） 背景排程任務 PostgreSQL v16 Azure DB for PostgreSQL hrms-db.postgres.database.azure.com:5432 主資料庫 Redis v7 Azure Cache for Redis hrms-cache.redis.cache.windows.net:6380 Session + Cache 3. 常見操作程序 📝 範本 3.1 {操作名稱} 項目 內容 操作目的 {為什麼要做} 執行頻率 手動觸發 / 每日 / 每週 / 每月 預估時間 {分鐘} 影響範圍 {影響說明} 所需權限 {權限} 步驟： ...

部署指南範本（Deployment Guide） 參照標準：ITIL 4 Release Management / ISO/IEC 20000-1:2018 第 8.5.2 節「Release management」 文件用途：提供系統部署的標準化步驟指引，確保可重複、可追蹤、可回滾的部署流程 適用階段：部署與上線階段（Release & Deployment） 📋 章節目錄 文件資訊 部署概述 先決條件 部署架構 部署步驟 驗證程序 回滾程序 監控確認 聯絡窗口 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 DG-{專案代碼}-{序號} 文件名稱 {系統名稱} v{版本} 部署指南 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 計畫部署日期 {YYYY-MM-DD HH:mm} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 依據 ITIL 4 Release Management 實務，每次部署需有正式的部署指南 文件需在部署前完成審核，未經核准不得執行部署 適用於所有環境（SIT / UAT / Staging / Production）部署 💡 範例 項目 內容 文件編號 DG-HRM-003 文件名稱 HRMS v1.0.0 正式環境部署指南 計畫部署日期 2026-10-15 22:00（維護窗口） 核准者 IT 副總 — 黃資訊 2. 部署概述 📝 範本 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 / 版本升級 / Hotfix / 組態變更 部署版本 {Application Version} 目標環境 {環境名稱} 部署方式 全量部署 / 滾動更新 / 藍綠部署 / 金絲雀部署 預估停機時間 {分鐘/小時} / 零停機 影響範圍 {受影響的服務/使用者} 維護窗口 {起始時間} ~ {結束時間} 2.2 變更內容摘要 變更編號 類型 描述 {CR/JIRA 編號} 功能/修復/組態 {簡述} 2.3 部署風險評估 風險等級 說明 高/中/低 {為何此等級} 📖 使用說明 部署類型決定所需的審核層級與流程嚴格度 Hotfix 可簡化流程但仍需記錄 預估停機時間需告知業務方，以便安排使用者通知 💡 範例 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 部署版本 HRMS v1.0.0 (Build #2026.10.12.1) 目標環境 Production (Azure AKS - hrms-prod) 部署方式 藍綠部署（Blue-Green Deployment） 預估停機時間 零停機（流量切換時間 < 30 秒） 影響範圍 全公司員工（約 2,000 人） 維護窗口 2026-10-15 22:00 ~ 2026-10-16 02:00 3. 先決條件 📝 範本 3.1 核准與簽核 項目 狀態 確認人 日期 變更審核委員會（CAB）核准 ☐ {姓名} {日期} 測試報告簽核 ☐ {姓名} {日期} 業務方確認上線同意 ☐ {姓名} {日期} 回滾計畫審核 ☐ {姓名} {日期} 3.2 技術先決條件 項目 驗證方式 狀態 {基礎設施就緒} {驗證命令/方式} ☐ {相依服務可用} {驗證命令/方式} ☐ {資料庫備份完成} {驗證命令/方式} ☐ {SSL 憑證有效} {驗證命令/方式} ☐ {DNS 設定確認} {驗證命令/方式} ☐ 3.3 部署所需權限 系統/資源 所需權限 帳號 {系統} {權限} {帳號} 📖 使用說明 所有先決條件需在部署開始前全部確認（Checklist 全部打勾） 任何一項未完成則不得啟動部署 資料庫備份是最關鍵的先決條件，未備份禁止部署 💡 範例 3.2 技術先決條件 項目 驗證方式 狀態 AKS 叢集節點 ≥ 4 kubectl get nodes 確認 Ready ☑ PostgreSQL 資料庫完整備份 確認 Azure Backup 最新備份 < 1 小時 ☑ Redis Cache 可連線 redis-cli ping 回應 PONG ☑ AD 連線正常 測試 LDAP bind ☑ Container Registry 映像已推送 az acr repository show-tags 確認 v1.0.0 存在 ☑ SSL 憑證效期 > 30 天 openssl s_client 確認到期日 ☑ 4. 部署架構 📝 範本 4.1 目標環境架構圖 {架構圖或 Mermaid 圖} 4.2 環境資訊 元件 主機/端點 規格 備註 Application Server {Host/IP} {CPU/RAM} {說明} Database {Host/IP:Port} {版本/規格} {說明} Cache {Host/IP:Port} {版本/規格} {說明} Load Balancer {Host/IP} {類型} {說明} Storage {Host/Path} {容量} {說明} 4.3 網路與防火牆規則 來源 目的 Port Protocol 用途 {來源} {目的} {Port} TCP/UDP {用途} 📖 使用說明 架構圖幫助部署人員理解全貌，建議使用 Mermaid 或繪製圖示 網路規則需在部署前確認已開通，避免部署後才發現連線失敗 機敏資訊（密碼、連線字串）不寫入文件，使用 Secret Manager 或變數引用 💡 範例 4.1 目標環境架構圖 Internet → Azure Front Door → AKS Ingress → Service ├── hrms-api (3 replicas) ├── hrms-worker (2 replicas) └── hrms-web (3 replicas) ↓ PostgreSQL (Azure DB for PostgreSQL) Redis (Azure Cache for Redis) Azure Blob Storage 5. 部署步驟 📝 範本 5.0 部署前通知 時間 對象 通知方式 內容 部署前 {N} 小時 {對象} {方式} {內容} 5.1 資料庫變更 步驟 指令/操作 預期結果 確認者 1 {SQL / Migration 指令} {預期輸出} {姓名} 2 {SQL / Migration 指令} {預期輸出} {姓名} 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 {部署指令} {預期輸出} {姓名} 2 {部署指令} {預期輸出} {姓名} 5.3 組態更新 步驟 指令/操作 預期結果 確認者 1 {組態變更指令} {預期結果} {姓名} 5.4 流量切換 步驟 指令/操作 預期結果 確認者 1 {切換指令} {預期結果} {姓名} 📖 使用說明 步驟需按執行順序排列，不可跳步 每步驟需有具體指令（可複製貼上執行）與預期結果 「確認者」在部署時簽名確認該步驟已完成 資料庫變更必須先於應用程式部署（確保 schema 相容） 機敏值（密碼）用環境變數或 Secret 引用，不寫死 💡 範例 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 kubectl set image deployment/hrms-api hrms-api=hrmacr.azurecr.io/hrms-api:v1.0.0 -n hrms-prod deployment.apps/hrms-api image updated DevOps 2 kubectl rollout status deployment/hrms-api -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 3 kubectl set image deployment/hrms-web hrms-web=hrmacr.azurecr.io/hrms-web:v1.0.0 -n hrms-prod deployment.apps/hrms-web image updated DevOps 4 kubectl rollout status deployment/hrms-web -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 5 確認所有 Pod 狀態正常：kubectl get pods -n hrms-prod 所有 Pod 狀態為 Running，READY 1/1 DevOps 6. 驗證程序 📝 範本 6.1 Smoke Test（冒煙測試） 測試項目 驗證方式 預期結果 實際結果 Pass/Fail {基本功能 1} {驗證方式} {預期} {實際} {基本功能 2} {驗證方式} {預期} {實際} 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail {端點} {指令} {預期} {實際} 6.3 整合驗證 驗證項目 驗證方式 預期結果 實際結果 Pass/Fail {外部系統連接} {指令/操作} {預期} {實際} 6.4 部署成功判定標準 標準 說明 所有 Smoke Test 通過 — 健康檢查端點回應 200 持續 5 分鐘 無 Critical/High Alert 部署後 15 分鐘內 日誌無異常 Error 抽查近 100 條 Log 📖 使用說明 驗證程序在部署完成後立即執行，決定是否接受本次部署 Smoke Test 覆蓋核心業務路徑（如登入、主要功能），不需全面測試 若任何 P1 驗證失敗，立即啟動回滾程序 💡 範例 6.1 Smoke Test 測試項目 驗證方式 預期結果 實際結果 Pass/Fail 首頁可存取 curl -s -o /dev/null -w "%{http_code}" https://hrms.company.com 200 200 Pass 員工登入 使用測試帳號登入 成功進入首頁 成功 Pass 請假申請 建立一筆特休假申請 申請成功，狀態=待審核 成功 Pass 薪資查詢 查詢本月薪資明細 顯示薪資資料 成功 Pass 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail API Health curl https://hrms-api.company.com/health {"status":"healthy"} 同預期 Pass DB 連線 curl https://hrms-api.company.com/health/db {"status":"connected"} 同預期 Pass Redis 連線 curl https://hrms-api.company.com/health/cache {"status":"connected"} 同預期 Pass 7. 回滾程序 📝 範本 7.1 回滾觸發條件 條件 決策者 {觸發條件 1} {角色} {觸發條件 2} {角色} 7.2 回滾步驟 步驟 指令/操作 預期結果 確認者 1 {回滾指令} {預期} {姓名} 2 {回滾指令} {預期} {姓名} 7.3 資料庫回滾 步驟 指令/操作 預期結果 確認者 1 {DB 回滾指令} {預期} {姓名} 7.4 回滾後驗證 驗證項目 方式 預期結果 {驗證項} {方式} {預期} 7.5 回滾時間預估 項目 預估時間 應用程式回滾 {分鐘} 資料庫回滾 {分鐘} 驗證完成 {分鐘} 總計 {分鐘} 📖 使用說明 每次部署必須有回滾計畫，這是 ITIL 4 Release Management 的核心要求 回滾步驟需預先演練驗證，不可「部署當天第一次嘗試回滾」 資料庫回滾是最複雜的部分（若有 schema 變更），需特別規劃 藍綠部署的回滾最簡單：切回舊版流量即可 💡 範例 7.1 回滾觸發條件 條件 決策者 Smoke Test 失敗 2 項以上 DevOps Lead 部署後 15 分鐘內出現 Critical Alert DevOps Lead 業務方回報核心功能異常 IT 副總 部署超過維護窗口仍未完成 DevOps Lead + PM 7.2 回滾步驟（藍綠部署） 步驟 指令/操作 預期結果 確認者 1 通知團隊啟動回滾 Teams 群組通知已發送 DevOps Lead 2 kubectl rollout undo deployment/hrms-api -n hrms-prod rollback to previous revision DevOps 3 kubectl rollout undo deployment/hrms-web -n hrms-prod rollback to previous revision DevOps 4 kubectl rollout status deployment/hrms-api -n hrms-prod successfully rolled out DevOps 5 執行 Smoke Test 驗證回滾成功 所有項目 Pass QA 6 通知業務方服務已恢復 Email/Teams 通知已發送 PM 8. 監控確認 📝 範本 8.1 部署後監控期間 項目 內容 加強監控期間 部署後 {N} 小時 監控人員 {姓名/值班表} 告警通知管道 {方式} 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API 回應時間 (P95) < {ms} > {ms} {工具} Error Rate < {%} > {%} {工具} CPU 使用率 < {%} > {%} {工具} Memory 使用率 < {%} > {%} {工具} 活躍連線數 < {N} > {N} {工具} 8.3 日誌檢查項目 日誌類型 檢查重點 工具/指令 Application Log {重點} {工具} Access Log {重點} {工具} Error Log {重點} {工具} 📖 使用說明 部署後加強監控是確保部署穩定的最後一道防線 監控期間內若指標異常，仍可啟動回滾 建議部署後 24 小時為加強監控期，48 小時後轉為一般監控 💡 範例 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API P95 回應時間 < 200ms > 500ms Grafana + Prometheus Error Rate (5xx) < 0.1% > 1% Azure Monitor CPU 使用率 < 60% > 85% Azure Monitor Memory 使用率 < 70% > 90% Azure Monitor Pod Restart Count 0 > 2 Kubernetes Dashboard DB Connection Pool < 80% > 95% Application Insights 9. 聯絡窗口 📝 範本 角色 姓名 電話 備用聯絡 職責 部署指揮 {姓名} {電話} {備用} 部署決策、Go/No-Go 判定 DevOps 工程師 {姓名} {電話} {備用} 執行部署操作 DBA {姓名} {電話} {備用} 資料庫變更 開發 Lead {姓名} {電話} {備用} 技術問題排除 QA {姓名} {電話} {備用} 部署驗證 業務窗口 {姓名} {電話} {備用} 業務確認 📖 使用說明 部署當天所有窗口需保持電話暢通 部署指揮負責 Go/No-Go 決策與回滾決定 建議建立即時通訊群組（如 Teams/Slack War Room）方便即時溝通 💡 範例 角色 姓名 電話 備用聯絡 職責 部署指揮 黃資訊（IT 副總） 0912-xxx-xxx Teams Go/No-Go 決策 DevOps 周維運 0933-xxx-xxx Teams 執行部署 DBA 趙資料 0922-xxx-xxx Teams DB Migration 開發 Lead 吳開發 0955-xxx-xxx Teams 問題排查 QA 林品質 0966-xxx-xxx Teams Smoke Test 10. 附錄 📝 範本 10.1 部署 Checklist 總表 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☐ 部署前 資料庫備份完成 ☐ 部署前 通知使用者 ☐ 部署中 DB Migration 完成 ☐ 部署中 應用程式部署完成 ☐ 部署後 Smoke Test 通過 ☐ 部署後 健康檢查正常 ☐ 部署後 監控指標正常 ☐ 部署後 通知使用者服務恢復 ☐ 10.2 相關文件 文件 說明 {文件名} {用途} 10.3 術語定義 術語 定義 CAB Change Advisory Board，變更諮詢委員會 Blue-Green 藍綠部署，同時維護兩套環境，透過流量切換完成零停機部署 Smoke Test 冒煙測試，部署後快速驗證核心功能 Rollback 回滾，將系統恢復至部署前的版本 Maintenance Window 維護窗口，預先規劃的系統維護時段 📖 使用說明 Checklist 在部署當天使用，逐項確認並記錄時間 此 Checklist 同時作為部署紀錄保存，不可事後補填 💡 範例 10.1 部署 Checklist（已執行） 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☑ 10/13 15:00 黃資訊 部署前 PostgreSQL Full Backup ☑ 10/15 21:30 趙資料 部署前 Email 通知全公司維護 ☑ 10/15 18:00 PM 部署中 DB Migration (3 scripts) ☑ 10/15 22:05 趙資料 部署中 K8s Deployment 更新 ☑ 10/15 22:15 周維運 部署後 Smoke Test (5/5 Pass) ☑ 10/15 22:30 林品質 部署後 監控 15 分鐘無告警 ☑ 10/15 22:45 周維運 部署後 通知服務恢復 ☑ 10/15 22:50 PM 📌 範本使用注意事項 ...

Agentic AI 與 LLM wiki Repo 建立教學手冊 — 企業級 AI 資產知識庫 版本：v3.1（2026-07-03） 適用對象：技術主管 / 架構師 / 資深工程師 / DevOps 團隊 定位：企業標準技術白皮書 參考範本：github/awesome-copilot（36.1k+ Stars / 4.5k+ Forks / 400+ Contributors） 延伸參考：Karpathy LLM Wiki（5,000+ Stars / 5,000+ Forks） 最後審閱日期：2026-07-03 執行摘要 企業導入 GitHub Copilot、Claude Code 等 AI 開發工具後，最大的隱憂不是工具本身，而是團隊產出的 Agent、Instruction、Skill、Prompt 等「AI 資產」缺乏統一管理，導致重複造輪子、品質參差、知識隨人員異動而流失。本白皮書提出一套可落地的解法：以 GitHub 官方 awesome-copilot 的分類體系與治理機制為骨幹，建立企業內部的 AI 資產知識庫（第 1–10 章涵蓋 Repo 建立、目錄設計、內容規範、CI/CD 自動化、治理與團隊導入的完整流程）；並進一步整合 Andrej Karpathy 提出的 LLM Wiki 模式（第 11 章），讓「研究型、決策型」的知識也能由 LLM 持續編譯、複合成長，而非每次查詢都重新從原始資料派生答案。兩者互補：AI 資產知識庫管理「可執行的工具」，LLM Wiki 管理「持久化的判斷與脈絡」。讀者可依團隊規模（第 9.5.4 節）選擇適合的導入深度，從最小可行的 4 個核心目錄開始，逐步擴展至完整的 10 類資產與 LLM Wiki 知識層。 ...