Boomi公司全球企業營銷主管Myles Suer表示，在他在2005年入職Peregrine Systems公司時，令他驚訝的是， Peregrine Service Manager的嵌入式數據庫是非關系的數據庫。Peregrine公司成立于1981年，比IBM將DB2推向市場還要早幾年。1989年，隨著ITSM的引入，英國政府的ITSM和ITSM的許多概念得到了明確的更新。IT基礎設施庫(ITIL)本身已經進行了一些更新。例如，Suer是ITIL第3版的審閱者。去年剛剛推出的版本4旨在使ITSM更容易與DevOps、敏捷和精益工作方法集成。問題是ITSM要從哪里著手?這是Suer提出的問題。

 

公共云使用和DevOps如何改變ITSM?

 

•首席信息官Rick Osterberg認為：“部署ITSM的最大好處就是使所有人都使用一種通用語言。在云計算/DevOps環境中，仍然需要每個人都了解P1事件和P4服務請求之間的區別。”

 

•首席信息官Joanna Young對此表示認同，并建議說，“ITSM的基本要素仍然相關。我認為它們是很好的指導和基礎。如果我們想談論ITSM系統的實現。將ITSM構建到交付過程中可以鼓勵/推動關于持續運營支持的對話。”

 

•首席信息官Carrie Shumaker認同Young的觀點。她指出，“理解所有組件、依賴關系仍然至關重要。此外，對于重大事件，制定流程和進行溝通也是至關重要的。最后，變化仍在發生，而且仍會令人興奮。”

 

•首席信息官David Seidl說，“人們在ITSM的工作地點以及如何執行ITSM的細節可能會改變，但我認為核心概念仍然存在。用戶可能需要為DevOps進行敏捷所需的相同類型的更改，而當進行另一項更改時，將需要再次進行更改。假設用戶所做的一切都使用DevOps，但通常情況并非如此。與其相反，在很多時候是在像ITIL這樣的組織或其他混合/組件化模型中將DevOps作為容器。”

 

DevOps改變了ITSM的面貌

 

•Seidl聲稱，“DevOps可以改變ITSM的面貌。盡管ITSM的票務方面可能仍然存在，但它提供的過程以及部署能力的方式和位置將具有更輕的治理結構。”

 

•首席信息官Jason James說，“我們已經從服務器擴展到虛擬機擴展，現在又轉向了云蔓延。當令人困惑的賬單來自供應商時，ITSM可以有效地用于配合部門的請求和批準，以幫助了解云計算資源的使用。ITSM可以幫助用戶進行內部審核。”

 

•首席信息官Isaac Sacolick對此持有不同的觀點。他認為，“服務臺主要是處理最終用戶的計算。但是，隨著數字化轉型使技術/數據業務變得至關重要;服務臺的重要性只會增加。在冠狀病毒疫情發生之后，ITSM就變得至關重要。”話雖如此，Sacolick建議變更管理現在必須成為轉型管理的一部分。此外，配置管理數據庫(CMDB)一直混亂不堪，現在考慮到云計算彈性計算、無服務器和SaaS時，這幾乎站不住腳。考慮到這一點，Sacolick說：“ITSM應該為用戶提供支持，為應用提供幫助，并彌補實施/選擇不佳的技術。”

 

•Splunk公司首席信息官Andi Mann對此表示：“DevOps通過使用數據和人員來解決問題，從而解決了問題。如今，服務臺已經成為記錄系統。”

 

盡管如此，Forrester公司的ITSM/DevOps分析師Charlie Betz建議：

 

(1)桌面支持(邊緣計算/最終用途計算)永遠是一回事。

 

(2)對于大規模數字化來說，信息管理是一個重要問題，但配置管理數據庫(CMDB)從來不是解決問題的辦法。在配置管理數據庫(CMDB)是否有用的問題中，有一些子集是有用的。

 

(3)將變更管理作為一個主要的自動化過程需要保留。

 

(4)變革咨詢委員會不是必不可少的，如果在其他地方進行協調，則可以取消。例如，它可以是Scrum of Scrums議程中的常設項目。

 

從歷史上看，ITIL將ITSM分為離散流程。是否需要更系統的觀點?

 

•首席信息官Jason James說：“ITSM需要現代化。需要實現更多的自動化，以便在需要時提供更大的自助服務，包括云計算服務。此外，所有工作流程都必須設計為支持響應能力，并消除不必要的批準和延誤。對人工智能驅動的ITSM的需求是存在的，但我們仍有一段路要走，使之成為現實。”

 

•Seidl對此表示，“我一直將ITIL視為有用的語言，不一定是完全不同的孤島。概念與實現的現實意味著這些都是模糊的，并且該語言可作為一種句柄，可以確保我們在行動時離目標很近。”

 

