導讀：
由於數字化轉型，技術已經嵌入到公司所依賴的每一個業務流程和實踐中。是時候接受DevOps的建議，重新思考業務與IT的劃分了。
每一年都會有人預言“某某已死”。SaaS風火熱炒的那幾年，有人說，SaaS已死，但似乎並沒有。那麼，在如今數字化轉型盛行的當下，又會有什麼被認為“已死”的呢？
近期，國外一家大型全球IT服務公司的高級管理和IT顧問 Bob Lewis 就認為在當下IT即業務的做法已死，取而代之的則是能幫助企業更好、更高效運作的 BusOps。為什麼這樣說？BusOps 是什麼？它又能帶來哪些好處？帶著這些問題，我們一起來學習一下。
要在數字時代取得成功，必須重新定義IT項目，以交付業務更改，而不僅僅是交付信息技術。但在這背後隱藏著一個更根本的轉變：IT操作應該嵌入到業務操作中，就像IT應用程序應該嵌入到實現業務的更改中一樣。
在許多組織中，IT的運行方式就好像它是一個獨立的業務（為內部客戶提供服務）一樣。不幸的是，這樣做會給IT部門的應用程序和操作方面帶來障礙。
部分原因是IT即業務（IT-as-a-business）的比喻導致了一種奇怪的實踐：IT操作與其內部客戶之間的協商服務水平協議(SLA)。
在實際的IT外包術語中，SLA是一個由兩部分組成的度量標準。第一部分是最低可接受的服務標準。第二部分列舉了外包商達到這種服務水平的頻率。
定義度量的第一部分通常很簡單。然而，第二部分則更有趣。例如，SLA可能將一次停機的最大可接受標準定義為恢復服務之前的一個小時或更少。度量的後半部分可能指定外包商必須達到99%的服務水平。
如果外包商未能滿足其SLA，那麼，合同將指定補救措施，這也是一個需要協商的問題。如果內部IT應該表現得像一個獨立的業務，那麼還有什麼比它與內部客戶協商SLA更合乎邏輯的呢？
事實證明，答案是：許多替代方案更符合邏輯。
創新性的挑戰
鑑於很多原因，內部SLA從來都不是一個好主意。首先，它們強化了錯誤的IT/業務關係模型——將IT即業務的觀念銷售給內部客戶。
第二是差異的後果：如果IT未能達成協商的SLA，它的“客戶”會怎麼做？沒有非性能懲罰的SLA是無效的，而帶有非性能懲罰的SLA則導致組織間的不信任。
第三，你得到了你所衡量的東西。在大多數情況下，這意味著IT衡量的是服務水平，但缺乏任何衡量創新的標準。
運行良好的IT操作不斷地在可靠性和創新之間取得平衡。但創新需要風險。因為SLA回顧過去，它們只報告創新的負面後果，而不是創新的好處。
我們以固態硬盤的初始轉換為例。它們的短期可靠性和長期耐用性，對於早期用戶來說，還沒有得到證實。然而，他們為那些嘗試使用它們的組織帶來了豐厚的回報，使它們在分析和大數據方面獲得了性能優勢。
所以，保持領先需要一些冒險和前瞻性思維，而SLA天生就不鼓勵這樣做。
反對SLA的案例
IT通常承擔兩種類型的職責：技術服務和支持服務。
技術服務的SLA涉及系統可用性和性能等事項。問題是，以前，高可用性架構是一種選擇。而現在他們則不是。
既然如此，IT是否應該繼續追蹤技術服務的服務水平呢？答案是肯定的，因為如果它做得不是很好，但只是作為一種工追蹤工具，那麼，這將是浪費時間。
因為雖然某個設備可能會出現故障，但這已不再是系統不能正常工作的原因。這就是高可用性架構的本質。如果一個系統曾經不可用，那應該是一個非常罕見的事件，因此，保持統計跟蹤是浪費時間。
不會浪費時間是根本原因分析，因為每次停機都意味著您的高可用性架構有一個需要修復的設計缺陷。同樣不浪費時間的是分析已報告的事件，以便在新出現的問題對整個業務造成影響之前及早發現並解決它們。
從另一方面來看，支持服務是IT人員幫助業務操作人員的工作。支持服務SLA涉及的問題包括：在幫助臺響應他們的請求之前，某人應該預期等待多長時間，以及在問題解決之前，他們應該預期等待多長時間。
在任何一天，對於任何給定的呼叫，幫助臺的響應要麼比服務級別指定的更快要麼更慢。當幫助臺人員的容量超過呼叫量時，它的響應速度更快。相應的，當呼叫量超過服務檯人員的能力時，它的響應速度會變慢。
因此，SLA與性能無關。它只是一根棍子，對敲打幫助臺經理很有用，除此之外別無它用。
唯一真正重要的是預算季節，此時幫助臺的服務水平可以用來證明僱傭更多員工的合理性。
公平地說，這不是一件小事。但是它證明了跟蹤服務性能而不是協商SLA的做法是正確的。
唯一重要的IT操作度量
對於大多數管理人員來說，成功會提高他們的知名度，從而獲得晉升、榮譽和更好的薪酬。而IT操作惟一可見的時候是出現問題的時候。
所有好的度量標準都是定性目標的數值表示。因此，最能反映其目標的IT操作度量是對其不可見性的度量。這個“不可見性指數”應該是一個複合度量，它包含應用程序可用性和性能、對幫助臺的調用數量(更少的調用意味著更多的不可見性)以及反映IT操作性能在其他領域的業務流程和實踐中成為瓶頸的頻率。
典型的IT組織被劃分為應用和操作、應用程序和運維，這些組織通常由於兩個主要原因而互不信任。首先，應用程序通過應用的更改獲得成功，但是每個應用更改都會增加運維可見性的風險。其次，應用程序需要運維來創建和維護開發和測試環境。所以，對於應用程序而言，這意味著運維是一個瓶頸。對於運維來說，這意味著要進行額外的工作，而且常常是計劃外的工作。
而此時DevOps便登場了。與大多數敏捷變體不同，在DevOps中，開發團隊包括一個或多個IT運維人員，他們在項目的時間表上協作處理IT運維職責，而不是通過運維請求隊列。
所有這一切都是在說，當兩個必須一起工作的團隊之間出現摩擦或不信任時，在每個團隊的起源下創建人員和流程的協作混合是一個有價值的解決方案。
數字化轉型和BusOps的到來
如今，對於大多數組織來說，數字化轉型是管理的主旋律。但又有哪一種管理潮流比數字化轉型更令人困惑和模糊呢？
在所有這些含糊不清的背後，是創造新功能的特定數字技術。企業可以利用它們來創造競爭優勢。或者，他們可以忽略它們，讓競爭對手獲得優勢。
在這些細節背後是核心的數字現實：信息技術不再是可選的。它深深地嵌入到每一個業務流程和實踐中，您的公司依靠它來進行日常業務。因此，從概念上講，IT操作只是整個業務操作中許多活動部分的一個集合，這使得IT操作與CIO一樣都是COO的職責範圍。
在此之前，作為一個實際的問題，我們應該考慮到，無論在哪裡，IT操作都應該保持完整。它的有效性(以及隨之而來的不可見性)取決於許多技術熟練的專家——成熟和發展良好的學科的實踐者——的持續合作。
而管理他們負責的過程和實踐反過來又依賴於瞭解他們內部的負責人。領導他們取決於管理者在處理他們的職責時能夠理解這些實踐者。
同樣值得注意的是，重組很少會修復任何東西。多數情況下，他們通過將以前不能很好地協同工作的團隊置於共同管理之下來消除障礙，這也意味著大多數重組會在曾經有共同管理但現在不再有共同管理的團隊之間製造障礙。
將IT操作移到組織結構圖中，以便IT部門能夠向COO報告，這與讓IT保持原樣的邏輯差不多。至於重組IT業務，將其拆分並在業務中分配職責則是行不通的。因為，畢竟技術人員一起解決共同的問題仍然有價值。
那麼，需要改變什麼呢？DevOps指出了方向。DevOps協作文化必須擴展到IT操作和其他業務操作之間的關係，就像希望更好地運行業務的業務經理和IT應用程序之間的關係一樣。
所以解放你的服務檯員工。由於沒有SLA將他們束縛在椅子上，您可以鼓勵他們起身去拜訪有問題的人，瞭解他們面臨的挑戰是什麼，併為他們如何利用現有技術提供見解。
同時，在IT部門的運維方面，敏捷性需要修正，這也是因為沒有所謂的IT項目：目前實踐的敏捷仍然關注於交付產品，而不是協作交付有策劃的業務變更。當您在修復敏捷時，可以通過添加DevOps維度(在業務更改項目團隊中包含系統和安全管理員)來進一步修復敏捷。如此一來，您的項目將有更好的結果，並且對業務領域中重要內容的額外瞭解將使IT操作在日常決策中更加有效。
最後，讓我們引入一個新術語使它更為正式吧。正如DevOps是IT應用程序和IT運維的融合和協作一樣，BusOps是IT操作和業務操作的融合和協作。
根據孫子兵法的說法，戰爭永遠都是為了人心。而新事物佔取人心的方式通常從創造新詞彙開始。通過添加新的詞彙，其結果可能會達到意料之外的效果。
閱讀更多 人稱T客 的文章
