Honeycomb工具能夠對生產系統進行內省和探查。該團隊長期以來都是基礎設施即代碼（infrastructure-as-code，IaC）的先鋒，目前他們使用HashiCorp Terraform進行配置即代碼（configuration-as-code）管理。最近，他們推動將二進制發佈過程的嚴格性引入到基礎設施配置發佈之中。
InfoQ有幸採訪到了該團隊，詢問了他們轉向集中式push-on-green（即自動化測試通過之後自動部署——譯者注）部署的情況，並瞭解了這種做法如何降低可靠性風險以及以前有多麼痛苦。
InfoQ：在最初的文章中你們曾建議，通過不斷地將基礎設施部署爲代碼，已經消除了運維的風險。付出這樣的代價這麼做，值得嗎？
Honeycomb團隊：是的，這種方式能夠讓我們更快地行動，從穩定狀態的每週兩到四次Terraform部署加快到每天兩次以上的部署，我們還用到了一些新的AWS和Terraform特性。
基礎設施工程師擔心現在我們可能會面臨另一方面的風險，儘管我們比以前行動更加快速，但是相對於做出的變更，風險增長的比例要更低。他的擔心在於我們已經對大規模的Terraform變更習以爲常，以至於對它們的審查要比理應的情況少得多……但是，我們也反駁說，這些變更可能已經在人們的Terraform客戶端執行過了，而沒有運行線上運行的審查。
InfoQ：這幫助你們實現基礎設施成本節省了嗎？
Honeycomb：與其他SaaS分析初創公司類似，我們的雲賬單佔了總支出的很大一部分。作爲這種轉變的一部分，升級Terraform實例意味着我們可以使用2018年11月發佈的AWS特性 ，該特性允許將我們已經使用的自動伸縮組與峯值負載的Spot請求結合起來，實現自動替換/重調度實例。
InfoQ：我注意到你們使用了HashiCorp的Terraform CI工具。你們建議其他人也使用這種方式嗎？
Honeycomb：是的，尤其要考慮到Terraform Cloud要比我們之前使用的工具便宜得多。我們現有的CI工具沒有管理Terraform狀態，同時，我們也不希望讓它訪問可變的生產環境。藉助易於理解的Terraform的開箱即用功能，再加上購買了HashiCorp的支持和bug優先解決的特權，這些保證了我們的勝利。在此之前，我想說的是，如果沒有Terraform Enterprise的收費服務，爲Terraform實現合適的CI/CD是很有挑戰性的。我們的報價是幾萬美元，這對我們來說有點貴，因爲我們公司有四個人已經接觸過Terraform。
InfoQ：你們下一步作何打算呢？
Honeycomb：我們還有很多的工作要做，以支撐Honeycomb的特性和正在進行中的操作，以及明年的規模擴張。另外，我還知道，在我們的2020願望清單中，包括中心化Chef管理，這是因爲，雖然我們使用Terraform將AWS基礎設施作爲代碼來處理，但我們還使用Chef引導單個節點，這個過程沒有我們希望的那麼平滑。
InfoQ：你們有計劃降低基礎設施工程師主管所提到的更高的風險嗎，或者你們是否認爲這種風險是可接受的？
Honeycomb：我們想要編寫更多的“策略即代碼（policy as code）Sentinel腳本，加強整體路徑的可用性和抗成本風險的能力。目前，這件事還排不到最重要的前五件事中，因爲基礎設施應該服務於業務需求，在列車軌道沒有達到那麼遠之前，設想那麼遠沒有太大的意義。
InfoQ：在將你們的基礎設施即代碼引入CI/CD管道時，面臨的最大挑戰是什麼，其他人可以在你們的經驗中學到什麼？
Honeycomb：這個過程挺簡單，也沒有太多的痛苦。將
backend s3替換爲backend remote {}是非常簡單的，但是顯然，我們必須讓大家將使用Terraform Cloud賬號作爲初始工作流的一部分，而不是在本地自己的機器上運行工作流。最痛苦的可能是對Terraform的升級，這個升級並不是強制性的但仍然會有一定的用處。在此之前，我們使用的是0.10版本上，遷移到Terraform 0.12引入了語言更改，但是使用它們的遷移工具，也會有很大的代碼差異。
原文鏈接：
Benefits and Challenges of Bringing Infrastructure as Code into a CD pipeline: Honeycomb Q&A