淺談運維數(shù)字化轉(zhuǎn)型

IT那活兒發(fā)布于2023-01-11 13:20 / 2897人閱讀

點擊上方“IT那活兒”，關注后了解更多精彩內(nèi)容?。?！

01

為什么運維工作要做數(shù)字化轉(zhuǎn)型？

相信在IT運維領域干過一段時間的同學，對于運維工作的內(nèi)容都耳熟能詳了，每天從早忙到晚，經(jīng)常加班加點。例行巡檢、安裝部署、風險評估、故障處置、性能優(yōu)化、安全加固、資產(chǎn)盤點、日志分析、安全審計等等。

但一到寫工作匯報的時候就抓耳撓腮，因為想不起自己到底干了啥能拿得出手的成績。這算是做運維同學的心病：工作沒有量化輸出，我做了那么多，你卻看不見。

運維工作重要嗎？絕大多數(shù)人都知道非常重要。畢竟一次意料之外的故障或訪問風暴帶來危害可能是災難級的。

疫情時代好幾個城市的健康碼平臺故障上了微博熱搜，不少相關行業(yè)干運維的同學都心有惶惶，擔心自家的家底是否能經(jīng)得起如此考驗。

做運維顯然不能靠天吃飯，除了把應急預案做足，我們也需要知道何時該觸發(fā)預案執(zhí)行。如果不能提前把自家平臺的底給摸透，出了問題真的是哭都來不及了。

所以，平臺業(yè)務能力數(shù)字化評估是預案執(zhí)行的前提。

運維自動化已經(jīng)做了多年，通過平臺實現(xiàn)了很多運維動作的自動化。確實有不少原本需要人工投入的工作交給了機器定時執(zhí)行，或根據(jù)規(guī)則算法等方式實現(xiàn)自動執(zhí)行。

但是在跨平臺或跨系統(tǒng)的環(huán)節(jié)，仍需要靠人力實現(xiàn)流轉(zhuǎn)，各平臺之間的流程打通和數(shù)據(jù)打通仍是困擾運維人員的一大難題。

領導在工作群里的指令下達到平臺上的任務執(zhí)行，仍然需要靠人來實現(xiàn)從自然語言到應用程序的轉(zhuǎn)換過程，只能感嘆一句：流程沒有基于數(shù)字化平臺打通，有人工才有智能。

02

運維的數(shù)字化轉(zhuǎn)型如何落地？

圍繞著上述這些困擾運維團隊的問題，把目光聚焦到數(shù)字化上。我們需要通過數(shù)字化的方式來實現(xiàn)對運維工作的現(xiàn)狀量化評估、目標量化設定、過程量化管理、成果量化體現(xiàn)。四步實現(xiàn)運維的數(shù)字化。

第一步，運維工作評估數(shù)字化

我們需要通過對運維對象做量化評估來明確下一步工作目標，也需要通過對運維過程做量化統(tǒng)計來發(fā)現(xiàn)效率問題。

A、構(gòu)建系統(tǒng)健康評估體系

在實施了監(jiān)控管理之后，我們對于所運維目標系統(tǒng)（設備）已具有了較強的性能采集和性能閾值告警的能力。

這個能力提供我們對于系統(tǒng)故障發(fā)生后的快速響應能力，但仍不足以提前預知故障的發(fā)生，并且這些性能指標往往只預示某一個維度的風險，而對于客戶感知到的整體業(yè)務性能或業(yè)務可用性，卻缺少關聯(lián)性支撐。

事實上，當客戶反饋系統(tǒng)存在業(yè)務緩慢或業(yè)務辦理不成功等異常時，運維人員往往從監(jiān)控指標層面是無法發(fā)現(xiàn)問題的所在。

這里面有性能劣化累加的緣故，例如完整流程中一個單元的微小性能變化也許無法觸發(fā)閾值告警，但存在多個單元存在性能下降時，帶來的業(yè)務辦理緩慢的感知卻是惡劣的。

又比如，業(yè)務日益復雜帶來流程過長，單點的效率略低，單個性能數(shù)據(jù)來看甚至無法引起運維監(jiān)控的注意，而在對外的接口側(cè)反饋卻是超時返回。另外一方面，也有業(yè)務層面異常與系統(tǒng)層面異常的差異。

運維人員往往關注到的性能指標都是偏向底層的Paas層指標，而客戶關注的其實是業(yè)務層的辦理是否成功、辦理是否迅速等感受。

而在業(yè)務規(guī)則條件日益復雜的情況下，因為某些業(yè)務邏輯受限帶來的辦理失敗，已經(jīng)遠遠超過系統(tǒng)自身故障（性能）的原因了。

