基礎架構即程式碼：如何使用 XP 克服問題

你好，哈布爾！ 之前，我抱怨過基礎設施即程式碼範式的生活，並且沒有提供任何解決當前情況的方法。 今天我回來告訴大家，有哪些方法和做法可以幫助你擺脫絕望的深淵，引導事態往正確的方向發展。

在上一篇文章中 “基礎設施即代碼：初識” 我分享了我對這個領域的印象，試圖反思這個領域的現狀，甚至建議所有開發人員都知道的標準實踐可以有所幫助。 看似對生活有很多抱怨，卻沒有提出擺脫現狀的出路。

我們是誰，我們在哪裡，我們有什麼問題

我們目前屬於 Sre Onboarding 團隊，該團隊由六名程式設計師和三名基礎設施工程師組成。 我們都在嘗試編寫基礎設施即程式碼（IaC）。 我們這樣做是因為我們基本上知道如何編寫程式碼並且擁有「高於平均水平」的開發人員的歷史。

• 我們有一系列的優勢：一定的背景、實踐知識、編寫程式碼的能力、學習新事物的願望。
• 還有一個下垂的部分，這也是一個缺點：缺乏對基礎設施硬體的了解。

我們在 IaC 中使用的技術堆疊。

• 用於創建資源的 Terraform。
• 用於組裝影像的打包器。 這些是 Windows、CentOS 7 映像。
• Jsonnet 在 Drone.io 中進行強大的構建，以及產生 Packer json 和我們的 terraform 模組。
• Azure上。
• 準備圖像時 Ansible。
• 用於輔助服務和配置腳本的 Python。
• 所有這一切都在 VSCode 中進行，並在團隊成員之間共享插件。

我的結論 上一篇文章 是這樣的：我試圖灌輸（首先是我自己）樂觀主義，我想說我們將嘗試我們已知的方法和實踐，以應對該領域存在的困難和複雜性。

我們目前正在努力解決以下 IaC 問題：

• 程式碼開發工具和手段不完善。
• 部署緩慢。 基礎設施是現實世界的一部分，而且速度可能很慢。
• 缺乏方法和實踐。
• 我們是新人，了解不多。

極限編程 (XP) 來救援

所有開發人員都熟悉極限編程 (XP) 及其背後的實踐。 我們中的許多人都採用過這種方法，並且取得了成功。 那麼為什麼不使用其中規定的原則和實踐來克服基礎設施挑戰呢？ 我們決定採用這種方法，看看會發生什麼。

檢查 XP 方法對您所在行業的適用性以下描述了 XP 非常適合的環境，以及它與我們的關係：

1. 動態變化的軟體需求。 我們很清楚最終目標是什麼。 但細節可能有所不同。 我們自己決定需要在哪裡搭計程車，因此要求會定期變化（主要是我們自己）。 如果我們以 SRE 團隊為例，它本身負責自動化，並且本身限制了需求和工作範圍，那麼這一點就很合適。

2、採用新技術的固定時間項目所帶來的風險。 當我們使用一些我們不知道的東西時，可能會遇到風險。 這就是我們 100% 的情況。 我們的整個專案使用了我們並不完全熟悉的技術。 一般來說，這是一個持續存在的問題，因為...... 基礎設施領域不斷湧現許多新技術。

3,4. 規模較小、位於同一地點的擴展開發團隊。 您使用的自動化技術允許進行單元和功能測試。 這兩點不太適合我們。 首先我們不是一個協調的團隊，其次我們有九個人，也算是一個大團隊了。 不過，根據「大型」團隊的一些定義，很多人都是 14 人以上。

讓我們看看一些 XP 實踐以及它們如何影響反饋的速度和品質。

XP回饋環原理

在我看來，回饋就是問題的答案，我做的事情正確嗎？我們會去那裡嗎？ XP對此有一個神聖的方案：時間回饋循環。 有趣的是，我們的位置越低，我們就能越快讓作業系統回答必要的問題。

這是一個相當有趣的討論主題，在我們的IT產業中，可以快速獲得一個作業系統。 想像一下，一個專案做了六個月才發現一開始就有錯誤，這是多麼痛苦的事。 這種情況發生在複雜系統的設計和任何建置中。

就我們的 IaC 而言，回饋對我們很有幫助。 我馬上對上圖做一個小調整：發布計畫沒有每個月的周期，而是一天發生幾次。 我們將更詳細地了解一些與此作業系統週期相關的實踐。

