什麼是IaC(Infrastructure as Code)
如果我們是Infra team的成員，不管是在地端機房或雲端運算，哪麼infra的自動化技術你多多少少一定會使用到，只是在於使用的程度如何而已。自動化的價值在於使用更少的時間與人力更可靠化的方式(避免每個人根據SOP做得還是不一樣的結果)。但是實際上不管是在雲端或地端架構都是越來越複雜，Infra team也有其他很多事情還需要管理。這些自動化技術究竟怎麼幫到我們呢?
這些自動化技術的產生是因為越來越多的企業朝向數位化的方向前進，就是把IT當作是企業運作的基石。IT不再是成本中心而是利潤中心。企業越接近"數位化"在企業的業務壓力下所要求的自動化(也就是IT的"效能與效率")將會越高。在IT人員有限的狀況下Infra team需要支援更多的員工，更多的業務服務，更多的客戶或商業夥伴都需要自動化技術來協助我們。
但不論面對雲端或地端的環境都要求Infra team要快要好要正確的提供服務出來。這麼多的需求出現，多數有規模的企業都有使用ITIL的變更管理(change management)流程來管理這些不斷出現的大量需求來避免混亂的狀況出現。他們希望能"限制與控制"這些業務需求。他們把這些要快要好的需求放進的一般的標準流程中。為了達到動態，有彈性的infrastructure 我們必須要具有雲端平台的思維在IaC的實踐中。IaC有三個核心概念
- 每樣東西我們都可以定義成code
- 這些code是可以被持續性的測試與交付出去
- 從Small and loosely coupled的系統持續變大
從Iron Age到Cloud age
我們上面有提到實踐IaC需要有雲端平台的思維在其中。哪甚麼又是"Iron age"呢?
- 它是需要實體機器的。
- 它從開需求到提供服務可能需以"月"計算。
- 它是有一堆人工作業。
相反的Cloud age就是:
- 它的一切都是虛擬的(你不會碰到任何實體機器)
- 提供服務出來是以＂分鐘＂計
- 它是自動化的
不過“Iron age”也沒有不好，它讓你有時間慢慢想可以控制變化太快導致變更管理上的混亂。要看的是這兩種方式你要用在哪裡。採用Cloud age的思維會讓我們的服務又快又好又便宜（重點是你與你的團隊可以駕馭得了它）。以下是Iron age與Cloud age的工作思維比較
從上面的比較中可以看到，雲端時代的Infrastructure是在高度的可靠性與品質控管下進行持續性的變更管理。
Infrastructure as Code
IaC是一個將IT infrastructure 用軟體思維的自動化的方式，它強調的是用一致性，可重複的流程來提供Infra 環境與configuration 變更管理。這些都可以把它變成code,然後使用自動化的方式來測試與實現這些變更。
我們也會透過用敏捷工程的實踐方式(像是TDD- Test Driven Development, CI- Continuous Integration, CD- Continuous Delivery)讓 Infrastructure 的管理更快與安全。哪麼企業擁抱IaC的方式會有那些效益呢?
- IaC可以讓產生服務快速交付的價值。
- 在變更Infra時可以減少"變更的風險"與企業所要"花費的氣力"。
- 當使用者想要拿到他們想要的Infra環境時他們就能很簡單的要到。
- 提供開發/維運/或其他相關人一套共同的工具。
- 讓系統更可靠，安全，與具成本效益。
- 使IT Infra的治理/安全/合規控制都是可見的。
- 加速troubleshoot 與resolve failures。
哪麼我們如何知道在擁抱的IaC的方式之後我們真的可以得到上面所提到的效益呢?我們提供以下四種的量測指標來參考。
- 交付時間:
我們花了多少時間在Production Infrastructure 環境的implement/test/日常的configuration change - 部署的頻率:
多常在Production system部署 - 變更失敗的百分比:
有多少比例是因為變更後造成服務有問題或是有錯誤需要立刻修正的，像是rollback或有budge有緊急修復。 - Mean time to Restore(MTTR):
你需要多久的時間回復服務完全掛掉或修復部分受損的服務?
上面的四項指標都是跟企業組織提供的服務有關，不管是對內還是對外。服務有問題了或服務沒更新到位都會影響企業的營運。
三種核心的實踐
在雲端的時代Infrastructure是動態的，是不斷變動的。這些經常性的變動往往要具可靠性與有變更的品質。哪麼我們如何做到這件事呢?以下我們提供三種核心的實踐方式
實踐一:每件事都是code
把Infra的每件事定義成code讓infra的變動是快速且可靠的，原因如下
- 可重複:
因為每件事都議定成code了，意味著我們可以在很多地方重複使用它。repair/rebuild也更快速。 - 一致性:
因為這種方式所以每次都動作流程都是一樣，不會像手動的方式。工程師有了SOP文件，但我們還是不能確定到底有沒有做對。這讓系統是可以預測以及讓測試是可靠，持續的交付與持續的測試也變成可能。 - 透明:
因為是寫成code的方式團隊的其他人或其他團隊的人也能看到你做了些甚麼進而確認是不是他們要的。如果code有問題或是有改進的空間團隊其他成員也更容易修正與改進。
實踐二:持續測試並交付所有進行中的工作
有效率的Infrastructure團隊對其infra的測試是有著很嚴格的流程的。他們使用自動化方式來測試與部署每個infra component並且整合這些經過測試的componnent，這些都是在工作進行中完成的而不是全部做完後再來測試。這樣的好處在於在工作處理中可以一邊做一邊驗證，哪麼整個infra品質就會融入在裡面。而不是全做完後再一次測試是不是有達到我們要的品質。
實踐三:從製作小型，簡單的部分，每個部份都是可以獨立修改的
團隊通常都陷入在大型且所有的component 又是緊密連結在一起的，而這將變得很難異動且容易ㄧ變動就死給你看。而在以code based的infra團隊，每一個部分小而精美的。每一部分都是易懂且有明確定義的interface。所以每部分都是容易分別的修改/部署/測試。
結論
我們可以看到在雲端時代，Infra的品質與速度是可以兼具的。自動化你的Infrastructure特別是你要如何地使用它將對你的日常工作是重要的第一步。