在這樣的形勢下，構(gòu)建一個覆蓋系統(tǒng)性能指標以及業(yè)務支撐能力指標的完整指標體系是必須的。

我們可以從單個重點業(yè)務辦理的流程維度、應用服務的物理拓撲架構(gòu)維度、業(yè)務支撐的整體性能維度來建立這樣一套評估指標體系。

1）業(yè)務流程維度

業(yè)務系統(tǒng)平臺對外的服務，是由一個個的業(yè)務流程組成的。一線的平臺使用者對于系統(tǒng)的最直接感知，也是單筆的業(yè)務辦理是否順暢。

通過對核心（重點）業(yè)務進行全流程的單元分解，基于單元明確服務能力指標，我們可以得到用于標識單個業(yè)務的一組運行指標。這里面包含有單個服務的調(diào)用總量、平均調(diào)用耗時、單位時間的調(diào)用成功率等。

通過對這些指標做基線沉淀，我們能夠得到一組用于快速發(fā)現(xiàn)該業(yè)務發(fā)生異常的感應器。

例如業(yè)務正常時段的調(diào)用量突降或變?yōu)?可能預示入口網(wǎng)絡訪問異常；平均調(diào)用耗時的增加可能是由于近期上線代碼質(zhì)量不過關導致服務性能劣化；單位時間內(nèi)調(diào)用成功率下降的原因可能多種多樣，也許是代碼級的bug，也許是某些業(yè)務規(guī)則改變帶來的辦理條件不滿足，需要從業(yè)務角度切入做進一步分析。

這些指標數(shù)據(jù)的長期歷史數(shù)據(jù)匯聚，能為運維分析提供強有力的數(shù)據(jù)依據(jù)支撐。

2）應用拓撲維度

應用拓撲是傳統(tǒng)的Paas層運維的納管對象。運維人員對于這個維度的指標體系是比較熟悉的。

通過對系統(tǒng)資產(chǎn)的部署關系、調(diào)用關系、歸屬關系的獲取和維護，并對各層級的應用模塊、設備模塊、網(wǎng)絡模塊的性能進行指標化管理，我們可以得到一座由下而上的異常影響分析金字塔。

目前在我們所運維的大多數(shù)現(xiàn)場，或多或少都已實現(xiàn)了這些指標數(shù)據(jù)。

在這座金字塔中，下層的物理設備故障必然引起部署于其上的應用模塊（數(shù)據(jù)模塊）發(fā)生異常，有調(diào)用關系的某個模塊發(fā)生故障時，必然會引起關聯(lián)模塊的服務調(diào)用異常。

通過對這些邏輯關系的分析，建立層級之間的模塊指標體系的關聯(lián)，運維人員可以做健康影響分析，也可應用高可用、雙中心、冷熱備等方式實現(xiàn)對系統(tǒng)可靠性進行優(yōu)化。

3）對外業(yè)務支撐能力維度

對外業(yè)務支撐能力維度是從系統(tǒng)整體來評估業(yè)務支撐能力。

這個維度是將系統(tǒng)作為一個整體來看待，關注點在其對外提供的能力。例如服務的并發(fā)提供能力、周期內(nèi)的業(yè)務容量、數(shù)據(jù)的存儲容量、單位時間的最大訂單執(zhí)行量等等。

通過這些系統(tǒng)整體指標，能看到當前系統(tǒng)承載容量水位，為及時擴縮容提供數(shù)據(jù)依據(jù)，也能為經(jīng)營分析評估提供業(yè)務增長或萎縮的數(shù)據(jù)支撐。

通過將業(yè)務支撐能力指標與應用拓撲或業(yè)務流程維度指標結(jié)合，我們能更快定位到系統(tǒng)的性能瓶頸所在，讓優(yōu)化工作開展更有針對性。

B、構(gòu)建運維效率評估體系

做了不短時間的現(xiàn)場運維團隊，都會面臨一個困擾。日常工作按部就班的在做，明確的運維范圍都覆蓋到了，系統(tǒng)的穩(wěn)定性也在優(yōu)化工作的推進下穩(wěn)步提升。

雖說仍有一些不可預知的故障發(fā)生，畢竟硬件的突然壞掉或業(yè)務上了個bug這種小概率事件無法徹底避免。

那么，運維工作的提升是否就到此為止了呢？

很顯然不是的。

隨著業(yè)務范圍的擴展，可以預見我們所運維的系統(tǒng)將日益龐大，業(yè)務模塊越來越多，系統(tǒng)架構(gòu)也變得更加龐大。更新的技術(shù)也帶來更多的能力，各種開源框架、開源組件層出不窮。

