The Mirages

买来的联想小新amd 2020版本，结果没多久发现了一个问题，就是休眠了之后经常无法正常开机。

当时找了微软支持说是amd的驱动问题，需要更新什么的。可更新了之后过几天依然有问题。

这次因为装了可恶的华宇拼音导致系统里一堆垃圾。然后想安个windows10，结果发现安装到一半居然挂了。

于是在微软官网下载了一个windows11，然后用别人的电脑（家里还有一个32位的windows xp做不了）做了一个启动u盘，一路正常安装居然都好了。

也没有什么序列号认证啥的，直接微软账号就认证通过了。

更好的是这次用了2周一次休眠死机都没有发生过。

这次MU事故后，跟球球一起回顾了很多事故。什么飞机撞南极火山，法航掉海这些事故， 以及当年的723动车事故。

这些所有事故都有详细的分析。比如 723： https://baike.baidu.com/item/7%C2%B723%E7%94%AC%E6%B8%A9%E7%BA%BF%E7%89%B9%E5%88%AB%E9%87%8D%E5%A4%A7%E9%93%81%E8%B7%AF%E4%BA%A4%E9%80%9A%E4%BA%8B%E6%95%85/10805173

723事故里最不该被处理的其实是后面的发言人。当然这是个人观点。

这些事故我们时候分析都会发现其实有很多次机会都是可以避免的，经常都是几件事情叠加导致的。按照海恩法则的说法：在机械生产过程中，每发生330起意外事件，有300件未产生人员伤害，29件造成人员轻伤，1件导致重伤或死亡。

反着说就是每一起重大事故后面都会有29件轻微事故，有300个意外事件。

把这个法则挪用到互联网公司上就是说每一次线上重大事故背后都有29个轻微事故和300个问题导致的。

早上看到有2个nginx服务器在6点多的时候带宽跑到100M多，整个磁盘io也都非常高。

因为现在都是vpc的服务器，内网公网都是在一个网卡上，随意一时也判断不出来到底是内网还是公网导致的。

查看对应的slb是否有异常。查看这个机器前面所有的slb发现流量都正常。

因为nginx的带宽是出口方向是100M的，那就是从本机往外传输，于是就看下nginx请求是否有异常，发现也都很正常。

查看整个集群的服务器的带宽是否有问题。发现整个集群里这个时间点只有这2个nginx的出，但是没有哪个服务器是进的。

因为这个机器对外服务端口只有web server，但是我们nginx又没有日志显示有那么多的流量。那基本可以确认是本机主动发起的对外请求。

我们都知道http1.1是支持keepalive，这样就可以减少建连的次数，可以提高性能。

于是简单在单机上做了一个测试。

我们先使用一个没有keepalive的配置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

upstream test_server {
        server 127.0.0.1:8999;
        server 127.0.0.1:8997;
        keepalive 32;
}

server {
    listen 8998;
      server_name _;
    access_log /opt/server/nginx/log/8998-access.log main;
    error_log /opt/server/nginx/log/8998-error.log;

      location / {
        proxy_pass http://test_server;
#        proxy_http_version 1.1;
#        proxy_set_header Connection "";
      }
}



server {
    listen 8999;
      server_name _;
    access_log /opt/server/nginx/log/8999-access.log main;
    error_log /opt/server/nginx/log/8999-error.log;

      location / {
        return 200 '{"status":"OK","entities":[]}';
      }
}
server {
    listen 8997;
      server_name _;
    access_log /opt/server/nginx/log/8997-access.log main;
    error_log /opt/server/nginx/log/8997-error.log;

      location / {
        return 200 '{"status":"OK","entities":[]}';
      }
}

测试结果如下：

1
2
3
4
5
6
7
8
9

$ wrk -t1 -c32 -d60s http://127.0.0.1:8998/
Running 1m test @ http://127.0.0.1:8998/
  1 threads and 32 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.61ms    2.14ms  76.87ms   99.52%
    Req/Sec    21.31k     2.22k   26.73k    69.00%
  1272221 requests in 1.00m, 260.85MB read
Requests/sec:  21202.84
Transfer/sec:      4.35MB

这周真算是波澜壮阔的一周。
周一周二的全面下跌，大有崩溃之势。而到了周三周四又是全面收复失地。

可实际上中概互联这些算最高点开始都已经打一折了，好多都是0.5折，0.1折了。就算现在一天涨50%，那也就是从0.1折变成0.2折，从0.5折涨到一折。

但是周一周二真的是底部吗？有过08年和15年的股民肯定知道这只是前菜。只有你哪天看到狂拉银行股的时候，那才算是最悲观的时候。但是市场的最低往往还要往后继续延后。

