blless
2022-07-15 14:53:27 +08:00
本老运维出来说一点点。
核心就是 B 站对运维投入应该不够重视。几个关键字，2021 年，自建机房，OpenResty+注册中心 ，线上网络和办公网络互通，关键业务 SLB 居然还要临时新建，业务回滚极不完善。
不过也是事后 BB 罢了，线上原因多种多样。运维做多了，个人觉得核心在于不是排查出问题或者解决问题，而是快速恢复，降低影响。所以一个老运维需要很清楚知道，一些改动可能影响的范围。
这里事故的关键点其实在于，利用 OpenResty 的灵活性，接入了一个可以动态获取网关配置的注册中心。也就是说 LB 的配置变更的核心在于注册中心配置下发的配置。(我以前公司任何可能改动到网关的配置审核都是三层审核)。这里我猜很有可能 B 站注册中心下发配置权限在另一个部门，而且可能绕开了线上运维人员的审核。然后整个事故报告里面没有提到一句下发错误配置的部门，整个事故报告围绕自身问题...似乎看到了一个已经被强势业务部门 PUA 成性的背锅老运维了。所以如何把关键变更权掌控在运维手上，或者至少有效通知到运维人员，才是运维的关键。但是这一点往往因为业务线太长，需要公司更高层级的支持，所以往往一个公司的运维好坏是跟公司整体相关的。强势业务部门就会以各种理由抵制这些手段，老板也会站在业务部门角度。没有任何办法，只能等血淋淋的线上事故发生之后，趁机搞一点运维建设。
另外好多人一说事故就提高可用，问题是高可用上限是没有边界的。公司不注重运维体系建设，盲目砸钱搞高可用，本来人就不多，还要加工作量，我只能说下次事故说不定指日可待