相信任何運維團隊都無法靠人力擴張來支撐隨之而來的運維壓力，人力捉襟見肘是常態(tài)。在人力無法擴張的時候，提升效率幾乎是唯一的出路。

在運維工作的初始階段，所有的工作都是靠人。巡檢是人工登到一臺臺的主機上去檢查的，數(shù)據(jù)庫是靠DBA一套套裝的。

十多年前，系統(tǒng)仍不算復雜，業(yè)務量尚沒有那么大時，我們曾經(jīng)這樣干過。而現(xiàn)在的設備翻了100倍還不止，動輒數(shù)百套庫的安裝部署。這已經(jīng)不是單憑個人效率或能力能解決的問題了。

當我們想到要提升運維工作效率的時候，首先面對的問題是如何評估現(xiàn)在的效率，并且找到現(xiàn)在運維工作中嚴重影響效率的環(huán)節(jié)，再有的放矢去優(yōu)化它們。

對于運維工作效率的考量可以從建立任務跟蹤體系和評估流程人力占比兩個方面開展：

1）運維任務跟蹤體系

運維工作是可以用任務的顆粒度進行跟蹤的，無論是對外提供的IT服務，還是對內(nèi)的日常工作，使用一套優(yōu)秀的任務系統(tǒng)來登記各項任務、設定預定完成時間、記錄實際完成時間，備注當前狀態(tài)及所遇到的問題有有必要的。

結(jié)合流程引擎，我們可以將需要執(zhí)行的運維工作拆解為一個個的任務單元，將任務單元分配給人或自動化平臺來完成。

通過接口獲取到任務單元的執(zhí)行狀態(tài)、執(zhí)行結(jié)果等信息，我們能知道哪些任務存在時延，哪些人導致效率瓶頸，甚至是哪些配合工作沒有做好，哪些組織存在配合上的問題。

流程復雜、耗時太長的運維工作一定是工作優(yōu)化的首要目標。

2）運維人力投入評估

如果一項運維工作絕大部分都需要靠人才能完成時，這項工作的效率一定是不夠高的，畢竟人的并發(fā)工作能力無法與機器相比。

當人力成為現(xiàn)場運維團隊最大的效率瓶頸，無論單個人的能力有多強，是時候考慮如何提高自動化能力在運維工作中的占比了。

日常巡檢這樣的工作當然應該盡量交給監(jiān)控告警系統(tǒng)；如果系統(tǒng)具備高可用環(huán)境，那么發(fā)現(xiàn)了故障后的處置，也可以由自動化平臺觸發(fā)自愈流程來完成；還有安裝部署、主機加固、配置調(diào)參這樣的操作動作相對固定，操作對象數(shù)量巨大的工作，也應轉(zhuǎn)由系統(tǒng)完成，人力在其中只負責值守并查看結(jié)果即可。

對于運維效率的評估中，是否占用更少的人力，提升機器自動化投入占比，是衡量現(xiàn)場運維工作成熟度的重要標志。

第二步，運維工作目標數(shù)字化

通過對運維對象健康狀況的量化評估，我們得以發(fā)現(xiàn)系統(tǒng)的運行狀態(tài)以及薄弱環(huán)節(jié)；通過對運維效率的量化評估，我們也具備了定位流程優(yōu)化及自動化改造關鍵環(huán)節(jié)的能力。

那么，應該如何推動運維工作的進一步優(yōu)化呢？

不少的現(xiàn)場運維團隊工作開展是事件觸發(fā)的。

一個告警觸發(fā)了一條任務工單，由某位運維工程師接單后執(zhí)行相應的運維操作，并通過回單動作結(jié)束了這項運維工作；領導或客戶的一個口頭工作安排，也可能是運維工作觸發(fā)的起點，出個系統(tǒng)運行情況報表，或者安裝一套庫。

經(jīng)常聽網(wǎng)上有職場人吐槽說上頭動動嘴，下面跑斷腿，大概就是這一類了。

這些工作當然是屬于日常工作的范疇，無論是系統(tǒng)事件還是客戶事件，都構(gòu)成了運維工作的一部分。

但，也只包括了一部分。

到了月底年底要做匯報的時候，我們顯然不能拿出一張清單來說處理了多少個系統(tǒng)告警，處理了多少起系統(tǒng)故障，處理了多少次客戶口頭工作安排。

這些不是運維工作應該展現(xiàn)的成績?；蛘哒f，這些只能代表工作的苦勞，卻不是功勞。

