這是監(jiān)控告警產(chǎn)品專題系列第一篇文章，涉及的主要內(nèi)容為監(jiān)控產(chǎn)品設(shè)計的一些相關(guān)基礎(chǔ)知識，算是這個系列文章的一個索引。

以前做QQ業(yè)務(wù)運維的時候，有一類平臺是自己天天會用，那這類平臺是什么呢？就是監(jiān)控告警平臺，每天在上面查大量的業(yè)務(wù)視圖、查異常、確認(rèn)告警、處理告警等等。對于運維同學(xué)來說，如果從使用頻率這個維度看，監(jiān)控告警類平臺的使用頻率要大于自動化類平臺，畢竟自動化類平臺多數(shù)都是由例行變更觸發(fā)，而監(jiān)控告警平臺是我們7X24小時都要使用的。

當(dāng)時自己名下有較多的業(yè)務(wù)和幾千臺機器，那時有過一天收1000多條告警的記錄，相當(dāng)崩潰。其實告警如果一天超過幾十條就基本是無效的，即關(guān)注不過來，也處理不過來。在業(yè)務(wù)運維這個角色中，我更多的是從使用者這個視角去看監(jiān)控的。

去年下半年我從業(yè)務(wù)運維轉(zhuǎn)型為產(chǎn)品經(jīng)理，現(xiàn)在負(fù)責(zé)騰訊織云（企業(yè)級運維管理平臺）監(jiān)控告警產(chǎn)品線的規(guī)劃與落地，對于業(yè)務(wù)運維同學(xué)想轉(zhuǎn)型成產(chǎn)品經(jīng)理的可以參考下我的另外一篇文章（從業(yè)務(wù)運維轉(zhuǎn)到產(chǎn)品經(jīng)理，我摸爬滾打的產(chǎn)品之路）。在產(chǎn)品經(jīng)理這個階段我更多的是從建設(shè)者這個視角去看監(jiān)控的。

使用者和建設(shè)者這兩個視角去看待同一個事物監(jiān)控告警這個產(chǎn)品，最大的差異點是什么呢？

使用者是點，建設(shè)者是面，使用者只關(guān)注能服務(wù)到自己的功能點，而建設(shè)者盡量要更全面的抽象多數(shù)使用者所具化的場景，在抽象的基礎(chǔ)上在去構(gòu)建功能，力爭滿足大部分的使用者場景，解決實際的問題。

“出了任何故障，其他環(huán)節(jié)都是可能有問題，唯獨監(jiān)控是一定有問題！”

—— 喬治·背黑鍋

基于這兩種不同的視角與在實際建設(shè)途中遇到的各種實際問題，我萌發(fā)了寫一個監(jiān)控專題系列的想法，哈哈 臉皮蠻厚的的。自己以前都是寫單篇的文章，這次也算是一個挑戰(zhàn)了。希望通過這個專題能與大家交流下關(guān)于一款企業(yè)級監(jiān)控產(chǎn)品是怎么樣規(guī)劃、設(shè)計與落地的。

可能是當(dāng)產(chǎn)品經(jīng)理習(xí)慣了用戶場景與角色的分析，如果把這個主題的文章當(dāng)做一個產(chǎn)品來看，那么其中的角色與場景是什么呢？

• 梳理一下自己在建設(shè)織云監(jiān)控告警產(chǎn)品線的一些經(jīng)驗和思考
• 對于剛?cè)胄袑ΡO(jiān)控告警這個產(chǎn)品還不太熟悉的新業(yè)務(wù)運維同學(xué)。
• 想自己建設(shè)監(jiān)控告警的運維同學(xué)或者運營建設(shè)同學(xué)。
• 正在建設(shè)監(jiān)控告警平臺的運維同學(xué)或者產(chǎn)品經(jīng)理。
• 對監(jiān)控告警產(chǎn)品天天使用的業(yè)務(wù)運維同學(xué)

這系列的文章我也會嘗試用開放式（類眾籌）的方式去寫，歡迎朋友們將日常使用監(jiān)控告警產(chǎn)品的痛點與具體的場景在評論區(qū)留言，后續(xù)會統(tǒng)一評估這些反饋的場景，如果是典型共性場景或者是很小眾，但是這個很小眾的場景卻能代表一個特定類型的業(yè)務(wù)的話，將會采納您提供的場景，在后續(xù)的文章中會標(biāo)明這是由那位朋友提供的，并且附上我的建議場景解決方案，供大家交流與討論。

本篇作為該系列的第一篇文章，也是最基礎(chǔ)的一篇，老鳥們可以直接散了，等著看后續(xù)的文章，該篇會主要涉及到以下主要內(nèi)容：

• 后續(xù)三篇文章講述的核心內(nèi)容（這個系列會比較長，先暫定了后面三篇的內(nèi)容）
• 關(guān)于監(jiān)控告警一些需要提前交代的概念
• 立體化監(jiān)控體系的闡述

