IaaB（IT即業(yè)務(wù)）已死，BusOps 接續(xù)

導(dǎo)讀：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

反對SLA的案例

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

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

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

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

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

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

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

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

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

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

唯一重要的IT操作度量

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

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

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

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

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

數(shù)字化轉(zhuǎn)型和BusOps的到來

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

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

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

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

而管理他們負責的過程和實踐反過來又依賴于了解他們內(nèi)部的負責人。領(lǐng)導(dǎo)他們?nèi)Q于管理者在處理他們的職責時能夠理解這些實踐者。

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

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

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

所以解放你的服務(wù)臺員工。由于沒有SLA將他們束縛在椅子上，您可以鼓勵他們起身去拜訪有問題的人，了解他們面臨的挑戰(zhàn)是什么，并為他們?nèi)绾卫矛F(xiàn)有技術(shù)提供見解。

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

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

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

生成海報

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