2023年第2期
總第16期
contents
目錄
【數據分析思維】多因素影響下如何歸因？
風向
豆瓣即戰場，春節檔口碑的極與極
數說
一線
指標設計方法，終于有人講明白了，數據分析師還不快看？！
輕松保障萬級實例，ViVo服務端監控體系建設實踐
熱點
以下文章來源于澎湃美數課 ，作者澎湃美數課
原文鏈接：//mp.weixin.qq.com/s/DHZaMzmcbUMrbBqE3p4Vuw
電影院舒展筋骨，張掛暗室里的夢，準備好恢復活力了。
截至 2023 年 2 月 5 日早上 10 點，今年春節檔總票房達到 101.49 億。據中國電影局數據，2023 年除夕至正月初六期間春節檔觀影人次為 1.29 億，2019 年為 1.32 億。
電影久違地成了話題中心。輿論場上，似乎每部電影的評價都要把“甲之蜜糖，乙之砒霜”這句話踐行到底。其中正反雙方廝殺得最激烈的是這四部電影，《無名》《深海》《流浪地球2》和《滿江紅》。通過分析豆瓣短評的數據，澎湃新聞試圖找出這幾部電影的爭議在何處，硝煙味又是如何彌漫開的。
豆瓣即戰場，
春節檔口碑的極與極
爭議在何處
Movie posters during the Spring Festival
和印象中喜氣洋洋的春節檔不同，今年春節檔電影的主題略顯灰暗，“晦氣電影”占一半，《深海》以一個不快樂的小女孩為主角，外號就叫“晦氣”，而《無名》和《滿江紅》里死傷頗眾，還有幾個殺人不眨眼的狠角色。一些懷著喜慶的期待拖家帶口走進電影院的觀眾因此感到猝不及防。
評論最割裂的顯然是《無名》。豆瓣短評區上方一行小字寫著：“當前觀眾意見分歧較大，隨機展示部分短評，請謹慎參考”。高爭議度的導演遇上高爭議度的演員，結果便是如此。導演程耳的前作《羅曼蒂克消亡史》被影迷認為是華語電影的遺珠，帶有極強的個人風格，因此沖著導演來的觀眾不少，喜歡的稱贊“程耳延續了他的美學風格”，不喜歡的則稱“故事講得破碎，沒有羅曼好看”。除開導演是否用非線性敘事講了一個平庸的故事，最大的爭議都在演員身上。有觀眾沖著梁朝偉來看，王一博的戲份卻更吃重，感到自己受了騙。
王一博演得好嗎？評論區的評價分歧到讓人疑惑他們看的是不是同一部電影。高贊評論說著風馬牛不相及的話，一個人說：“王一博哪有那么差，程耳抓他的氣質抓得很準，好導演可以成就演員”，有 1747 個贊。另一個人說讓王一博回去做愛豆，放棄演員這條路，也有 1581 個贊。
今年春節檔的超級關鍵詞之一是“流量”。另一部有頂級流量參與的電影是《滿江紅》，張藝謀導演，易烊千璽在影片中飾演少年將軍孫均。對于他演技的評價，在熱評區也呈現了一定的兩極趨勢。身陷“抄襲”“偷票房”等爭議，《滿江紅》官方在北京互聯網法院提起 4 起訴訟，包括起訴大 V @屠龍的胭脂井 和 @沈逸。紛雜的場外信息之外，關于影片本身，主要的爭議點落在電影結尾上，全軍齊誦《滿江紅》。有人質疑角色的行為邏輯，不惜用自己的生命連環設局，反轉反轉再反轉，最后就是為了一首詞嗎？
女性角色仍作為陪襯，甚至陳舊的陪襯存在。《滿江紅》里的瑤琴，既要她性感，又要她貞潔。《流浪地球2》里的韓朵朵，“身手矯捷結婚生子匆匆領盒飯”。《深海》倒是以一個小女孩為主角，但光芒卻在男主身上。不過《深海》的主要爭議點不在于此，而在劇情追不上畫面的乏力感上。“要特效有特效，要劇情有特效”，有網友這樣評價道。
王一博的粉黑大戰甚至導致了豆瓣開分的延遲。
隨著高人氣、高爭議的“流量”藝人逐漸在電影中演上主角，扛起票房，豆瓣短評區成了新的戰場。?
自 2017 年起，豆瓣電影不展示全部短評。官方的回應為“短評展示機制是反水軍的重要一環，算法會試圖把不可信的短評藏起來”，同時，“無論展示不展示全部短評，都有部分評論相關的打分是不會被計入條目評分的”。
豆瓣在努力消除水軍對評分的影響。然而從熱評區的評分“割據”情況，我們能仍看出水軍努力的痕跡：只要用力點贊，就能創造奇跡。點贊數越高，就越有可能進入熱評區，這是“熱評”的定義。
粉黑大戰的遺跡
這可能也是為什么《無名》關閉了熱評區，改為隨機顯示短評。粉黑大戰時，雙方只要點贊符合各自立場的評論，就能讓其進入熱評區，從而塑造普通觀眾點進條目熱評區時看到的景象——主旋律影響電影，粉絲影響電影的評價。
電影回來了，但面對的是新世界。
在所有數據分析師面對的分析問題中，有一種類型的分析十分費頭發，但是業務中又會經常遇到，這種分析就是歸因分析，先看以下兩個案例：
為什么要寫【數據分析思維】這個系列文章？還是回到一個最根本的問題上：數據分析師到底是干什么的？
我相信不僅是想入門的小伙伴，已經入行很久的數據分析師可能多多少少還是會有些不清楚。數據分析師是每天被各個業務方呼來喚去的提數工具人么？還是被各種不靠譜的可視化軟件蹂躪的報表maker？還是好不容易做了個專題分析，卻被業務方嫌棄不說“人話”的，只會紙上談兵、指手畫腳的外行？
我相信每個數據分析師都會多多少少經歷以上的心路歷程，直到某天突然明白數據分析的終極奧義，才能跳出這個讓人迷茫的怪圈。原來數據分析是要：熟悉業務，在此基礎上基于對業務的理解發現業務上的問題，然后提出分析的方案，然后再是用工具提數分析，最后給出結論和建議，并推動相關方實施落地，進而解決問題，完成從業務中發現問題，再回到業務中解決問題的完整閉環。這才是數據分析的真正意義。
明白了這些，你可能就會發現，區別于其他的開發類工作，數據分析是以業務、思維為主、工具為輔的工作，重要的不是你會多么高端牛逼的工具和算法，而是你怎么發現問題，怎么形成分析思路，這才是數據分析師拉開差距的關鍵所在，至于剩下的就是怎么具體實施，這個，找個實習生也能做，哪部分工作含金量更高、被取代難度更大，一目了然了吧？
這也是我寫【數據分析思維】系列文章的原因，數據分析本身就是業務和思維為重，授人以魚不如授人以漁，清晰完備的思維可以讓你事半功倍，知道怎么做遠比實際做要重要的多，代碼未動，思維先行，懂得運籌帷幄才能走得更遠。
01 寫在前面
以下文章來源于數據分析星球 ，作者數據分析星球
原文鏈接：//mp.weixin.qq.com/s/vay1o1MLUiGwqSYUCDgPGQ
數據分析思維——
多因素影響下如何歸因？
02 什么是歸因分析？
案例1：
小果在手機上看到了朋友圈廣告發布了最新的蘋果手機，午休的時候刷抖音看到了有網紅在評測最新的蘋果手機，下班在地鐵上刷朋友圈的時候發現已經有小伙伴收到手機在曬圖了，于是喝了一杯江小白壯壯膽回家跟老婆申請經費，最后老婆批準了讓他去京東買，有保障。那么問題來了，朋友圈廣告、抖音、好友朋友圈、京東各個站外渠道對這次成交分別貢獻了多少？
案例2：
小丹在淘寶上買一雙籃球鞋 ，通過首頁搜索看到了AJ，點進去看了款式和顏色，覺得真香，無奈囊中羞澀，就作罷。五一期間，小明再次打開了淘寶，看到首頁的優惠活動，點擊進入活動分會場，再次看到AJ，點進去再過了一把眼癮，想想下個月的生活費，又忍痛退出到了首頁。但是，緣分就是那么神奇，在首頁-猜你喜歡的頁面再次看到了AJ，點擊進去看了一下評論和買家秀，不管了，要剁手了。那么問題來了，淘寶內首頁搜索、活動會場和猜你喜歡這些站內的資源位對這次成交分別貢獻了多少？
隨著移動互聯網的興起，業務的形態越來越復雜，歸因分析的需求日趨增多。上面兩個案例分別是站外渠道和站內資源位兩個經典場景下的歸因分析。場景雖有所區別，但是目的都是相似的。即針對當前的場景和目標，怎么把“貢獻”合理分配到每一個坑位上。
實際上這類問題其實并沒有標準答案，因為真正的業務錯綜復雜，很難精準地把貢獻進行合理的分配，但歸因分析的需求又是如此高頻且要求很強的時效性，所以需要一些方法論的支撐來進行快速嘗試，快速定位問題而不至于面對問題一臉懵B不知從何處下手。以下介紹 幾種常見的歸因分析模型供參考。
03 常見的歸因分析模型
也稱最后點擊模型，這種歸因模型將功勞100%分配給轉化前的最后一個渠道，即不管用戶發生了啥行為，只關注最后一次。這是最簡單、直接，也是應用最為廣泛的歸因模型。
1、末次歸因模型
優點：首先它是最容易測量的歸因模型，在分析方面不容易發生錯誤。另外由于大部分追蹤的cookie存活期只有30-90天，對于顧客的行為路徑、周期比較長的場景，在做歸因分析的時候可能就會發生數據的丟失，而對于末次互動模型，這個數據跟蹤周期就不是那么特別重要了。
缺點：這種模型的弊端也是比較明顯，比如客戶是從收藏夾進入商品詳情頁然后形成了成交的，按照末次歸因模型就會把100%的功勞都歸功于收藏夾（直接流量）。但是真實的用戶行為路徑更接近于產生興趣、信任、購買意向、信息對比等各種環節，這些都是其他渠道的功勞，在這個模型中則無法統計進來，而末次渠道的功勞評估會被大幅高估。
適用場景：短期的投放，轉化路徑少、周期短的業務快速提升，效果，按照末次歸因模型，能比較好了解到底是哪個渠道對于最終的轉化有比較好的促進作用。
2、首次歸因模型
線性歸因是多觸點歸因模型中的一種，也是最簡單的一種，他將功勞平均分配給用戶路徑中的每一個觸點。
也稱首次點擊模型，這種歸因模型將功勞100%分配給第一個觸達渠道，即不管用戶發生了啥行為，只關注第一次。如果，末次互動是認為，不管你之前有多少次互動，沒有最后一次就沒有成交。那么首次互動就是認為，沒有我第一次的互動，你們剩下的渠道連互動都不會產生。換句話說，首次互動模型更加強調的是驅動用戶認知的、位于轉化漏斗最頂端的渠道。
優點：是一種容易實施的單觸點模型，初次點擊的歸因會讓你明確潛在消費者是怎樣找到你的，且和最后點擊一樣，不需要大量的數據。
缺點：受限于數據跟蹤周期，對于用戶路徑長、周期長的用戶行為可能無法采集真正的首次行為，且初次點擊歸因并不能夠解釋所有后續所發生的用戶行為，對于后續的用戶行為沒有關注。
適用場景：一般是需要進行拉新的時候，公司處于市場開拓的時候，這個時候我們關心把更多的用戶先圈過來，那么用首次互動模型可以看出來哪些渠道對于業務拉新最有效。所以首次歸因模型對于沒什么品牌知名度、且重點在市場拓展，渠道優化的公司，比較適用。
3、線性歸因模型
4、時間衰減歸因模型
優點：它是一個多觸點歸因模型，可以將功勞劃分給業務路徑中每個不同階段的營銷渠道，不用考慮不同渠道的價值權重，大家一視同仁，計算也不復雜。另外，它的計算方法比較簡單，計算過程中的價值系數調整也比較方便。
缺點：很明顯，線性平均劃分的方法不適用于某些渠道價值特別突出的業務，對于價值比價高的渠道，可能會“被平均”，因為這種渠道是靠質量而不是數量贏得結果的。比如，一個客戶在線下某處看到了你的廣告，然后回家再用百度搜索，連續三天都通過百度進入了官網，并在第四天成交。那么按照線性歸因模型，百度會分配到75%的權重，而線下某處的廣告得到了25%的權重，這很顯然并沒有給到線下廣告足夠的權重。
適用場景：根據線性歸因模型的特點，它更適用于企業期望在整個銷售周期內保持與客戶的聯系，并維持品牌認知度的公司。在這種情況下，各個渠道在客戶的考慮過程中，都起到相同的促進作用。
對于路徑上的渠道，距離轉化的時間越短的渠道，可以獲得越多的功勞權重。時間衰減歸因模型基于一種假設，他認為觸點越接近轉化，對轉化的影響力就越大。這種模型基于一個指數衰減的概念，一般默認周期是7天。也就是說，以轉化當天相比，轉化前7天的渠道，能分配50%權重，前14天的渠道分25%的權重，以此類推...
優點：這個模型考慮了時間的作用，因為一般情況下也是時間越久對于用戶的轉化作用是越弱。相比線性歸因模型的平均分權重的方式，時間衰減模型讓不同渠道得到了不同的權重分配，當然前提是基于"觸點離轉化越近，對轉化影響力就越大"的前提是準確的情況下，這種模型是相對較合理的。
5、位置歸因模型
缺點：如果有的渠道天然處于轉化鏈路的起點，那么對于這些渠道是不公正的，因為它們總是距離轉化最遠的那個，永遠不會得到一個公平的權重。
適用場景：和末次歸因比較類似，適用于客戶決策周期短、銷售周期短、引導用戶完成轉化的場景的情況。比如，做短期的促銷，就打了兩天的廣告，那么這兩天的廣告理應獲得較高的權重。
U型歸因模型也是一種多觸點歸因模型，實質上是一種重視最初帶來線索和最終促成成交渠道的模型，一般它會給首次和末次互動渠道各分配40%的權重，給中間的渠道分配20%的權重，也可以根據實際情況來調整這里的比例。
U型歸因模型非常適合那些十分重視線索來源和促成銷售渠道的公司。該模型的缺點則是它不會考慮線索轉化之后的觸點的營銷效果，而這也使得它成為銷售線索報告或者只有銷售線索階段目標的營銷組織的理想歸因模型。
6、自定義模型
以電商用戶購物場景為例，用戶進入App到最終產生支付購買行為，中間可能會有以下關鍵的渠道和坑位：
- 點擊搜索欄進行搜索進入商詳頁
- 點擊首頁運營位進入商詳頁
- 通過點擊push消息進入商詳頁
- 通過參與限時活動進入商詳頁
- 通過微信公眾號推動消息進入商詳頁
- 通過購物車等坑位直接轉化
我們對近30日成交訂單進行歸因分析，此處我們選用的歸因計算方式是“末次歸因”。歸因窗口期設為 1 天，即觀察用戶在發生訂單行為之前的 24 時之內點擊了哪些坑位。然后再找到離“提交訂單”最 近的一個坑位點擊行為。
基于位置的歸因模型，也叫U型歸因模型，它綜合了首次歸因、末次歸因、線性歸因，將第一次和最后一次觸點各貢獻40%，中間的所有觸點平均剩下的20%貢獻。
你可以根據自己對于業務的理解，創建你自己的模型，讓其具有更具體的業務性和目的性，并可將其來和其他默認模型做對比。
優點：在這種模式下，你可以使用線性歸因、首次歸因、末次歸因、時間衰減歸因，以及位置歸因模型作為基準線，通過不斷地測試，調整各個渠道的權重，最好的效果是，它可以個性化地評估當前的業務，并可以隨著時間的推移進行優化。
缺點：在沒有先做一些測試之前不要直接使用自定義模型，不要僅靠經驗判斷哪些渠道的貢獻可能更大，實際數據上的表現可能會有所差異，需要基于數據的測試來進行判斷。
04 歸因分析的實際案例
最終得到的結果如上圖，APP 內多個坑位中，點擊搜索欄和直接轉化對于成單的 貢獻分別占據了 52.67%、27.56%。運營位、活動、Push和微信公眾號的相關推薦僅帶來不足 10% 的成單貢獻。通過這 個結果，可以清晰地反映如下幾點信息:
最終的貢獻度反映了不同坑位對最終成單轉化的貢獻及互相之間的差異。
對比不同坑位的有效轉化點擊率，可得知不同坑位對用戶的吸引程度。
因為我們知道的太少。
不僅是Jon Snow，“我們真的知道的，比我們認為自己知道的，知道的少。”是一個對于大多數人而言都普遍存在的現象。
為什么要設計指標？
而設計指標的目的就在于：讓我們了解更多。
具體而言，通過指標數值，可以在可接受的成本下，傳遞足夠多的信息。
設想一下：
- 中年危機老賈去醫院體檢，咨詢身體狀況如何；醫生說：“還行。有點問題。問題不大。”而不是告訴他血壓如何、體脂如何、血糖如何。
- 法外狂徒小藝被查酒駕，交警質問他喝了多少；小藝說：“沒醉。喝了一點。喝的不多。”交警卻沒有一個血液酒精含量的指標，去判斷他是否醉駕，應該作何處罰。
- 霸道總裁阿餅例行月會詢問業績，負責銷售的副總說：“很棒。業績很好，賣了不少。”只字不提銷售總額、人均產能、業績趨勢。
倘若沒有指標這個工具，我們能獲得的信息，就會變得是非常有限的；或是獲取信息的成本變得極高。為了更好的使用這個工具，我們首先要了解“指標”的定義是什么。
讓我們簡單的回憶一下：我們日常最常接觸到的指標，像身高、體重、溫度、GDP。
- 它們的共性是什么？——共性在于它們的載體都是數值。例如，身高180，體重154，溫度26，GDP14.7萬億。
- 它們的差別是什么？——差別在于它們的含義各不相同。比方說，身高180（cm）和體重180（斤）的含義是截然不同的。
以下文章來源于來源：知乎，作者：好好的分析師
原文鏈接：//mp.weixin.qq.com/s/UNKC_57tG4j10QWzFAhQJQ
指標設計方法，
終于有人講明白了
#01
什么是指標？
#02
如何設計一個指標？
所以，指標是一個被定義的數值，用來對事實進行量化抽象。這個抽象過程可以是一次的，也可以是多次：
- 當一個事實比較簡單的時候，例如某個物品的輕重，我們用通過質量這一個指標就可以衡量清楚。
- 但當一個事實更復雜一些的時候，例如一個人的胖瘦，也許僅僅是用質量（體重）就不足以說明這個事實。這個時候我們可能會用BMI、體脂率等經過了兩次抽象的指標。
- 當這個事實變得更加復雜，例如一個國家的經濟狀況，我們會用GDP，這個一個進行了很多層復雜抽象、涉及到大量數據[1]的指標。甚至是僅僅一個指標也完全不足以描述出這個事實的重要特征；這時候就要設計一整套的指標體系，來量化這個復雜的事實。
↑? 事實、數據、指標之間的關系
數據經過初步抽象，形成原子指標，即絕對數指標。例如：保費、客戶數、用戶量。
原子指標經過三種加工方式，形成衍生指標。例如：升學率、平均客單價、滬深300。這3種加工方式分別為：進行對比、計算統計量、指數設計（結合對比和統計計算）。
當我們對原子指標和衍生指標，進行維度限定的時候，就形成了派生指標。
1、指標設計的過程與分類
結合統計與數據治理視角，我們可以將指標的設計過程分為三個步驟：抽象、加工、限定。
綜上所述，一個應該至少包含4個要素：
- 名稱：指標名稱要清晰明確，避免歧義，降低溝通成本。
- 責任人：責任人要保證指標可維護、可運營。
- 含義：指標含義要描述的是“被量化的事實”；例如——這個指標是在什么場景下？為了什么目的？刻畫了什么事實？
- 口徑：指標口徑要保證我們能及時地、準確地取到所需的“數值”；例如——這個指標是如何計算的？所需的數據從哪獲取？獲取的時效如何？
當然僅僅知道什么是指標是遠遠不夠的，還要知道怎么去生成一個指標。
↑? 指標的生成過程
這里對原子指標、相對指標以及統計量指標的使用做一個簡單的介紹：
原子指標記錄事實：根據指標的定義，指標是一個被定義的數值，用來對事實進行量化抽象。這個量化過程的起點是傳感器、數字化等；然后是日志、記錄、標簽等；進入指標匯總層面的第一步就是原子指標。我們通過原子指標來記錄事實，例如訪問的次數、出行的距離、消費的金額等等。所以當我們需要記錄一些基本事實的時候，我們設計一個原子指標來量化它們。
相對指標用于評價：我們通過原子指標，記錄下了一堆的事實。緊接著，我們要做的就是對這些事實進行評價。常說“沒有比較就沒有傷害。”為什么沒有傷害呢？因為沒有比較，就很難做評價，進而我們也不知道自己是好是壞。所以當我們需要評價一些事實的時候，我們設計一個相對指標來量化它們。
- 當我們要評價?件事情的發展趨勢的時候，我們可以?動態相對數；例如：同?、環?。
- 當我們要評價?件事對整體的影響的時候，我們可以??例相對數；例如：市場占有率。
- 當我們要評價同?個事物在不同維度下的差異程度的時候，我們可以??較相對數；例如：TGI、
- 男??例。
- 當我們要評價兩個不同事物之間的關聯的時候，我們可以?強度相對數；例如：投訴發起強度、退
- 款發起強度。
- 當我們要評價計劃的完成情況的時候，我們可以?完成相對數，例如：銷售額完成進度。
#03
↑? 指標的類型
統計數指標提煉信息：有時候，我們會有非常多的記錄或指標。它們蘊含著非常多的信息，但是價值的密度卻很有限。這個時候就可用通過一些統計的方式，提煉其中的信息價值。例如我們有數以千萬記的用戶的月均消費金額，這時候可以通過統計分位置的方式對我們客戶整體的消費能力做一個刻畫。
2、指標的尺度特性
不同的指標，還會具有不同的尺度特性。根據可比程度的不同，我們可以將指標劃分為4個測量尺度：定比尺度、定距離尺度、定序尺度和名義尺度。
↑? “T+n”與“時間切片統計”、“關聯綁定統計”的示意說明
3、指標的時間特征
在指標設計的過程中，時間是一個非常重要的因素。由于多個事實的發生時間之間的異步性，以及事實發生時間與指標計算時間之間的異步性，導致不同的時間統計口徑會對指標產生重大的影響。
定距尺度不能直接做乘除：
例如溫度就是一個典型定距尺度，“20度有10度的2倍那么熱，是一個非常令人困惑的表述。”定比尺度具有絕對起點“0點”；而定距尺度沒有絕對起點，定距尺度的“0點”是人工計算出來的。換言之，定比尺度的指標，本身和零點的差是有意義的。但，定距尺度，之間的差才是有意義的。這就導致了，定比尺度可以直接和自然數做乘除法，但定距尺度不可以。
定序尺度不能直接做加減：
滿意度評分就是一個典型的定序尺度。如果消費者給A酒店的評分是5分，B酒店的評分是3分，C酒店的評分是1分。很可能這并不意味著，A比B酒店好的程度與B酒店比A酒店好的程度相等。實際情況可能是 ，大多數的酒店都在4分左右，而5分是非常棒的；1、2、3分的酒店都乏善可陳，甚至體驗很差。因為定距尺度之間的距離是精確定義了的，而定序尺度沒有。所以定序尺度只能比較大小，而不能夠進行直接的加減。雖然很多場景下，我們都會用平均滿意度來衡量客戶的滿意情況。但我們會發現這樣的使用方法，存在一些問題，例如說沒有區分度等。這些問題中，有一部分就是由于“定序尺度”的特性帶來的。
指標尺度的特性是我們必須要了解清楚的，因為低尺度的指標不能使用高尺度的數據運算進行處理。這里舉2個反例說明以下，如果沒有弄清楚指標的尺度特性會導致什么問題：
| 名義尺度 | 定序尺度 | 定距尺度 | 定比尺度 | |
| 類別區別 | √ | √ | √ | √ |
| 次序區別 | √ | √ | √ | |
| 距離區別 | √ | √ | ||
| 比例區別 | √ |
多個事實發生時間之間的異步性：
一個件事通常在一件事發生后一段時間，才會發生，或者才會被觀測到。例如訂單退款必須在下單支付之后才能發生；退房必須在入住酒店之后才能發生，且存在著一定的時間差。
事實發生與指標計算之間的異步性：
一個事實發生與這個事實被計算（為指標）之間通常存在著時間差。例如，一個消費者1分鐘內在APP上（生產環境下）下了20筆訂單。但可能在1個小時后，才能在后臺數據庫中查詢到這20筆增量的訂單記錄。這種情況的發生可能是由于任務調度的設置導致的，也可能是由于技術能力的限制導致的。再舉個例子，應該幾個月前，知乎在創作中心中統計的閱讀量還是日頻刷新的。現在也僅僅做到了小時刷新。這樣的刷新頻次可能在“創作中心”的業務場景下是可接受的，但在很多其他的業務場景下（例如短視頻推薦），是不可接受的。為了解決以上業務場景的問題，我們就需要采取流計算的技術，來提高數據生產的時效性。
事實間的“異步性”和事實與計算間的“異步性”，會影響指標反饋信息的“及時性”與對事實抽象的“準確性”。
總的來說，我們希望指標在保證一定準確性的前提下，越及時越好。為了達成這個目標，我們需要慎重的考慮兩個時間特征：“T+n”和“時間切片 v.s. 關聯綁定”
我們可以從4個維度去評價一個指標的優劣：
1. 有效性：這個指標能不反映我們量化的事實？
例如，我們想要去衡量某個APP的用戶量有多少，應該用DAU，還是MAU？不同類型的APP可能有不同的選擇，對于外賣而言，每天的DAU可能都非常關鍵。而對于一個旅行類的APP而言，因為類目本身消費頻次的不同，可能MAU才是一個更能真實反映用戶數量的指標。
2. 可信性：反映事實的指標是不是穩定的？
例如，人力部門設計了一套題庫去衡量應聘者的數據能力，希望通過測試題的分數，去做出是否招聘某位同學的決定。那么對于同一個面試的同學而言，第一次參加數據能力測試，和第二次參加數據能力測試的分數應該是相近的。
3. 敏感性：事實的變化，能否被指標敏感的捕捉到，并反映出來?
例如，對于酒店住宿預訂而言，到酒店前臺卻沒有空房可以入住，是一種非常糟糕的用戶體驗。但也是一個非常低頻發生的情況。那么是否應該用“到店無房發生率”來追蹤這個問題就是一個值得思考的問題。同理，對于輿情監控，是應該用絕對數指標來監控，還是比例指標來監控更好呢？
4. 可運營：這個指標能否被用于日常的運營，及時的幫助我們謀求改善？
例如，越來越多的公司因為對客戶忠誠度的重視，開始用NPS（客戶凈推薦值）來衡量客戶的感受。但是如果僅僅有這個主觀指標，當NPS降低了10%的時候，公司應該如何去提升用戶的忠誠度呢？
T+N：
T+n中的n應該設置為什么更為合適，是1天、3天還是5天；1小時、2小時還是5分鐘。舉個例子，保險公司要衡量保單的品質，即有沒有賣給消費者他們所需要的產品。那么用什么指標來衡量更為合適呢？大家可能會想到“退保率”。但是退保率該如何計算呢？嚴格來說，一筆保單在其合同約定的期限內的任意一天都是可以退保的。所以，從完全準確的角度出發，如果某個保險產品的合同期為20年，那么應該統計20年零1天前所有保單的退款率，即T+20y。但是，這顯然是不現實的。因為“及時性”太差了，完全不可運營。因此，我們要設計一個更恰當的時間特征n。假設，現在我們知道保險的猶豫期大約是10~15天，也許在平衡“及時性”與“準確性”之后，退款率的設計就會是“T+15d”計算。
綜上所述，當我們遇到一個量化的問題，就從上述的指標類型中選取一種設計方法，完成指標的設計工作。接下來我們要做的，就是去衡量這個設計的好壞。
- 使用指標的原因：指標可以幫助我們低成本的獲取更多信息。
- 指標的定義：指標是一個被定義的數值，用來對事實進行量化抽象。
- 指標設計的4個要素：名稱、責任人、含義、口徑。
- 指標設計的3個過程：通過抽象、加工、限定，我們可以將數據轉化為原子指標、衍生指標和派生指標。衍生指標是原子指標經過運算的結果，派生指標是原子指標和衍生指標經過維度限定的結果。
- 衡量指標設計好壞的4個標準：有效性、可信性、敏感性、是否可運營。
時間切片 v.s. 關聯綁定：
我們在計算相對指標的時候，應該以什么樣的方式進行對比？舉個例子，運營常用的流程分析，AAARR（獲取、激活、留存、收益、傳播）。通常使用這套方法去做運營分析，就要計算激活率、留存率、消費轉化率等等一系列的指標。如果我們要計算這類指標就存在一個選擇，是使用時間切片的方式去計算激活率嗎？即：今日的激活率 = 今天獲取的用戶量 / 今天激活的用戶量。但是思考一下：今天激活的用戶中，有沒有昨天獲取的用戶呢？有沒有前天獲取的用戶呢？有沒有去年獲取的用戶呢？顯然是有的。而我們在使用切片數據時，就可能導致一個現象，今天的激活率高，可能僅僅是因為今天獲取的用戶數少，而今天激活的用戶都是之前積累下來的。也就是說，有可能轉化率高，是件壞事。那么，是不是為了準確性，就用關聯綁定的方式去設計指標呢？即，計算激活率的時候，應該圈定某天獲取的那些用戶，看這些用戶中有多少激活了。例如，今天計算“T+7d ”前獲取的用戶中的激活率是多少。如果采取這樣的方式，我們就回到了問題1：“n”應該如何選擇。
什么樣的指標算一個好好的指標？
#04
小結一下
#05
經過幾年的平臺建設，vivo監控平臺產品矩陣日趨完善，在vivo終端龐大的用戶群體下，承載業務運行的服務數量眾多，監控服務體系是業務可用性保障的重要一環，監控產品全場景覆蓋生產環境各個環節。從事前發現，事中告警、定位、恢復，事后復盤總結，監控服務平臺都提供了豐富的工具包。從以前的水平拆分，按場景建設，到后來的垂直劃分，整合統一，降低平臺割裂感。同時從可觀測性、AIOps、云原生等方向，監控平臺也進行了建設實踐。未來vivo監控平臺將會向著全場景、一站式、全鏈路、智能化方向不斷探索前行。
監控服務平臺是自研的、覆蓋全場景的可用性保障系統。經過多年深耕，vivo監控團隊已經成體系構筑起一整套穩定性保障系統，隨著云原生可觀測技術變革不斷深化，監控團隊如何掌舵前行？下面就平臺的建設歷程、思考、探索，做一下簡單介紹。
Monitoring system construction
回顧監控建設歷程，最初采用Zabbix，與告警中心的組合實現簡易監控。隨著業務的發展在復雜監控場景和數據量不斷增長的情況下，這種簡易的組合就顯的捉襟見肘。所以從2018年開始我們開啟了自研之路，最開始我們建設了應用監控、日志監控、撥測監控解決了很大一部分監控場景沒有覆蓋的問題；2019年我們建設了基礎監控、自定義監控等，完成了主要監控場景的基本覆蓋；2020年我們在完善前期監控產品的同時，進一步對周邊產品進行了建設；隨著AI技術的不斷成熟，我們從2021年開始也進行了轉型升級，先后建設了故障定位平臺、統一告警平臺有了這些平臺后我們發現，要想進一步提升平臺價值，數據和平臺的統一至關重要；所以從2022年開始建設了統一監控平臺，也就是將基礎監控、應用監控和自定義監控進行了統一，統一監控包含了統一配置服務和統一檢測服務。從監控的建設歷程來看，我們一路覆蓋了IaaS、PaaS、DaaS、CaaS等平臺。我們的職能也從DevOps向AIOps邁進。
1.1 監控建設歷程
輕松保障萬級實例，
vivo服務端監控體系建設實踐
以下文章來源于dbaplus ，作者陳寧寧，vivo 互聯網服務器團隊。
原文鏈接：//mp.weixin.qq.com/s/UOI6ByTyQeo3irHNyjxOTg
一、監控體系建設之道
講了監控的發展歷程，那么這些監控產品在我們的生產環境中是如何分布的呢？要想支撐數以萬計的業務運行，需要龐雜的系統支撐，服務器、網絡環境、基礎組件等，都需要監控系統保障它的穩定性。我們將監控的對象分為五層，在基礎設施層，包含了網絡設備、服務器、存儲硬件等，這一層我們通過VGW監控對網絡設備進行監控，VGW是Vivo Gateway的縮寫，類似于LVS；通過自定義監控，對機房進行監控；系統服務器層，我們定義的監控對象是服務運行依賴的環境，通過主機監控對物理機、虛擬機等監控，當前容器在云原生技術體系中，已然成為微服務運行的最佳載體，所以對容器的監控必不可少；系統服務層，包含了各種數據庫產品、大數據組件等，在這一層主要通過自定義監控檢測、告警；業務應用層，主要有應用服務，我們通過應用監控對業務鏈路信息進行監控；客戶體驗層，我們定義了端上的訪問質量，由宙斯平臺實現監控。前面我們講了監控能力矩陣，下面我們具體介紹一下監控的范圍和整個平臺的能力。
1.3 監控對象范圍
1.2 監控能力矩陣
監控對象涉及網絡、主機、基礎服務等。面對各地機房我們做到了監控全覆蓋，為滿足各類環境部署訴求，我們可以做到針對不同環境的監控。我們支持多種采集方式，SDK和API采集主要應用在自定義監控場景，Agent主要采集主機類指標，采集上來的時序數據經過預聚合、統一的數據清洗，然后存儲在TSDB數據庫。針對海量數據存儲我們采用了數據降精，寬表多維多指標等方案。我們常用的檢測算法有恒值檢測、突變檢測、同比檢測等，同時還支持了無數據檢測、多指標組合檢測，檢測出現的異常我們會形成一個問題，問題在經過一系列的收斂后發出告警，我們有多種告警通道，支持告警合并、認領、升級等，需要展示的指標數據我們提供了豐富的自定義指標看板，對使用頻率高 固化場景，我們提供了模板化配置方案。有了完備的監控體系，那么系統的關鍵指標和監控對象體量如何？
1.4 監控系統體量
當前監控服務體系保障著x萬+的主機實例，x萬+的DB實例，每天處理x千億條各類指標和日志，對x千+的域名做到秒級監控，對x萬+的容器實例監控，每天從統一告警發出的各類告警達到x十萬+ ，對主機實例的監控覆蓋率達到x %，監控平臺通過不斷的探索實踐，實現了對海量數據計算存儲，當前對核心業務的告警延遲在x秒以內，告警召回率大于x %。
1.5 監控系統面臨挑戰
雖然現階段取得了一些成果，但是目前仍然面臨很多挑戰，主要分為三大類：
>>>部署環境復雜
對數以萬計的主機和容器，實時采集 計算是一項困難的事情；面對各地機房監控，部署過程中依賴項多，維護工作復雜；對海量數據計算存儲，保障監控服務穩定性、可用性難度大。
>>>平臺系統繁多
當前系統還存在割裂，用戶體驗不強；數據割裂，沒有從底層融合在一起，對于數據組合使用形成挑戰。
>>>新技術挑戰
首先基于容器的監控方案，對傳統監控方案形成挑戰，當前對Prometheus指標存儲處在探索階段，暫時沒有標準的解決方案，但是面對快速增長的數據量，新組件的探索試錯成本相對較高。
產品架構的能力服務層，我們定義了采集能力、檢測能力、告警能力等；功能層我們對這些能力做了具體實現，我們將監控分為主機、容器、DB等9類場景，展示層主要由Dashboard提供靈活的圖表配置能力，日志中心負責日志查詢，移動端可以對告警信息進行認領、屏蔽。
2.2 技術架構
2.1 產品架構
二、監控服務體系架構
技術架構層分為采集、計算、存儲、可視化幾大塊，首先在采集層我們通過各種采集方式進行指標采集；上報的數據主要通過Bees-Bus進行傳輸，Bees-Bus是一款公司自研的分布式、高可用的數據收集系統，指標經過Bees-Bus之后寫入Kafka，隨著Pulsar的受關注度與使用量的顯著增加，我們也在這方面進行了一定的探索；計算層我們經歷了Spark、Flink、KafkaStream幾個階段的探索，基本實現了計算層技術棧收歸到KafkaStream；數據主要存儲在Druid，當前有190+節點的Druid集群。Opentsdb和Hive早期應用在主機監控場景，隨著業務發展其性能已經不能勝任當前的寫入和查詢需求，所以逐步被舍棄。
當前我們選用了VictoriaMetrics作為Prometheus的遠端存儲，日志信息存儲在ES中，目前我們有250+的ES節點。服務層中各類監控場景的元數據，都由統一元數據服務提供；各類檢測規則、告警規則都由統一配置服務維護，統一告警服務則負責告警的收斂、合并、發送等。Grafana則主要用作自監控告警。
2.3 交互流程
在監控架構的基礎上，我們介紹一下整體交互流程，采集規則由統一元數據服務管理，并主動下發到VCS-Master，VCS-Master主要用來任務下發，Agent執行結果數據接收，任務查詢和配置管理等，Agent會定期從VCS-Master拉取緩存的采集規則，指標經過Bees-Bus雙寫到Kafka，由ETL程序對指標數據消費，然后做清洗和計算，最后統一寫入到存儲服務
中，統一配置服務下發檢測規則到異常檢測服務，檢測出的異常信息推送到Kafka，由告警代理服務對異常信息進行富化，處理好的數據推到Kafka，然后由統一告警服務消費處理。在存儲服務之上，我們做了一層查詢網關，所有的查詢會經過網關代理。
前面說了監控服務體系整體架構，那么監控產品如何服務于業務可用性。我們將業務穩定性在時間軸上進行分割，不同的時段有不同的系統保障業務可用性，當前我們主要關注MTTD和MTTR，告警延遲越小發現故障的速度也就越快，系統維修時間越短說明系統恢復速度越快，我們將MTTR指標拆解細化然后各個擊破，最終達成可用性保障要求。vivo監控服務體系提供了，涵蓋在穩定性建設中需要的故障預防、故障發現等全場景工具包，監控平臺提供了產品工具，那么與運維人員，研發人員是怎樣協作配合的？
3.2 系統可用性保障
3.1 可用性體系構建
三、可用性體系構建與保障
當監控對象有問題時，監控系統就會發送告警給運維人員或業務開發，他們通過查看相關指標修復問題。使用過程中運維人員的訴求和疑問，由監控平臺產品和開發協同配合解決，我們通過運營指標，定期梳理出不合理的告警，將對應的檢測規則同步給運維同學，然后制定調整計劃，后期我們計劃結合智能檢測，做到零配置就能檢測出異常指標。通過監控開發、運維人員和業務開發一起協同配合，保障業務的可用性。
3.3 監控系統可用性
除了保障業務可用性外，監控系統自身的可用性保障也是一個重要的課題。為了保障Agent存活，我們構建了多種維活機制，保障端上指標采集正常。數據經過Bees-Bus之后，會雙寫到兩個機房，當有一個機房出現故障，會快速切到另一個機房，保障核心業務不受損。數據鏈路的每一層都有自監控。監控平臺通過Grafana監控告警。
3.4 復雜場景下依托監控解決問題手段 監控能力矩陣
隨著公司業務發展，業務模型、部署架構越來越復雜，讓故障定位很困難，定位問題成本高。而監控系統在面對復雜、異構、調用關系冗長的系統時就起到了重要作用。在問題發現階段，例如多服務串聯調用，如果某個階段，出現耗時比較大的情況，可以通過應用監控，降低問題排查難度。在告警通知階段，可以通過統一告警對異常統一收斂，然后根據告警策略，通知給運維或者開發。問題定位時，可以利用故障定位服務找到最可能出現問題的服務。解決問題時，類似磁盤打滿這種比較常見的故障，可以通過回調作業快速排障。復盤改進階段，故障管理平臺可以統一管理，全流程復盤，使解決過程可追溯。預防演練階段，在服務上線前，可以對服務進行壓力測試，根據指標設置容量。
當前行業正迎來快速變革，我們在云原生、AIOps、可觀性等方向均進行了探索實踐。未來我們也想緊跟行業熱點，繼續深挖產品價值。隨著Kubernetes成為容器編排領域的事實標準，Prometheus因為對容器監控良好的適配，使其成為云原生時代，容器監控的事實標準。下面我們介紹一下整體架構，我們將容器監控分為容器集群監控和容器業務監控，首先對于容器集群監控，每個生產集群都有獨立的監控節點，用于部署監控組件，Prometheus按照采集目標服務劃分為多組，數據存儲采用VictoriaMetrics，我們簡稱VM，同一機房的Prometheus集群，均將監控數據Remote-Write到VM中，VM配置為多副本存儲。通過撥測監控，實現對Prometheus自監控，保障Prometheus異常時能收到告警信息。容器業務監控方面，Agent部署在宿主機，并從Cadvisor拉取指標數據，上報到Bees-Bus，Bees-Bus將數據雙寫到兩個Kafka集群，統一檢測服務異步檢測指標數據，業務監控指標數據采用VM做遠端存儲，Dashboard通過Promql語句查詢展示指標數據。
4.2 AIOps：故障定位
4.1 云原生：Prometheus監控
四、行業變革下的監控探索實踐及未來規劃
當前業界對AIOps的探索，大部分在一些細分場景，我們也在故障定位這個方向進行了探索。分析過程中首先通過CMDB節點樹，選定需要分析的項目節點，然后選擇需要分析的時段，就可以按組件和服務下鉆分析，通過計算得出每個下游服務的波動方差，再利用K-Means聚類，過濾掉波動較小的聚類，找到可能出現異常的服務或組件。分析過程會形成一張原因鏈路圖，方便用戶快速找到異常服務，分析結果會推薦給用戶，告知用戶最可能出現異常的原因。詳情查看功能可以看到被調用的下游服務、接口名、耗時等信息。
4.3 可觀測性：可用性大盤
由于CNCF在云原生的定義中提到了Observerbility，所以近兩年可觀性，成了技術圈很火熱的關鍵詞。當前業界基于Metrics、Logs、Traces對可觀測性形成了一定共識。谷歌也給出了可觀測的核心價值就是快速排障。我們認為指標、日志、追蹤是實現可觀測性的基礎，在此基礎上將三者有機融合，針對不同的場景將他們串聯在一起，實現方便快捷的查找故障根因，綜上我們建設了可用性大盤，它能查看服務的健康狀況，通過下鉆，可以看到上下游服務依賴關系、域名健康狀況、后端服務分布等。通過串聯跳轉等方式可以看到對應服務的日志和指標信息。
4.4 場景串聯
未來我們希望在場景串聯、可觀測性、服務能力化進一步探索，深挖產品價值。場景串聯上：
首先我們希望告警能夠與故障定位平臺串聯，幫助用戶快速找到故障根因，縮短排查時間 ；
告警記錄能夠一鍵轉為事件，減少數據鏈路中人為操作的環節，保障數據的真實性；
我們希望能與CMDB等平臺打通，將數據價值最大化。?
4.5 統一可觀測
現在，vivo監控服務體系的可觀測產品沒有完全融合在一起，所以后續我們希望構建統一可觀測平臺：在一元場景中，可以單獨查看指標、日志、追蹤信息；
在轉化場景中，能夠通過日志獲得指標數據，對日志的聚合和轉化得到追蹤，利用調用鏈的分析，獲得調用范圍內的指標。通過指標、日志、追蹤多個維度找到故障的源頭；
在二元場景，我們希望日志和指標、日志和追蹤、追蹤和指標能夠相互結合，聚合分析。
4.6 能力服務化
目前監控有很多服務，在公司構建混合云平臺的大背景下，監控系統的服務應該具備以能力化的方式提供出去。未來我們希望指標、圖表、告警等，以API或者獨立服務的方式提供能力，例如在CICD服務部署過程中，就可以通過監控提供的圖表能力，看到服務部署時關鍵指標變化情況，而不需要跳轉到監控服務查看指標信息。
最后，我們希望監控能更好的保障業務可用性，在此基礎上，我們也希望通過監控系統提升業務服務質量。
電話：15801365057
郵箱：kai.zhao@yeepay.com
地址：朝外大街甲6號萬通中心D座
增值電信業務經營許可證：陜B2-20210327 |