因為我現(xiàn)在是織云監(jiān)控告警產(chǎn)品線的產(chǎn)品經(jīng)理，而且這部分的產(chǎn)品也在分版本的持續(xù)建設(shè)中。所以后續(xù)主要的產(chǎn)品規(guī)劃、設(shè)計、實現(xiàn)的講述都是基于織云這個載體上實現(xiàn)。

預(yù)告后續(xù)系列頭三篇文章核心內(nèi)容

• IAAS層監(jiān)控（服務(wù)器性能、網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)流量分析）等如何設(shè)計與實現(xiàn)？
• 一個企業(yè)級監(jiān)控告警產(chǎn)品需要設(shè)計怎樣的cmdb？（在云化時代CMDB所扮演的角色越來越核心，我以前也設(shè)計過織云的CMDB）

平臺級的監(jiān)控產(chǎn)品如何更好的支撐五花八門，而且業(yè)務(wù)形態(tài)差別很大的組件監(jiān)控？

萬丈高樓平地起

監(jiān)控的定義

通過技術(shù)手段發(fā)現(xiàn)服務(wù)異常，持續(xù)優(yōu)化業(yè)務(wù)可用性與用戶體驗。這句話的關(guān)鍵詞是 發(fā)現(xiàn) ?持續(xù)優(yōu)化 可用性與體驗。

監(jiān)控的方式

• 主動：程序內(nèi)部埋點，服務(wù)主動上報自身的運行情況，一般都是具化為業(yè)務(wù)的各個屬性或者指標(biāo)，這種方式準(zhǔn)、快，靈活性好，指標(biāo)豐富。但是在非標(biāo)準(zhǔn)框架下會有一定的代碼改造成本。
• 被動：無需埋點，從外部探測或獲取服務(wù)的運行情況，例如ping探測、日志采集分析等等。
• 旁路：與程序邏輯無關(guān)，對服務(wù)質(zhì)量與口碑的監(jiān)控，例如輿情分析。

那么這三類有優(yōu)劣之分嗎？其實沒有，這里的方式都是針對于不同場景的，例如對域名的監(jiān)控，就可以通過該域名的外部撥測來達(dá)到監(jiān)控的目標(biāo)，域名的訪問耗時也可以通過不同的撥測點來監(jiān)控。在我們騰訊內(nèi)部QQ和Qzone兩個海量業(yè)務(wù)對這三類監(jiān)控都應(yīng)用到了。

監(jiān)控的類型

從大的對象范疇與層級關(guān)系來說，監(jiān)控一般分為5種類型：

• 基礎(chǔ)監(jiān)控：這里的基礎(chǔ)監(jiān)控囊括范圍比較廣主要指IAAS層(服務(wù)器、系統(tǒng)、網(wǎng)絡(luò)等)
• 服務(wù)端監(jiān)控：一般指的是后臺服務(wù)了，例如QQ的后臺消息服務(wù)
• 客戶端監(jiān)控：一般指app了，手Q的客戶端與微信的客戶端。
• WEB監(jiān)控：一般指站網(wǎng)站了，例如對網(wǎng)站域名的撥測。
• 用戶端監(jiān)控：一般指用戶輿情監(jiān)控，例如某個APP的口碑好壞

監(jiān)控的目標(biāo)

一個好的監(jiān)控體系應(yīng)該要達(dá)到以下三點目標(biāo)：

• 全：監(jiān)控對象的廣度，監(jiān)控點的覆蓋率，例如上文提到的5種對象類型是否都能覆蓋到
• 快：監(jiān)控的性能，數(shù)據(jù)流的處理能力
• 準(zhǔn)：智能分析與收斂、監(jiān)控對象收攏

監(jiān)控的本質(zhì)

在DevOps中，運維、開發(fā)、測試這三個角色應(yīng)該視角統(tǒng)一，這里為什么說要視角統(tǒng)一，就是大家在監(jiān)控這個層面關(guān)注的點應(yīng)該是一致的，而不是你關(guān)注你的點，我關(guān)注我的點。例如所有的業(yè)務(wù)監(jiān)控都可以抽象出三個核心指標(biāo)：請求量、成功率、耗時。這三個關(guān)鍵指標(biāo)來判斷我們服務(wù)的可靠性，通過可靠性可以推算出可用性，并且可以間接反映用戶使用我們產(chǎn)品的的體驗。例如如果服務(wù)的可靠性不好，那么用戶的產(chǎn)品體驗肯定不會好。

監(jiān)控的目的

通過對上文的一些概念介紹，其實我們已經(jīng)可以推導(dǎo)出應(yīng)用監(jiān)控告警的目的，就是持續(xù)優(yōu)化業(yè)務(wù)服務(wù)質(zhì)量，并建設(shè)質(zhì)量體系。同樣織云監(jiān)控也是為了打造質(zhì)量體系的閉環(huán)路徑。

