昨天我們幫各位預備了執行的容器，從每日的內在價值與工作分解結構 (WBS)、每週的週報、每月的月報，到每年的年報以及總計畫。有了這樣的容器，我們接下來就能將各種例行的事務疏而不漏地執行與管理。

以下就用列舉的方式，說明安全營運有哪些紀律，需要我們狂熱地執行。

安全營運審查清單 (Security Operations Review)

基本上，下面每一項我們都會有一個審查的標的物，我們會把每一項都有表格 (或「容器」) 管理。根據以下原則與面向進行審查，將帶給您諸多啟發：

1. 職責分離 (Separation of Duties)：
   對於重大功能或系統，沒有一個人有控制其所有元素。
2. 職務輪調 (Job Rotation)：
   除了資安，職務輪調對於發展人才也有助益，如果有海外派任機會更好，我們可以要求未來計畫擔任關鍵職位者，需具備跨組織輪調經驗。
3. 特權操作監控 (Monitoring Priviledged Operations)：
   因為絕對的權力帶來絕對的腐化，所以定期看看這些特權的給予以及使用狀況，確保特權沒有被濫用。
4. 敏感資訊生命週期管理 (Sensitive Information Life Cycle)：
   Marking => Handling => Storing => Destroying。
5. 服務等級合約審查 (Service Level Agreements)：
   針對外部供應單位，檢查其服務合約規定之效能期望最大下線時間，是否有超過；若超過則進行懲罰。
6. 組態審計 (Configuration Audit)
7. 補丁管理 (Patch Management)：
   有效的補丁程式管理，會進行評估、測試、批准、部署等階段，並進行組態管控。
8. 弱點管理 (Vulnerability Management)：
   包括例行的弱點掃描，以及週期性的弱點分析。
9. 日誌回顧 (Log Reviews)
10. 帳號管理回顧 (Account Management Reviews)
11. 備份驗證 (Backup Verification)
12. 關鍵績效與風險指標 (Key Performance and Risk Indicators)

Development and Operations

這裡面的邏輯我想了很久，且聽寂寞說書人娓娓道來。首先，上面這些安全營運的任務過程中，包含許多隱藏「變更」：有的變更是從發展中來，有的變更是從營運中提出；通常從發展來的變更需求是功能性的，從營運來的變更需求是非功能性的。

當營運正常時，從發展來的需求導入營運後，可能使得系統進到不穩定態，這中間需要經過測試，以保證品質。但終究要放到實際執行環境部署之後，才知道實測結果如何。如果這些變更，能夠極短週期地、自動化地部署至營運環境，會發生什麼事呢？好處會有三個：

1. 避免一次性的大變更，造成新舊版本適應困難：
   小變更部署、小變更部署，一旦新版本有問題，可以立即回復為上一版，也比較容易追溯是哪一個變更造成營運測試失敗。
2. 自動化減少部署成本：
   目標是一鍵部署 (online)，或一鍵打包 (offline)。
3. 透明地資訊看板：
   做了第一第二項後，隨之而來的問題就是品質保證問題，以及隨時監看通報問題。這時候就會發展出「資訊看板」的溝通方式，溝通雙方是發展驅動方與營運驅動方。

為了達到 上面的境界，有幾個導入步驟：

1. 自動化的基礎建設 (Automated Infrustructure)
2. 共享的版本控制 (Shared Version Control)
3. 一鍵建置及部署 (One Step Build and Deploy)
4. 特徵旗標 (Feature Flags)：
   這個最特別，是在發展上述階段後，所碰到問題之解法。因為在多次部署中有不同部署環境的需要，比方說開發環境、測試環境、預部署環境、實際執行環境。
5. 協助溝通與協作之平台代理人 (Collaborative Change Management Agent)

最近在 DevOps 社群裡面看到推薦的書，有血有淚，我認為作者有懂得開發與維運的痛點與解決方案，所以也推薦給大家。

《鳳凰專案：看 IT 部門如何讓公司從谷底翻身的傳奇故事》
《The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win》
資料來源：
https://cdn.kingstone.com.tw/book/images/product/20147/2014713534095/2014713534095b.jpg