Maxkit: 放「乖乖」還不夠的服務維運管理

軟體系統服務的維運管理，在台灣最常見的，就是請到「乖乖大神」出面，因為一般伺服器都是透過燈號，來辨識主機的運作情形，綠燈代表正常，紅燈則是故障燈號，這是軟體系統維運人員某個不成文的信仰。

當線上的服務不正常地離線後，我們最常見到的答案就是「駭客攻擊」，因為類似的服務競爭對手很多，如果官方承認是內部管理不周，沒有忠誠度的客戶，或許就可能鳥獸散，或發生使用者集體位移的狀況，都可能會影響到公司的營運。

大概是被駭客攻擊的新聞太多了，使用者很習慣接受這樣的理由，甚至有可能連開發的工程師，在系統上線一段時間之後，再遇到自己系統當機的情況時，第一時間，也會認為自己的服務被攻擊了。

大家猜測，責任在駭客身上，這是再直接不過的事情了。就系統開發者來說，不管任何時候發生問題，絕對不能一開始就下定論，首先要檢查的是系統的 log，要想的是有沒有任何造成當機的原因。

還記得遠通 ETC 的事件嗎？回想一下這個新聞政院踢爆全因APP設計不良 eTag遭駭攏係假當時因為 ETC APP 上線後，瞬間過多 APP 向 Server 查詢餘額，造成系統的當機，而這瞬間過多的 server request，是 APP 設計不良造成的，而且由於 APP 還得經過兩週的審核程序才能更新，當時立委每天都得質詢修正的進度，相信不管是每一個承辦單位，都承擔了很多壓力。不過幸好 ETC 是個獨占事業，不管如何，他們都撐過了系統上線那一段混亂時期，現在已經進入了穩定的營運期。

5/28 發生了中國最大的線上旅遊網站攜程網當機，疑遭駭客攻擊的事件，而且到了晚上八點，系統都還沒有恢復正常。

系統掛點，第一時間收到的解釋，就是駭客攻擊。針對這個問題，由於沒有正式的官方說明，各方的臆測很多，可以看一下這些連結。

服務中斷、瘋傳數據庫遭刪除　攜程網堅稱數據庫安好

ezTravel 最大股東中國攜程網，系統疑似遭到內部物理刪除

看著這樣的事件，我們可以知道什麼，學到什麼？

線上服務最重要的是資料的完整性
客戶最在意的，就是自己的權益，不管發生什麼事情，都必須要讓客戶的資料完整地復原回來，這或許不是賠錢就能解決的問題。

實務上資料備份有三道防線，第一個是 HA，再來是異地備援，第三是磁帶備份，這三個部份都是分開管理的，基本上很難同時被刪除，但比較難達到的是系統還原的程序。
系統還原需要有演練的程序
一般系統常常會因為成本的考量，而放棄了備援的機制，甚至有了備援，卻沒有測試環境可以進行系統還原的驗證，這一切都是機器與人力成本的問題，而同時又是很難合理說明的必要花費。

磁帶備份只要有磁帶機就能作，但是誰能保證備分出來的資料，可以還原回去？用什麼方法還原回去？這是個謎！
維運人員要如何避免人為疏失
要說駭客攻擊造成資料遺失很容易，但真正比較有可能發生的，是內部員工疏忽，造成系統資料被刪除。

這是推動 DevOps 的最佳理由，讓維運作業，加上系統工程的管理，可以降低發生錯誤的機會。
線上服務的架構複雜
現在的系統設計時，常會考慮到混搭的作法，最基本的資料庫選擇，就有 NoSQL 跟關聯式資料庫兩大派別。而且最麻煩的是，不同的系統有不同的優缺點，也因此在系統發展的過程中，各式各樣的程式語言，作業環境，常會出現混搭的狀況。
重構時，要勇敢去刪除不必要的東西 -> 這只是口號
軟體系統的進入發展與維護期，會增加一些新的小功能，當開發人員、管理人員、維護人員異動之後，新的人員會調整與修改系統，真正熟悉這個系統實作的人就消失了，整個作業環境，就只會逐漸地疊床架屋，系統之間的依賴關係，只會越來越混亂。

重構時，要勇敢去刪除不必要的東西，這是最好的方式，但也是一種不負責任的說法，因為這樣的說法，並沒有完全考慮到現場實作人員的狀況。

假設我們是開發人員，接收了一個既有產品或服務的更新或維護的工作，首先我們能得到的既有的文件，再來是前一個負責人員的幫助，要知道更深入一點的問題，就只能去查看程式碼，或實際發布看看。

有時候，即使是出自自己開發與設計的產品，在經過半年或一年的維運期之後，如果突然要改什麼新功能，也不能保證會不會影響就的功能，這時候，也只有唯一一個選擇，就是避開舊的程式碼，把新功能疊加上去。

很抱歉，在這裡只能提出一個理想化的口號，完全沒有實際上可行的作法。
我們缺少的維運管理工具
DevOps將顛覆未來IT人角色文章中提到，DevOps其實是針對雲端運算環境，提出來的一個概念，我們需要一個快速且穩定的開發、測試以及釋出軟體服務的方法。【知識庫】Github上推薦的12款DevOps開發工具列舉出來的也都是針對雲端運算的維運工具。

在這裡，有個想法，就是我們需要一種工具，可以將維運的文件與維護的script整合在一起，在管理時，可直接點擊 script 然後就遠端執行並取得結果。文件與 script本身要有版本管理的功能，才能在維護團隊之間共享維運知識。

如果是修改設定檔，可以即時將設定檔取回，修改並存檔後，即時同步到遠端，重點是要有新舊設定檔的備份。

另外，我們還需要知道，透過這個工具，每一個維護人員在這個機器上做過什麼事情，改過什麼設定，每一台機器的執行結果都能記錄下來。

在有多台機器的服務環境上，一個產品會部屬在多個雲端機器上，這時候可能要面對版本同步的問題，或許一個指令同時在多個 server 執行會有幫助。

puppet 的用途，看起來是要用 DSL 程式設計的方式，快速地將每一台機器的安裝設定做好。對於一般企業內部的服務管理來說，看起來有點大材小用。

這個工具的想法與概念還沒有一個比較確切的藍圖，還只在紙上談兵而已。