運維工作在一系列繁雜的事項中，是有一條主線的。

這條主線是要讓我們運維的系統(tǒng)運行越來越穩(wěn)定、性能越來越強、業(yè)務越來越高端、承載的客戶越來越多；讓我們運維服務效率越來越高，投入的低效勞動越來越少，自動化水平越來越高，所面向的客戶越來越滿意。

這個目標是沒有止境的，聽著似乎是一句很空洞的口號，所以如果要實現(xiàn)它，需要做一層層的拆解。

運維工作目標的數(shù)字化，以及對該目標分解為各階段的執(zhí)行計劃和執(zhí)行任務項，是落地目標實現(xiàn)方案的具象。

我們可以通過運維工作任務系統(tǒng)，設定每一年度或時間階段的運維提升目標。這個目標可以是面向所運維業(yè)務系統(tǒng)的，也可以是面向運維服務過程的。

A、面向運維業(yè)務系統(tǒng)的優(yōu)化目標

1）確保系統(tǒng)運行更加健康

這個目標的設定是與前面所講述的系統(tǒng)健康量化評估相關的。

隨著業(yè)務的發(fā)展壯大，要承載的業(yè)務量越來越多，業(yè)務邏輯越來越復雜，必然帶來系統(tǒng)的壓力日益增長以及對于單筆業(yè)務的辦理效率下降。

如同逆水行舟，如果不持續(xù)關注系統(tǒng)的運行狀態(tài)，并推動關鍵環(huán)節(jié)的優(yōu)化，則必定會積重難返。

可以預見的未來會出現(xiàn)時不時的業(yè)務辦理流程超長導致超時失敗，數(shù)據(jù)庫并發(fā)訪問增大導致死鎖或夯住甚至宕機，網(wǎng)絡流量過大出現(xiàn)阻塞……

各種的異常故障并不是瞬間形成的，而是在一次次微小的變化后積累而成，當最后一根稻草輕輕壓下時，已是回天乏術(shù)了。

所以，通過對業(yè)務系統(tǒng)各項運行指標的分析和評估，確定階段時間內(nèi)的優(yōu)化指標項，保障這些指標不會進一步劣化，對存在風險的指標進行優(yōu)化，更甚至將未來可能的劣化提前進行優(yōu)化改造，都成為運維工作設定的重要目標。

例如高負荷系統(tǒng)的擴容改造，高水位數(shù)據(jù)存儲的騰挪清理并重新制定生命周期管理規(guī)劃，訪問峰值的負載均衡調(diào)整等等。

這些工作也許沒有那么緊急，但卻非常重要，這是現(xiàn)場運維團隊任務的重中之重。

2）確保系統(tǒng)運維向符合業(yè)務發(fā)展方向演進

這個目標的設定是伴隨著企業(yè)發(fā)展規(guī)劃的。隨著行業(yè)業(yè)務的發(fā)展，以及業(yè)務系統(tǒng)所面向客戶的需求提高，系統(tǒng)的能力也被寄予了更高的要求。

例如建立數(shù)據(jù)共享中心必然會引入一些大數(shù)據(jù)組件，按不同的數(shù)據(jù)應用需求來提供數(shù)據(jù)存儲及開放。新引入的開源數(shù)據(jù)組件該如何運維則即將成為運維團隊所面臨的問題。

又例如客戶需要更快的在線數(shù)據(jù)分析能力，那么引入實時計算的開源架構(gòu)也勢在必行，如何確保計算過程中不出現(xiàn)異常中斷，或系統(tǒng)異常中斷后如何恢復不丟失數(shù)據(jù)，同樣是運維團隊應該參與考慮解決的問題。

這些問題在系統(tǒng)改造或系統(tǒng)建設階段就應該介入，從利于運維的角度提出解決方案，并將方案作為階段目標，并分解出任務子項，與系統(tǒng)建設團隊一起推動落地施行。

例如故障場景的應急預案構(gòu)建，數(shù)據(jù)遷移任務準備等等，這樣才不至于在接手系統(tǒng)運維時故障頻發(fā)，手忙腳亂。

B、面向運維服務過程的優(yōu)化目標

1）運維服務效率提升

運維工作的執(zhí)行效率是衡量運維服務水平的重要指標體系。這個效率的評估是以完成任務為前提的。

例如50套數(shù)據(jù)庫的裝庫及數(shù)據(jù)遷移工作，兩個人一個月完成，投入60個人日，最終達到了任務目標，但客戶不見得滿意，因為這是以犧牲其他工作的完成為代價的。