監(jiān)控告警的產(chǎn)品屬性

監(jiān)控告警是一款數(shù)據(jù)類屬性的產(chǎn)品，既然是數(shù)據(jù)類產(chǎn)品，那么在產(chǎn)品設(shè)計的時候一定要注意這樣的路徑閉環(huán) 數(shù)據(jù)生產(chǎn)->?數(shù)據(jù)增值–>數(shù)據(jù)消費，圍繞著這樣的路徑我們就可以勾勒出很多的用戶故事，用戶故事就是針對具體的角色，會有什么具體的活動，這個活動所產(chǎn)生的價值。

這里舉個簡單的例子，來說明數(shù)據(jù)生產(chǎn)與數(shù)據(jù)消費。隨著后面詳細(xì)的講述產(chǎn)品建設(shè)過程中會更加詳細(xì)的闡述這個閉環(huán)的路徑。

• 數(shù)據(jù)生產(chǎn)：例如一臺服務(wù)器上報的各種基本的OS指標(biāo)數(shù)據(jù)，例如CPU使用率，內(nèi)存使用量等。這就產(chǎn)生了若干待消費的原始數(shù)據(jù)，那么我們能用這些數(shù)據(jù)干什么呢？
• 數(shù)據(jù)消費：對這些上報的原始數(shù)據(jù)整理可以用作視圖展示，例如圖形化展示該服務(wù)在最近一個小時的cpu使用率。 又或者對這些原始數(shù)據(jù)設(shè)定閾值，當(dāng)超過某個閾值的時候，就產(chǎn)生告警通知。這些都是最直接的消費的場景。

我們在延伸一步對于這些消費場景產(chǎn)生的告警數(shù)據(jù)，是否可以在進一步消費呢？答案是可以的，例如對若干承載Cpu計算型業(yè)務(wù)的服務(wù)器所產(chǎn)生的cup使用率告警(生產(chǎn))時間進行分析統(tǒng)計(消費)，是不是可以基本推導(dǎo)出該業(yè)務(wù)的服務(wù)高峰期是大概在那個時間范圍呢？

這里想說明的是多數(shù)原子數(shù)據(jù)并無單一的消費或者生產(chǎn)的屬性，而是要取決于在具體的場景與所處的數(shù)據(jù)鏈條中的角色。

并且監(jiān)控告警的數(shù)據(jù)加上特定的流程（ITSM）也可以驅(qū)動監(jiān)控告警+自動化的大的業(yè)務(wù)邏輯交互閉環(huán)，這個場景容我先買個關(guān)子，隨著后面的敘述會再次提及到這部分。

監(jiān)控體系

體系，泛指一定范圍內(nèi)或同類的事物按照一定的秩序和內(nèi)部聯(lián)系組合而成的整體，是不同系統(tǒng)組成的系統(tǒng)。其實這個描述是有些抽象的，咱們用大白話套用監(jiān)控體系來解讀下。

對于一個有一定體量的公司，需要一些不同的監(jiān)控系統(tǒng)，通過系統(tǒng)與系統(tǒng)間的內(nèi)部交互來組成一個大的整體，從而完成對不同場景下的監(jiān)控需求即監(jiān)控體系。用我們內(nèi)部來舉例說，我們內(nèi)部在現(xiàn)網(wǎng)上跑的監(jiān)控系統(tǒng)也有快10套了，同樣在構(gòu)建體系時關(guān)鍵的部分也是要用動態(tài)的視角去看待這些系統(tǒng)所產(chǎn)生的數(shù)據(jù)，而不是每個系統(tǒng)都是一個孤立的數(shù)據(jù)孤島。下圖是織云整體的監(jiān)控體系。

在織云監(jiān)控告警產(chǎn)品建設(shè)過程種，我們?nèi)谌牒秃芏嚓P(guān)于海量運維的監(jiān)控思考與經(jīng)驗沉淀。

這里的監(jiān)控體系是和公司體量大小有直接關(guān)系的，但是一般來說在這個體系中，應(yīng)該有三類監(jiān)控系統(tǒng)是必備的。

? 總結(jié)

通過上文的簡單介紹，相信大家對監(jiān)控告警會有個初步的宏觀認(rèn)識，隨著后續(xù)文章的鋪開，大家會逐步了解到一個企業(yè)級的監(jiān)控產(chǎn)品是怎樣從0到1演化而來的。同時下篇文文章就會進入到實戰(zhàn)階段。 建設(shè)監(jiān)控告警是一條持續(xù)且漫長的路也是蠻復(fù)雜的，坑也很多，但還是有一些基本的方法論和規(guī)律可以遵循的。

本文由 @李光 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。