這篇文章會示範怎麼在不影響原來的服務的前提下，怎麼安全的去維護 ECE 中的元件服務。

維運與除錯

除錯其實就是維運團隊的日常任務，當然有些公司的維運可能只會

• 重開虛擬機加重啟服務
• 寄信然後跟主管一起用嘴高光負責的 RD

不過一個稱職的維運通常可能還會給力的幫忙

• 幫忙上補釘或是緊急修復系統異常
• 日常的系統底層服務或軟體更新
• 協助啟用新的附加功能，譬如加密傳輸

ECE 的維運與除錯

ECE 目前體驗下來的心得是有好用方便的 UI，而且透過 Docker 容器化的配置也解決了一部分早期分散式系統會遇到的多租戶 (Multi-Tenancy)、腦裂 (split brain) 等等關於實體資源分配搶奪的問題，缺點大概就是目前還沒有 logstash? 不過這次 30 天體驗也沒怎麼使用到，其實大多狀況看起來也都可以處理得很好?

透過 Cloud UI 的介面，可以初步方便簡單觀察各個服務叢集目前的狀況，符號會有三種顏色，綠色正常、黃色警告、紅色不正常。

符號會有三種顏色，綠色正常、黃色警告、紅色不正常

正常在做維護或除錯的時候，理論上不應該影響原來系統的運行，會影響的話現在的 SA/SD 就應該去撞豆腐了? 接下來的示範中目前有三個可用區域，假設我們今天要進行第二個可用區域的相關維護。

第一個步驟進到 Allocators 選單找到第二個可用區域並啟動維護模式。

Allocators 選擇 zone 2 進行維護

啟動後會發現只有一個服務節點是只存在這個可用區域，這就是這次要移動的對象，有兩個 zone 以上的不需要移動，因為會有 Tiebreakers 幫忙自動做 HA，所以在真的停機之後會影響的就是這個節點的服務。

找出在這個可用區域且只有 1 zone 的服務

嘗試進行移動

移動的時候可能會發現一點小問題

會發現是沒有對應的可用區域可以移動，這邊就先簡單修改 Tag，把 highCPU 改成 false 就可以移動了

移動完成後假裝進行維護，把 Docker 停掉並重開機

會發現可用區域就不見了

等重開機完成後啟用 Docker 取消維護服務後，Tiebreakers 會自動讓節點服務恢復，收工 ???