如果投入1個人半個月時間，通過寫腳本、測試腳本并順利執(zhí)行50套庫的安裝遷移工作，雖然整個安裝庫的過程也耗時1個月，但實際投入的人力其實只有15人日，并且這套裝庫程序在后續(xù)的同類工作中稍加改造還能繼續(xù)發(fā)揮作用。

那么效率的提升是明顯的。因為對于單個運維人員來說，還能并發(fā)執(zhí)行其他的運維工作。

我們可以把常見的運維工作場景化，并梳理這些場景的工作流程，基于這些工作場景設定流程時長壓降目標，或人力投入壓降目標。

無論是縮短單個場景的工作時長，還是減少人力投入，對于整個運維團隊來說，都是運維效率的提升，可以帶來巨大的并發(fā)工作能力增長。

流程的優(yōu)化，可以分拆到各個步驟環(huán)節(jié)，使用自動化平臺能力替代人工執(zhí)行，還可以對審核環(huán)節(jié)由人工審批轉(zhuǎn)為自動審批，甚至優(yōu)化掉一些不合理環(huán)節(jié)。

所有的優(yōu)化方案都可以分拆到一項項子任務來推動實施，并最終完成一項運維服務工作效率的整體提升。

2）運維服務質(zhì)量提升

面對客戶，面對業(yè)務系統(tǒng)，應該心存敬畏，如履薄冰。沒有哪家老爺會愿意自家的長工當成了祖宗。

在筆者還是個運維行業(yè)菜鳥的時候，就曾聽前輩大佬說過這樣一句話：當用戶還愿意罵你的時候，說明他還對你有所依賴；如果他已經(jīng)懶得罵你時，你就離滾蛋不遠了。

所以，運維服務應該有質(zhì)量標準，并且運維服務要把不斷提升質(zhì)量標準作為階段目標。

不過，運維服務的質(zhì)量評估較難通過數(shù)字做客觀量化體現(xiàn)，一般現(xiàn)場往往用客戶滿意度或客戶最終的合作伙伴打分來作為相應目標，而這些打分標準或扣分標準也來源于客戶對于系統(tǒng)運行穩(wěn)定性、運維支撐情況、事件處置效率的綜合印象。

由于各個現(xiàn)場存在差異，因此在這里不做贅述了。

第三步，運維執(zhí)行過程數(shù)字化

運維執(zhí)行過程的數(shù)字化，包括應用任務管理系統(tǒng)將所有的運維工作任務化記載，通過連接自動化平臺實現(xiàn)部分任務的自動化完成，以虛擬數(shù)字員工跨系統(tǒng)對接工作流程閉環(huán)。

A、運維工作任務化記載

通過前述的運維目標評估和運維目標設定，我們已引入了運維任務這個名詞。

所謂運維任務，應該是指運維過程中的每一個執(zhí)行環(huán)節(jié)。當然，這個執(zhí)行環(huán)節(jié)可以是大的運維場景，也可以是細小到具體的一項運維操作。

例如安全加固這個事項可以是一個運維任務，其實這個任務里面也可以繼續(xù)拆分為多個子任務分派給不同的人執(zhí)行，又或者可以將部分加固操作分配給某個自動化程序來執(zhí)行。

運維任務的設定，可以更好的對運維過程進行把控。

應用任務管理系統(tǒng)從整體目標分解到階段計劃，設定階段里程碑目標，再分解到每個階段需要執(zhí)行的運維任務，指定任務的執(zhí)行人或執(zhí)行程序，設定計劃開始時間和計劃結(jié)束時間，預分配人工工時占用等等。

以數(shù)字化方式管理運維執(zhí)行過程，將運維工作的無序轉(zhuǎn)變?yōu)橛行颉?/span>

這里有個理想與現(xiàn)實的差異。有不少同學會認為運維工作存在很強的不確定性，領導一句話可能就會完全打亂既定的運維工作，又或者一個突發(fā)的故障事件也會讓原來正在執(zhí)行的某個運維動作不得不暫停下來，畢竟保障系統(tǒng)正常運行是第一重要的工作。

基于這種顯示情況，我們提出一個任務補登記的流程，由運維人員將臨時安排的工作手工補登記到任務系統(tǒng)。

通過任務歷史記錄，管理人員可以回溯獲得以下信息：

1）哪些事件導致了正常安排的運維任務的延期。

2）哪些事件存在周期性觸發(fā)，應該可以作為計劃任務預先安排。

3）哪些任務時間預估不合理，應調(diào)整預估時間。

4）哪些任務存在較大的優(yōu)化空間，應推動自動化平臺執(zhí)行來提升效率。

