本文上接随笔：利用云服务器+脚本实现自动“健康填报”，感兴趣的朋友可以看一看
继6月份考试周我实现了每天自动健康填报后，每天的懒觉睡得更香了，再也不用担心漏打卡写检讨的风险了。
当然，有时候我为了保险，还是检查了一下打卡列表。在研发自动打卡程序时，我就已经发现，学校打卡所显示的打卡时间比实际时间要慢约10分钟。我相信大部分同学都或多或少知道这个bug，但对于另外的一个有趣现象，我相信只有少数人才能发现。
请大家观察一下下面的打卡截图，你发现了什么？
细心的朋友应该发现了，每天的打卡时间似乎是一个随时间递减的等差数列。按理来说，由于之前所设置的crontab定时命令，自动打卡脚本会在云服务器时间8:00准时运行，不存在每天打卡时间的变化。放大到一个月的数据里分析，这个规律更加明显。通常这只有两种可能：
- 云服务器每天的系统时间正在变快
- 学校疫情填报系统服务器的时间源正在变慢
我们使用排除法，首先检验第一种可能。Linux查找系统时间的命令如下：
ubuntu@VM-4-17-ubuntu:~$ date Fri 22 Jul 2022 08:43:25 PM CST
通过多方比对可以认定，云服务器的系统时间分秒不差。那么问题一定出在学校那边，这就很有趣了。
为了更深入的讨论，我们首先来进行简单的数据分析。将自变量设为自2020年1月1日的天数，因变量设为打卡时间相对于8:00的秒数偏移量（取负数），建立一元线性回归模型，并以95%的置信度计算系数的置信区间。
数据预处理：由于自动打卡脚本曾被维护过，打卡时间列表中其实存在无效值，用相邻两天打卡时间均值代替。
实在懒得学python回归分析相关的库（其实是没咋学会），就用matlab算了
clc,clear,close all
x = [ones(25,1) (910:934)'];
y = [-584,-586,-588,-589,-591,-592,-594,-595,-597,-598,-599,-601,-602,...
-604,-605,-606,-609,-609,-611,-612,-613,-615,-616,-618,-619]';
hold on
plot(x(:,2),y,'r.')
[b,bint,~,~,stats] = regress(y,x)
f = @(x) b(1)+b(2).*x;
fplot(f,[910 934],'b-')
xlabel('日期')
ylabel('时间偏移量')
title('线性回归模型')
Output:
b = 2×1
717.7585
-1.4315
bint = 2×2
694.2374 741.2795
-1.4570 -1.4060
stats = 1×4
0.998296164684288 13475.9571984436 2.38844513707907e-33 0.197692307692307
利用最小二乘法得到回归方程为y=717.7585-1.4315*x，拟合优度99.83%，线性关系显著，拟合函数图像如下：
当时间偏移量为零时，x显然就是时间变慢的起始时刻，由上面所得到的线性回归方程，简单计算可得x=501.3896，大概对应2021年5月16日星期日9时20分59秒，在95%置信度下，这个时刻的误差大约±25天。
我最初以为这个时间就是”每日疫情填报“系统上线的时间，后来发现还是我太天真了。我在学校信息化与管理处官网查到，最早2020年2月9日就有关于每日填报的通知。因此这个时间可能单纯就是某个bug被触发的时刻，且这个bug导致了每天填报系统的打卡时间变慢。我想到了两种可能：
- 系统时间每天均匀变慢：可能是疫情填报系统服务器时间源出了问题，或者是其他硬件原因
- 系统时间在某一刻突然停止或变慢：可能是服务器在这一刻重启或是运行其他程序，导致系统时间短暂停止或受影响而变慢
为了排查具体原因，我们可以尝试利用之前的自动化打卡脚本，每隔10分钟打卡一次，连续运行3天，观察打卡时间是否有均匀变慢现象，或者线性相关性是否显著，还是说时间偏移量呈现阶梯函数型，这样大概就可以知道大致的原因了。
由于我没啥时间懒，故不作尝试了，感兴趣的朋友可以继续排查一下