GitHub网站究竟可不可靠？谷歌工程师教你用BigQuery一探究竟
程序员文章站
2022-07-15 16:57:37
...
以独特方式组织的可视化数据往往能够为我们提出一些有趣的观点。Felipe Hoffa最近使用BigQuery结合Reddit近八年来的网站活动以及上线时间数据进行了可视化分析，我们从中看到了一些非常有趣的信息。作为一名刚入门的负责任务控制的网站可靠性工程师，我总是会这样问自己，"如果我是负责这项服务的可靠性工程师，我会采用什么方法解决这个问题？"
这次，Felipe将从可靠性工程师的角度出发，对GitHub的一些历史数据展开分析。首先，我们需要先确定，使用BigQuery对GitHub Archive上关于GitHub的部分事件数据进行分析是否足以推断出GitHub网站的健康状况。GitHub为开发者定义了很多种不同的活动事件类型，但在本篇文章的分析中，我们仅关注成功向GitHub发出请求的事件。
我们可以使用这个查询语句：
#StandardSQL
SELECT TIMESTAMP_TRUNC(created_at, MINUTE) minute, COUNT(*)
FROM `githubarchive.month.201607`
GROUP BY 1
ORDER BY 1
我们可以找到在2016年7月中GitHub在每一分钟发生的事件数量。created_at字段记录了一个以微秒为单位的时间戳，查询语句将其按分钟进行截取。这使得我们将查询结果按时间戳分组时，可以使用COUNT聚合函数来统计每分钟对应的事件数量。将查询结果简单可视化即可得到下图：
9a26e9f745bea2c293acd60f823df35236e30f64
在上图中我们可以发现一些很有趣的数据点，这些数据点对应的事件数量格外得低，但是，仅通过上图我们很难准确判断每一分钟究竟是"正常的"还是"异常的"。因此，我们可以根据查询结果创建事件数据直方图，使判断的过程变得更加清晰。
b4346e1a391eedfaee31ff66c2d9bc79172d69be
这幅图很明显地表明，对于GitHub，当每分钟内处理的事件总数低于200时，网站处于异常的状态，这一结论至少在2016年7月份是成立的。我们假设每分钟极少数的事件与异常少的终端用户请求无关，而是由于网站自身服务器问题所导致的。在这个前提下，有两种可能的解释：用户请求未达到服务器，或者服务器无法成功响应用户请求。这为我们提供了一个标志来近似地判断GitHub当前的状态是"健康"还是"不健康"。
阅读全文直接点击：http://click.aliyun.com/m/10252/
这次，Felipe将从可靠性工程师的角度出发，对GitHub的一些历史数据展开分析。首先，我们需要先确定，使用BigQuery对GitHub Archive上关于GitHub的部分事件数据进行分析是否足以推断出GitHub网站的健康状况。GitHub为开发者定义了很多种不同的活动事件类型，但在本篇文章的分析中，我们仅关注成功向GitHub发出请求的事件。
我们可以使用这个查询语句：
#StandardSQL
SELECT TIMESTAMP_TRUNC(created_at, MINUTE) minute, COUNT(*)
FROM `githubarchive.month.201607`
GROUP BY 1
ORDER BY 1
我们可以找到在2016年7月中GitHub在每一分钟发生的事件数量。created_at字段记录了一个以微秒为单位的时间戳，查询语句将其按分钟进行截取。这使得我们将查询结果按时间戳分组时，可以使用COUNT聚合函数来统计每分钟对应的事件数量。将查询结果简单可视化即可得到下图：
9a26e9f745bea2c293acd60f823df35236e30f64
在上图中我们可以发现一些很有趣的数据点，这些数据点对应的事件数量格外得低，但是，仅通过上图我们很难准确判断每一分钟究竟是"正常的"还是"异常的"。因此，我们可以根据查询结果创建事件数据直方图，使判断的过程变得更加清晰。
b4346e1a391eedfaee31ff66c2d9bc79172d69be
这幅图很明显地表明，对于GitHub，当每分钟内处理的事件总数低于200时，网站处于异常的状态，这一结论至少在2016年7月份是成立的。我们假设每分钟极少数的事件与异常少的终端用户请求无关，而是由于网站自身服务器问题所导致的。在这个前提下，有两种可能的解释：用户请求未达到服务器，或者服务器无法成功响应用户请求。这为我们提供了一个标志来近似地判断GitHub当前的状态是"健康"还是"不健康"。
阅读全文直接点击：http://click.aliyun.com/m/10252/