5）哪些運維人員執(zhí)行任務存在較大時延，分析能力因素或其他因素。

通過上述的數(shù)字化轉(zhuǎn)型，將運維工作任務化記載，為運維工作的迭代優(yōu)化提供數(shù)據(jù)分析依據(jù)。

B、運維動作自動化執(zhí)行

運維動作的自動化主要由各類自動化平臺承載，通過運維工作任務系統(tǒng)與自動化平臺接口對接，將配置在自動化平臺的運維操作調(diào)度執(zhí)行實現(xiàn)。

每一個執(zhí)行動作需要采集執(zhí)行時長信息，反饋到任務系統(tǒng)用于事后分析，并對存在執(zhí)行過久的動作程序進行不斷優(yōu)化，提升執(zhí)行效率。

通過任務系統(tǒng)將原本散亂在不同自動化平臺的程序、腳本、后臺定時任務整合起來，通過平臺的任務流程進行串聯(lián)執(zhí)行，并數(shù)字化記錄完整流程的執(zhí)行過程，避免運維人員在各種不同平臺或主機、數(shù)據(jù)庫檢查執(zhí)行過程和執(zhí)行結(jié)果的繁瑣。

C、數(shù)字員工實現(xiàn)跨系統(tǒng)連接

數(shù)字員工伴隨著元宇宙的概念，現(xiàn)在著實是火了。

通過數(shù)字員工鏈接企業(yè)各個系統(tǒng)，在不入侵企業(yè)原有系統(tǒng)基礎上對各個數(shù)據(jù)資源快速調(diào)取和處理；擺脫了系統(tǒng)孤立、數(shù)據(jù)孤島的問題，同時規(guī)避跨系統(tǒng)操作的風險。

如何將數(shù)字員工的理念在實際工作中落到實處帶來真實的效率呢？這里給出一些方案給大家參考。

1）任務系統(tǒng)以數(shù)字員工身份進入工作通訊工具接收工作安排

這個方案中借鑒了電商系統(tǒng)的智能店小二的能力，打開數(shù)字員工的私聊窗口或在工作群中@數(shù)字員工時，數(shù)字員工回應消息并提供自己能提供的服務清單目錄，客戶可以選擇對應的服務項目并確認執(zhí)行。

通過模擬實際的運維任務交代、任務執(zhí)行和任務反饋的流程，實現(xiàn)從工作社群到后臺任務執(zhí)行的無障礙串聯(lián)。

例如特定需求巡檢、空間清理、進程重啟等常規(guī)運維操作均可以用這樣的方式執(zhí)行，與數(shù)字員工的交互過程以逐層服務目錄選擇方式推進。

當然，也可以通過捕捉自然語言中的關鍵詞信息智能識別任務，需要搭配一定的機器學習算法等應用，在此不過多展開了。

2）任務系統(tǒng)以數(shù)字員工身份進入OA平臺對接工作安排

在企業(yè)內(nèi)部已有OA系統(tǒng)環(huán)境中，可以將任務系統(tǒng)以數(shù)字員工身份注冊到OA中。

通過OA系統(tǒng)下發(fā)的工作安排通過接口傳遞到任務系統(tǒng)中。通過對OA下發(fā)的工作安排的解析（自然語言解析或轉(zhuǎn)排人工），發(fā)起任務系統(tǒng)中的任務工單，并在任務系統(tǒng)中工單完結(jié)后通過接口回傳到OA平臺繼續(xù)流轉(zhuǎn)。

OA系統(tǒng)中應用數(shù)字員工的好處主要是實現(xiàn)任務工作的自動流轉(zhuǎn)對接，降低運維人員的人工對接工作量。

對于一些重復性的工作安排，甚至可以在任務系統(tǒng)中部署一些自動化環(huán)節(jié)實現(xiàn)對文件、數(shù)據(jù)的預加工處理，甚至某些處理工作都可以全部配置為自動化執(zhí)行動作，降低人工耗時，提高效率。

例如常見的項目備案、項目合規(guī)審計等運維工作，都可以以數(shù)字員工的形式提供全流程的自動化執(zhí)行。

3）監(jiān)控告警平臺以數(shù)字員工身份進入工作通訊工具發(fā)送系統(tǒng)預警

監(jiān)控告警平臺常規(guī)的消息推送形式一般是短信、郵件等，通過數(shù)字員工身份注冊到工作通訊工具后，更加符合日常的工作交互習慣。避免了運維人員從多處接收信息的繁瑣和忙亂。

