產品巡檢的心得體會

2021-10-09 04:27:00 字數 3297 閱讀 1009

公司是平台產品及技術解決方案的提供方,在目前公司依然承接實施專案,結合專案磨鍊產品及人員培訓,收集一線客戶需求不斷充實、細化、完善公司產品及交付體系。在實際專案推進過程中,如果平台出現不穩定及間歇性不能響應的情況,就會影響使用者的使用體驗,此類問題需得到高度重視,否則一旦成為客戶詬病之處需要花費更多時間和精力才能扭轉客戶對平台的認知。由於問題是間歇性發生難以實現高概率的重現,問題難以定位,因此需要對平台進行巡檢排查分析平台不穩定的原因。解決相關問題,保證平台的穩定性,提公升客戶的滿意度及體驗度。

本文是結合專案實際巡檢過程中的體驗、經歷及個人領悟的總結,為後續類似情況發生後的處理方式、方法提供參考借鑑。

整體工作推進過程中需要明晰當前有哪些問題,體現哪些現象,結合問題分析平台中的影響因素,分別對影響之處進行檢查確認,明確問題分析情況,影響因素及解決方式。

結合現場交付團隊整理內容及客戶現場表述,個人問題跟蹤所發現問題的情況對問題進行梳理,明確問題的種類、優先順序、責任人、時間計畫、驗證方式、核對負責人。此過程中重點在於收集、彙總、明確,結合問題的情況明確影響問題波動的功能**及配置,需要對相關涉及內容進行巡檢,檢查是否有問題引發的隱患。

首先:對於專案實施中的當前部署架構梳理,明晰產品部署情況、部署架構,結合實施團隊提供的部署架構及問題共同分析是否存在因部署而造成的問題影響。其次:對平台功能架構梳理是否能夠完全涵蓋支撐當前問題中描述的場景情況。最後:對產品級、專案級的功能**進行檢查,有無因**邏輯問題影響問題發生的影響。

解決問題的過程中有問題、有目標、有解決、有交付,首先需要對問題明晰,哪些是平台級別,哪些是專案級別,針對不同問題制定解決方式;結合問題分析明確每個問題的解決目標,與客戶明確後,進行優化迭代至解決問題達成問題解決的目標。

整理問題清單,包含分類、描述、優先順序、提出人、時間,問題分析,解決人、時間,驗證人、時間及交付補丁檔案版本,根據清單問題進行分類,劃分是平台級還是專案級明確相關負責人及解決時間。

平台級別:結合問題清單對訪問過程中需要涉及到的相關**進行巡檢,排查是否存在問題,如:效能影響的迴圈中運算元據庫;redis連線沒有設定密碼;查詢資料庫沒有過濾條件等;

配置級別:平台配置內容進行巡檢;典型包含:伺服器系統本身優化引數,中介軟體如:nginx、redis層面安全及效能;產品本身效能優化內容巡檢排查;

專案級別:專案實施過程中所擴充套件的**巡檢,巡檢遵循**巡檢規範;專案級制定對接方案梳理是否存在紕漏能否涵蓋全部業務場景;

結合問題清單中問題情況的分析,需要與專案團隊及客戶團隊明確最終對應問題的解決目標,明確問題的原因、整改責任人、解決時間及客戶方確認人、確認時間,保證問題的閉環,而不是自我主觀臆斷認為完成就關閉該問題。實際確認需要以客戶方提出人明確解決為準。

梳理部署架構及部署模式,對平台**級別,配置級別,伺服器級別分別進行巡檢,針對發現問題進行逐個解決,包含**優化、效能優化、伺服器優化。

部署巡檢: 部署結構、部署資源情況,部署伺服器優化情況統一確認檢查,明確核查內容、負責人及核查結果;

產品巡檢:問題相關功能**巡檢,結合本身**規範機制及邏輯梳理,排查問題影響因素;

有問題、有分析後需要著手落實解決問題,對問題不斷迭代優化,優化過程有整理、有記錄、有驗證、有對比、有分析,證明優化內容為真實有效的。

效能問題:需要對伺服器、中介軟體、產品進行效能優化,明確各節點引數及優化結果;產品上典型為新增快取機制,對於動態資訊需要核查優化**邏輯,減少頻繁請求資料庫互動;

功能問題:功能問題需要具體分析,首先需要保證功能的可用性,然後結合**進行優化分析,有針對性的調整、驗證、交付;

問題交付後需要說明功能驗證方式,調整內容,輸出整體巡檢調整過程,問題分析梳理交付產物交付客戶,持續跟進5~7天是否重現問題至關閉。

問題驗證劃分幾個階段,負責人內測、專案團隊測試、客戶驗證測試、跟進觀察測試,如果問題解決穩定執行一周內依然沒有復現則視為問題關閉。

負責人內測:功能負責人完成功能調整需自身對功能進行單元測試,保證功能的可用性;整理交付內容以郵件的方式傳送公升級補丁包;

