中止爭論：ITIL v四、SRE和DevOps助力數字化轉型

中止爭論：ITIL v四、SRE和DevOps助力數字化轉型

許峯 譯 DevOps咖啡館
By Eveline Oehrlich, DevOps Institute
With Stephen Thorne, Google; Jayne Groll, DevOps Institute; Barclay Rae, Barclay Rae Consulting
譯者序：本文爲發表在DevOps Institute上的一篇文章。闡述了ITIL v四、SRE和DevOps的概念，類似性、差別已經組織應如何採用。對於差別部分，下期會引用另外一篇文章重點說明DevOps和ITIL之間的「不兼容」部分。

隨着最近ITIL 4的推出以及站點可靠性工程（SRE）的日益普及，關於這些最佳實踐的差別和類似性的爭論再次浮出水面。
這些框架或最佳作法中的每個均可以在整個IT價值鏈中增長價值。可是，面對數字世界中的服務管理，哪個是正確的？我認爲這不是要問的正確問題。IT主管應該中止爭論每一個方法的優勢。相反，他們應該集中精力於如何最好地發展高績效團隊，從而既能夠實現又能夠加快公司的數字化戰略。
這三種方法均具備一些共同的目標，包括：

• 引入協做和聯繫的文化
• 更加註重爲利益相關者快速、優質地創造價值
• 依靠自動化來減小由人形成的浪費和錯誤的能力
  這些框架或最佳實踐中的每個在增長整個IT價值鏈的價值方面都有其地位。在咱們2019 survey on Upskilling DevOps調查中，咱們瞭解到66％的人正在使用DevOps，47％的人將ITIL用做最佳實踐框架，以及10％的受訪者正在使用（SRE）實踐。另外，必須注意的是，咱們調查的許多團隊同時使用了這三種實踐。
  爲了提供更好的指引，這裏列出一些你須要知道的重要的事項。

  對ITIL 4，SRE和DevOps的高層級概述

  讓咱們對涉及的每一個框架分別闡述。

  ITIL 4是Axelos服務管理框架的最新發展。

  它引入了一個新的服務價值體系（Serive Value System)，該體系由最初開發的指導原則支持，如今隨 ITIL Practitioner Guidance出版而進一步發展。該框架使得其與DevOps和敏捷保持了一致性，這種方法保留了之前ITIL版本中的許多活動，但也承認DevOps的實踐，如價值流和持續交付。
  IT組織的全部成員都參與其中，他們一塊兒工做，經過IT所支持的服務促進價值創造。ITIL 4框架的關鍵組件圍繞着服務價值鏈（service value chain），旨在經過指導原則、治理、實踐和持續改進，根據需求或機會交付價值。
  利益相關者（客戶）經過需求或機會得到IT所支持的服務或產品。例如，「銷售人員花更多的時間與客戶互動」（利益相關者和機會），這得益於「一種遠程訪問服務，使銷售人員的筆記本電腦可以可靠地訪問公司銷售系統」（IT支持的有價值的服務）。重點關注服務功能和可用性、性能、安全性和可維護性等非功能性需求。

  站點可靠性工程（SRE） 是Google的服務管理方法，在同名書中有介紹 。

  它是用於在生產環境中大規模操做大型系統實踐集，其工程重點是運維。關鍵角色是SRE團隊，這是組織內部定義的工做角色。這些團隊成員是旨在執行運維功能的軟件工程師，而不是專門的運維團隊。
  生產系統及其用戶的可靠性由工程師提供支持，該工程師採用SRE站點原則來管理可用性、延遲、性能、效率、變動管理、監視、緊急響應和容量規劃。
  他們還能夠充當支持工程師，利用監控、容量和優化自動化工具。他們的重點是可用性、性能、安全性和可維護性的非功能性需求。

  DevOps是由多學科的開發和運維團隊組成的，以取代豎井式的開發和運維團隊。這些團隊與共享的、高效的實踐和工具一塊兒工做。

  DevOps團隊的關鍵成員是來自開發、運維和安全團隊的成員，他們在軟件生命週期中協同工做，以提升軟件開發和交付的質量和速度，從而提升客戶體驗；重點關注功能（應用程序特性等）的速度和質量，以及可用性、性能、安全性和可維護性等非功能需求。

  ITIL 4，SRE和DevOps的目的是什麼？

  ITIL 4強調服務質量和一致性，旨在經過從利益相關者的角度確保價值來提升利益相關者的滿意度。它的指導原則是支持組織爲其利益相關者的需求增長價值，而無論這些利益相關者是內部仍是外部客戶。它由服務生命週期中的34種實踐組成。有關更多詳細信息，請參見此處：https : //www.axelos.com/welcome-to-itil-4
  SRE強調系統和軟件的開發，以提升應用程序和服務的可靠性和性能。SRE還具備隨叫隨到的責任，這意味着它們須要隨時可用以提供服務或支持。有關更多詳細信息，請參見此處：https : //landing.google.com/sre/
  DevOps在軟件的開發和交付中集成了各類團隊和流程。DevOps的目的是提升質量，同時爲業務線管理足夠的速度的軟件和服務。該方法符合精益原則和敏捷。有關更多詳細信息，請參見此處：http : //www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/

  ITIL 4，SRE和DevOps有哪些類似之處？

  全部這三個方法都涉及變動管理的關鍵主題。ITIL 4聚焦在變動管理治理，而SRE使用「出錯預算」（error budget）1的概念，該概念容許SRE團隊進行變動，直到出錯預算「耗盡」 。DevOps團隊則以漸進的方式不斷地管理變動。
  1 譯註：業務或產品必須創建系統的可用性目標。一旦目標創建，用1減去該可用性目標就是咱們所說的出錯預算。
  全部這三種方法都鼓勵IT部門不一樣利益相關者之間以及與業務和/或產品全部者之間的協做。並且，全部方法都由大量自動化工具支持。一些工具聲稱專一於DevOps，另外一些工具則使關鍵流程自動化。因爲新進入者，技術（AI等）以及併購，自動化工具的格局很是複雜且不斷變化。集成是可能的，但也具備挑戰性。
  每種方法還着重於持續學習和實驗。這些方法的技能可能有所不一樣，但實際上你須要結合自動化和流程技能、軟技能、功能技能（functional skills）以及業務和技術技能 2。
  2 譯註：這些技能說明在2019 survey on Upskilling DevOps能夠找到對應的說明和調查結果

  ITIL 4，SRE和DevOps之間有什麼區別？

  這些方法之間的主要區別在於團隊拓撲結構（team topology），度量標準和自動化工具，以及其基本理念和對治理模型的遵循。ITIL 4不須要團隊成員組成一個團隊。它還具備許多能夠應用的子過程，而且在基礎級別、管理專業人士級別、戰略領導者級別和Master級別有各類認證。ITIL 4中的關鍵指標是服務水平目標的實現。該框架爲中型和大型組織的IT和企業服務管理流程的優化和改進提供了堅實的治理。
  SRE具備肯定的角色和明確的頭銜。正如其頭銜所指明的那樣，關鍵責任包括應用程序和服務的可靠性，重點放在服務級別目標和服務級別指標上。Google和其餘公司能夠提供學習和理解SRE的課程。DevOps研究所還將提供SRE Foundation認證。
  DevOps團隊的拓撲結構各不相同，可是最有效的DevOps團隊是一個具備相同目標和指標的團隊。DevOps的關鍵指標包括部署頻率和恢復時間。DevOps認證包含基礎級別和其餘各個級別 3。治理模型主要經過自組織完成。
  3 譯註：EXIN DevOps認證系列包含了DevOps Foundation、DevOps Professional和DevOps Master三個級別

  何時應該使用ITIL 4，SRE和DevOps？

  任什麼時候候均可以採用ITIL 4。不須要之前的ITIL版本。一個關鍵的觸發點是在設計、開發和構建階段建立產品和服務的總體方法。ITIL 4引入並管理通用的最佳實踐和語言，以提升客戶滿意度、服務可用性和財務效率。ITIL 4還涉及組織和人員、信息和技術、合做夥伴和供應商以及價值流和流程。
  能夠經過在DevOps團隊或服務管理團隊中引入SRE工程師做爲正式團隊成員來採用SRE。不採用ITIL 4或DevOps的組織也能夠採用SRE。SRE成員也是新系統設計中的涉衆，由於在設計新系統時會充分利用他們對當前服務、產品和/或環境的瞭解。採用SRE的關鍵是當可靠性是組織的既定目標，而且系統的用戶、複雜性和/或配置項的數量正在增加時。SRE團隊的一個主要好處是建立了自服務工具和自動化腳本，以解決應用程序和服務的可靠性和性能問題，從而消除了手工工做。
  DevOps的採用能夠隨時進行。關鍵的觸發點是對交付給利益相關者的軟件、產品和/或服務的速度和質量提升的要求。一個主要好處是，它帶來了文化變革，提升了軟件開發和交付方式的速度和質量。它創建在敏捷軟件開發和服務管理技術的基礎之上，並鼓勵使用自動化來減小熟練技能人員的手工工做，從而專一於更多的增值任務和活動。DevOps要求全部團隊成員都重視軟件的可靠性、可維護性和可運維性。

  分析：

  軟件產品的開發和管理須要敏捷技術，重點是經過減小浪費的方式共同創造價值。這三種方法能夠共存，以使團隊保持一致，知足利益相關者的需求，並改進交付的價值。不管您選擇哪一種方法（或其組合），只要專一於：1）一個共同的願景和目標，2）注入和管理關懷文化（a culture of care）3）制定決策並使決策可見4）在開始以前定義指標和度量，持續向利益相關者證實你所作努力的價值，由於數字化轉型的價值不是在整個組織中能夠當即實現的。資深的公司應從適合本身需求的最佳實踐和方法入手，從小作起，而後學習、積累專業知識並擴大規模。