重要提示：回饋可以解決上述所有問題。 結合XP實踐，可以將你從絕望的深淵中拉出來。

如何將自己從絕望的深淵中拉出來：三個練習

測試

XP 回饋循環中兩次提到了測試。 不只是這樣。 它們對於整個極限編程技術極為重要。

假設您進行了單元測試和驗收測試。 有些會在幾分鐘內給你回饋，有些會在幾天內給你回饋，所以他們需要更長的時間來寫，並且很少被審查。

有一個經典的測試金字塔，它表明應該有更多的測試。

這個框架如何應用於我們的 IaC 專案？ 事實上……一點也不。

• 單元測試雖然應該很多，但也不能太多。 或者他們正在非常間接地測試某些東西。 事實上，我們可以說我們根本不寫它們。 但以下是我們能夠進行的此類測試的一些應用：
  1. 測試 jsonnet 程式碼。 例如，這是我們的無人機組裝流水線，相當複雜。 jsonnet 程式碼已被測試很好地覆蓋。
     我們用這個 Jsonnet 的單元測試框架.
  2. 測試資源啟動時執行的腳本。 腳本是用 Python 編寫的，因此可以對其進行測試。
• 有可能在測試中檢查配置，但我們不會這樣做。 也可以透過組態檢查資源配置規則 特弗林特。 然而，那裡的檢查對於 terraform 來說太基本了，但許多測試腳本是為 AWS 編寫的。 而我們使用的是 Azure，所以這又不適用。
• 組件整合測試：這取決於您如何對它們進行分類以及將它們放在哪裡。 但它們基本上有效。

  這就是整合測試的樣子。

  
  
  這是在 Drone CI 中建立圖像時的範例。 要到達它們，您必須等待 30 分鐘，讓 Packer 映像形成，然後再等待 15 分鐘，讓它們通過。 但它們確實存在！

  影像驗證演算法

  1. Packer首先必須準備好鏡像。
  2. 在測試旁邊有一個具有本地狀態的 terraform，我們用它來部署此映像。
  3. 展開時，附近有一個小模組，可以更輕鬆地處理影像。
  4. 從映像部署 VM 後，即可開始檢查。 基本上，檢查是用汽車進行的。 它檢查腳本在啟動時如何工作以及守護進程如何運作。 為此，我們透過 ssh 或 winrm 登入新啟動的電腦並檢查配置狀態或服務是否已啟動。

• 這種情況與 terraform 模組中的整合測試類似。 這是一個簡短的表格，解釋了此類測試的特徵。

  
  
  管道回饋時間約 40 分鐘。 一切都會發生很久。 它可以用於回歸，但對於新的開發來說通常是不切實際的。 如果你對此準備得非常非常充分，準備好運行腳本，那麼你可以將其減少到 10 分鐘。 但這些仍然不是 5 秒內完成 100 條的單元測試。

組裝映像或 terraform 模組時缺乏單元測試，鼓勵將工作轉移到可以簡單地透過 REST 運行的單獨服務或 Python 腳本。

例如，我們需要確保當虛擬機器啟動時，它會在服務中註冊自己 規模FT，當虛擬機器被銷毀時，它會自行刪除。

由於我們將 ScaleFT 作為一項服務，因此我們被迫透過 API 來使用它。 那裡寫著一個包裝紙，你可以拉出它並說：“進去刪除這個那個。” 它存儲所有必要的設定和存取。

我們已經可以為此編寫正常的測試，因為它與普通軟體沒有什麼不同：某種 apiha 被模擬，你拉它，看看會發生什麼。

測試結果：單元測試應該在一分鐘內給出作業系統，但沒有給出。 金字塔高層的測試類型是有效的，但只能涵蓋部分問題。

結對編程

測試當然是好的。 你可以寫很多，它們可以有不同的類型。 他們將按照自己的水平工作並向我們提供反饋。 但糟糕的單元測試（提供最快的作業系統）的問題仍然存在。 同時，我仍然想要一個快速且易於使用的作業系統。 更不用說最終解決方案的品質了。 幸運的是，有些技術可以提供比單元測試更快的回饋。 這就是結對程式設計。

編寫程式碼時，您希望盡快獲得有關其品質的回饋。 是的，你可以在功能分支中編寫所有內容（以免破壞任何人的任何東西），在 Github 中發出拉取請求，將其分配給意見有分量的人，然後等待回應。

但你可以等很久。 人們都很忙，即使有答案，也可能不是最高品質的。 假設答案立即出現，審稿人立即理解了整個想法，但答案仍然遲到，在事實之後。 我希望早一點。 這就是結對程式設計的目標——在撰寫本文時立即進行。

