我們公司正在組建 SRE 團隊。 我是從開發的角度來了解整個故事的。 在這個過程中，我提出了一些想法和見解，想與其他開發人員分享。 在這篇反思文章中，我討論了正在發生的事情、它是如何發生的以及每個人如何繼續忍受它。
根據我們內部活動的演講所撰寫的一系列文章的延續 :
2. 基礎設施即代碼。 （你在這裡）
3. 使用 C# 模型產生 Typescript 合約。 （進行中...）
4.Raft共識演算法介紹。 （進行中...）
...
我們決定創建一個 SRE 團隊來實施這些想法 。 他們從自己的開發人員中招募程式設計師，並派他們接受幾個月的培訓。
該團隊有以下訓練任務：
- 描述我們的基礎設施，它主要以程式碼的形式存在於 Microsoft Azure 中（Terraform 和周圍的一切）。
- 教導開發人員如何使用基礎設施。
- 為開發人員做好履行職責的準備。
我們引入基礎設施即程式碼的概念
在世界的通常模型（古典管理）中，有關基礎設施的知識位於兩個地方：
- 或以專家頭腦中的知識的形式。
- 或者這些資訊是在某些打字機上的，其中一些是專家所知道的。 但事實上，外人（以防我們整個團隊突然死亡）能夠弄清楚什麼是有效的以及它是如何運作的。 一台機器上可能有很多資訊：配件、定時任務、恐嚇（請參閱。 ）磁碟和可能發生的事情的無窮無盡的清單。 很難理解到底發生了什麼事。
在這兩種情況下，我們都會發現自己陷入了依賴：
- 或來自一個凡人，容易受到疾病、戀愛、情緒波動和平庸的裁員的影響；
- 或者來自實體工作的機器，該機器也會掉落、被盜，並帶來意外和不便。
不言而喻，理想情況下所有內容都應該翻譯成人類可讀、可維護、編寫良好的程式碼。
因此，基礎設施即程式碼（Incfastruct as Code - IaC）是對整個現有基礎設施以程式碼形式的描述，以及用於使用它並從中實現真正基礎設施的相關工具。
為什麼要把一切都翻譯成程式碼？人不是機器。 他們無法記住一切。 人和機器的反應是不同的。 任何自動化的事情都可能比人類所做的事情更快。 最重要的是單一事實來源。
新的 SRE 工程師從哪裡來？因此，我們決定聘請新的 SRE 工程師，但從哪裡找他們呢？ 預訂正確答案（）告訴我們：來自開發商。 畢竟，它們與程式碼一起工作，並且您達到了理想的狀態。
我們在公司外部的人才市場上尋找了很長一段時間。 但我們不得不承認，我們沒有找到符合我們要求的人。 我必須在自己的同胞中尋找。
問題 基礎設施即程式碼
現在讓我們來看看如何將基礎設施硬編碼到程式碼中的範例。 程式碼寫得很好，品質很高，有註解和縮排。
來自 Terraforma 的範例程式碼。
來自 Ansible 的範例程式碼。
先生們，如果事情有這麼簡單就好了！ 我們身處現實世界，它隨時準備好給你驚喜，帶給你驚喜和問題。 這裡也離不開他們。
1. 第一個問題是，在大多數情況下，IaC 是某種 dsl。
而 DSL 又是對結構的描述。 更準確地說，你應該擁有：Json、Yaml、一些大公司的修改，這些公司提出了自己的 dsl（HCL 用於 terraform）。
問題是它可能很容易不包含以下熟悉的內容：
- 變數；
- 狀況;
- 有些地方沒有註釋，例如Json，預設不提供註釋；
- 功能;
- 我甚至不是在談論諸如類、繼承之類的高級事物。
2. 這類程式碼的第二個問題是，大多數情況下它是異質環境。 通常你會坐下來使用 C#，即使用一種語言、一種堆疊、一種生態系統。 這裡有各種各樣的技術。
這是一個非常真實的情況，當 bash 使用 python 啟動一些插入 Json 的進程。 您對其進行分析，然後其他生成器會產生另外 30 個檔案。 為此，從 Azure Key Vault 接收輸入變量，這些變數由用 Go 編寫的 Drone.io 外掛程式整合在一起，並且這些變數透過 yaml 傳遞，而 yaml 是 jsonnet 模板引擎產生的結果。 當您擁有如此多樣化的環境時，很難擁有嚴格且良好描述的程式碼。
一項任務框架內的傳統開發使用一種語言。 在這裡，我們使用大量語言。
3.第三個問題是調優。 我們習慣了很酷的編輯器（Ms Visual Studio、Jetbrains Rider）為我們做一切。 即使我們很蠢，他們也會說我們錯了。 這看起來很正常、很自然。
但附近有 VSCode，其中有一些以某種方式安裝、支援或不支援的插件。 新版本發布但不受支援。 實現一個功能（即使它存在）的平庸過渡變成了一個複雜且不平凡的問題。 變數的簡單重命名就是在包含十幾個檔案的專案中重新命名。 如果他放置了你需要的東西，你就會很幸運。 當然，到處都有背光，有自動完成，有地方有格式化（儘管它在 Windows 上的 terraform 中對我不起作用）。
在撰寫本文時 儘管已經發布了 0.12 個月，但尚未發布支援 3 版本。
是時候忘記...
- 調試。
- 重構工具。
- 自動完成。
- 檢測編譯期間的錯誤。
這很有趣，但這也增加了開發時間並增加了不可避免發生的錯誤數量。
最糟糕的是，我們被迫思考的不是如何設計、將文件組織到資料夾、分解、使程式碼可維護、可讀等等，而是如何正確地編寫這個命令，因為我不知何故寫錯了它。
作為初學者，您正在嘗試學習 terraform，而 IDE 根本無法幫助您。 有文檔的話就進去看看。 但如果你輸入新的程式語言，IDE會告訴你有這樣的類型，但實際上並沒有這樣的東西。 至少在整數或字串層級。 這通常很有用。
測試怎麼樣？
你問：“程式設計師先生們，測試怎麼樣？” 認真的人會測試生產中的一切，這很困難。 這是網站上 terraform 模組的單元測試範例 .
他們有很好的文檔。 我一直喜歡 Microsoft 的文檔和培訓方法。 但即使您不是 Bob 叔叔，您也能明白這不是完美的程式碼。 請注意右側的驗證。
單元測試的問題在於你和我可以檢查 Json 輸出的正確性。 我輸入了 5 個參數，得到了一個包含 2000 行的 Json 腳布。 我可以分析這裡發生的事情，驗證測試結果...
在Go中解析Json是很困難的。 而且您需要用 Go 編寫，因為 Go 中的 terraform 是用您編寫的語言進行測試的良好實踐。 程式碼本身的組織非常薄弱。 同時，這是最好的測試庫。
Microsoft 自己編寫其模組，並以這種方式測試它們。 當然它是開源的。 我所說的一切你都可以過來解決。 我可以坐下來在一周內修復所有問題，開源 VS code 插件、terraforms、為騎手製作一個插件。 也許寫幾個分析器，加入 linter，貢獻一個測試庫。 我什麼都可以做。 但這不是我該做的。
最佳實踐基礎架構即程式碼
讓我們繼續。 如果 IaC 中沒有測試，IDE 和調優很糟糕，那麼至少應該有最佳實踐。 我剛剛訪問 Google Analytics，比較了兩個搜尋查詢：Terraform 最佳實踐和 C# 最佳實踐。
我們看到了什麼？ 無情的統計數據對我們不利。 材料的量是一樣的。 在 C# 開發中，我們有大量的資料，我們有超級最佳實踐，有專家寫的書，也有其他批評這些書的專家寫的書。 大量的官方文件、文章、培訓課程，現在還有開源開發。
至於 IaC 請求：這裡你試圖從 highload 或 HashiConf 報告、官方文件和 Github 上的眾多問題中一點一點地收集資訊。 一般如何分發這些模組，如何處理它們？ 看來這是一個真正的問題...先生們，有一個社區，對於任何問題，您都會在 Github 上獲得 10 條評論。 但事實並非如此。
不幸的是，此時專家才剛開始出現。 到目前為止，他們的數量太少了。 而社區本身仍處於初級水準。
這一切要去哪裡以及該做什麼
你可以放下一切，回到 C#，回到騎士的世界。 但不是。 如果你找不到解決方案，為什麼還要費力這樣做呢？ 下面我提出我的主觀結論。 你可以在評論裡和我爭論，這會很有趣。
就我個人而言，我押注於以下幾件事：
- 該領域的發展非常迅速。 以下是 DevOps 請求的時間表。
這個話題可能是炒作，但這個領域正在發展的事實本身就帶來了一些希望。如果某件事發展得這麼快，那麼聰明的人一定會出現，他們會告訴你什麼該做，什麼不該做。 受歡迎程度的增加導致這樣一個事實：也許有人最終有時間為 vscode 的 jsonnet 添加一個插件，這將允許你繼續實現該功能，而不是透過 ctrl+shift+f 搜尋它。 隨著事物的發展，更多的材料出現。 Google 發佈的一本關於 SRE 的書就是一個很好的例子。
- 我們可以在這裡成功應用傳統開發中的成熟技術和實務。 是的，測試和異質環境存在細微差別，工具不足，但已經累積了大量有用且有幫助的實踐。
一個簡單的例子：透過結對程式設計進行協作。 弄清楚它有很大幫助。 當你附近的鄰居也試圖理解某件事時，你們在一起就會更好地理解。
即使在這種情況下，了解重構是如何完成的也有助於執行重構。 也就是說，你不能一下子改變所有的東西，而是改變命名，然後改變位置，然後你可以突出某些部分，哦，但是這裡註釋不夠。
結論
儘管我的推理可能看起來很悲觀，但我對未來充滿希望，並真誠地希望我們（和您）一切順利。
接下來正在準備文章的第二部分。 在其中，我將討論我們如何嘗試使用敏捷開發實踐來改進我們的學習過程並使用基礎設施。
來源： www.habr.com