背景

目前任職公司的SSO服務架構是由我建立以及維護的。我們在四個廠區建立服務群集，每個廠區分別有一個負載平衡/反向代理節點、一個備援的負載平衡/反向代理節點，以及實際作為服務的兩個應用節點。

資料庫同樣在四個廠區皆有節點，並組成跨廠區群集，使用MariaDB的Galera Cluster機制。由於資料庫是多主叢集架構，各別都可以作爲主節點寫入，因此SSO服務節點使用的AD服務和DB服務都是設定相同廠區，減少物理上的路徑。但不同的是資料庫是由DBA負責管理的。

而這次的狀況是： 資料庫需要進行設定調整，啟用某些功能。這些功能有助於了解服務使用狀況等等。

不過DBA並沒有信心能夠調整而不影響服務。因此有先向我詢問過意見。

※ SSO: Single Sign-ON單點登入
※ DBA: Database Administrator 資料庫管理人員
※ AD: Active Directory 活動目錄。與SSO使用LDAP與AD通訊。
※ LDAP: Lightweight Directory Access Protocol 輕型目錄存取協議

擔心MO & 8D

我告訴DBA：我規劃的架構，雖然服務切分成四個廠區/四個服務，但實際上，任意廠區的應用節點若失效，會自動尋找其他廠區的應用節點使用，因次並不用擔心DB分廠區下線調整的問題。

爾後，遇到我請假沒有上班。 DBA並沒有自行調整作業。

接著，DBA又與我另外約定時間共同進行：「DB是不會死啦，但怕會有8D」。

「8D問題解決法」簡稱「8D」，是一種在問題發生後，探討問題的處理方式與預防方法的報告。我就曾在所有作業都按計畫執行後，因為他人的配合不當，造成更大範圍的使用問題而寫。

D8：感謝團隊成員：認可團隊整體的貢獻，需要由組織正式的感謝此團隊。

上述D8來自維基百科的內容，是8D的一個內容項目，但我沒有印象收到的範本與之前交出去的報告有這麼一項。在我認知上，這不應該是一個問責的檢討報告。但事實是，它就像一個懲罰遊戲一般令人厭惡的存在……

共同作業

DBA依其上級指示，先填寫了異動紀錄表： 「服務備援演練，並啟用資料庫效能監控功能。」

從原本主要的「啓用資料庫功能」爲主要目的，變成「備援演練」爲主要目的。DBA認爲把我拖下水了。

被拖下水…了嗎？
其實是覺得還好…(可能我對我規劃的架構是有信心的)

總之，到了約定時間，我就standby盯著服務狀態，隨時準備進行設想過的狀況處理。

作業結果

四個廠區的輪流調整，可以說是非常順利。沒有任何服務檢測到下線情況，僅有個別服務實例有檢測出短暫異常，但甚是連通知都來不及發出。在作業間的服務操作嘗試，也幾乎沒有遇到任何問題。

服務實例連線DB失敗，因此存在異常，這完全在我預期之內。負載平衡檢測上游節點問題也如想像的發揮作用，這也使得：從服務層面角度來看，根本沒有發生任何異常。

儘管在DBA那塊仍有一些額外工具並未設定正確，但這次的DB調整是順利完成。我也收到DBA的感謝：「現在確認DB restart影響很小了，以後有類似需求就沒這麼怕了，謝謝…」

反思

首先，為什麼會害怕寫8D？是「不可犯錯文化」造成的嗎？這是個好的文化嗎？雖然沒有明說，但我認爲環境依然塑造了這種感覺，且近期我確實也有一些蛛絲馬跡說明了這種感覺並不單純是假象。
我不認爲這是個好文化，但目前我也沒有想法與能力可以改變該文化。在經過了數天沉澱後，也算是有點認清與接受這項事實。

接著，有些什麼方式，能讓我們在作業時更具有信心？
良好的監控措施、適當的錯誤處理應對計劃還有測試，我想這些都有助於提升在作業時不用擔心出錯的信心。

你知道台積電之前因爲自動部署造成了重大的損失嗎？台積電都做不到了，你憑甚麼認爲我們產業適合做？

上面是曾在討論敏捷對於多次部署適不適用於製造業/半導體業，上級給我的回覆。
我不知道。但是就因爲台積電曾經的損失，就認定整個產業不適合是不是有問題的？

至少我認爲這次的調整經驗，也證明了在一些情況下的多次部署是可行的。

結論

• 這證明我規畫的這個架構確實存在一定程度的穩健性，是強韌的。
• 環境有點小讓我感受到不自在。

以上絕大多數都是在該次作業完後立刻寫下的。 原本想在補充一些後續內心在掙扎的內容，但還是以後獨立寫吧。

上班該幹什麼幹什麼，然後準時下班做自己想做的。

• work