起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識監控告警產品專題（1）：企業級監控產品設計基礎
這是監控告警產品專題系列第一篇文章，涉及的主要內容為監控產品設計的一些相關基礎知識，算是這個系列文章的一個索引。
以前做QQ業務運維的時候，有一類平臺是自己天天會用，那這類平臺是什么呢？就是監控告警平臺，每天在上面查大量的業務視圖、查異常、確認告警、處理告警等等。對于運維同學來說，如果從使用頻率這個維度看，監控告警類平臺的使用頻率要大于自動化類平臺，畢竟自動化類平臺多數都是由例行變更觸發，而監控告警平臺是我們7X24小時都要使用的。
當時自己名下有較多的業務和幾千臺機器，那時有過一天收1000多條告警的記錄，相當崩潰。其實告警如果一天超過幾十條就基本是無效的，即關注不過來，也處理不過來。在業務運維這個角色中，我更多的是從使用者這個視角去看監控的。
去年下半年我從業務運維轉型為產品經理，現在負責騰訊織云（企業級運維管理平臺）監控告警產品線的規劃與落地，對于業務運維同學想轉型成產品經理的可以參考下我的另外一篇文章（從業務運維轉到產品經理，我摸爬滾打的產品之路）。在產品經理這個階段我更多的是從建設者這個視角去看監控的。
使用者和建設者這兩個視角去看待同一個事物監控告警這個產品，最大的差異點是什么呢？
使用者是點，建設者是面，使用者只關注能服務到自己的功能點，而建設者盡量要更全面的抽象多數使用者所具化的場景，在抽象的基礎上在去構建功能，力爭滿足大部分的使用者場景，解決實際的問題。
“出了任何故障，其他環節都是可能有問題，唯獨監控是一定有問題！”
—— 喬治·背黑鍋
基于這兩種不同的視角與在實際建設途中遇到的各種實際問題，我萌發了寫一個監控專題系列的想法，哈哈 臉皮蠻厚的的。自己以前都是寫單篇的文章，這次也算是一個挑戰了。希望通過這個專題能與大家交流下關于一款企業級監控產品是怎么樣規劃、設計與落地的。
可能是當產品經理習慣了用戶場景與角色的分析，如果把這個主題的文章當做一個產品來看，那么其中的角色與場景是什么呢？
- 梳理一下自己在建設織云監控告警產品線的一些經驗和思考
- 對于剛入行對監控告警這個產品還不太熟悉的新業務運維同學。
- 想自己建設監控告警的運維同學或者運營建設同學。
- 正在建設監控告警平臺的運維同學或者產品經理。
- 對監控告警產品天天使用的業務運維同學
這系列的文章我也會嘗試用開放式（類眾籌）的方式去寫，歡迎朋友們將日常使用監控告警產品的痛點與具體的場景在評論區留言，后續會統一評估這些反饋的場景，如果是典型共性場景或者是很小眾，但是這個很小眾的場景卻能代表一個特定類型的業務的話，將會采納您提供的場景，在后續的文章中會標明這是由那位朋友提供的，并且附上我的建議場景解決方案，供大家交流與討論。
本篇作為該系列的第一篇文章，也是最基礎的一篇，老鳥們可以直接散了，等著看后續的文章，該篇會主要涉及到以下主要內容：
- 后續三篇文章講述的核心內容（這個系列會比較長，先暫定了后面三篇的內容）
- 關于監控告警一些需要提前交代的概念
- 立體化監控體系的闡述
因為我現在是織云監控告警產品線的產品經理，而且這部分的產品也在分版本的持續建設中。所以后續主要的產品規劃、設計、實現的講述都是基于織云這個載體上實現。
預告后續系列頭三篇文章核心內容
- IAAS層監控（服務器性能、網絡設備、網絡流量分析）等如何設計與實現？
- 一個企業級監控告警產品需要設計怎樣的cmdb？（在云化時代CMDB所扮演的角色越來越核心，我以前也設計過織云的CMDB）
平臺級的監控產品如何更好的支撐五花八門，而且業務形態差別很大的組件監控？
萬丈高樓平地起
監控的定義
通過技術手段發現服務異常，持續優化業務可用性與用戶體驗。這句話的關鍵詞是 發現 ?持續優化 可用性與體驗。
監控的方式
- 主動：程序內部埋點，服務主動上報自身的運行情況，一般都是具化為業務的各個屬性或者指標，這種方式準、快，靈活性好，指標豐富。但是在非標準框架下會有一定的代碼改造成本。
- 被動：無需埋點，從外部探測或獲取服務的運行情況，例如ping探測、日志采集分析等等。
- 旁路：與程序邏輯無關，對服務質量與口碑的監控，例如輿情分析。
那么這三類有優劣之分嗎？其實沒有，這里的方式都是針對于不同場景的，例如對域名的監控，就可以通過該域名的外部撥測來達到監控的目標，域名的訪問耗時也可以通過不同的撥測點來監控。在我們騰訊內部QQ和Qzone兩個海量業務對這三類監控都應用到了。
監控的類型
從大的對象范疇與層級關系來說，監控一般分為5種類型：
- 基礎監控：這里的基礎監控囊括范圍比較廣主要指IAAS層(服務器、系統、網絡等)
- 服務端監控：一般指的是后臺服務了，例如QQ的后臺消息服務
- 客戶端監控：一般指app了，手Q的客戶端與微信的客戶端。
- WEB監控：一般指站網站了，例如對網站域名的撥測。
- 用戶端監控：一般指用戶輿情監控，例如某個APP的口碑好壞
監控的目標
一個好的監控體系應該要達到以下三點目標：
- 全：監控對象的廣度，監控點的覆蓋率，例如上文提到的5種對象類型是否都能覆蓋到
- 快：監控的性能，數據流的處理能力
- 準：智能分析與收斂、監控對象收攏
監控的本質
在DevOps中，運維、開發、測試這三個角色應該視角統一，這里為什么說要視角統一，就是大家在監控這個層面關注的點應該是一致的，而不是你關注你的點，我關注我的點。例如所有的業務監控都可以抽象出三個核心指標：請求量、成功率、耗時。這三個關鍵指標來判斷我們服務的可靠性，通過可靠性可以推算出可用性，并且可以間接反映用戶使用我們產品的的體驗。例如如果服務的可靠性不好，那么用戶的產品體驗肯定不會好。
監控的目的
通過對上文的一些概念介紹，其實我們已經可以推導出應用監控告警的目的，就是持續優化業務服務質量，并建設質量體系。同樣織云監控也是為了打造質量體系的閉環路徑。
監控告警的產品屬性
監控告警是一款數據類屬性的產品，既然是數據類產品，那么在產品設計的時候一定要注意這樣的路徑閉環 數據生產->?數據增值–>數據消費，圍繞著這樣的路徑我們就可以勾勒出很多的用戶故事，用戶故事就是針對具體的角色，會有什么具體的活動，這個活動所產生的價值。
這里舉個簡單的例子，來說明數據生產與數據消費。隨著后面詳細的講述產品建設過程中會更加詳細的闡述這個閉環的路徑。
- 數據生產：例如一臺服務器上報的各種基本的OS指標數據，例如CPU使用率，內存使用量等。這就產生了若干待消費的原始數據，那么我們能用這些數據干什么呢？
- 數據消費：對這些上報的原始數據整理可以用作視圖展示，例如圖形化展示該服務在最近一個小時的cpu使用率。 又或者對這些原始數據設定閾值，當超過某個閾值的時候，就產生告警通知。這些都是最直接的消費的場景。
我們在延伸一步對于這些消費場景產生的告警數據，是否可以在進一步消費呢？答案是可以的，例如對若干承載Cpu計算型業務的服務器所產生的cup使用率告警(生產)時間進行分析統計(消費)，是不是可以基本推導出該業務的服務高峰期是大概在那個時間范圍呢？
這里想說明的是多數原子數據并無單一的消費或者生產的屬性，而是要取決于在具體的場景與所處的數據鏈條中的角色。
并且監控告警的數據加上特定的流程（ITSM）也可以驅動監控告警+自動化的大的業務邏輯交互閉環，這個場景容我先買個關子，隨著后面的敘述會再次提及到這部分。
監控體系
體系，泛指一定范圍內或同類的事物按照一定的秩序和內部聯系組合而成的整體，是不同系統組成的系統。其實這個描述是有些抽象的，咱們用大白話套用監控體系來解讀下。
對于一個有一定體量的公司，需要一些不同的監控系統，通過系統與系統間的內部交互來組成一個大的整體，從而完成對不同場景下的監控需求即監控體系。用我們內部來舉例說，我們內部在現網上跑的監控系統也有快10套了，同樣在構建體系時關鍵的部分也是要用動態的視角去看待這些系統所產生的數據，而不是每個系統都是一個孤立的數據孤島。下圖是織云整體的監控體系。
在織云監控告警產品建設過程種，我們融入和很多關于海量運維的監控思考與經驗沉淀。
這里的監控體系是和公司體量大小有直接關系的，但是一般來說在這個體系中，應該有三類監控系統是必備的。
? 總結
通過上文的簡單介紹，相信大家對監控告警會有個初步的宏觀認識，隨著后續文章的鋪開，大家會逐步了解到一個企業級的監控產品是怎樣從0到1演化而來的。同時下篇文文章就會進入到實戰階段。 建設監控告警是一條持續且漫長的路也是蠻復雜的，坑也很多，但還是有一些基本的方法論和規律可以遵循的。
本文由 @李光 原創發布于人人都是產品經理。未經許可，禁止轉載。
- 目前還沒評論，等你發揮！