對于一些重要預警信息和預警恢復信息直接以數(shù)字員工身份在工作群中反饋，一方面加快了信息的傳遞效率，另一方面也可以提升領導對運維工作的感知。

需要特別注意的是，對于數(shù)字員工在工作群的告警需要做相應的級別控制和告警合并壓降，避免出現(xiàn)告警風暴的現(xiàn)象，影響了故障發(fā)生時的正常交流，帶來負面效果。

4）運維相關平臺以數(shù)字員工身份進入任務系統(tǒng)

自動化平臺具備了越來越多運維動作的執(zhí)行能力，一些自動化運維動作已經(jīng)可以由事件觸發(fā)。

例如自愈類的切換、重啟等，又例如常規(guī)的備份清理等，都已可自動觸發(fā)，這些自動化工作的執(zhí)行給運維帶來了巨大的效率提升，但我們其實很難對其收益價值進行評估。另外，仍有很多能力的執(zhí)行需要人工判斷后再觸發(fā)。

還有不少的企業(yè)內(nèi)部的信息化建設中，自動化能力是根據(jù)不同的需求分散建設在不同的系統(tǒng)中的，如何講這些自動化能力進行整合，同樣是運維團隊需要考慮的問題。

我們可以將各自動化平臺注冊為數(shù)字員工接入到任務系統(tǒng)。在任務系統(tǒng)中，各自動化平臺可以以任務流程形式串聯(lián)，將一個個子任務組成完整的運維工作場景，避免的運維場景的零散化。

我們還可以將監(jiān)控告警系統(tǒng)也注冊為數(shù)字員工接入到任務系統(tǒng)作為任務派單者角色，使其與自動化操作能力對接，這樣也避免了監(jiān)控告警平臺對接多種不同自動化平臺的改造工作量和繁瑣配置。

最后，通過將各類自動化平臺數(shù)字員工化，我們可以在任務工時統(tǒng)計時更方便的獲得運維工作的人工工時與機器工時的占比，并推動更多的運維工作自動化執(zhí)行。

第四步，運維成果體現(xiàn)數(shù)字化

一個運維周期下來，通過上述的現(xiàn)狀量化評估、目標量化設定、過程量化執(zhí)行，最終仍需要對整個運維過程的改進進行再一次的量化評估。

一方面看初始設定的數(shù)字化目標是否達成，也為我們的匯報提供充足素材。另一方面回顧整個運維過程，發(fā)現(xiàn)管理上的薄弱環(huán)節(jié)以及效率瓶頸。

這些數(shù)據(jù)信息，又成為了下一個運維周期的量化目標。通過一次又一次的目標迭代優(yōu)化，運維團隊的工作將更加趨向完善。

至于運維成果的數(shù)字化呈現(xiàn)效果，從最早的報表、可視化展現(xiàn)，到現(xiàn)在很多企業(yè)建設的各類領導駕駛艙或指揮中心大屏等能力，無不酷炫，在此不做展開了。

本文作者：李秋霖

本文來源：IT那活兒（上海新炬王翦團隊）

點贊

在看

GPU云服務器云服務器數(shù)字化轉(zhuǎn)型企業(yè)數(shù)字化轉(zhuǎn)型設計淺談淺談javascript

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/129661.html

這場金融網(wǎng)絡盛宴華為又要秀出哪些前瞻性布局？

摘要：最新發(fā)布的全球半年度行業(yè)云跟蹤報告也顯示，年全球四大行業(yè)金融制造醫(yī)療和公共部門的行業(yè)云支出總額將高達億美元。這樣一來，華為的金融網(wǎng)絡能夠獲得市場的青睞也就順理成章了。金融業(yè)數(shù)字化轉(zhuǎn)型的加速，使得金融云越來越成為行業(yè)標配；但金融云的普及，又讓傳統(tǒng)網(wǎng)絡技術(shù)架構(gòu)受到了前所未有的沖擊。這樣看來，邏輯就簡單了：金融業(yè)必須先推動傳統(tǒng)網(wǎng)絡技術(shù)架構(gòu)的升級，促進金融云的普及應用，才能進一步實現(xiàn)自身的數(shù)字化轉(zhuǎn)型...

crossoverJie 2019-04-29 19:29 評論0 收藏0
UCloud與云智慧簽署戰(zhàn)略合作協(xié)議，助力行業(yè)數(shù)字化轉(zhuǎn)型