專案團隊測試:專案團隊需要對交付客戶功能負責,對開發人員交付功能進行複測,能否滿足問題解決目標,然後轉交客戶驗證測試;

客戶驗證測試:客戶驗證測試作為問題閉環的重要環節,根據使用者驗證反饋總結記錄問題驗證人及時間,標誌問題進一步狀態;

跟進觀察測試:對客戶反饋通過驗證的問題跟進觀察如果7天內沒有再次重現則標誌著問題關閉,實現問題的閉環;

輸出整體排查過程,對平台部署架構、巡檢過程、記錄發現問題、對應的解決方案及驗證監控進行總結記錄,輸出相關產物作為上一節點的總結輸出;典型交付內容如下:

部署架構說明:專案中產品部署體系、部署架構說明文件,包含部署架構圖、伺服器ip、部署目錄位址及伺服器配置資訊等;

巡檢狀態說明:結合巡檢過程的巡檢內容的狀態說明,如:伺服器狀態、中介軟體日誌狀態、集群狀態、產品效能狀態等;

巡檢問題清單:巡檢過程中發現的問題及客戶使用過程中發現的問題清單,主要明確責任人、時間、驗證人、時間;

總體巡檢報告:結合整體過程輸出巡檢的報告,包含解決方案,驗證方案、結果及跟進監控狀態;

問題驗證後不是真實意義上的問題關閉,驗證後需要緊密跟蹤觀察相關問題是否依然有反覆出現或連帶影響其他業務場景的使用,對於問題緊密觀察跟進7天後,如果沒有再次復現問題則標記問題為關閉狀態,如果出現場景涵蓋不全情況需要進一步迭代優化至連續7天不再重現,標記問題關閉。

再成熟的產品也會出現掛萬漏一的情況,專案交付過程好比人生,過程**現問題、挫折是常態,有問題並不可怕關鍵的是如何快速的響應、解決問題,不要讓問題發酵、膨脹,出現問題直面應對、把握時機、響應解決。

對於問題的原因有的理解分析及對應的解決方案,且能夠與客戶交流清楚具體的原因及問題以及相應的解決方案;有理有據的說明問題原因所在,不是自身的問題需要明晰相關責任人共同推進;自身問題也不推諉積極響應解決,提供解決問題的計畫及時間節點,推進下一步工作,且工作進度同步客戶實現工作推進的透明化。

面對使用者的反饋不要消極反饋,而是積極應對,讓客戶安心,增加客戶的信心,客戶對平台的信心是需要逐步累積及建立的,客戶反饋的問題需要高度重視,不要拖沓,把握問題解決的時機有效建立客戶對平台的信任度及認可度。如果平台出現問題,團隊承認缺不積極響應則會造成客戶的信任度不斷的降低,當客戶認知形成固式後,需要花費更大的精力、心力才能扭轉認知。

領導也是一種資源,不要畏懼領導的評價為不反饋突出問題的重要性。現場團隊是以實際專案最終結果論成敗的,團隊成員需要以實際專案走向為驅動,為專案爭取優質資源推進專案發展,而不是因個人畏懼而任由專案「鋌而走險」。當然資源是解決問題的一種有效途徑,卻不是必要途徑,不能產生依賴心理,需要自身從內心直面問題、分析問題、分析解決方案,進一步落實解決。

有開始就要有結束,問題最終是需要被關閉處理的,而團隊反饋問題後需要對問題進度有跟進,接收交付驗證後需要推動客戶進一步確認,持續跟進問題的**情況,至問題關閉,形成問題的閉環。而不是只反饋不跟進這樣問題會越來越多無論是對專案交付還是客戶認證均是無任何益處的。

PHP PDO 心得體會

關於pdo 我想可以不用做過多的描述,寫一寫最近的使用心得體會 首先 關於如何使用pdo 連線到資料庫 dbms mysql 使用的資料庫 host localhost 選擇的主機 dbname test 選擇的資料庫 user root 登陸的使用者名稱 password 使用者密碼 dsn dm...

銷售心得體會

銷售思維的培養 1.裝可憐讓客戶動惻隱之心是一種方法但是不適合男人 2.身處高位的銷售領導往往擁有給客戶的折扣和動用資源的優勢,不要當綠葉,要按兵不動尋找時機 3.市場上的大客戶與哪家合作就會成為標桿事件,哪家公司就會成為一線公司。4.站在客戶的角度,在業務上給予中肯的意見,得到客戶的感謝和認可。5...

面試心得體會

最近開發人手短缺成了大問題,因此招人也成了乙個重要任務。通過這幾天的面試,對這方面有了一些心得體會。一是it企業需要哪方面素質的人才。我感覺關鍵有兩條,一是能幹活,二是能合作。企業為什麼青睞有經驗的人?因為來了就能幹活。當然對於學生而言,經驗缺乏是一大缺陷,這就要展現另一方面 我具備成為幹活能手的能...