流水的运维，铁打的锅
在 6 月 5 号，唯品会发布了 23 年 3 月 29 号的故障报告，因为南沙 IDC 冷冻系统故障导致唯品会线上商城停止服务，造成了数以亿计的损失（作为小运维的我，瑟瑟发抖）。
对于唯品会来说，线上商城是其核心业务入口，故障不可避免，但是故障如此之长却不能容忍，为什么会造成这种事情发生呢？在我们这种小运维的眼里，这种事故不应该发生在这种量级的公司中，我们都是在模仿、学习他们的 PPT 中寻找运维之路。
但是，PPT 的高大上，无法压住故障不发生，这是为什么呢？
我个人斗胆说几种猜测：
- PPT≠ 现实
- 故障演练=走过场？
- 多活，说说而已？
- 巧妇难为无米之炊
PPT≠ 现实
现在国内各种技术大会，然后邀请一些知名企业的 CTO、技术负责人等到场演讲，从演讲来看，每家公司都很强（至少 PPT 上是这样展示的），每次我听完都会豁然开朗，大受裨益，打心底佩服这些公司，佩服他们超强的思维、超高的能力以及超酷的团队。
但是，PPT 毕竟只是一个辅助工具，它不能代替现状。
漂亮的 PPT 只是给想看的人看的，不漂亮的事情是要独自去承受的。
之前有看多唯品会在 GOPS 上的分享，PPT 上呈现的确实很棒，如果拿着这个向上汇报，老板也会觉得我们公司的技术真厉害，做的真好，给了老板一切都很好的假象。
出了问题，不办你办谁？
从自己嘴里吹出去的牛逼，也会回到自己嘴里。
故障演练=走过场？
在《SRE：Google 运维解密》这本书中，故障演练占了很大的篇幅。通过故障演练，可以提高系统的可靠性和容错性，可以让团队更好的了解系统的架构和工作原理，可以更好的理解各模块的相互影响，可以更快的发现系统架构中的漏洞和故障。
可以说，故障演练是整个稳定性保障的核心环节，因为它可以帮助团队最大限度的减少实际故障的同时，也能更高效的应对可能出现的问题。
但是，实际中是这样的么？
在实际进行故障演练的时候，要预定故障点，要整理输出具体的应对措施，要指定全面的计划，要准确描述每个人的工作职责和任务。
光这些前置工作就需要耗费很大的人力物力，很多团队、很多人就会精简步骤、精简措施，抱着做了就行的心态看待故障演练，抱着侥幸心态看待故障本身，把希望寄托在别人不出问题的情况下。
比如把希望寄托于公有云，公有云不出问题，整个系统就是稳定的，但是公有云 ≠ 完全可靠，谷歌云、阿里云、腾讯云等都发生过重大事故，然而买单的还是用户自己。
所以，对于运维团队或者 SRE 团队，需要认真对待故障演练，不仅要做好演练的前置准备工作，在演练中也要密切关注计划，发现问题及时采取措施并进行修正。
不要让演练成为走过场，不要让演练成为 KPI，不然你就是下一个优化对象。
多活，说说而已？
3 月 29 日唯品会的问题，可以从侧面反映：多活，也许真是说说而已。
随着业务的发展，系统架构会不断演变，因为我们对高可用的要求越来越高。
例如，从单机架构在同一机房升级到主备架构，再升级到同城多机房架构，最终到达两地三中心架构等级。
如果唯品会做了同城多机房，就算最简单的同城主备，也不至于宕机 12 个小时。
更别说如果做了同城双活。
但是，我只是站在上帝视角猜测。也许他们也做了多活，只是假多活罢了。
巧妇难为无米之炊
上面总总，到头来都会走到财力、人力、物力上来，就拿多活来说，搞一个同城灾备，投入的成本就不是 dubbo 那么简单，每当 SRE 负责人向上汇报申请资金的时候，如果上面的领导不予支持（钱，钱没挣，还要花这么多），什么都是白搭。
领导要压成本，下面要钱做事，成本不足导致入不敷出，也就会出现 PPT 漂亮，实际很烂的局面。
纵有一腔抱负，乃无用武之地。
出了问题，还要用你祭天。
最后
上面所说纯属虚构，如有雷同，请点赞~
在很多公司，运维的话语权很低，低到离谱，这就导致运维在做事或者推进事情的时候寸步难行。
但是，一旦出现问题，运维却是被第一个推出来的，所以“背锅侠”一直被扣在运维头上。
那作为运维应该怎么做呢？
- 走出去——不要局限于运维团队内部，要走出去，让业务部门知道运维的价值。
- 走进去——运维知识体系复杂多变，要走进知识内部，深度理解背后的原理，用你的专业来为团队服务。
- 走上去——要提升运维影响力，通过专业的能力和积极的态度争取更多的信任和支持，改变现状，提升地位。
最后，说归说，闹归闹，别拿生产开玩笑。
相关文章