记10月份两次生产故障
我的线下考试因为新冠疫情，本来12月能考，硬是推到了年后，搞到我无比困扰，早考早超生嘛~~~~感觉太久没写博客，人都懒了
之前说过，在10月份那会出现了两次生产故障，一个是关于系统安全加固的；另一个是git问题。
生产故障（1）
系统安全加固做的是登录失败处理功能策略，大家肯定不陌生，centos 7用的是pam_tally2模块，但如果换成阿里的操作系统：Alibaba Cloud Linux 3.2104 LTS 64位，再使用pam_tally2模块，就会出现问题。而我在9月份刚部署完生产环境，就顺便配置系统的登录失败功能。因为记得等保是需要做的，而且我也做过很多次，于是直接编辑文件：/etc/pam.d/system-auth 和 /etc/pam.d/password-auth，不假思索地敲进去
auth required pam_tally2.so onerr=fail deny=5 unlock_time=180 even_deny_root root_unlock_time=180
wq保存的时候，是不会直接告诉你配置是不是有问题的，不像crond计划任务，编辑有问题会使你无法保存文件。只有查看：/var/log/secure，才会看到报错（这个我还是事后才知道关于pam模块的日志都在secure里，messages是看不到报错的）
Oct 12 10:43:10 sudo[610567]: PAM unable to dlopen(/usr/lib64/security/pam_tally2.so): /usr/lib64/security/pam_tally2.so: cannot open sh
ared object file: No such file or directory
Oct 12 10:43:10 sudo[610567]: PAM adding faulty module: /usr/lib64/security/pam_tally2.so
我当时以为没有问题，因为测过登录失败处理是能生效的。
另外，为了方便，我还设置了普通用户免密码切换到root “sudo su -”。如果没有去掉这个设置，系统能很正常地使用！
visudo查看是这样的配置
{普通用户} ALL=(ALL) NOPASSWD:ALL
然后，10月份那会，阿里的云安全中心，爆出个应用系统远程执行漏洞，这个漏洞很可怕，能在系统上提权。当时领导担心攻击者已经偷偷潜入到服务器，伪装成正常程序，甚至想我格式化系统，等修复完问题再重新部署。我苦口婆心地给他说，要是以后又爆出个这样的漏洞，岂不是每次都要格式化系统？这样非常浪费人力物力，所以最后还是没有格式化，而是该安全加固赶紧加固好。想到应用程序运行用户就是那个可以直接免密码切换到root的用户，所以我得赶紧把这个权限收回来，运行“su - ”需要输入root密码。大家都知道直接 visudo 把普通用户那条命令去掉即可，我当时选择晚上10点后生产环境服务停了之后再去掉。
当去掉的时候，报su 模块未知错误，普通用户再也切换不到root了，而且那会已经断开了root用户的终端，所以想去掉该配置都不行。一开始还以为root密码改过，关机重置密码后还是不行。
在接近11点夜深人静的时候，我开始急了（那会系统刚上线没多久，经常加班，人也是恍恍惚惚状态，只能说，不要晚上下决策！！！），改之前没有做快照备份，想着一个这么简单的东西，都做过很多次了，然而，就是自信过头害了我~~~想到每天凌晨3点都有备份快照，应用服务器应该除了jar包外，没有什么重要东西，然后关机，直接回滚前一天云盘快照了。回滚完能切换到root了，但突然想起来开发有在这台服务器建了个目录，专门用来存用户图片，再查下这个目录，搞丢了当天凌晨3点后到我回滚快照前的数据！跟阿里沟通能不能后台恢复，他们也没办法。
话说故障是国庆假期之后连续上班的第7个工作日，本想着第二天终于能休息，但搞出个这样的故障，只能第二天回去认错（是的，我基本一晚上没睡，想着怎么被祭天，想着赶紧转行再也不要当运维了，乱七八糟想了一堆，第二天早早醒了，7点多打电话给我经理、开发说明了情况，说回去公司一趟，看有什么需要处理的，该写故障报告就写故障报告）。
最后这个事，经理统一了市场客服口径，说那天网络不稳定，叫客户重传数据，而我后面两周基本天天无偿加班（都不好意思提加班，因为自己犯的错）。重传图片，并不是把客户图片单纯放上去就行了，图片名字是程序给的无规律一长串的字符串，得改成那样的名字，才能对上。。。大概处理了几百张图片吧
回到正题，为啥会搞出这样的问题：因为阿里的操作系统是基于centos 8 的（Alibaba Cloud Linux 3.2104 LTS 64位），centos 8 是没有 pam_tally2.so 这个模块，在测试服务器都没测过，因为压根没有测试服务器！！！当时做的采购方案，是没有预留买相同操作系统的测试服务器的（一直想着采购方案怎么压成本），全部都是生产，以至于我对阿里的操作系统很陌生，第一次用，以为跟centos 7 一样。后来比较感动的一个事，我老板特意说他自己也有问题，没有给我买一台测试服务器，当天我就有了一台属于我自己测试的服务器了~~
写了这个不存在的模块到配置文件没关系，前提是visudo没有去掉普通用户免密码运行root命令的配置，去掉就会导致普通用户怎么样都无法切换到root。最后发现centos 8 需要用 faillock.so。
总结就是：
（1）不要太过自信
连备份都不做直接改生产环境的东西，即使之前有经验也要留点心眼。
（2）按规范行事
后来我领导为了给我提个醒，搞了个工单记录，修改生产环境配置前有提交工单记录，包括问题处理措施，恢复措施，需要申请什么权限等等；云控制台设置操作保护
（3）不要一知半解
譬如我就不知道pam安全模块的日志都写到 secure 日志里的，而且我还直接忽略报错信息，没去深究报错会影响什么东西
生产故障（2）
这个也是10月份的生产故障，不过只有前台和我知道，业主方没有发现。。。比上一个故障更可怕
当时老板想把业主方的网站代码迁回到他们的服务器上，不要继续放在我们公司域名下的gitlab，原因是在我们域名下，是没有WAF防护的，他们服务器上就有，所以需要我在他们服务器上重新部署个gitlab。
简单介绍下背景，业主方的网站是个静态网，从我们公司内网后台程序发布新闻，再上传同步到gitlab，最后再同步拉取到他们服务器网站，nginx去代理访问。其中gitlab用的是我们公司域名的。
老板说的挺轻易，叫我直接将内网后台关联的远程gitlab指回到业主方的gitlab，然而并不容易，因为隐藏目录.git存储的都是我们公司域名下gitlab的东西。另外一点就是，每天都需要做发文章做同步，公司内网后台程序服务器只有一台，该服务器所在宿主机ESXI的空间又不够，以至于我经常要斟酌空间大小，去做关键操作前的快照备份。
在测试修改远程关联的gitlab地址时（也就是从我们公司，指回到业务方的服务器上），不知道什么原因，可能我改过关联仓库到业主方gitlab，然后发现报错又改回到我们公司gitlab，有一天发新闻的时候同步到线上的过程中，竟然把在我们公司的gitlab存放的代码给清空了！！！而线上网站一直是从gitlab拉的代码，gitlab代码空了，同步到服务器上，直接导致网站访问404。
我之前空闲没事的时候，做了一主两备的架构，其中一台备机是20分钟同步一次，另一台是晚上同步一次。一主一备代码都被清空了，只有那台晚上同步一次的备机还存放着代码，但是我那会没想到这台机器，恢复的时候是用主服务器上前一天备份文件恢复的，解压完大概半个小时，整个半小时恢复过程中真是肾上腺素飙升，我一直关注前台消息，业主方那边有没有发现，幸好那会9点多，业主方没人去看网站，所以算是瞒天过海。
最终不得不在内网服务器上，重新上传到gitlab，恢复了差不多1天时间，中午都没睡。
后来为了保险起见，我装了个vmware vsphere web client，虽然这个后台程序服务器所在的esxi空间不足，但另一台新买的esxi空间够，所以我通过克隆模板【https://www.cnblogs.com/windysai/p/16773860.html】创建跟这个后台发布服务器一摸一样的环境，安心地做着测试，再快要测试成功的时候，发现WAF压根不支持ssh协议，同步gitlab代码需要ssh协议，而且要开ssh端口，意味着，迁移回去没有多大意义！！！（总不能git同步的时候开个https协议，每次都需要人手输入账号密码那么麻烦的吧）
最后不需要改回到业主方的gitlab，我的测试就到此为止了，再也不需要做这种危险的修改关联gitlab远程仓库的测试（感觉已经超出我的能力水平），业主方这个gitlab也变成备用代码仓库留着。。。
再加上我告诉老板，WAF保护不了是一个问题，业主方那批服务器是没有快照备份的（天翼云），放我们公司名下（阿里云），一天一备，会更有保障。
终逃过一劫。。。哈哈哈