以下是結對程式設計風格及其在 IaC 工作中的適用性：

1.經典，經驗+經驗，定時輪班。 兩個角色－駕駛員和領航員。 兩個人。 他們使用相同的代碼，並在一定的預定時間後切換角色。

讓我們考慮一下我們的問題與風格的兼容性：

• 問題：程式碼開發的工具和工具不完善。
  負面影響：開發需要更長的時間，我們放慢速度，失去工作的節奏/節奏。
  我們如何戰鬥：我們使用不同的工具、通用的 IDE，也學習捷徑。
• 問題：部署緩慢。
  負面影響：增加創建工作代碼所需的時間。 我們在等待的過程中感到無聊，等待的過程中我們伸出雙手去做其他的事情。
  我們如何戰鬥：我們沒有克服它。
• 問題：缺乏方法和實踐。
  負面影響：不知道如何做好、如何做好。 延長回饋的接收時間。
  我們如何戰鬥：在工作中相互交換意見和做法幾乎可以解決問題。

在 IaC 中使用這種風格的主要問題是工作節奏不均勻。 在傳統的軟體開發中，你的動作非常統一。 你可以花10分鐘寫N。花2分鐘寫15N，3分鐘寫30N。 在這裡你可以花五分鐘寫下N，然後再花XNUMX分鐘寫下N的十分之一。在這裡你什麼都不知道，你被卡住了，愚蠢的。 調查需要時間並且會分散程式設計本身的注意力。

結論：它的純粹形式不適合我們。

2.乒乓球。 這種方法涉及一個人編寫測試，另一個人執行測試。 考慮到單元測試一切都很複雜，而且你必須編寫一個需要很長時間編程的整合測試，所有乒乓球的輕鬆感都消失了。

我可以說，我們嘗試將設計測試腳本和實現程式碼的職責分開。 劇本是由一位參與者提出的，這部分工作是他負責的，他有最終決定權。 另一個負責實施。 效果很好。 採用這種方法的腳本品質會提高。

結論：唉，工作節奏不允許在 IaC 中使用乒乓球作為結對編程練習。

3.風格強烈。 練習困難。 這個想法是，一個參與者成為指令導航者，第二個參與者扮演執行驅動者的角色。 在這種情況下，決策權完全屬於導航員。 驅動程式僅列印並且可以透過單字影響正在發生的事情。 角色很長一段時間不會改變。

適合學習，但需要很強的軟技能。 這就是我們動搖的地方。 這項技術很困難。 這甚至與基礎設施無關。

結論：它有可能被使用，我們不會放棄嘗試。

4. 圍攻、蜂擁而至以及所有已知但未列出的風格 我們不考慮它，因為我們還沒有嘗試過，也不可能在我們的工作中談論它。

使用結對程式設計的一般結果：

• 我們的工作節奏參差不齊，這令人困惑。
• 我們遇到了軟技能不夠好的問題。 而這個學科領域無助於克服我們的這些缺點。
• 長時間的測驗和工具問題使得配對開發變得困難。

5. 儘管如此，還是取得了成功。 我們提出了自己的方法「收斂-發散」。 我將簡要描述它是如何工作的。

我們有幾天（不到一周）的永久合作夥伴。 我們一起做一項任務。 我們坐在一起一會兒：一個人寫作，另一個人坐下來觀看支援團隊的工作。 然後我們分散一段時間，各自做一些獨立的事情，然後我們又聚在一起，很快地同步，一起做一些事情，然後又分散。

規劃與溝通

解決作業系統問題的最後一個實踐區塊是任務本身的工作組織。 這也包括結對工作以外的經驗交流。 我們來看看三個實踐：

1. 透過目標樹實現目標。 我們透過一棵無限延伸到未來的樹來組織專案的整體管理。 從技術上講，追蹤是在 Miro 中完成的。 有一個任務 - 這是一個中間目標。 從中可以得出較小的目標或任務組。 任務本身來自於他們。 所有任務均在此板上建立和維護。

該方案還提供回饋，當我們在集會上同步時，每天都會發生一次。 在每個人面前有一個共同的計劃，但結構化且完全開放，可以讓每個人都知道正在發生的事情以及我們取得的進展。

視覺視覺任務的優點：

