任務調度產品經理如何備戰618?
編輯導讀:618作為一年中最重要的兩個促銷活動之一,會涉及到各個部門各個系統。而作為一名任務調度產品經理,要如何開展工作,為618保駕護航?本文作者對此進行了分析,與你分享。
618是電商的大日子,各路人馬各顯神通。作為中臺系統的小伙伴兒們,在“見不得人的中后臺”各種忙活。我們揭開它的神秘面紗,探究這群“地下”工作者們,是如何為618保駕護航的,如何讓那千萬臺冷冰冰的服務器協作起來、支撐PB級的數據運轉,保障百億級訂單,千億級別的GMV的達成……
故事,從大數據平臺的核心環節“調度平臺”說起,任務調度是大數據平臺離線計算的重量級產品,它既承載了各類數據庫與數據集市間的同步工作,還承載了各類的離線數據計算工作。主要的應用場景是數據的管理、搬運、計算、存儲。
目前任務調度支持多種任務類型,包括:普通任務、數據計算(py/sh/zip)、數據入庫任務、數據出庫任務、數據拉鏈任務、數據同步(JDW到Jmart)。
- 數據計算(py/sh/zip):調度可以支持python、shell、jar等多種腳本類型,提供強大的計算能力可定時功能支持數據的分析運算。
- 入庫任務:目前任務調度支持從MySQL、HBase、ElasticSearch、Oracle、mongodb、SQLServer、log、phoenix多種數據源抽取數據到數據倉庫的bdm層。
- 出庫任務:支持從Hive推送到包括MySQL、jss、HBase、Oracle、jinggo、postgresql、ElasticSearch、jimdb、phoenix等多種數據庫。
- 數據拉鏈任務:支持將bdm層的流水表,加工成fdm層的拉鏈表。
- 數據同步(JDW到Jmart):支持將數據從數據倉庫,同步到數據集市。
通過任務調度系統,可以方便快捷的管理定時任務,支持任務間建立依賴關系,任務的快速補數和重跑,以及強大的監控功能,提供良好的作業管理服務。
任務調度以強大的技術能力保障618的各種任務、那么作為調度的產品經理如何保障618呢?
一、事前:制定大促保障策略&宣貫、執行資源傾斜
準備工作一:制定任務等級劃分規范、分等級保障機制和管控規范
將任務等級劃分為:0級、1級、2級、3級。0級:公司核心業務,數據面向對象為外部客戶或內部VP、一級部門領導及以上。一旦發生不可用會直接影響外部客戶合作項目,可能造成P0-P2級事故發生。
- 1級:數據面向對象為二級部門領導,一旦發生不可用會影響跨一級部門或以上合作項目,可能造成一般事故(P3級)的發生。
- 2級:數據面向對象為三級部門領導,一旦發生不可用會影響二級部門內部項目。
- 3級:數據面向對象為三級部門內部,一旦發生不可用會影響三級部門內部項目或個人報表數據。調度平臺會根據設置的等級進行資源的分配
?準備工作二:制定調度任務和質量檢測的降級策略
制定任務調度的降級策略:
- L0、L1提供專屬監控,保障任務及時收到告警通知。
- 大促期間資源緊張時平臺會對L2、L3采取任務延時抽取策略和任務一鍵推遲策略
- 必要時刻為L0、L1任務開啟綠色通道保障任務正常運行。
- L0、L1任務節點資源優先分配。
- 針對任務關鍵屬性的修改以及任務禁用等高風險操作,平臺針對不同級別有不同的管控策略。
制定數據質量的降級策略:
- 質量規則執行時長達到30分鐘,會給質量分區負責人、關聯調度告警人發送提醒,確認是否做干預;
- 質量規則執行時長達到60分鐘,系統自動終止質量檢測,關聯調度任務正常執行,本次質量檢測失效,并給質量分區負責人、關聯調度告警人、質量管理員發送通知。
準備工作三:制定調度任務的封板管理措施(新建、拷貝,禁用、重跑等)
在大促備戰期間如果有用戶進行任務的創建及拷貝,由于新任務的安全性得不到保證,會存在諸如性能低、資源占用高等風險,影響系統穩定性等問題,針對上述問題產品制定了如下管控措施:禁止新建和拷貝任務,需二級部門負責人審批。
對于新建任務項需要逐一檢查,包括:
- 關注任務周期為小時、分鐘;
- 評估任務對系統的影響;
- 檢查出庫任務SQL的where條件;
- 建議用戶配置任務監控及超時時間。
對于拷貝的任務建議轉為新建任務,按照新建任務進行檢驗。如果沒有轉換要確認一下幾項:
- 確認原任務的近一周執行情況,如運行異常,溝通具體原因;
- 確認新任務與原任務的邏輯差別,包括SQL、參數等;
- 確認所屬應用、負責人、集市、隊列、賬號與申請單填寫的信息一致;
- 任務描述包含“通過流程申請拷貝,申請單ID及原任務ID”;
- 運行規則配置屬性檢驗:周期類型、運行時間與申請單一致。超時時間必填,需溝通確認。最大并發實例數選擇為10以內。
- 與用戶確認節點編號;
- cgroup配置與用戶核實,避免資源不夠被kill或執行慢;出庫任務,建議對于內存在推薦值上上浮1G;
- 任務監控,推薦配置。對于啟用任務、修改任務運行規則、修改抽數sql、模型變更、修改任務屬性等操作,均有可能對系統的穩定性造成影響,需要二級負責人進行審批,停止接口的申請、任務調度3.5升級,其他任務非大促相關接入申請不再審批。對于數據質量服務異常導致無法校驗數據是否符合要求時,對服務進行降級。
準備工作四:保障策略宣貫
按天發送調度任務等級劃分策略宣貫郵件。2.用戶視頻培訓,主要針對離線平臺、常用場景、監控告警配置、調優策略、大促保障五個方面為用戶做介紹。保證用戶在大促期間充分了解調度保障策略。
準備工作五:資源傾斜,保障重點業務
產品經理推進用戶去評估任務的等級,并進行變更,對L0、L1的任務必須要配置告警和質量;對于核心業務,?數據質量檢測時長超過5分鐘,需配置超時策略,避免影響SLA;對于管控和保障大促穩定性的措施,產品經理對產品功能做相應的設計、跟進落地上線。做好大促保障的每一環。
二、事中:啟用保障策略
1)嚴格執行封版管控措施
雖然在5月25號任務調度平臺會進行封版的管控,但期間仍有特殊場景或業務進行任務的新建和修改,此時需要二級部門負責人進行審批。比如,在大促期間一個部門要批量禁用所有任務,此時產品經理就要考慮幾個問題:
- 是禁用一次還是大促期間多次啟用禁用?
- 是否所有任務都歸屬于這個部門?
- 禁用所有任務都價值?
- 會產生哪些不利的影響?
- 操作完成所需的時間?
- 任務的生效時間和失效時間。
這些都是產品經理需要在研發之前把控的信息。這些信息需要業務方提供,由產品經理來衡量是否可以提供封版期間禁用任務的白名單權限。一般這種批量禁用任務的情況都是業務方為了保證高級別任務的穩定。所以產品應該做好把控,做到靈活應對,即不影響業務穩定,又快速解決業務面臨的問題。
2)優先保障高級別任務平穩運行
同一隊列中運行的多種級別任務會爭搶資源,如果在線上核心數據出現問題需快速恢復、大促活動產生極大數據量等應急場景下,需優先保障高級別任務平穩運行。這時需要啟動一鍵推遲功能,下面介紹一下一鍵推遲功能:
- 點擊“推遲”,導入需推遲的任務id,填寫推遲時長及自動恢復時間;
- 發起審批流程,審批通過后,這些任務推遲成功,系統發郵件給當前任務及下一層任務的負責人;
- 在推遲后,還未恢復前,可”繼續推遲“,點擊繼續推遲,也要發起審批,審批通過后,繼續推遲任務成功,系統發郵件給當前任務及下一層任務的負責人;
- 到達自動恢復時間后,推遲的任務自動恢復到原始的計劃執行時間,5.如果還未到達自動恢復時間時,也可以點擊”恢復“,任務提前恢復到原始的計劃執行時間。
3)值班保障
針對任務調度的保障策略和大促期間的緊急事項如果用戶有疑問,提供交流群群答疑并且每日安排固定的值班人員進行答疑。對于用戶的咨詢做到及時回復,讓用戶充分了解任務調度的保障策略
在618期間,產品經理會在11點就開始堅守在電腦前,目不轉睛的各自盯住顯示器,一旦某臺機器、某個業務、某條鏈路出現一點點的波動,他們都能第一時間看到,流量上漲、積壓、抖動,出現問題及時跟進,推動解決,及時報備問題。
三、事后:復盤、總結
因為調度平臺上跑著很多離線任務,所以到6月19號的凌晨才會解除平臺的封版,大促結束之后要對出現的問題進行復盤、總結、歸檔。
- 明確備戰的節奏:首先明確公司整體的備戰節奏,跟隨大節奏進行壓測、故障預演、災備演練;
- 建立良好的溝通機制:提前與業務進行溝通,收集業務需求和業務等級有無變更情況。做到及時響應靈活應變。
- 提前預估業務峰值情況:搜集每年大促業務的峰值情況,進行數據對比,做回歸分析,預測業務今年的情況,可以做到合理利用資源。
- 制定更完善的管控策略:從用戶的應用場景出發,預想到每個場景會遇到的問題及風險,比如創建任務、拷貝任務、任務啟用、實例重跑、修改任務運行規則等。
對于電商來說618意義非凡,雖然作為偏底層的產品經理,離618業務較遠,但是也在用行動保障大促平滑穩定。
本文由 @斗羅魂靈 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
- 目前還沒評論,等你發揮!