就算是2015年千股跌停，但是市场一直到2018年底才是最最低的那个底。因为这些都是有惯性的。

2000年纳斯达克一泻千里，但是最低的那个底一直到2002年才出现。

其实最快的是08年的崩溃，我从其他资料也看到了，在2006年有人就已经开始做空了，2007年大部分泡沫也都已经破裂了，只是雷曼本身作为一个标志性事件，然后就是几万亿的资金进入。

nginx connection limit模块是用来限制整体的连接数。这个贵司是用来限制单个nginx最大连接数。一旦超过了就限制重新连接，默认就返回503了。

这个阿里云slb也是这样的策略。

但是我们碰到了一点问题。突然有一台服务器reload之后，发现很多503返回了。可查了一下当时该机器的连接数，并没有超过我们设置的限定数。但其他服务器的却没有问题。

配置如下：

1
2
3

#整个整体连接数限制：
  limit_conn_zone all zone=allserver:10m;
  limit_conn allserver 50000;

而且每次reload之后我们会清理的对应shutting down的进程。 后来只能通过restart nginx来处理。于是我们就进行了测试。

mesos+marathon是一个很好用的资源调度框架.
原先我们很多调度原则都是基于hostname来进行，但是这样其实很不方便。

其实很早mesos slave就支持使用attribute了。

首先需要在mesos slave服务器上增加相应的attribute

1

echo "rack:bj-h;type:v4c;internet:no" > /etc/mesos-slave/attriburtes

如果这个服务器上还运行着对应容器，那我们先挪走这些容器。然后重启mesos-slave进程

1
2
3

sudo rm -rf /data/apps/mesos-slave/data/meta/slaves/latest
sudo systemctl restart mesos-slave
ps aux | grep mesos-slave | grep attribute

上一次物业要求关窗户，关窗帘还是2006年的时候了，那时候内贾德老兄来魔都开会，于是整个延安路高架两边的写字楼都被要求了。毕竟是敏感人物和敏感事情。

不过现在帝都还要求这样，还跟开会地方八竿子都打不着的写字楼也要求这样，下午路过，这路口全部都是保安，难道这旁边这宾馆住了什么敏感人物？

年年开两会，以前都每啥要求，这真的有点过头。两会不都是人大代表，人大代表不就是人民自己选出来的。

要做一个很简单的功能。就是对整个nginx限流，因此也不需要定义好特别的变量

1
2
3
4

#整个nginx每秒请求数限制：
  limit_req_zone allreq zone=allreq:10m rate=20000r/s;
  limit_req_dry_run on;
  limit_req zone=allreq burst=10 nodelay;

为了防止被误拦截，于是还特地加了limit_req_dry_run方法。这里就是限制整个nginx每秒20000次请求。超过了就返回503.

可观察了一天，发现居然还是要有超过的，虽然burst设置为10，可居然还是有超过的，最多的都超了20多。

这就很奇怪了，这个机器的并发根本不会到2万每秒的，难道这里必须写变量？ 可也不对啊，这里检查也没有报错。那不会是nginx的bug，于是下载1.18.1的代码看了下

src/http/modules/ngx_http_limit_req_module.c文件的468行里是这样来的。

在IT相关的公司中，sa和sre一般都会被称为运维。 原先我一直认为并没有特别大的区别，但是这2者的概念其实是有很大的区别，出发点也是不一样的。

sa（system admin）这个岗位在大宋是在20多年前产生的，也是伴随着第一代互联网公司产生的。 而他们的工作职责主要是维护服务器，交换机，高级点还有点防火墙什么的。而这些事情可能就花费了大量的时间。当年就看到某游戏公司的2个运维在机房里待了1个月，就为了上架30多个机柜的服务器。

而当年会用kickstart安装操作系统也算是小有成就。更高点的还要进行驱动更新，kernel裁剪这些事情。以及要对整个操作系统的启动流程要烂熟于心。
而我当年还干了一点什么测量服务器最大电流，平均工作负载的电流，就是为了一个机柜里塞更多的机器。

魔都电话电报局的那个机房因为年代久远，管理混乱，经常你推着机房小推车就不知道把谁家的网线电源给兜走了。能知道的就给人插回去，不知道插哪里的就只能扔那里了。

这个第一代sa主要就是针对硬件，操作系统相关的工作。因此他们一般对于操作系统，网络协议都会非常熟悉。这些是跟后面几代的区别差异。

而第二代sa的成长是由于整个硬件和操作系统的成熟度越来越高，而且远程控制卡(iDRAC)这些越来越成熟，终于可以脱离物理的限制进行远程工作了。那时间更多的在操作系统之上的基础软件上了。http server，db server， cache server这些事情上花的时间更多了。