••Osterberg說：“這仍然是語言的問題。不管其后端是什么，仍然有中斷、更深層的問題、更改和事務性請求，這些都是交叉和重疊的。并需要有一種共同的語言來解釋這一切。”

 

ITIL事情太復雜了嗎?

 

•Sacolick認為，ITIL使事情變得過于復雜，并且術語和過程過多。如今的工具，尤其是集成的DevOps和Agile以及AIOps極大地簡化了事件支持。而Agile與擴大規模無關。這是關于文化和思維方式的。組織需要做出明智的決定，以決定Agile團隊可以在何處進行自我組織以及制定了哪些標準。因此，他說：“ITSM應該專注于云計算世界中的主要問題，并且正確地采用自助服務。”

 

•對于這一點，James建議說，“ITSM必須高度自動化和可移動。如今，ITSM的許多功能都可以用機器人來完成。這些包括密碼重置、設備配置和基本的問答。這些都可以實現自動化，以便服務臺團隊可以集中精力處理更復雜的問題。許多現有的ITSM解決方案仍然缺乏這些功能。聊天機器人如果得到有效的實施，比起等待或與人員交談要輕松得多。去年我與亞馬遜公司的幾次互動都是通過他們的機器人程序完成的，每次我提出的問題都很快得到回應。”

 

關于ITSM中還包含哪些功能，還收到了不同的答復：

 

•Young說，“ITSM需要在問題、變更、服務請求、資產、供應商和配置方面擁有主數據管理和集成流程”。然而，Pitt將清單縮小為“事件、問題、變化和請求”。首席信息官Carrie Shumaker從更全面的角度看待事情，他說，“變更導致了事件發生，并且周而復始。我認為統一因素是服務，有時是配置管理數據庫(CMDB)元素。”

 

•關于變更管理，Betz說：“問題是我們將變更管理等同于變更咨詢委員會(有時是批準的)。CAB是效率低下、節奏受限、同步的面對面專用通信通道。需要有更好的方法來解決協調問題。”

 

•盡管如此，首席信息安全官Michael Oberlaender建議說，“添加一個專注于價值創造/價值鏈的端到端概念是絕對必要的。我們在ITSM中做了很多沒有增加足夠價值的事情。”

 

在ITSM中，對于消費性數字商務服務的目錄是否有著廣泛的作用?

 

•Seidl說：“對于某些組織來說是這樣的。訣竅在于挑選和選擇適合組織、目標和能力的組件和模型。我看到越來越多的組織未能推出ITSM，更多的組織成功地解決了如何工作的問題。”

 

•首席信息官Martin Davis認為，“這取決于組織定義ITSM的方式。它的范圍應該只限于幫助人們解決與IT相關的問題、服務，還是比這個范圍更廣。那么其邊界在哪里?隨著業務的發展和IT的發展，如果組織有很強的紀律性和遠見的話，目錄是一個很好的方法，如果發生脫節，而且是對任何事情都有例外的組織，那么就很可能出問題。而組織需要成為一家以流程為導向的公司，才能使這項工作取得成功。”

 

•Young有相似的觀點，他說，“這是可能的。然而，許多組織甚至沒有能力或負擔得起。對他們來說，DevOps和敏捷性仍然是一種新生事物或愿望清單。問題是，供應商正在采取什么措施來提供一種途徑，特別是為中小型企業提供這種途徑。”

 

•同樣，James認為，“ITSM可能發展并與更多系統和云計算服務交互，從而在提供更多洞察力和響應能力的同時提供更多服務。”但仍然存在一個懸而未決的問題，那就是，服務目錄是否成為API和消耗品業務服務的目錄?

 

•Sacolick建議：“從SOAP到微服務，IT團隊一直在嘗試通過許多技術來開發消耗性數字業務服務的目錄。我相信，除非有簡單的方法，否則它不會大規模發生。”

 

 

顯然，隨著越來越多的工作負載轉移到公共云，IT運營的許多方面都在經歷變化。ITIL和ITSM并沒什么不同。很多首席信息官認為ITIL和ITSM有做更多事情的機會。未來五年，ITSM將經歷更多的變化。

 

Constellation研究公司的Dion Hinchcliffe表示，ITSM必須并且將不斷發展，以便與DevOps保持良好的協調。這意味著要包含所有IT技術，包括SaaS、公共云和影子IT。這意味著，ITSM將成為一個積極的支持和管理網絡，同時使選擇和競爭成為可能。這樣做將創建一個高度可用的方法，包括潛在擴展的服務目錄概念。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。