如何打造易用的DevOps工具鏈

內容來源：2017年6月10日，易維科技聯合創始人在任發科「DevOps&SRE 超越傳統運維之道」進行《如何打造易用的DevOps工具鏈》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2237 | 4分鐘閱讀

嘉賓演講視頻地址： suo.im/4O9wKu

摘要

隨着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雖然沒有你們想得那麼複雜，可是也沒有那麼簡單。

今天的分享就到這裏，謝謝你們！