一般從早上八點(diǎn)開始，服務(wù)的訪問量就會(huì)漸漸地升起來，初始爬坡會(huì)比較緩，大概到10點(diǎn)左右會(huì)走到頂峰，然后會(huì)趨向平穩(wěn)波動(dòng)。

作為公司的后臺(tái)服務(wù)研發(fā)人員，早上到公司第一件事情就是打開監(jiān)控，查看服務(wù)的各項(xiàng)指標(biāo)是否正常，及時(shí)解決各種突發(fā)狀況。

監(jiān)控系統(tǒng)是 Prometheus + Grafana， Prometheus 負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)層面獲取處理，Grafana 負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)面板展示及報(bào)警預(yù)警。

• 基礎(chǔ)面板

  基礎(chǔ)面板包括于各個(gè)服務(wù)，主要指標(biāo)有 CPU、Mem、I/O、網(wǎng)卡帶寬、進(jìn)程存活等

• 應(yīng)用服務(wù)監(jiān)控面板

  整體：qps、延遲、線程池，異常相應(yīng)率等。

  接口層級(jí)：qps、延遲。

• 數(shù)據(jù)服務(wù)監(jiān)控面板

  mysql：qps、連接數(shù)、主從延遲、slow log等。

  redis：qps、延遲、連接數(shù)、容量、鍵增量，鍵過期、慢查詢等。

  mq：業(yè)務(wù)通道消息量及消費(fèi)狀況，

• 報(bào)警預(yù)警

  監(jiān)控系統(tǒng)支持閾值觸發(fā)報(bào)警，實(shí)時(shí)發(fā)送通訊軟件接收，相當(dāng)于 OnCall 狀態(tài)了。

一套成熟完善的監(jiān)控系統(tǒng)對(duì)于掌控服務(wù)狀態(tài)是必需的，而且至關(guān)重要。它需要涵蓋整個(gè)服務(wù)鏈條，包括流量入口網(wǎng)關(guān)、應(yīng)用服務(wù)、數(shù)據(jù)服務(wù)、網(wǎng)絡(luò)等。

除此之外，還需要結(jié)合日志系統(tǒng)來綜合評(píng)估服務(wù)的健康狀況。通常需要檢查各個(gè)級(jí)別日志率。如error 日志量、整體的日志增量等。

日志系統(tǒng)，ELK 一套定制，filebeat 做日志收集，kafka 數(shù)據(jù)傳送、logstash 數(shù)據(jù)格式處理轉(zhuǎn)換、elasticsearch、kibana 數(shù)據(jù)查詢展示。也可以做一些簡(jiǎn)單的近實(shí)時(shí)統(tǒng)計(jì)性預(yù)警。

檢查完系統(tǒng)，大概需要15分鐘左右。如果沒有特別需要處理的問題，那么就進(jìn)入下一階段任務(wù)處理。

到這里基本就是組內(nèi)信息匯集，溝通，協(xié)調(diào)環(huán)節(jié)。

每個(gè)人手里的工作進(jìn)度，是否有阻塞的問題，內(nèi)外部資源需求，當(dāng)天的工作計(jì)劃等。

這是一個(gè)很重要的環(huán)節(jié)，保持組內(nèi)信息互通及一致性是維持團(tuán)隊(duì)正常、高效協(xié)作的基礎(chǔ)。

例如，一個(gè)對(duì)于對(duì)于 A 來說比較麻煩的問題，可能 B 已經(jīng)處理過了，A 如果再解決一次那就是巨大的資源浪費(fèi)了，同時(shí)也沒有必要。

對(duì)于內(nèi)外部資源需求，可能涉及到測(cè)試環(huán)節(jié)測(cè)試資源引入，新服務(wù)器擴(kuò)容 SRE 資源協(xié)調(diào)等。個(gè)人協(xié)調(diào)效率不高的話及時(shí)向上反饋，由上一層級(jí)推動(dòng)。

當(dāng)前工作計(jì)劃，每個(gè)人可以按照各自的實(shí)際情況合理安排，要綜合考慮日常運(yùn)維時(shí)間占用及部門協(xié)作時(shí)間花費(fèi)。

公司的業(yè)務(wù)發(fā)展會(huì)伴隨著層出不窮的新業(yè)務(wù)需求，這也是一個(gè)公司健康發(fā)展的標(biāo)志。

新的業(yè)務(wù)需求分配，需要根據(jù)每個(gè)人的負(fù)責(zé)域及進(jìn)行中任務(wù)等因素來考量。通常來說，一個(gè)業(yè)務(wù)組內(nèi)，不同的業(yè)務(wù)模塊，人員都是主輔搭配的。比如，A 主要負(fù)責(zé) A1 模塊，并且 backup B1 模塊，同樣，B 則主要負(fù)責(zé) B1 模塊 backup A1 模塊。這種方式也是為了應(yīng)對(duì)人員缺席及任務(wù)集中導(dǎo)致的技術(shù)資源緊張問題。

1、前期溝通

前期需要和產(chǎn)品方面大致的溝通需求形態(tài)，確認(rèn)可行性、風(fēng)險(xiǎn)性及未來預(yù)期。

2、需求評(píng)審

確認(rèn)沒問題的話，就要和各個(gè)關(guān)聯(lián)方（產(chǎn)品、測(cè)試、前端、其它業(yè)務(wù)組等）共同參與需求評(píng)審。

首先產(chǎn)品會(huì)通過 prd 展示進(jìn)行整體需求闡述，包括目標(biāo)，形態(tài)，roi 預(yù)期，周期等。

技術(shù)方需要綜合各個(gè)功能點(diǎn)實(shí)現(xiàn)難度及必要性給出意見。然后就具體需求細(xì)節(jié)，考量現(xiàn)有服務(wù)、資源支撐及前端評(píng)估反饋，給出初步技術(shù)方案。

需求排期方面，在既定周期下，各個(gè)關(guān)聯(lián)方給出初步排期。開發(fā)周、測(cè)試周，多了，少了協(xié)調(diào)協(xié)調(diào)再協(xié)調(diào)。

3、技術(shù)方案

需求確定了（只能認(rèn)為是確定了），研發(fā)就要開始發(fā)發(fā)力了。

一般一個(gè)產(chǎn)品需求會(huì)由某一個(gè)業(yè)務(wù)組做主導(dǎo)，輸出詳細(xì)的技術(shù)方案。給到協(xié)助業(yè)務(wù)組及前端等。

對(duì)于比較復(fù)雜的技術(shù)方案，一般需要開技術(shù)評(píng)審會(huì)，評(píng)審包括行不行，哪里不行，怎么會(huì)更好。具體涉及過多，不做詳細(xì)評(píng)述。

4、開發(fā)、聯(lián)調(diào)、測(cè)試、上線、驗(yàn)收

開發(fā) coding。

前后左右各種聯(lián)調(diào)。

自測(cè)、提測(cè)、功能測(cè)試、集成測(cè)試。

上線，驗(yàn)收，公測(cè)、灰度，放量。

什么叫日常運(yùn)維及支持呢？

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

線上各種的業(yè)務(wù)報(bào)警需要及時(shí)響應(yīng)處理。

別的業(yè)務(wù)組要使用組內(nèi)業(yè)務(wù)數(shù)據(jù)需要對(duì)接支持。

測(cè)試人員有些業(yè)務(wù)測(cè)試數(shù)據(jù)需要配置支持。

... ...

等等

五、附加訂閱

文章來源地址http://www.zghlxwxcb.cn/news/detail-468128.html