最近大家應該上Patch上得很開心
老實說 個人影響不大 因為平常就常被追殺 Patch 完成度 :P
而且已經丟上 MS SCCM, 手上有的系統 有辦法就是讓 SCCM 自動上 Patch
當然 系統維護不會是只有 Patching. 任何系統維護都可能會造成服務中斷
重點在於 如何設計 可以減少系統中斷之後 要復原所需的人力資源
這邊講的大都是 Infra 部分設計方向
- 系統中任何元件, 任何 Server 都可以在任何時候重開
而且當下會有另一個備用元件補上 避免服務中斷過久
加上 重開的元件 一旦重開完成 必須要可以自動接上變成另一個備用元件才行
如果有考慮到 HA, 就得考慮要用 VMware HA 即可 還是要搭配 MSCS, NLB 之類
個人曾經看過有些比較"沒那麼好"的系統 DB 斷線之後 必須要人為去將服務啟動 - 任何程序 都要考慮到在任何階段 中斷時的自動復原機制
MQ是種方式, 被挑走的 task 最好有個 timeout 設定
Transaction 別包太大包也是種方式 免得跑到一半要 rollback. 要花太多成本
還有如果系統有多種運作方式 得考慮哪種方式可以允許跑到一半 剛好重開 又可以自動復原, 並不是速度快的方式才是優先選項, 個人有個 Veeam Backup 範例 等之後再詳細聊 - Patching, 或是其他類似動作 最好可以自動並且分群組完成
例如
自動上Patch, 最好分兩到三群, 每群隔一個禮拜
Patch 有問題至少可以控制範圍 沒法 rollback 也還有一半系統回應能力
MS Patch 也有出過事低~~~ 個人血淚的教訓 T___T - 監控部分 最好每個端點都可以 End to End 監控到
例如 Server, Service, Port, Web Service response, 最好是都有監控到
避免像是有些只看ping, 結果service死掉都不知道
或是只看 Port 通不通 結果 page都掛了 還在那邊亮綠燈
這部分當然要靠 System Owner 跟監控部門合作才行不過塞郎有事後會 偷偷關一下 看看有沒有人會發現 並通知 - 一堆小小 Schedule Task 是你的小幫手, 有啥事情 靠 script 即可
從十幾年前 VB Script, Java Script, 後來的 Powershell, 最近還自在摸索 Python.
Error Control + Reporting 都要搞好 重點是 失敗了也一定要通知到你
每天早上到公司只要看 email 就知道他們有沒有乖乖工作
例如
自動清理 Snapshot, 不用再自己 或是找人定期去清理
自動排序 Backup Task Schedule, 避免過度集中 造成 Backup system 壓力過大
週期性的系統自動健康檢查報表 看看有哪邊該注意的 該處理還沒處理的
自動掃VM的通用設定 並且更正 避免系統設定不一致的情形發生
每個月的資料備份清理 準備轉 Tape 的動作 - 還有一個很重要的
手上一定有一堆大大小小的 schedule task, 而且包準還會越寫越多
要想辦法集中管理 就算沒法集中管理 文件一定要記錄清楚
這對之後的 Troubleshooting 很重要
有時候就是會遇到找不到問題在哪的狀況 被遺忘的 schedule task 往往是原因之一
塞郎我 曾經有事沒事就是搞了一堆小 schedule task.
然後就忘了他們的存在 十年後一次偶然的機會還發現他們還在默默的工作...
趕快替他們上香 請下來....
其實還有一堆有的沒的 一下子想不了那麼多
那麼 祝大家 patching 愉快.. :p
No comments:
Post a Comment