AWS的雲端架構框架-卓越維運篇
卓越不是終點，而是途徑 — 是持續發展和改進的一條漫長、曲折、艱辛的道路
容忍失敗的精神是卓越企業特有的文化，而且是高層直接給予的教誨。捍衛者必須不斷嘗試，並忍受隨之而來的失敗打擊，否則組織便無法從中學習。
— <<追求卓越：探索成功企業的特質>>
本篇要講述的是根據AWS服務成千上萬的客戶所得出的良好框架應該是要如何來設計的．這個AWS所提出的框架可以讓我們的平台在AWS上能夠運作得"安全，可靠，有效率，具成本效益與可持續的"。
框架定義
所謂良好的框架是根據每間公司”不同的狀況與不同的目標”所定義出來的．而一般所謂的最佳實踐也可能只是參考，我們必須根據”當時的狀況”的要求做出一些變動．簡單的來說，整個架構出來的東西就是一個詞: “權衡”。
而AWS提出了良好框架應該要考慮的六大面向，它們分別是:
- 卓越維運(Operational excellence)
- 安全(security)
- 可靠的(reliability)
- 有效益的(performance efficiency)
- 成本優化(cost optimization)
- 可持續的(sustainability)
在解釋上面六大面向(支柱)之前，我們需要先定義一些名詞解釋．然後再來解釋這六大面向的內容．
- Component(組件) — 指的是將程式碼，組態設定與AWS resource組合起來成為符合功能需求的．這通常會有一個技術單位來負責，並且是能夠與其他組件解耦．
- Workload (工作負載)— 這是指一組的組件能夠產生業務價值的．這通常會是業務與技術單位共同定義出來的．
- Architecture (架構)— 這是指各個組件在工作負載中如何一起作業的．這些組件之間如何溝通與互動的．這架構面上要聚焦的事情．
- Milestones (里程碑)— 這是在架構面上因為產品的生命週期而做出重大的改變(設計，實作，測試，上線)．
- Technology portfolio (技術組合)— 一組能夠持續營組織業務的工作負載
六大面向的定義
卓越維運
有能力支援程式開發與有效運作的組件，並且從維運的作業流程中獲得新的見解，還可以持續強化整個作業流程與改善其程序最終能對能貢獻業務價值。
安全(security)
如何利用雲端科技的能力來達成保護運作在雲端上的資料，系統與數位資產，來強化我們在雲端上的安全．
可靠的(reliability)
能將我們的工作負載運行得如我們預期的將功能正確且持續性的運作．這包含了整個工作負載的生命週期的維運與測試．
有效益的(performance efficiency)
能將運算資源有效的符合系統需求，並且能依據業務需求跟技術變化來維持所需要的資源。
成本優化(cost optimization)
用最低的費用獲取最高的業務價值。
可持續的(sustainability)
能最大程度提高供應資源的效益並最大程度的減少所需的總體資源，降低能源消耗並提高工作負載所有組件的效率。不過這可能對所有人是很困難的，因為使用雲端運算是困在三元悖論(就是在成本-速度-品質取得平衡)中的。
關於IT架構
比起傳統的IT治理架構(如TOGAF)，像是基礎架構師(Infrastructure)，解決方案架構師(Software)，資料架構師，網路架構師和資安架構師等這種中心化的組織架構．AWS更傾向將這些職權下放給各個團隊(根據AWS提出的領導原則)。
這麼做的好處有兩個：
- 有真實的實踐(做事的方式，流程，標準)，而不是嘴砲
- 2.實行一種自動化的檢查機制，以確認我們所需要的比標準能持續不斷達成
但是絕大部分的C-Level的高管還是比較偏策略面(嘴砲的做法)，AWS的雲端架構框架是較偏"戰術面"，而非整體IT戰略面。所以如果讀者中有C Level的可以參考此篇文章: 企業的雲端架構管理，如何使用TOGAF來建立與管理雲端架構。
一般性的設計原則
AWS的架構原則能協助我們指引我們達成一個好的雲端架構，包含：
- 停止猜測我們需要多少資源
- 能用生產環境的規模來進行測試
- 自動化使我們進行架構實驗更容易
- 持續進化我們的架構
- 用資料來驅動我們的架構，而不是瞎猜
- 以Game day的方式得到架構上的強化
六大面向(支柱)
建立軟體系統很像建房子。 如果基礎不牢固，結構問題會破壞房子的完整性和功能。 在構建技術解決方案時，如果我們忽略了上述架構面的六大支柱，那麼造出來的房子就會很容易垮掉。 將六大支柱整合到我們的架構中將幫助我們產生一個穩定且高效的系統。 這將使我們的團隊能夠專注於系統設計的其他方面，像是功能性需求。
卓越維運(Operational excellence)
卓越維運提提供一個能全面檢視設計原則，最佳實踐與問題．傳統上的IT架構大概如下圖
每一個象限都有一個專屬團隊在負責(如果是夠大又有錢的公司)．每一個團隊大都是靠ITSM(IT service management)在溝通．但是在這樣的方式下團隊協同作業很差。
PS: 這是AWS的說法，但還是有人可以做得好。因為車開太快翻車的可能性會大。
AWS提出了中心化治理的AEO(Application Engineering and Operations)與IEO(Infrastructure Engineering and Operations)模式(如下圖)．這個模式的中心思想是:”你建立的服務由你自己來維運”。整體的平台需要由開發人員與維運人員共同負起這個責任(這是理想，真實世界可能會吵翻天)。
而中心化的治理，AWS則提供了AWS Organization與AWS Control Tower甚至AWS Service Catalog的方案，進行一致性的政策控管．
另外AWS還倡議了COPE(Cloud Operation and Platform Enablement)團隊，來管理除了寫code之外的任何雲端運算技術性的事務，包含使其作業自動化．而在COPE之上(如果公司夠大夠有錢)則會有CCoE(Cloud Center of Enablement ，AWS把原先的雲端卓越中心 — CCoE中的這個E字本來是Excellence)團隊負責其高階的雲端運算治理．
設計原則
在卓越維運中有五種設計原則，分別是：
- 雲端的維運作業要像代碼一樣．從技術層面(Application to Infrastructure)到作業程序的自動化．
- 頻繁，小量且可倒回(roll back)的變更
- 經常精煉維運程序
- 預期系統一定會掛掉．確認可能會掛掉的地方並且進行測試．
- 從所有的失敗維運經驗中學會
最佳實踐
卓越維運中提供的四個最佳實踐：
- 組織
- 準備
- 維運
- 進化
企業組織一定會定義其業務目標．我們的組織有必須了解因業務目標所產生的需求與優先順序，並且使用這些來組織與指導我們的工作來達成組織想要的目標．
我們的系統平台必須完全理解這些必要的資訊來支援企業的目標．實作我們的系統平台來實現整體系統的整合、部署和交付，將通過自動化(重複性)流程來增加對生產環境有效益的變更。
PS:不是所有作業都能自動化。在自動作之前請先思考此項作業是否可以自動畫。
我們的系統運行可能存在既有風險。 我們必須了解這些風險並做出明智的決定來建構生產環境。 我們的團隊必須能夠支援我們的系統平台。 源自預期的業務成果和運營指標將使我們能夠了解系統平台的健康狀況、運營活動並回應維運中的各類事件。 我們的優先事項應該隨著組織的業務需求和業務環境的變化而變化。 將這些用作反饋循環，來推動組織和系統平台運作的強化。
以下是在卓越維運中我們可能會要回答的問題：
Q1: 我們如何決定我們的優先順序？
每個人都需要了解他們在幫助組織獲得業務成功中的作用。 有共同的目標，以便為需要投資的資源設定優先等級。 這將可以讓我們事半功倍。
最佳的實踐包含了：
- 評估內外部客戶/使用者的需求
- 評估企業治理的需求(戰略面所導出的戰術面需求)
- 評估合規的需求
- 評估威脅模型：這裡是指哪些威脅會對組織的業務產生衝擊．將這些風險放入企業的風險清單中．根據清單的順序來對應我們將要首先聚焦在哪一部分．
- 權衡取捨的評估
- 效益與風險管理
Q2: 我們如何架構我們的組織結構來支援組織的業務目標？
我們的團隊必須了解他們在實現業務成果方面的貢獻是什麼。 團隊需要了解他們在其他團隊的助攻角色，其他團隊會助攻他們的角色是什麼，並有共同的目標。 了解其責任、負責人是誰、決策方式以及誰有權做出決策將有助於集中精力並最大程度的從團隊中取得效益。這一部分我們需要一堆C-Level人員的支持，不然可能會白搭。
最佳的實踐包含了：
- 誰是各項資源/流程/程序的負責人(Owner — 問責制)
- 誰是維運作業並為其負責效能的負責人(Owner —問責制 )
- 每個人有明確的R&R(Role and Responsibility)並有清楚的機制可以確認R&R
- 每個團隊之間的R&R必須要先被定義或是協調其責任義務
上面說白了就是把大家的責任義務獎清楚，但這在台灣企業不容易，因為台灣老闆只會要你做更多卻沒有考慮其他關於"人員"的其他因素。
Q3: 我們的組織文化如何支援我們需要的業務成果？
為我們的團隊成員提供他們所需的資源，使他們能夠更有效地採取行動並支援組織的業務成果。
最佳的實踐包含了：
- 這也需要一堆C-level長官的支持
- 團隊成員能夠被賦權來進行應該有的行動，即使其結果是有風險的
- 鼓勵團隊成員能夠對上層的決策提出疑慮．也就是組織文化需要能容納不同的意見，即使是階級不同的人．
- 團隊及團隊成員之間的溝通需要即時，清楚並能有明確的下一步
- 鼓勵團隊成員進行實驗並且不會受到處罰，因為這是創新的來源
- 團隊成員能夠持續增進與精進他們的技能
以上的組織文化，每個公司不一定都能有，實作時請小心服用。
Q4: 我們如何設計一個我們能了解它的狀態的系統平台？
設計我們的系統平台，使其提供跨所有組件（如metrics、logs和traces）所需的訊息，讓我們能了解其內部狀態。 這使我們能夠在適當的時候提供有效的回應。
最佳的實踐包含了：
- 設定Application layer的監控
- 設定系統平台的監控(如API call volume, HTTP statue code)
- 設定使用者的監控
- 設定各組件相依性間的監控(如 DNS與網路之間的相依性關係)
- 設定整個系統平台的交易流程或整個運作流程是可以被記錄且追蹤的
這一題所建立的資訊最好能夠讓全部的厲害關係人都能夠及時的被看見。
Q5: 我們如何在生產環境減少缺陷，修復是容易的，並且能強化其流程？
強化生產環境的變更流程方式，以實現重構、快速的質量回饋和錯誤修正。 這些加速了進入生產的有效變動，部署的問題可以被限制，並能夠快速識別和修復通過部署活動產生的問題。
最佳的實踐包含了：
- 使用版本控制
- 變更的測試與驗證(盡量使用自動化的方式減少人為錯誤)
- 使用組態管理
- 使用建置與部署管理系統(這一類也屬於自動化方案)
- 使用補丁管理
- 制定設計標準
- 使用多個環境(開發/測試/生產等)
- 使用一些軟體開發的最佳實踐來增進代碼的品質(如Test-driven)
- 進行頻繁，小型且是可逆轉的變更
- 全自動化的整合與部署
這些是屬於流程面的變革。請確認我們的組織文化與企業營運是可以慢慢的服用還是可以推倒重來。
Q6: 我們如何減少部署風險？
使用能夠提供關於質量的快速回饋並能夠從沒有預期到的結果的變化中快速恢復的方法。 使用這些方式可以減輕通過部署變變更時所產生問題的影響。
最佳的實踐包含了：
- 計畫不成功的變更對應
- 變更的測試與驗證
- 使用部署管理系統
- 進行有限部署的測試
- 進行頻繁，小型且是可逆轉的變更
- 全自動化的整合與部署
- 自動化的測試與倒回(rollback)
雖然說實踐是檢驗真理的唯一方式。但是我們還是必須先有"謹慎"的計畫。不然蒙著眼睛瞎測試事倍功半。
Q7:我們如何知道我們已經準備好能夠支援我們的系統平台？
評估我們的系統平台、流程和程序以及人員的維運準備情況，以了解與我們的系統平台相關的維運風險。
最佳的實踐包含了：
- 確認人員的能力(台灣老闆知會拿出香蕉，請確認要不要去吃)
- 確認我們能對維運準備情況有一套標準可供檢視(請準備好要用哪一套標準去吵)
- 有各種操作手冊來進行各項程序(盡量能有自動化機制)
- 調查問題能有一套劇本．意思是我們檢查各種問題能夠有一些標準步驟存在於文件中
- 部署系統和變更是在經過深思熟慮的
花時間將維運活動轉變為代碼，以最大程度的提高維運人員的生產力、最大程度降低人為錯誤率並實現自動化回應。 使用“事前分析”來預測失敗並在適當的情況下建立回應失敗的程序。 應用metadat來遵循一致的標籤策略，使用資源標籤和 AWS 資源組，以識別我們的資源。 標記我們的資源以用於組織、成本估算、存取控制和針對自動化維運作業的執行。 使用部署實踐，利用雲端的彈性來強化開發作業，並預先部署系統以加快實施。 當我們更改用於評估系統平台的清單時，我們需要計劃我們將如何處理不再符合要求的運作中的系統。
系統平台的成功運作是通過“實現業務成果”來衡量的。定義預期結果，確定如何衡量業務是成功的，並確定將在這些計算中使用的指標，以確定我們的系統平台和維運是否成功。維運狀況包括系統平台的狀況以及為支援系統平台而進行的維運活動的狀況（例如，部署和事件回應）。為了強化、調查和介入建立基本指標，收集和分析我們的指標，然後驗證我們對維運作業及其隨時間變化的理解。使用收集的指標來確定我們是否滿足客戶和業務需求，並確定需要改進的領域。簡單的來說我們需要對我們的系統進行品質管理大師戴明所提倡的P.D.C.A(Plan/Do/Check/Action)。
為了實現卓越運營，需要對維運事件進行高效和有效的管理。這適用於計劃內(Even)和計劃外(incident)的維運事件。使用既定的操作手冊來處理易於理解的事件，並使用手冊來幫助調查和解決問題。根據事件的業務和客戶影響確定對事件回應的優先等級。確保如果為回應事件而引發的告警，則有一個相關的流程要執行，並有一個明確標識的事件負責人。提前定義解決事件所需要的人員，並根據急迫性和影響範圍包括升級事件以在必要時聘用更多人員。關於Incident Management的更多資訊，請參閱本篇文章: 資訊安全事故管理。
在 AWS 中，我們可以產生從系統平台從 AWS 收集的指標的儀表板視圖。 我們可以利用 CloudWatch 或第三方應用程式來聚合和呈現維運活動的業務、系統平台和維運等級的視圖。 AWS 通過包括 AWS X-Ray、CloudWatch、CloudTrail 和 VPC Flow Logs 在內的日誌記錄功能提供系統平台的洞察，從而能夠識別系統平台的問題以支援RCA(root cause analysis)和修復。
而根據上面所述，我們也會遇到以下需要回答的問題：
Q8: 我們如何知道我們的系統平台是否運作良好？
定義、擷取和分析系統平台的指標以獲得對系統平台事件的可見性，以便我們可以採取適當的措施。
最佳的實踐包含了：
- 確認KPI(系統的哪些KPI關乎組織的業務成果，如下單率/客戶來客數等)
- 定義系統的指標．我們要衡量的指標(像是系統回應時間/錯誤率/使用率)能夠達成KPI
- 收集與分析系統指標
- 建立系統指標的baseline
- 從預期的系統活動的模式來辨認異常的行為
- 當系統變得有風險時可以發出告警(請與該系統所有利害關係人定義，甚麼叫有風險)
- 當系統變得有異常時可以發出告警(請與該系統所有利害關係人定義，甚麼叫有異常)
- 驗證達成的成果以及 KPI 和指標的有效性
系統能否運作良好需要與該系統所有利害關係人定義出甚麼叫做運作良好，並且能對該定義進行所有的量化指標，量化指標讓我們沒有任何模糊空間。
Q9: 我們如何知道我們的維運作業是否良好？
定義、擷取和分析系統平台的指標以獲得對維運作業事件的可見性，以便我們可以採取適當的措施。
最佳的實踐包含了：
- 確認KPI(系統的哪些KPI關乎組織的業務成果，如下單率/客戶來客數等)
- 定義維運指標(如MTTD/MTTR/RPO/RTO)
- 收集與分析維運指標
- 建立維運指標的baseline
- 從預期的維運活動的模式來辨認異常的行為
- 當維運變得有風險時可以發出告警
- 當維運變得有異常時可以發出告警
- 驗證達成的成果以及 KPI 和指標的有效性
維運作業一樣需要有量化指標。
Q10:我們如何管理系統平台與維運事件？
準備和驗證事件回應程序，以最大程度的減少事件對我們系統平台的破壞。
最佳的實踐包含了：
- 針對各項事件/事故/問題管理有處理流程
- 每個流程都有告警
- 根據業務衝擊對維運事件進行等級分類
- 定義事件升級的路徑
- 啟動推播通知(像是email或是SMS)
- 用一個儀表板來溝通系統狀態(也就是根據一個事實來源來溝通)
- 針對各項事件能有自動回應機制
我們需要學習、分享並不斷強化以維持卓越運營。將工作週期用於進行持續的增量強化。對所有影響客戶的事件進行事後分析。確定影響因素和預防措施以減緩或防止再次發生。定期評估和優先考慮強化機會（例如，功能請求、問題補救和合規性要求），包括系統平台和作業程序。
在我們的程序中包含回饋循環，以快速確定需要強化的領域並從作業執行中獲取經驗教訓。
在 AWS 上，我們可以將日誌資料導出到 S3 以進行長期存儲。使用 AWS Glue，我們可以在 S3 中探索和準備我們的日誌資料以進行分析，並將關聯的metadata存儲在 Glue data catalog中。 Athena 通過其與 AWS Glue 的整合，可用於分析我們的日誌資料，並使用標準 SQL 對其進行查詢。使用 QuickSight 等BI工具，我們可以可視化、探索和分析我們的資料。發現可能推動強化的機會。而根據這些描述我們可能會有以下問題需要回答：
Q11: 我們如何強化我們的維運作業？
投入時間和資源進行持續增量強化，以提高維運的效能和效率。
最佳的實踐包含了：
- 需要有一個強化流程是可以強化各項作業
- 進行維運作業的事後的分析
- 有一個反饋回路
- 有一個知識管理系統
- 定義我們強化的驅動力是什麼
- 得到的維運見解需要被驗證
- 進行維運指標的回顧
- 文件與經驗的分享
- 一定要騰出時間進行強化
維運的成功進化在於建立： “頻繁的小改良； 提供安全的環境和時間來試驗、開發和測試改良； 鼓勵從失敗中學習的環境”。 sandbox、開發、測試和生產環境的維運，隨著維運控制等級的提高，促進了開發並提高了部署到生產中的變更成功結果的可預測性。
雲端的卓越維運帶來創新
當某項創新對市場領先者有利時，有種機制可以讓市場領先者運作這項創新在市場中勝出，哪就是"資源分配流程"。透過雲端運算，企業的領導者可以全面檢視企業運作的流程中，資源可以如何重新再分配。同樣的，市場的破壞性創新者也是使用資源的分配流程攻擊市場領導者的舊有模式。
上面所說的這一些企業使用資源分配流程的案例多不勝數。亞馬遜本身就是利用資源分配流程變成了電商霸主或是網飛將資源從租片服務轉向線上串流擊敗了百事達。
而我們(企業經理人或企業/雲端架構師)必需要了解自己處於何種情況，所以使用那些雲端服務，還必須知道自己"沒有"處於那些哪情況，故不使用那些雲端服務。當我們界定所有狀況，或是將各種互斥的情況分類之後，就能預測事情的發展，也可以說明甚麼原因導致甚麼結果，也能夠預測這個因果關係在甚麼情況下，會有甚麼樣的變化。創新由此而來。我們要用以情境分類為基礎的理論(這很容易應用)，因為我們是在各種"情境"之下工作，而不是在各種雲端產品或服務的"屬性"中工作。
