<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          能解決 80% 故障的排查思路

          共 4694字,需瀏覽 10分鐘

           ·

          2022-06-18 16:29

          往期熱門文章:
          1、40 個 SpringBoot 常用注解:讓生產(chǎn)力爆表!
          2、3種常見的數(shù)據(jù)脫敏方案
          3、BigDecimal使用不當(dāng),造成P0事故!
          4、改造BeanUtils,優(yōu)雅實現(xiàn)List數(shù)據(jù)拷貝
          5、SpringBoot 啟動時自動執(zhí)行代碼的幾種方式,還有誰不會??

          在講解事件、故障處理思路前,先講一個故障場景(以呼叫中心系統(tǒng)作為一例子):

          業(yè)務(wù)人員反映呼叫中心系統(tǒng)運行緩慢,部份電話在自助語言環(huán)節(jié)系統(tǒng)處理超時,話務(wù)轉(zhuǎn)人工座席,人工座席出現(xiàn)爆線情況。

          運維人員開始忙活了,查資源使用情況、查服務(wù)是否正常、查日志是否報錯、查交易量還有沒有……時間不知不覺的在敲鍵盤、敲鍵盤、敲鍵盤中過去,但是原因還未定位。

          經(jīng)理過來了解情況:“系統(tǒng)恢復(fù)了嗎?”、“故障影響是什么?”、“交易中斷了嗎?”……

          運維人員趕緊敲鍵盤,寫 SQL,看交易量;敲鍵盤,寫命令,看系統(tǒng)資源、情況……

          最終,定位到問題原因是其中一個功能沒有控制返回數(shù)量,導(dǎo)致內(nèi)存泄露。

          針對這個故障,業(yè)務(wù)希望運維能否更快的解決故障的恢復(fù),經(jīng)理希望制定優(yōu)化呼叫中心故障處理流程,做了以下幾件事:

          優(yōu)先故障處理過程的時間:”能通過鼠標(biāo)完成的工作,不要用鍵盤“

          提前發(fā)現(xiàn)故障,加強監(jiān)控:“技術(shù)早于業(yè)務(wù)發(fā)現(xiàn)問題,監(jiān)控不僅是報警,還要協(xié)助故障定位”

          完善故障應(yīng)急方案:“應(yīng)急方案是最新的、準(zhǔn)確的、簡單明了的”

          長遠(yuǎn)目標(biāo):故障自愈:“能固化的操作自動化,能機器做的讓機器做”

          下面將從故障常見的處理方法開始介紹,再從故障前的準(zhǔn)備工作(完善監(jiān)控、制定應(yīng)急方案等方式)來解決經(jīng)理提出的問題,并提出未來解決故障的想法。

          一、常見的方法

          1、確定故障現(xiàn)象并初判問題影響

          在處理故障前,運維人員首先要知道故障現(xiàn)象,故障現(xiàn)象直接決定故障應(yīng)急方案的制定,這依賴于運維人員需要對應(yīng)用系統(tǒng)的整體功能有一定的熟悉程度。

          確認(rèn)了故障現(xiàn)象后,才能指導(dǎo)運維人員初判斷故障影響。

          2、應(yīng)急恢復(fù)

          運維最基本的指標(biāo)就是系統(tǒng)可用性,應(yīng)急恢復(fù)的時效性是系統(tǒng)可用性的關(guān)鍵指標(biāo)。

          有了上述故障現(xiàn)象與影響的判斷后,就可以制定故障應(yīng)急操作,故障應(yīng)急有很多,比如:

          • 服務(wù)整體性能下降或異常,可以考慮重啟服務(wù);

          • 應(yīng)用做過變更,可以考慮是否需要回切變更;

          • 資源不足,可以考慮應(yīng)急擴容;

          • 應(yīng)用性能問題,可以考慮調(diào)整應(yīng)用參數(shù)、日志參數(shù);

          • 數(shù)據(jù)庫繁忙,可以考慮通過數(shù)據(jù)庫快照分析,優(yōu)化SQL;

          • 應(yīng)用功能設(shè)計有誤,可以考慮緊急關(guān)閉功能菜單;

          • 還有很多……


          另外,需要補充的是,在故障應(yīng)急前,在有條件的情況需要保存當(dāng)前系統(tǒng)場景,比如在殺進程前,可以先抓個CORE文件或數(shù)據(jù)庫快照文件。

          3、快速定位故障原因

          1)是否為偶發(fā)性、是否可重現(xiàn)

          故障現(xiàn)象是否可以重現(xiàn),對于快速解決問題很重要,能重現(xiàn)說明總會有辦法或工具幫助我們定位到問題原因,而且能重現(xiàn)的故障往往可能是服務(wù)異常、變更等工作導(dǎo)致的問題。

          但如果故障是偶發(fā)性的,是有極小概率出現(xiàn)的,則比較難排查,這依賴于系統(tǒng)是否有足夠的故障期間的現(xiàn)場信息來決定是否可以定位到總是原因。
          是否進行過相關(guān)變更。

          大部份故障是由于變更導(dǎo)致,確定故障現(xiàn)象后,如果有應(yīng)的變更,有助于從變更角度出現(xiàn)分析是否是變更引起,進而快速定位故障并準(zhǔn)備好回切等應(yīng)急方案。

          2)是否進行過相關(guān)變更

          大部份故障是由于變更導(dǎo)致,確定故障現(xiàn)象后,如果有應(yīng)的變更,有助于從變更角度出現(xiàn)分析是否是變更引起,進而快速定位故障并準(zhǔn)備好回切等應(yīng)急方案。

          3)是否可縮小范圍

          一方面應(yīng)用系統(tǒng)提倡解耦,一支交易會流經(jīng)不同的應(yīng)用系統(tǒng)及模塊;另一方面,故障可能由于應(yīng)用、系統(tǒng)軟件、硬件、網(wǎng)絡(luò)等環(huán)節(jié)的問題。在排查故障原因時應(yīng)該避免全面性的排查,建議先把問題范圍縮小到一定程序后再開始協(xié)調(diào)關(guān)聯(lián)團隊排查。

          關(guān)聯(lián)方配合分析問題

          與第(3)點避免同時各關(guān)聯(lián)團隊同時無頭緒的排查的同時,對于牽頭方在縮小范圍后需要開放的態(tài)度去請求關(guān)聯(lián)方配合定位,而對于關(guān)聯(lián)方則需要有積極配合的工作態(tài)度。

          4)是否有足夠的日志

          定位故障原因,最常用的方法就是分析應(yīng)用日志,對運維人員不僅需要知道業(yè)務(wù)功能對應(yīng)哪個服務(wù)進程,還要知道這個服務(wù)進程對應(yīng)的哪些應(yīng)用日志,并具備一些簡單的應(yīng)用日志異常錯誤的判斷能力。

          5)是否有core或dump等文件

          故障期間的系統(tǒng)現(xiàn)場很重要,這個在故障應(yīng)急前建議在有條件的情況下留下系統(tǒng)現(xiàn)場的文件,比如 CORE\DUMP,或TRACE采集信息等,備份好一些可能被覆蓋的日志等。

          上述是一般性的故障常見的方法,在重大故障或多方處理的故障出現(xiàn)時,往往小范圍的排查不利于快速解決,需要啟動緊急處理的流程,建議可以考慮以下溝通:

          • 召集相關(guān)人員

          • 描述故障現(xiàn)狀

          • 說明正常應(yīng)用邏輯流程

          • 陳述變更

          • 排查進展,展示信息

          • 領(lǐng)導(dǎo)決策


          二、完善監(jiān)控

          1、從監(jiān)控可視化上完善

          完善的監(jiān)控策略需要有統(tǒng)一的可視化操作界面,在制定完善的監(jiān)控策略后,故障處理人員需要能夠快速的看到相應(yīng)的運行數(shù)據(jù),比如:能夠看到一段時間的趨勢、故障期間的數(shù)據(jù)表現(xiàn)、性能分析的情況等等數(shù)據(jù),且這些數(shù)據(jù)可以提前制定好策略直接推出分析結(jié)果給故障處理人員,這樣就大大提高了故障的處理效率,以呼叫中心系統(tǒng)為例,需要提前配置好以下實時交易數(shù)據(jù),以便故障定位:

          • 交易性能數(shù)據(jù):平均交易耗時、系統(tǒng)內(nèi)部模塊交易耗時(IVR交易耗時、接口總線交易耗時)、關(guān)聯(lián)系統(tǒng)交易耗時(核心交易耗時、工單系統(tǒng)交易耗時等)


          • 重要交易指標(biāo)數(shù)據(jù):交易量、IVR交易量、話務(wù)量、座席通話率、核心交易筆數(shù)、工單等系統(tǒng)交易量


          • 交易異常情況數(shù)據(jù):交易成功率、失敗率、錯誤碼最多交易


          • 按服務(wù)器分析交易數(shù)據(jù):按server統(tǒng)計各服務(wù)交易處理筆數(shù),交易總耗時


          有了以上交易數(shù)據(jù),并通過監(jiān)控按一定頻率統(tǒng)計,運維人員在出現(xiàn)故障時,通過鼠標(biāo)即點擊即可看到故障什么時候開始,是系統(tǒng)內(nèi)部有問題還是關(guān)聯(lián)系統(tǒng)有問題,最突出的交易是哪一支,各服務(wù)器交易量是否均衡等情況。

          2、從監(jiān)控面上完善

          監(jiān)控最基本的工作就是實現(xiàn)對負(fù)載均衡設(shè)備、網(wǎng)絡(luò)設(shè)備、服務(wù)器、存儲設(shè)備、安全設(shè)備、數(shù)據(jù)庫、中間件及應(yīng)用軟件等IT資源的全面監(jiān)控管理。在應(yīng)用軟件類的監(jiān)控工作中,不僅需要有服務(wù)進程、端口等監(jiān)控,還需要有業(yè)務(wù)、交易層的監(jiān)控。

          全面性的應(yīng)用監(jiān)控可以讓故障提前預(yù)警,并保存了影響應(yīng)用運行環(huán)境的數(shù)據(jù),以縮短故障處理時間。

          3、從監(jiān)控告警上完善

          完善的監(jiān)控策略需要有清晰的監(jiān)控告警提示,值班人員要以根據(jù)監(jiān)控告警即可作出簡單的問題定位與應(yīng)急處理方案。比如類似以下的監(jiān)控短信:

          22時,【理財應(yīng)用系統(tǒng)】中【應(yīng)用服務(wù)器LC_APPsvrA 10.2.111.111】的【前置應(yīng)用模塊】出現(xiàn)【應(yīng)用端口:9080】不存在,該端口作用【提供理財應(yīng)用處理(負(fù)載均衡部署)】,原因可能為【SERVER1服務(wù)異常停止】,監(jiān)控系統(tǒng)己進行以下應(yīng)急處理【自動執(zhí)行端口進程啟動】,該事件緊急程度【高】。

          管理員可以通過短信內(nèi)容看到哪個系統(tǒng)、哪個應(yīng)用、哪個模塊出了什么問題,可能是什么原因,對業(yè)務(wù)有什么影響,是否需要馬上處理(比如凌晨出現(xiàn)此預(yù)警是否可以延遲到次日處理)等信息。

          4、從監(jiān)控分析上完善

          完善的監(jiān)控策略不僅需要有實時的數(shù)據(jù)告警,也要有匯總數(shù)據(jù)的分析告警,實時數(shù)據(jù)分析的告警的重要性不用多說,對于匯總分析的數(shù)據(jù)則能發(fā)現(xiàn)潛在風(fēng)險,同時也為分析疑難雜癥提供幫忙。

          5、從監(jiān)控主動性上完善

          監(jiān)控不僅僅是報警,它還可以做得更多,只要我們想辦法賦予它主動解決事件的規(guī)則,它便有為管理員處理故障的能力。

          三、應(yīng)急方案

          提前制定好故障應(yīng)急方案是很有必要的,但在日常工作過程中我們的應(yīng)急方案遇到一些問題:

          • 應(yīng)急方案缺乏持續(xù)維護,缺乏演練,信息不及時、不準(zhǔn)確;


          • 應(yīng)急方案過于追求大而全,導(dǎo)致不利于閱讀與使用;


          • 應(yīng)急方案形式大于實際使用效果,方案針對性不強;


          • 只關(guān)注應(yīng)急方案的內(nèi)容,但沒有關(guān)注運維人員對方案的理解;


          針對上述常見問題,應(yīng)急方案需要做到以下幾點:

          1、內(nèi)容精簡

          很多人可能會認(rèn)為故障出現(xiàn)的形式各種各樣,所以應(yīng)急方案需要涉及到方方面面。但實際的故障處理過程中,我們可以發(fā)現(xiàn)其實我們的應(yīng)急措施往往重復(fù)使用幾個常用的步驟,所以我認(rèn)為應(yīng)急方案要有重點,如果一個應(yīng)急方案可以應(yīng)對平時故障處理80%的場景,那這個應(yīng)急手冊應(yīng)該是合格的。過于追求影響應(yīng)用系統(tǒng)方方面面的內(nèi)容,會導(dǎo)致這個方案可讀性變差,最終變更一個應(yīng)付檢查的文檔。以下是我覺得應(yīng)用系統(tǒng)應(yīng)急方案應(yīng)該有的內(nèi)容:

          1)系統(tǒng)級

          能知道當(dāng)前應(yīng)用系統(tǒng)在整個交易中的角色,當(dāng)前系統(tǒng)出現(xiàn)問題或上下游出現(xiàn)問題時,可以知道如何配合上下游分析問題,比如:上下游系統(tǒng)如何通訊,通訊是否有唯一的關(guān)鍵字等。

          另外,系統(tǒng)級里還涉及一些基本應(yīng)急操作,比如擴容、系統(tǒng)及網(wǎng)絡(luò)參數(shù)調(diào)整等。

          2)服務(wù)級

          能知道這個服務(wù)影響什么業(yè)務(wù),服務(wù)涉及的日志、程序、配置文件在哪里,如何檢查服務(wù)是否正常,如何重啟服務(wù),如何調(diào)整應(yīng)用級參數(shù)等。

          3)交易級

          能知道如何查到某支或某類交易出現(xiàn)了問題,是大面積、局部,還是偶發(fā)性問題,能用數(shù)據(jù)說明交易影響的情況,能定位到交易報錯的信息。這里最常用的方法就是數(shù)據(jù)庫查詢或工具的使用。

          知道最重要的交易如何檢查是否正常,重要的定時任務(wù)的應(yīng)急處理方案,比如開業(yè)、換日、對賬的時間要求及應(yīng)急措施。

          4)輔助工具的使用

          有時候,需要借助一些工具或自動化工具輔助分析并應(yīng)急,這時需要有輔助工具如何使用的方法。

          5)溝通方案

          溝通方案涉及通訊錄,包括上下游系統(tǒng)、第三方單位、業(yè)務(wù)部門等渠道。

          6)其它

          上述5點內(nèi)容如何都完備,相信這個應(yīng)急手冊己可以解決80%的故障恢復(fù)工作。

          2、應(yīng)急方案是一項持續(xù)的工作

          有了應(yīng)急方案,如何讓運維人員持續(xù)去更新是難點。我認(rèn)為要解決這個難點,需要先讓運維人員經(jīng)常使用這個手冊。如果一個手冊沒有場景可以用,那就需要管理者為運維人員創(chuàng)造機會去使用這個手冊,比如應(yīng)急演練。

          3、關(guān)注運維人員對應(yīng)用關(guān)鍵信息的認(rèn)識

          前兩點關(guān)注了手冊,最后一點我覺得有必要關(guān)注使用這個手冊的人。有些運維人員認(rèn)為應(yīng)用運維人員沒有能力去把應(yīng)用系統(tǒng)本身的內(nèi)容了解得很透徹,所以應(yīng)用運維人員在故障處理過程中的地位很尷尬,運維人員掌握操作權(quán),但卻不知道應(yīng)該操作什么。

          對此,我認(rèn)同應(yīng)用運維人員不需要掌握應(yīng)用系統(tǒng)的業(yè)務(wù)功能,但我覺得就對應(yīng)用系統(tǒng)本身來講應(yīng)用運維人員需要具備以下最基本的能力:

          • 知道應(yīng)用系統(tǒng)這個是干什么的,基本的業(yè)務(wù)是什么;


          • 知道應(yīng)用架構(gòu)部署、上下游系統(tǒng)邏輯關(guān)系;


          • 知道應(yīng)用下的服務(wù)的作用、端口、服務(wù)級的應(yīng)急處理,日志等數(shù)據(jù)信息如何找到并簡單定位;


          • 知道應(yīng)用系統(tǒng)重要的時間點及任務(wù),比如開業(yè)、停業(yè)、換日、定時任務(wù)的時間點以及如何判斷這些任務(wù)是否正確;


          • 知道最重要的幾支交易的流程;


          • 知道常見數(shù)據(jù)庫表結(jié)構(gòu),并能使用。


          四、智能化事件處理

          處理方法如下圖(詳細(xì)的智能化涉及監(jiān)控、規(guī)則引擎、配置工具、CMDB、應(yīng)用配置庫等模塊協(xié)同工作)。

          來源丨網(wǎng)址:https://blog.csdn.net/Dou_Hua_Hua/article/details/108829245


          最近熱文閱讀:

          1、40 個 SpringBoot 常用注解:讓生產(chǎn)力爆表!
          2、3種常見的數(shù)據(jù)脫敏方案
          3、BigDecimal使用不當(dāng),造成P0事故!
          4、改造BeanUtils,優(yōu)雅實現(xiàn)List數(shù)據(jù)拷貝
          5、讓人上癮的新一代開發(fā)神器,徹底告別Controller、Service、Dao等方法
          6、SpringBoot 啟動時自動執(zhí)行代碼的幾種方式,還有誰不會??
          7、延時消息常見實現(xiàn)方案
          8、勁爆!Java 通用泛型要來了。。
          9、如何寫出讓同事吐血的代碼?
          10、遭棄用的 Docker Desktop 放大招!宣布支持 Linux
          關(guān)注公眾號,你想要的Java都在這里


          瀏覽 25
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  国产黄色免费 | 国产久久久久久久久 | 国产激情久久久 | 日本乱码视频在线播放 | 亚洲视频久久久 |