一般從早上八點開始，服務的存取量就會漸漸地升起來，初始爬坡會比較緩，大概到10點左右會走到頂峰，然後會趨向平穩波動。

作為公司的後臺服務研發人員，早上到公司第一件事情就是開啟監控，檢視服務的各項指標是否正常，及時解決各種突發狀況。

監控系統是 Prometheus + Grafana， Prometheus 負責監控資料層面獲取處理，Grafana 負責監控資料面板展示及報警預警。

• 基礎面板

  基礎面板包括於各個服務，主要指標有 CPU、Mem、I/O、網路卡頻寬、程序存活等

• 應用服務監控面板

  整體：qps、延遲、執行緒池，異常相應率等。

  介面層級：qps、延遲。

• 資料服務監控面板

  mysql：qps、連線數、主從延遲、slow log等。

  redis：qps、延遲、連線數、容量、鍵增量，鍵過期、慢查詢等。

  mq：業務通道訊息量及消費狀況，

• 報警預警

  監控系統支援閾值觸發報警，實時傳送通訊軟體接收，相當於 OnCall 狀態了。

一套成熟完善的監控系統對於掌控服務狀態是必需的，而且至關重要。它需要涵蓋整個服務鏈條，包括流量入口閘道器、應用服務、資料服務、網路等。

除此之外，還需要結合紀錄檔系統來綜合評估服務的健康狀況。通常需要檢查各個級別紀錄檔率。如error 紀錄檔量、整體的紀錄檔增量等。

紀錄檔系統，ELK 一套客製化，filebeat 做紀錄檔收集，kafka 資料傳送、logstash 資料格式處理轉換、elasticsearch、kibana 資料查詢展示。也可以做一些簡單的近實時統計性預警。

檢查完系統，大概需要15分鐘左右。如果沒有特別需要處理的問題，那麼就進入下一階段任務處理。

到這裡基本就是組內資訊彙集，溝通，協調環節。

每個人手裡的工作進度，是否有阻塞的問題，內外部資源需求，當天的工作計劃等。

這是一個很重要的環節，保持組內資訊互通及一致性是維持團隊正常、高效共同作業的基礎。

例如，一個對於對於 A 來說比較麻煩的問題，可能 B 已經處理過了，A 如果再解決一次那就是巨大的資源浪費了，同時也沒有必要。

對於內外部資源需求，可能涉及到測試環節測試資源引入，新伺服器擴容 SRE 資源協調等。個人協調效率不高的話及時向上反饋，由上一層級推動。

當前工作計劃，每個人可以按照各自的實際情況合理安排，要綜合考慮日常運維時間佔用及部門共同作業時間花費。

公司的業務發展會伴隨著層出不窮的新業務需求，這也是一個公司健康發展的標誌。

新的業務需求分配，需要根據每個人的負責域及進行中任務等因素來考量。通常來說，一個業務組內，不同的業務模組，人員都是主輔搭配的。比如，A 主要負責 A1 模組，並且 backup B1 模組，同樣，B 則主要負責 B1 模組 backup A1 模組。這種方式也是為了應對人員缺席及任務集中導致的技術資源緊張問題。

1、前期溝通

前期需要和產品方面大致的溝通需求形態，確認可行性、風險性及未來預期。

2、需求評審

確認沒問題的話，就要和各個關聯方（產品、測試、前端、其它業務組等）共同參與需求評審。

首先產品會通過 prd 展示進行整體需求闡述，包括目標，形態，roi 預期，週期等。

技術方需要綜合各個功能點實現難度及必要性給出意見。然後就具體需求細節，考量現有服務、資源支撐及前端評估反饋，給出初步技術方案。

需求排期方面，在既定週期下，各個關聯方給出初步排期。開發周、測試周，多了，少了協調協調再協調。

3、技術方案

需求確定了（只能認為是確定了），研發就要開始發發力了。

一般一個產品需求會由某一個業務組做主導，輸出詳細的技術方案。給到協助業務組及前端等。

對於比較複雜的技術方案，一般需要開技術評審會，評審包括行不行，哪裡不行，怎麼會更好。具體涉及過多，不做詳細評述。

4、開發、聯調、測試、上線、驗收

開發 coding。

前後左右各種聯調。

自測、提測、功能測試、整合測試。

上線，驗收，公測、灰度，放量。

什麼叫日常運維及支援呢？

客戶各種各樣的問題需要要幫忙排查。

線上各種的業務報警需要及時響應處理。

別的業務組要使用組內業務資料需要對接支援。

測試人員有些業務測試資料需要設定支援。

... ...

等等