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

導(dǎo)讀：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

運(yùn)行良好的IT操作不斷地在可靠性和創(chuàng)新之間取得平衡。但創(chuàng)新需要風(fēng)險(xiǎn)。因?yàn)镾LA回顧過去，它們只報(bào)告創(chuàng)新的負(fù)面后果，而不是創(chuàng)新的好處。

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

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

反對(duì)SLA的案例

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

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

既然如此，IT是否應(yīng)該繼續(xù)追蹤技術(shù)服務(wù)的服務(wù)水平呢？答案是肯定的，因?yàn)槿绻龅貌皇呛芎茫皇亲鳛橐环N工追蹤工具，那么，這將是浪費(fèi)時(shí)間。

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

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

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

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

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

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

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

唯一重要的IT操作度量

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

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

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

而此時(shí)DevOps便登場了。與大多數(shù)敏捷變體不同，在DevOps中，開發(fā)團(tuán)隊(duì)包括一個(gè)或多個(gè)IT運(yùn)維人員，他們?cè)陧?xiàng)目的時(shí)間表上協(xié)作處理IT運(yùn)維職責(zé)，而不是通過運(yùn)維請(qǐng)求隊(duì)列。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

生成海報(bào)

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