Teams通话质量仪表盘进阶使用

本文针对已经了解Teams 通话质量仪表盘的读者

目前官网的7张模板其实对大多数用户来说不是特别适用

那么在GitHub上现在有新的模板下载，名叫QER–Quality Experience Report–质量体验报告。
这份报告接触下来是受到很多管理员喜爱的，因为从各个维度分析了通话质量，并且几乎每张表之前都可以互相联动。

首先是下载地址–这里
安装和链接方式不熟悉的可以看这里

其次从哪里入手来看这张表：
一下子有20多个页面可以去查看，的确会有点儿懵，这里有几下几种情况

1. 你知道自己要查什么
   查特定用户
   特定的网段
   特定的会议
2. 你不知道从哪里查起

对于第一种情况很简单，有个专门的search 页面：

如果不知道怎么获取conference id或者meeting id，其实下面有提示：

有人会注意到这个只针对过去28天，是不是2个月以前的看不到呢?
不是的，通话质量仪表盘（后面简称CQD）可以保存1年以上的记录，这个限制是在Page level filter里做了设置所以只能看到28天内，你可以去修改：

现在着重讲第二种情况，也就是你不知道这个报告从哪里下手来看：
这里如果你是Teams的管理员，那么多多少少会收到一些用户关于Teams会议质量方面的反馈，比如语音卡顿，视频分辨率低，掉线等等，反正会议嘛，不外乎就是音频，视频，分享这三个。这里也针对这三样分别有8张报告，一个基础的一个详细的：（图截不完整，LOL）

这里建议去看Audio Health，因为如果音频质量都不行那么其他几个肯定也好不到哪去，因为都是走的UDP，而且音频占用带宽最少。

这里首先看最上面几个，还记得我上面说过用户给你的日常反馈么？这里就可以实际看看是不是反映出来了。
首先是整体-overall是5.75%的poor call rate，那么因为这里我们没有区分内外网，所以需要达到3%才是一个比较合理的也就是变绿的指标，下面附一张微软的建议的健康指标：

然后我们看到这里很有意思：

插了网线的反而质量最不好，wifi 5G大概率是优于2.4GHz的这正常。这里先记住，有线链接质量最差，当然这里没法直接知道为什么，可能是各种各样的原因，网线老化，交换机问题等等。注意的是这个情况一定是大批量存在的而不是个别用户的问题拉低了整体的通话质量。

接着来看国家情况：

这里只看stream最多的，你会发现在CQD里总有一些空白的名称也有数据，这些是无效的，不用管他们，如果你需要的话可以在filter里过滤掉blank和null。不然对于强迫症来说可能有点儿难受，或者你给老板展示的时候人家也会问：

这样看着是不是好受点儿？
看这个实例，虽然香港的poor call rate是100%但是一共过去7天也就2路流，所以不作为参考，其他几个国家也是一样，当然这些问题也要解决，不过我们着重看stream数量最多的印度尼西亚，进入焦点模式然后打开下拉菜单：

通过这些网段不难判断一些问题，192这些大概率都是用户自己家里，10.开头的一般是公司。家里或者酒店咖啡厅这些我们就不用管了，因为也管不了。总不能公司出钱去优化星巴克的网络吧。
这里我们找一个poor call rate较高然后stream也挺高的网段来做排查：

记得我说的联动么，这就是联动，可以下钻到针对这个网段的一些detail页面，这里我们仍然来看audio detail：

首先不要惊讶有些数据是空的或者图标展示不出来，有些是小bug导致的，有些是确实没有相关数据，也就是是Teams没有收集到，也是因为我们的采样现在非常具体化了，精确到了特定的这个网段而且如果数据流不够多确实会有这样的情况，那么还是记住那句话，我们只关注被采集到的数据。

先看大的，wif 2.4的表现确实不好，但是这里没有数据显示有人链接5G这个频段，所以可以考虑看看这个路由器是否支持5G，又或者用户设备是否支持5G。

再看heatmap：

同样，看stream数量多的，但是这里很明显三个子网在packet loss rate max上一致的飘红。丢包率都非常严重，而且RTT也很高，这就有可能是用户没有连接到就近的微软数据中心所导致的，数据绕的弯儿太大丢包是肯定的。

当然你不用特别点进去看heatmap，下面的四个饼图也告诉你了同样的问题。这里反而我先看最右边的协议，很好都是UDP基本，如果看到大量TCP那就不对了，开会用TCP基本不会有好的体验。

这里还有要针对用户级别的一个表格，但是我一般不会去看
我会去看这个meeting audio quality：

poor feedback rate基本都是NaN，这个就是用户打分，每个会议后打星的哪个，所以没有也罢。
找个会议然后同样的方式下钻到meeing health detial。

有意思的来了，记得我上面看的是印度尼西亚的用户么？
这个Host Region居然是Japan，我印度尼西亚的用户没有连到印尼，香港新加波这三个离得最近的数据中心，反而连到了日本？？？

怪不得RTT这么高，不过总的来说这个会议质量是OK的，一共19个人的会议，而且是内部会议，也没有人电话拨入：

如果是外边的人就会显示anyoumous，当然外人切换成来宾身份加入也会显示为user。

这里的数据就有些过于庞大，70%其实你都不用管，主要也是因为这个会议的质量还不错，重点看的几个其实之前也看过了，因为我们都是一路下钻过来的，每一次下钻都等于用了一个filter，所以wifi都是2.4，不过这里wifi协议可以升级一下，transport用的也都是UDP没问题，个别用户发现用的是自己的手机流量，不过无所谓。
因为我们最重要的发现就是这个会议ISP都是印度尼西亚的但是却选址在日本的数据中心，这是为什么呢？

1. 第一个加入会议的用户在日本？
2. 公司的网络出口在日本？
3. DNS解析是在日本？
4. VPN连到了日本?
5. ISP给我连到了日本？
6. 就近的3个微软数据中心在做负载均衡所以给我重定向到了日本？
   等等

这些就需要管理员自行排查了，可能需要公司的网络工程师来一起看一下。

最后自己做一个图标发现，公司30%多的会议流全都走到了日本的数据中心

那如果网络部门可以确定自己跟ISP都没有做什么把流量定向到日本的操作，这大概率就是微软在做负载均衡所以导致的。

当然还有其他的一些排查，比如用户使用的客户端上，安卓表现肯定没苹果好，移动端和网页端肯定没客户端好：

所以建议大家都用windows会瞬间提升全公司的会议质量。

一篇文章很难写完所有的报告改怎么看，因为各有各的情况，本文只是一个比较通用的方式。也就不断地下钻，最后在根据发现的原因重新放大的全公司看是否可以套用。

如果有问题，欢迎留言私信讨论。