基礎設施即代碼(IaC) Part-1 概念
IaC已經從管理Server進化到管理整個雲端平台，但這種新的強大能力是以復雜性作為代價的。本系列文章將帶領我們超越單純只下command的方式，而是理解良好實踐背後的設計模式以及下一個等級的自動化。
我們將會學到在雲端時代的如何有效的運用原則、實踐與模式來管理我們雲端基礎設施。同時學到定義每件事都是代碼與套用軟體設計與工程實踐來建立小型、解偶的基礎設施組件。
IaC幫助我們的是在基礎設施上的變更是"具經常性、更快、更可靠"並且強化我們系統的品質。重點不是我們使用那些工具，而是我們怎麼使用那些工具。而訣竅是利用技術將品質、可靠性和合規性嵌入到變更流程中。
本系列的文章重點有三:
- 定義每件事都是代碼(everything as code) —
這將創造可重複性與一致性 - 持續測試並交付所有正在進行的工作 —
每一次變更都增強了安全性。因為這樣，所以能強化我們的信心。 - 構建小型且簡單的組件，以便能夠獨立的變更這些單一組件 —
這將比變更大型組件更容易與安全。
以上這三種實踐是相輔相成的。
甚麼是IaC?
企業的數位化代表著其基礎設施的變動更頻繁與快速，也代表著IT人員的壓力更多更大。因為需要加入與支援更多的IT服務。IaC是一種基於軟體開發實踐的基礎設施自動化方法。 它強調用於啟用和便更系統及其配置的一致性、可重複的例行作業。 對代碼進行變更，然後使用自動化來測試這些變更並將其應用到系統中。
雲端與自動化工具則可以協助IT人員已更簡便的方式進行這些變更。但是準備不足的IT部門或團隊，一但開始使用雲端與自動化就好像把一棟建築物裡的防火區間給拆除，無法阻止火勢與混亂蔓延到整個企業。而許多企業的做法就是用了雲端與自動化技術後，反而收緊他們的變更管理流程。這等於將將一台頂級跑車放在爛泥巴路上跑。
這樣做會引發兩個問題:
- 沒有享受到使用雲端帶來的效益
- 使用者會直接跳過那些想限制雲端帶來效益的人(也就是shadow IT的產生)。更糟的可能是會跳企業的風險管理(ERM)。
從傳統時代到雲端時代
傳統時代的Infra與雲端時代的差異如下
- 實體硬體 VS. 虛擬化資源
- 資源的啟用可能要數周 VS. 只需要數分鐘
- 手動流程 VS. 自動化流程
然而，這些雲端相關技術並不一定能讓我們的系統管理和擴展變得更容易。 將具有"技術債"的系統轉移到無限制的雲端基礎設施上會加速混亂。
與其使用緩慢步調的傳統時代流程和快節奏的雲端時代技術，不如採用新的思維方式。 利用快節奏的技術來降低風險並提高質量。 要做到這一點，需要從根本上改變方法以及思考"變革和風險"的新方式。下表為傳統時代與雲端時代的作業方式比較:
- 變更的成本高昂 VS. 變更成本低
- 變更代表故障(變更需要被管理與控制) VS. 變更代表學習與改進
- 減少失敗的機會 VS. 極大化改進的速度
- 一次性的大變動，最後才測試 VS. 變動是小量且是持續測試的
- 單體式架構 VS. 微服務架構
- GUI與實體方式的配置 VS. 配置檔(Configuration)即代碼
IaC的效益
總體而言，採用IaC來管理動態基礎設施的企業希望獲得的效益有：
- 使用 IT 基礎設施作為快速交付價值的推動者
- 減少基礎設施變更的工作量和風險
- 使基礎設施的使用者能夠在需要時獲得所需的資源
- 為開發、維運和其他利害關係人提供通用工具
- 建立可靠、安全且具成本效益的系統
- 使治理、安全性和合規性的控制措施是可見的
- 提高問題排除和解決故障的速度
使用IaC來優化變更
由於變更是生產系統的最大風險，而持續變更無法避免的，而變更是改進系統的唯一方法，因此優化快速且可靠地進行變更的能力才是有意義的。
當企業要用自動化來優化變更時，常有一些反對意見。 我們認為這些源於對如何能夠並且應該如何使用自動化有以下的一些誤解。
誤解一:我們所做的變更沒有很頻繁，不足以證明自動化是合理的
IT人員經常覺得我們建了一個系統，然後它就“完成了”。 從這個角度來看，我們沒有進行太多變更，因此自動化是浪費時間。
事實上，很少有系統沒有變更的，至少在系統退役之前不會。 有些人認為他們目前的變更程度是暫時的。 其他人則建立一個大霹靂式(可能接近打掉重練)的變更請求流程來阻止人們要求變更。 這些人都在否認。 大多數支援一值都有人在用的系統的團隊都會處理連續性的變更。
在雲端時代，系統的穩定是來自於變更。沒有補丁的系統不穩定； 它們是脆弱的。 如果發現問題後不能立即解決，則說明我們的系統不穩定。 如果我們不能從故障中快速恢復，我們的系統就不穩定。 如果我們所做的變更涉及相當長的停機時間，我們的系統不穩定。 如果變更經常失敗，則表明我們的系統不穩定。
誤解二: 我們應該先建立系統，後面再來自動化
IaC的入門是一個陡峭的學習曲線。 設定工具、服務和工作實踐來自動化基礎設施交付是一項艱鉅的任務，特別是如果我們還採用新的基礎設施平台的話。 在開始使用它構建和部署服務之前，很難證明這項工作的價值。 即便如此，對於那些不直接使用基礎設施的人來說，其價值可能並不明顯。
利害關係人經常向Infra team施壓，要求他們手動快速構建新的雲端託管系統，並其自動化後面再說。
事後自動化不是一個好主意，原因有三：
- 自動化應該能夠實現更快的系統交付，即使對於新系統也是如此。 大部分工作完成後才進行自動化會犧牲許多效益。
- 自動化使我們可以容易的為我們的系統編寫自動化測試。 當我們發現問題時，它可以更簡易的快速修復和重建。
- 自動化現有系統非常困難。 自動化是系統設計和實施的一部分。 要向沒有自動化所建立的系統加入自動化，我們需要顯著改變該系統的設計和實現。 對於自動化測試和部署也會是這樣。
沒有自動化建構的雲端基礎設施會比我們預期的更快報廢。 手動維護和修復系統的成本因為複雜性的增加也會迅速增加。 如果雲端服務運作順利，利害關係人將迫使我們擴展入和加功能，而不是停止重建它。
如果我們打算使用自動化來管理我們的基礎設施，我們其實需要了解其工作原理，因此它應該成為PoC的一部分。 解決方案是逐步構建系統，並在運行過程中實現自動化。 確保我們提供穩定的價值流，同時建立持續這樣做的能力。
誤解三:我們必須在速度與品質之間做出抉擇
人們很自然地認為，只有降低品質才能快速進展，只有緩慢發的進展才能有品質。但實情真的是如此嗎?
在很多案例表明，提高效能與實現更高水準的穩定性和品質之間不用做出抉擇。 相反，高績效者在所有這些指標上都做得更好。 這正是敏捷和精實運動所預測的，但許多產業的許多教條仍然基於錯誤的假設，即更快的行動意味著與其他績效目標進行權衡，而不是運用和強化它們。
這表示在速度與品質之間可以魚與熊掌兼得。如以下象限圖:
上面的象限圖說明了為什麼嘗試在速度和品質之間進行抉擇會導致兩者都表現平庸：
右下角 — 速度優於品質
這就是“快速行動，打破常規”的理念。 為了優化速度而犧牲品質的團隊會構建混亂、脆弱的系統。 他們會進到左下象限，因為他們的劣質系統減慢了他們的速度。 許多已經以這種方式工作了一段時間的新創公司抱怨失去了“魔力”。 過去他們會很快做出的簡單變更現在需要幾天或幾週的時間，因為系統是一團混亂。
左上角 — 品質優於速度
這稱為“我們正在做嚴肅而重要的事情，所以我們必須正確地做事。” 然後最後期限的壓力就會催生“變通辦法(workarounds)”。 重量級流程給改進帶來了障礙，因此技術債隨著“已知問題”清單的增加而增加。 這些團隊也陷入左下角象限。 他們最終會得到低品質的系統，因為改進它們太難了。 他們加入更多流程來應對失敗。 這些流程使得改進變得更加困難，並增加了脆弱性和風險。 這會導致更多的失敗和更多的流程，產生一個死亡螺旋(或稱鬼打強)。 許多在以這種方式工作的組織中工作的人認為這是正常的，尤其是那些在風險敏感產業工作的人。
四個主要指標
以下四種衡量標準與企業要實現高品質與高效產品與服務的程度具有最強的相關性：
- 交付時間:
實施、測試和交付生產系統變更所需的時間 - 佈署頻率:
生產系統多常進行變更 - 變更失敗的百分比:
有多少百分比的變更會導致服務出問題或需要立即修正（例如rollback或緊急修復） - MTTR(Mean Time to Restore):
發生未預期中斷或損壞時需要多長時間才能恢復服務
三個IaC的核心實踐
定義每件事都是代碼(everything as code)
將所有每件事定義為“代碼”是快速並且可靠地進行變更的核心實踐。 這有幫助的原因有幾個：
- 可重複使用性(Reusability)
如果將事物定義為代碼，則可以一直重建或複製許多相同的系統。 我們可以快速修復和重建，其他人也可以用相同的代碼建立一樣的系統。 - 一致性(Consistency):
從代碼構建的東西每次都以相同的方式呈現。 這使得系統行為可預測，使測試更加可靠，並實現持續測試和交付。 - 透明度(Transparency):
每個人都可以通過查看代碼了解這個東西是如何構建的。 人們可以查看代碼並提出改進建議。 他們可以學習在其他代碼中使用的知識，獲得在故障排除時使用的洞察力，以及審查和稽核合規性。
持續測試並交付所有正在進行的工作
高效的Infra team對測試非常嚴格。 他們使用自動化來部署和測試系統的每個組件，並整合每個人正在進行的所有作業。 他們在作業中進行測試，而不是等到完成。
"重點是構建品質而不是試圖測試品質"
人們經常忽視的一部分是它涉及整合和測試所有正在進行的作業。 在許多團隊中，人們在不同的branches中處理代碼，只有在完成後才進行整合。 然而，當每個人至少每天整合他們的作業時，團隊會取得更好的結果。 CI 涉及在整個開發過程中合併和測試每個人的代碼。 CD 更進一步，使合併的代碼始終可用於生產環境。
構建小型且簡單的組件，以便能夠獨立的變更這些單一組件
當系統龐大且緊密耦合時，團隊就會陷入困境。 系統越大，變更就越困難，也就越容易被破壞。 高績效團隊的代碼庫，系統是由小而簡單的部分組成。 每個部分都很容易理解，並且具有明確定義的介面。 團隊可以輕易的自行更改每個組件，並且可以單獨部署和測試每個組件。
