2023年第2期
总第16期
contents
目录
【数据分析思维】多因素影响下如何归因？
风向
豆瓣即战场，春节档口碑的极与极
数说
一线
指标设计方法，终于有人讲明白了，数据分析师还不快看？！
轻松保障万级实例，ViVo服务端监控体系建设实践
热点
以下文章来源于澎湃美数课 ，作者澎湃美数课
原文链接：https://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 写在前面
以下文章来源于数据分析星球 ，作者数据分析星球
原文链接：https://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（斤）的含义是截然不同的。
以下文章来源于来源：知乎，作者：好好的分析师
原文链接：https://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 互联网服务器团队。
原文链接：https://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 | 
陕公网安备 61102302611033号