內容來源：2017年6月10日，易維科技聯合創始人在任發科“DevOps&SRE 超越傳統運維之道”進行《如何打造易用的DevOps工具鏈》演講分享。IT 大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：2237 | 4分鐘閱讀
摘要
隨著DevOps在企業內逐步推進，作為其最為重要一環的DevOps工具鏈會逐步構建起來——無論是基於開源的解決方案還是自研的系統。這個過程中，如何能夠打造出易用的DevOps工具鏈，從而真正的實現DevOps的目標：
1. 從持續交付的角度審視DevOps工具鏈的各環節所要達到的目標。
2. 定義DevOps工具鏈易用性的範圍和意義。
3. 結合DevOps工具鏈目標結合案例來探討如何實現易用性。
理念
我們覺得開發和運維需要交付到一個執行的系統。如果執行的系統承載的是執行的業務的話，系統是不應該當機的。在這基礎上，我們認為“誰構建，誰運維”。區別於合作形式的，我們強調的是研發更多承擔運維的職責，研發去做大部分測試的工作，包括上線的部署、效能的監控以及容量的測試。運維人員可以更專業性地提供運維相關的工具。
理念->體系
從一開始的理念通過持續交付這樣現有的開源工具去打磨工具鏈條。
上圖這個簡單的架構圖是我們現在做得比較多的一個解決方案，做了一段時間後我們也在其中發現了一些問題，這些問題促使我們開始做自己的工具生態。
理念->體系->工具
在這基礎上，我們分析了很多工具類軟體是怎麼做的，並且也慢慢做了自己的工具鏈條。
在這過程中有一些問題不斷地被提及，我們需要重複地和產品、研發去溝通。
系統為什麼要這樣架構？軟體設計為什麼要選擇不完美的方案？同樣的問題為什麼要研發多種工具？為什麼屢試不爽的設計理念不起作用？
隱藏在這些問題背後的共性就是我們今天要討論的，怎樣打造一個易用的工具鏈。
最關鍵的是一個“易”字，它代表了兩個意思。第一個意思是簡易。也就是工具設計的架構本身要足夠簡單，這樣才容易擴充套件，相互之間容易配合。
第二個意思是易用。使用者在使用它的時候應該不造成過多的負擔，能快速地解決問題。
我們在DevOps落地和工具鏈研發過程中遇到的問題以及解決問題的所思所做，是我今天所要分享的內容。
簡易和易用為什麼這麼重要呢？
如果我們從產品的使用者體驗要素模型去看的話，在我們講到易用性的時候，大家都是知道的，因為作為使用者每天都在用不同的網際網路工具。
但是當我們談到2C和談到2B的時候，它們的易用性完全是在兩個層面。
2C強調的是要讓使用者儘量減少思考決策的東西，保持粘性。但是2B講的是直接影響到解決義務問題的效率。
業務問題和使用者問題能夠直接影響到簡易性，影響體現在架構、設計和互動。
部署流水線每次只生成一次二進位制包，測試或運維人員手工選擇需要的某個版本，將其部署到相應的環境中。操作人員應該可以看到所有構建版本和它們的狀態（通過的階段、包含的修改、提交註釋等），一切都是為了了儘快得到反饋。必須能夠看到每個環境中都部署了哪個版本，建立全程的追溯性。
技術人員是整個工具鏈的使用者。他們的特點就是自視甚高，但有些事標準極低——能用就行；能夠並行處理大量資訊，卻在一些事上特別較真。
經驗
經驗一
實現層面上分離，服務上整合。
關注點分離，各自獨立發展。有些系統有自己的複雜性，必要時可以通過檢視整合。
做系統的時候，我們只做一件事，並且把這件事做好。這樣帶來的好處是10個系統做10件事比一個系統做10件事好，因為它的複雜度低。
一站式系統大部分都是反人類的，只在真正需要時才給出一站式的檢視。
經驗二
設計上需要的關注點分離。
經驗三
在設計層面上，包括架構、軟體設計等，簡單性都要大於完美性。
假如更新輪值排班表，有四個方案。
方案1：追求人員資訊的準確性，不考慮歷史資訊。IPD⼈人員刪除、人員排班資訊調整，無歷史資訊。
方案2：無實時查詢，歷史資料跑批沉澱。沉澱階段內的資料仍然不一致。
方案3：修改即沉澱。
方案4：縮短沉澱週期，縮小資料錯誤範圍。
方案3和方案4哪一個更好？取決於具體的訴求到底是什麼，但是我們真正做的時候會選擇方案4。
經驗四
做工具鏈的時候一定要關注到高階的使用情況。基於DSL命令列的工具特點是擴充套件性更好，效率更高。
當提供命令列的時候一定要要防止來自指令碼的誘惑。如果指令碼的處理不是業務上原子的話，那麼指令碼不應該成為系統的組成部分。
經驗五
Just work。當你去使用一個電視或者遙控器的時候，只關注怎麼用它，並不關心它背後實現的邏輯。
如圖所示，從這個層面來看，通過這兩個介面的對比就會發現，上面介面最大的問題就是這個流程暴露了太多內部實現的細節，而下面的介面只關注重點的階段。
上面的介面還有一個巨大的問題在於測試是否通過和人工測試是屬於兩個抽象層面上的東西，在這個層面上不需要了解太多的細節，關鍵的階段是發生了什麼事。所以我們應該呈現出這樣一個介面。
經驗六
重在當下。如果是做部署的話，只關心最近一次發生的時間和情況，在歷史上的列表可以先隱藏起來。
經驗七
隱藏非關鍵資訊。配置完成在使用過程中，只有在出了問題的情況下才會關注細節。整個工具鏈的資訊非常豐富，所以只要出錯的時候再提醒，告知細節性的資訊。
經驗八
業務為線，不要堆砌功能。以專案為單元，檔案為基本的組成部分進行除錯、開發和編輯。
經驗九
突出使用，分離配置。當我們去使用一個工具鏈產品的時候，10%的時間是在配置工作流，一旦配置好，90%的時間都不需要再改動了。如果工具有這樣一個 “用得多，變得少”的特點，重點突出使用的部分，把配置的部分簡化一些，把功能隱藏起來，把配置慢慢地剝離開。
經驗十
簡化操作。整個2B工具鏈的研發都是解決效率的問題。DevOps裡有一個重大的問題，如果每一次的構建生成一個版本，而且之後都是基於這個版本來做測試上線的話，就需要check整個生命週期的狀態。
所以我們要建立一個全流程追蹤的體系。
DevOps雖然沒有大家想得那麼複雜，但是也沒有那麼簡單。
今天的分享就到這裡，謝謝大家！