• 因果關係。 每項任務都會導致一些全局目標。 任務被分成更小的目標。 基礎設施領域本身就具有很強的技術性。 並不總是立即清楚具體的影響，例如，編寫有關遷移到另一個 nginx 的操作手冊對業務有何影響。 將目標卡放在附近會更清晰。
  
  因果關係是問題的重要屬性。 它直接回答了這個問題：“我做的事情正確嗎？”
• 並行性。 我們有九個人，從身體上來說根本不可能讓每個人都完成一項任務。 一個領域的任務也可能不總是足夠的。 我們被迫在小型工作組之間並行工作。 同時，各小組會在自己的任務上停留一段時間，他們可以得到其他人的加強。 有時人們會脫離這個工作小組。 有人去度假，有人為 DevOps 會議做報告，有人寫一篇關於 Habr 的文章。 了解哪些目標和任務可以並行完成變得非常重要。

2. 更換早會主持人。 在站立會議中，我們遇到了這個問題——人們同時執行許多任務。 有時，任務之間的聯繫鬆散，無法了解誰在做什麼。 另一位團隊成員的意見非常重要。 這是可以改變問題解決過程的額外資訊。 當然，通常有人陪伴您，但建議和提示總是有用的。

為了改善這種情況，我們採用了「改變領先站立」技術。 現在它們按照一定的列表輪換，這就有了它的效果。 當輪到你時，你必須深入了解正在發生的事情，以便召開一次好的 Scrum 會議。

3.內部演示。 透過結對程式設計來幫助解決問題、問題樹視覺化以及在早上的 scrum 會議上提供幫助都是不錯的，但並不理想。 作為夫妻，你們只受你們知識的限制。 任務樹有助於全局了解誰在做什麼。 上午會議上的演講者和同事不會深入探討你的問題。 他們肯定可能會錯過一些東西。

解決方案是透過向彼此展示所做的工作然後進行討論來找到的。 我們每週會面一次，每次一小時，展示我們過去一周完成的任務的解決方案的詳細資訊。

在演示過程中，需要揭示任務的細節，並一定要示範其操作。

該報告可以使用清單進行。1.進入上下文。 任務從何而來，為什麼有必要？

2、之前這個問題是怎麼解決的？ 例如，需要大量點擊滑鼠，或根本無法執行任何操作。

3.我們如何改進它。 例如：“看，現在有 scriptosik，這是自述文件。”

4. 展示它是如何運作的。 建議直接實現一些使用者場景。 我想要 X，我做 Y，我看到 Y（或 Z）。 例如，我部署 NGINX，檢查 url，然後得到 200 OK。 如果動作較長，請提前準備好，以便稍後展示。 如果它很脆弱，建議在演示前一小時不要對其進行太多破壞。

5. 解釋問題是如何成功解決的，還有哪些困難，哪些尚未完成，未來可以改進哪些。 像現在有CLI，那麼CI就會完全自動化。

建議每位發言者的發言時間控制在 5 至 10 分鐘。 如果您的演講顯然很重要且需要更長的時間，請提前在 sre-takeover 頻道中進行協調。

面對面的部分之後總是會在帖子中進行討論。 這是我們需要的任務回饋出現的地方。

因此，進行了一項調查以確定正在發生的事情的有用性。 這是對演講本質和任務重要性的回饋。

長結論與下一步

文章的基調似乎有些悲觀。 這是錯誤的。 兩個較低層次的回饋，即測試和結對編程，起作用。 不像傳統開發那樣完美，但也有正面的效果。

目前形式的測試僅提供部分程式碼覆蓋率。 許多配置功能最終都未經測試。 他們在編寫程式碼時對實際工作的影響很小。 然而，整合測試有一定的作用，它們可以讓你無所畏懼地進行重構。 這是一項偉大的成就。 此外，隨著重點轉向高階語言（我們有 python、go）開發，問題就消失了。 而且您不需要對「黏合劑」進行大量檢查；一般整合檢查就足夠了。

結對工作更多取決於特定的人。 有任務因素和我們的軟技能。 對某些人來說，效果很好，而對其他人來說，效果更糟。 這肯定有好處。 顯然，即使沒有充分遵守結對工作的規則，一起執行任務這一事實也會對結果的品質產生積極的影響。 就我個人而言，我發現結對工作更容易、更愉快。

影響作業系統的更高層級的方法 - 規劃和處理任務精確地產生效果：高品質的知識交換和提高的開發品質。

一行簡短的結論

• HR從業人員在IaC中工作，但效率較低。
• 加強有效的措施。
• 提出你自己的補償機制和做法。

來源： www.habr.com