■ 浙江 張江山
編者按:筆者單位的信息中心的重點工作是快速排查解決信息系統生產問題、保障信息系統安全運行。經實踐后,對信息系統生產問題分析處理進行總結歸納,并提煉成最佳實踐,本文將進行詳細探討和分享。
生產問題是信息系統運行使用過程中遇到的各種需要研究討論并加以解決的矛盾和疑難,用戶在使用信息系統過程中如果遇到功能、性能、權限以及數據等各種與實際預期不相符合的異常狀況,站在用戶角度都會將此狀況報告為問題并要求技術人員進行處理解決。
目前的工作中,解決生產問題,除了對技術的掌握外,對人本身經驗有一定依賴,本文主要從問題分析、問題解決、防范建議等幾個方面展開一些探討,力爭對經驗進行提取和整理總結,形成最佳實踐,對更好地解決生產問題提供參考和幫助。
當一個系統生產問題發生時,可能是由技術監控手段報告,也有可能是老師或學生在使用系統時遇到問題后反映。
分析生產問題的第一步是要對問題現象做精確的描述和記錄,例如時間、范圍、人員、動作或異常現象等。對已知問題可以直接利用問題案例庫進行解決。對未知問題的處理思路。
應用系統運行在各種IT設施之上,應用的生產問題并不只是由程序缺陷引起,可源自于底層的基礎設施、用戶的操作等,按發生的位置來分,也可以分為客戶端和服務器端。
當得到一個問題現象的描述時,首先要對該問題進行初步的定位,為進一步問題分析縮小范圍,常用的預判思路有:
1. 單個用戶反映的客戶端問題需要認真確認現象,此類問題通常是操作不熟悉或者客戶端環境引起。但當有3個以上用戶同時報一個問題現象時,可初步歸為服務器端問題或者應用客戶端軟件缺陷。
2. 跟業務邏輯相關的現象,初步先排除IT基礎設施問題 。
3. 底層的故障通常會帶來上層大面積故障,但越往底層,出錯概率越低 。
在有了初步判斷后,就要查找理清問題原因。一個問題的發生,并不是簡單的因果關系,通常是存在一個原因鏈,當一個或多個起始原因發生,在系統本來運行機制的控制下,一環環影響,最后一環(直接原因)造成了問題的發生,現象能被監控到或者被反映出來。
例如:某次變更修改課程管理系統的后臺文件生成策略->每天產生1萬個空文件->主備機同步比往常延遲半小時才能完成,備機不能按時獲取到課程排版文件->連接到備機的用戶無法及時下載到課程排版報表。
分析問題,首先要求系統運維人員要了解整個應用系統的運行機制,主要包括應用拓撲結構、配置信息、數據流、系統關聯關系、重要業務邏輯。其次就要排查問題原因,借鑒軟件測試相關理論,排查問題原因也可以有兩種方法,即白盒法和黑盒法。白盒法指的是通過搜集信息方式來分析問題。黑盒法則是通過找變化、找規律、找聯系,從外部來進行推理。
分析問題能夠對根治問題提供幫助,也能夠通過理清脈絡來排除問題發生的隱患。但是當問題發生時,盡快恢復對外服務、消除后續影響才是首要目的。因此在遇到未知問題并且短時間內找不到解決方案時候,首先從盡快先消除和減少影響面入手,采取應急臨時解決措施,而不是一味地在業務影響時間內鉆牛角尖去找出問題原因。
目前我校信息系統應急預案大部分都是針對這類場景,如在遇到突發性不可預知的設備故障時,首先就是采取通過應急切換之類的手段隔離故障機器,恢復業務使用,或者在遇到一些進程或者用戶訪問突然異常時候,往往先嘗試緊急重啟相關應用服務進行初始化操作。
在目前的運維實踐過程中,從問題所產生的影響來看,主要有性能類、數據類、功能類、進程類、接口類等幾個方面。
根據對最近半年的信息系統數十個生產問題進行初步統計,問題所表現出來的影響主要體現在數據異常、進程異常和功能異常上,但是從問題原因分析難易程度來看,性能和進程方面的排查耗費精力較多,難度也相對較大。
性能類問題是目前運維過程中經常遇到的問題,主要集中在用戶并發訪問量大的教學管理系統和校園網站,現象就是系統響應緩慢甚至不能訪問,從技術角度來看會有三種情況,系統資源瓶頸、參數或設計缺陷、數據量或用戶訪問超常規增長。
不同的情況原因有不同的應急解決辦法,用戶反映性能問題后,首先需要檢查系統資源使用情況了解到瓶頸所在的層次,如果是系統資源層面如CPU、內存已經達到閥值,則要考慮緊急擴容或臨時限制用戶使用以確保當前資源能滿足一定范圍的用戶訪問,這種措施雖然會影響一部分用戶使用,但是至少不會引起全面的系統堵塞現象。
如果系統資源檢查結果正常,同時用戶訪問量沒有明顯擴大的情況下,則需要考慮系統參數設置或者應用設計缺陷導致的問題,檢查數據庫和中間件的參數設置是否合理,程序設計特別是SQL語句是否存在效率問題。
遇到此類情況,比較常見的應急措施是重啟應用,使被占滿的應用資源進行初始化。
如果能充分預估到可能出現的性能瓶頸,可以通過相關壓力、容量等測試進行規避或者提前防范。
數據類問題一般由用戶反映業務數據出現錯誤需要排查解決,這在學生信息庫、課程管理系統等數據敏感系統中比較常見,由于數據產生的邏輯往往可以追溯,因此針對該問題往往從兩方面入手排查:
首先就是排查數據源是否正確,此外需要根據程序處理邏輯逐步排查數據出錯在哪個環節,必要時需要手工進行計算比較。原因一旦明確就可以做相應的修復處理。
功能類問題往往與軟件缺陷直接相對應,針對用戶通過客戶端使用后反映的功能問題,如果是直接界面上可以看出的異常,在確認用戶權限、使用方式等正確情況下,則一般可以定位是程序缺陷,進一步根據日志和程序邏輯通過對該錯誤現象進行追溯,定位到問題根源。
針對此類問題,首先要了解到是否首次發生、是否普遍現象,如果用戶之前可以正常使用此類功能,從用戶權限、客戶端環境、現場數據、使用方式、最近變更情況等去排查引發此功能問題的原因。
進程異常類問題經常是生產問題中最為棘手問題之一,進程異常特別是進程突然掛起或僵死,一方面發生比較突然并嚴重影響業務使用,需要快速恢復,另一方面經常遇到排查此類問題時候缺乏清晰的系統日志記錄和現場保留信息,同時由于進程所在環境的復雜性,排查此類問題需要硬件、操作系統、數據庫、中間件、應用自身等同時排查取證,協調難度較大。
目前針對該問題也積累了一些常用幾種排查和處理經驗:針對常見的如JAVA進程突然僵死之類的問題,往往需要通過dump文件及時采樣當時的內存信息分析。進程問題往往也與操作系統參數設置關系密切,特別是某些應用系統在運行過程中會針對不同的應用請求開啟不同的服務進程,考慮到應用進程數都是最終占用了操作系統層面的進程總數,因此操作系統進程參數如果設置過低則會嚴重影響到應用進程數的增加。
如果進程問題解決較難,可以定期在非工作時間段重啟進程甚至重啟整臺機器,通過重啟進行初始化操作,因為生產系統運維的核心目標首先是滿足用戶在服務時間內運行正常。
通俗地理解,只要有數據的交互或者系統之間的連接就可以定義為接口,如接口數據傳輸、數據庫連接、API連接、進程間通信等,接口數據問題的排查思路可以借鑒數據問題的排查思路,主要就是通過檢查日志等方式尋根溯源,接口問題比較困難的可能是用戶往往只是反映數據或者功能問題,但是最終是因為模塊或者系統間數據通信異常導致。
針對此類問題,首先就是運維人員要在開發階段要提出詳細的運維需求,特別是數據交互過程中日志記錄需求,能將所有程序運行過程通過詳細的日志記錄下來,其次要有完善的接口方面的應急預案。
對一些比較顯現的接口數據來往,一旦遇到問題,可以通過其他變通方式將數據傳輸到下游系統。對于一些不能直接采用手工處理的接口,則需要實現制定完善的應急預案,最好對接口傳輸有備用的變通手段。
相比教學業務需求主要是從系統具體功能考慮,運維需求則就是面向安全運行、面向日常運維操作效率考慮,運維需求提的內容主要就是有助于應用系統運行更安全、更可靠、更可控,有助于日常運維和應急處理效率更高,最終目的其實也是為了更好地支持業務開展,保障系統服務水平。
常見的運維需求主要都是從應用可靠性、可用性、安全性、環境兼容性、日志規范、監控需求、運維人機界面、安裝部署規范等一些方面考慮。
不同的業務特點有不同的運維需求,如針對教學管理系統,首先強調的是穩定可靠和性能效率,而針對學生信息庫、信息網站則更強調批量處理性能和報表訪問效率以及應急數據處理的便利性等方面,完善的運維需求不僅可以減少問題發生概率,同時還能有助于更快地分析定位問題原因和解決問題。
測試不僅僅用于檢驗系統是否滿足業務要求,同時也是用來檢驗系統是否滿足安全運行要求,在設計測試案例過程中,需要充分考慮到對業務和技術邊界臨界場景的覆蓋,站在運維角度,還希望在測試過程中增加一些“破壞性”場景以檢驗系統的可靠性和應急預案是否有效,特別是對核心教學系統尤為重要。
如前文所述,問題現象的發生都存在一條原因鏈,問題暴露在發生鏈越后端處理起來越復雜棘手。很多問題如性能、資源等方面的發生都有前兆,所以要充分利用一些已有的監控工具,對應用運行的關鍵點進行不間斷監控,除了資源利用率、進程、差錯日志等常規監控以外,條件允許的話,還要對運行質量進行監控,如數據一致性、程序響應時間、用戶訪問異常行為等,目的是能及時發現問題出現的征兆,贏得問題排查處理時間,減少對教學業務的影響。
除此之外,包括各個IT環境之間的系統配置一致性、數據一致性、安全策略實施、系統軟件補丁升級等也都是事先發現問題和防范問題的重要方面。
在具體的問題處理案例中,不同類型的應用系統處理方式不同,所采用的技術、要求的技能、緊急程度等也往往不同,本文討論的主要是一些校園信息系統領域的生產問題處理思路,并總結一些最佳實踐。
隨著信息技術的日新月異發展和應用系統不斷地升級開發,整體系統環境越發復雜。因此,要提高問題處理效率,首先就是要不斷地加強對信息系統的技術掌握、充分熟悉校園信息系統特點、完善問題管理流程、維護好問題處理知識庫、積累技術經驗提高問題處理能力。