導讀：

由于數字化轉型，技術已經嵌入到公司所依賴的每一個業(yè)務流程和實踐中。是時候接受DevOps的建議，重新思考業(yè)務與IT的劃分了。

每一年都會有人預言“某某已死”。SaaS風火熱炒的那幾年，有人說，SaaS已死，但似乎并沒有。那么，在如今數字化轉型盛行的當下，又會有什么被認為“已死”的呢？

近期，國外一家大型全球IT服務公司的高級管理和IT顧問 Bob Lewis 就認為在當下IT即業(yè)務的做法已死，取而代之的則是能幫助企業(yè)更好、更高效運作的 BusOps。為什么這樣說？BusOps 是什么？它又能帶來哪些好處？帶著這些問題，我們一起來學習一下。

要在數字時代取得成功，必須重新定義IT項目，以交付業(yè)務更改，而不僅僅是交付信息技術。但在這背后隱藏著一個更根本的轉變：IT操作應該嵌入到業(yè)務操作中，就像IT應用程序應該嵌入到實現業(yè)務的更改中一樣。

在許多組織中，IT的運行方式就好像它是一個獨立的業(yè)務（為內部客戶提供服務）一樣。不幸的是，這樣做會給IT部門的應用程序和操作方面帶來障礙。

部分原因是IT即業(yè)務（IT-as-a-business）的比喻導致了一種奇怪的實踐：IT操作與其內部客戶之間的協(xié)商服務水平協(xié)議(SLA)。

在實際的IT外包術語中，SLA是一個由兩部分組成的度量標準。第一部分是最低可接受的服務標準。第二部分列舉了外包商達到這種服務水平的頻率。

定義度量的第一部分通常很簡單。然而，第二部分則更有趣。例如，SLA可能將一次停機的最大可接受標準定義為恢復服務之前的一個小時或更少。度量的后半部分可能指定外包商必須達到99%的服務水平。

如果外包商未能滿足其SLA，那么，合同將指定補救措施，這也是一個需要協(xié)商的問題。如果內部IT應該表現得像一個獨立的業(yè)務，那么還有什么比它與內部客戶協(xié)商SLA更合乎邏輯的呢？

事實證明，答案是：許多替代方案更符合邏輯。

創(chuàng)新性的挑戰(zhàn)

鑒于很多原因，內部SLA從來都不是一個好主意。首先，它們強化了錯誤的IT/業(yè)務關系模型——將IT即業(yè)務的觀念銷售給內部客戶。

第二是差異的后果：如果IT未能達成協(xié)商的SLA，它的“客戶”會怎么做？沒有非性能懲罰的SLA是無效的，而帶有非性能懲罰的SLA則導致組織間的不信任。

第三，你得到了你所衡量的東西。在大多數情況下，這意味著IT衡量的是服務水平，但缺乏任何衡量創(chuàng)新的標準。

運行良好的IT操作不斷地在可靠性和創(chuàng)新之間取得平衡。但創(chuàng)新需要風險。因為SLA回顧過去，它們只報告創(chuàng)新的負面后果，而不是創(chuàng)新的好處。

我們以固態(tài)硬盤的初始轉換為例。它們的短期可靠性和長期耐用性，對于早期用戶來說，還沒有得到證實。然而，他們?yōu)槟切﹪L試使用它們的組織帶來了豐厚的回報，使它們在分析和大數據方面獲得了性能優(yōu)勢。

所以，保持領先需要一些冒險和前瞻性思維，而SLA天生就不鼓勵這樣做。

反對SLA的案例

IT通常承擔兩種類型的職責：技術服務和支持服務。

技術服務的SLA涉及系統(tǒng)可用性和性能等事項。問題是，以前，高可用性架構是一種選擇。而現在他們則不是。

既然如此，IT是否應該繼續(xù)追蹤技術服務的服務水平呢？答案是肯定的，因為如果它做得不是很好，但只是作為一種工追蹤工具，那么，這將是浪費時間。

因為雖然某個設備可能會出現故障，但這已不再是系統(tǒng)不能正常工作的原因。這就是高可用性架構的本質。如果一個系統(tǒng)曾經不可用，那應該是一個非常罕見的事件，因此，保持統(tǒng)計跟蹤是浪費時間。

不會浪費時間是根本原因分析，因為每次停機都意味著您的高可用性架構有一個需要修復的設計缺陷。同樣不浪費時間的是分析已報告的事件，以便在新出現的問題對整個業(yè)務造成影響之前及早發(fā)現并解決它們。

從另一方面來看，支持服務是IT人員幫助業(yè)務操作人員的工作。支持服務SLA涉及的問題包括：在幫助臺響應他們的請求之前，某人應該預期等待多長時間，以及在問題解決之前，他們應該預期等待多長時間。

在任何一天，對于任何給定的呼叫，幫助臺的響應要么比服務級別指定的更快要么更慢。當幫助臺人員的容量超過呼叫量時，它的響應速度更快。相應的，當呼叫量超過服務臺人員的能力時，它的響應速度會變慢。

因此，SLA與性能無關。它只是一根棍子，對敲打幫助臺經理很有用，除此之外別無它用。