摘要：未來將攜手云智慧，把雙方合作落到實處，共同服務行業(yè)數(shù)字化發(fā)展，實現(xiàn)共贏。未來，與云智慧將整合各自在云計算服務和智能運維服務上的優(yōu)勢，推出更多面向運營商政府公共服務工業(yè)互聯(lián)網(wǎng)及傳統(tǒng)企業(yè)數(shù)字化轉(zhuǎn)型的解決方案，提供更專業(yè)高效的產(chǎn)品和服務。3月23日，優(yōu)刻得科技股份有限公司（以下簡稱UCloud優(yōu)刻得）與云智慧（北京）科技有限公司（以下簡稱云智慧）簽署戰(zhàn)略合作協(xié)議，雙方將整合各自技術(shù)資源優(yōu)勢，聯(lián)合推...

Tecode 2022-06-28 19:00 評論0 收藏0
UCloud優(yōu)刻得參加2022浙江CIO峰會，助推傳統(tǒng)企業(yè)數(shù)字轉(zhuǎn)型

9月16日，由浙江省企業(yè)信息化促進會主辦的2022浙江CIO峰會在臺州市順利舉辦。UCloud優(yōu)刻得作為云計算領軍企業(yè)受邀出席，并在大會論壇現(xiàn)場圍繞企業(yè)海量數(shù)據(jù)存儲、多云管理等展開了數(shù)字化轉(zhuǎn)型技術(shù)經(jīng)驗分享。浙江CIO峰會是促進會推動全省制造業(yè)企業(yè)數(shù)字化轉(zhuǎn)型發(fā)展的品牌大會。為響應十四五協(xié)同推進數(shù)字產(chǎn)業(yè)化和產(chǎn)業(yè)數(shù)字化，賦能傳統(tǒng)產(chǎn)業(yè)轉(zhuǎn)型升級的政策號召，推動大數(shù)據(jù)技術(shù)產(chǎn)業(yè)創(chuàng)新發(fā)展、促進數(shù)字技術(shù)與實體經(jīng)濟深...

社區(qū)管理員 2022-09-16 16:10 評論0 收藏0
BAT數(shù)據(jù)中心建設背后的“推手” 新華三是怎么做到的？

摘要：日前，聚焦于的新華三數(shù)據(jù)中心基礎設施研討會在福州召開，在此次研討會上，新華三集團全面展現(xiàn)了自身在數(shù)據(jù)中心全生命周期服務上的綜合實力。從在我們的生活中，幾乎每天都會用到百度的搜索引擎，騰訊的微信、QQ，阿里巴巴的淘寶和支付寶，但你有沒有想過，這些工具每天會被用到多少次？盡管沒有非常精確的統(tǒng)計，數(shù)以億計肯定只是保守估計。我們之所以能夠享受這些互聯(lián)網(wǎng)工具帶來的便捷，與其背后所擁有的強大數(shù)據(jù)中心支撐...

Nino 2019-04-30 14:38 評論0 收藏0
AIOps 一場顛覆傳統(tǒng)運維的盛筵

摘要：陳旭相信的發(fā)布將開啟人工智能技術(shù)與傳統(tǒng)運維碰撞顛覆的新時代。我卻認為是一場顛覆傳統(tǒng)運維的盛筵。綜上所述，的確是一場對于傳統(tǒng)運維工具的顛覆革命，每個企業(yè)都應該從現(xiàn)在開始，關注并嘗試使用智能運維平臺。顛覆傳統(tǒng)運維。是 OneAPM CEO 陳旭經(jīng)常掛在嘴邊的一句話。為什么說 AIOps 將顛覆傳統(tǒng)運維?如何才能把人工智能和運維管理相結(jié)合并落地?2018年5月，OneAPM 推出了全新的 ...

XFLY 2019-05-28 17:08 評論0 收藏0
華云攜手蘇中建設集團實現(xiàn)數(shù)字化轉(zhuǎn)型 云計算替代傳統(tǒng)IT模式已成大勢

摘要：對于蘇中建設來說，選用云計算逐步替代傳統(tǒng)的信息化環(huán)境是必然的選擇。在眾多云計算廠商中，蘇中集團最終選擇牽手大型云計算服務提供商華云。隨著云計算時代的到來，傳統(tǒng)行業(yè)IT信息化也面臨巨大的機遇和挑戰(zhàn)，過去的IT架構(gòu)也已經(jīng)無法滿足日新月異的新業(yè)務模式的發(fā)展需求。而云計算技術(shù)，可以很好地解決快速擴展、應用高可用、數(shù)據(jù)容災、安全可靠、數(shù)據(jù)集中共享、軟件集中部署、快速響應業(yè)務對IT資源需求的問題，云計算...

fevin 2019-04-30 11:31 評論0 收藏0