唯一真正重要的是預算季節(jié)，此時幫助臺的服務水平可以用來證明雇傭更多員工的合理性。

公平地說，這不是一件小事。但是它證明了跟蹤服務性能而不是協(xié)商SLA的做法是正確的。

唯一重要的IT操作度量

對于大多數管理人員來說，成功會提高他們的知名度，從而獲得晉升、榮譽和更好的薪酬。而IT操作惟一可見的時候是出現問題的時候。

所有好的度量標準都是定性目標的數值表示。因此，最能反映其目標的IT操作度量是對其不可見性的度量。這個“不可見性指數”應該是一個復合度量，它包含應用程序可用性和性能、對幫助臺的調用數量(更少的調用意味著更多的不可見性)以及反映IT操作性能在其他領域的業(yè)務流程和實踐中成為瓶頸的頻率。

典型的IT組織被劃分為應用和操作、應用程序和運維，這些組織通常由于兩個主要原因而互不信任。首先，應用程序通過應用的更改獲得成功，但是每個應用更改都會增加運維可見性的風險。其次，應用程序需要運維來創(chuàng)建和維護開發(fā)和測試環(huán)境。所以，對于應用程序而言，這意味著運維是一個瓶頸。對于運維來說，這意味著要進行額外的工作，而且常常是計劃外的工作。

而此時DevOps便登場了。與大多數敏捷變體不同，在DevOps中，開發(fā)團隊包括一個或多個IT運維人員，他們在項目的時間表上協(xié)作處理IT運維職責，而不是通過運維請求隊列。

所有這一切都是在說，當兩個必須一起工作的團隊之間出現摩擦或不信任時，在每個團隊的起源下創(chuàng)建人員和流程的協(xié)作混合是一個有價值的解決方案。

數字化轉型和BusOps的到來

如今，對于大多數組織來說，數字化轉型是管理的主旋律。但又有哪一種管理潮流比數字化轉型更令人困惑和模糊呢？

在所有這些含糊不清的背后，是創(chuàng)造新功能的特定數字技術。企業(yè)可以利用它們來創(chuàng)造競爭優(yōu)勢。或者，他們可以忽略它們，讓競爭對手獲得優(yōu)勢。

在這些細節(jié)背后是核心的數字現實：信息技術不再是可選的。它深深地嵌入到每一個業(yè)務流程和實踐中，您的公司依靠它來進行日常業(yè)務。因此，從概念上講，IT操作只是整個業(yè)務操作中許多活動部分的一個集合，這使得IT操作與CIO一樣都是COO的職責范圍。

在此之前，作為一個實際的問題，我們應該考慮到，無論在哪里，IT操作都應該保持完整。它的有效性(以及隨之而來的不可見性)取決于許多技術熟練的專家——成熟和發(fā)展良好的學科的實踐者——的持續(xù)合作。

而管理他們負責的過程和實踐反過來又依賴于了解他們內部的負責人。領導他們取決于管理者在處理他們的職責時能夠理解這些實踐者。

同樣值得注意的是，重組很少會修復任何東西。多數情況下，他們通過將以前不能很好地協(xié)同工作的團隊置于共同管理之下來消除障礙，這也意味著大多數重組會在曾經有共同管理但現在不再有共同管理的團隊之間制造障礙。

將IT操作移到組織結構圖中，以便IT部門能夠向COO報告，這與讓IT保持原樣的邏輯差不多。至于重組IT業(yè)務，將其拆分并在業(yè)務中分配職責則是行不通的。因為，畢竟技術人員一起解決共同的問題仍然有價值。

那么，需要改變什么呢？DevOps指出了方向。DevOps協(xié)作文化必須擴展到IT操作和其他業(yè)務操作之間的關系，就像希望更好地運行業(yè)務的業(yè)務經理和IT應用程序之間的關系一樣。

所以解放你的服務臺員工。由于沒有SLA將他們束縛在椅子上，您可以鼓勵他們起身去拜訪有問題的人，了解他們面臨的挑戰(zhàn)是什么，并為他們如何利用現有技術提供見解。

同時，在IT部門的運維方面，敏捷性需要修正，這也是因為沒有所謂的IT項目：目前實踐的敏捷仍然關注于交付產品，而不是協(xié)作交付有策劃的業(yè)務變更。當您在修復敏捷時，可以通過添加DevOps維度(在業(yè)務更改項目團隊中包含系統(tǒng)和安全管理員)來進一步修復敏捷。如此一來，您的項目將有更好的結果，并且對業(yè)務領域中重要內容的額外了解將使IT操作在日常決策中更加有效。

最后，讓我們引入一個新術語使它更為正式吧。正如DevOps是IT應用程序和IT運維的融合和協(xié)作一樣，BusOps是IT操作和業(yè)務操作的融合和協(xié)作。

根據孫子兵法的說法，戰(zhàn)爭永遠都是為了人心。而新事物占取人心的方式通常從創(chuàng)造新詞匯開始。通過添加新的詞匯，其結果可能會達到意料之外的效果。

生成海報

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。