高“效”运维已死，高质运维永生

本周 P0 级别运维事故不断，前有8月19日的网易云音乐[1]，后有8月21日的 WPS 云[2]。虽然具体原因众说纷纭尚未有个究竟，但很显然，矛头都对准了运维。

犹记得去年腾讯云广州电信机房的一把“火”，不仅烧掉了好几个管理者的职位和绩效[3]，还连带把客户那边管理者的饭碗也砸了[4]。

出故障的都是有着过亿用户的大厂云产品，从常理推断，大厂应该都有良好的 IT 运维管理体系、制度、流程和执行过程记录，但故障依然前赴后继，原因何在呢？

一种可能的原因，在于业界长期片面地强调运维效率，甚至喊出“降本增效”这种典型的马儿好马儿不吃草的口号来，这是彻头彻尾的方向性错误。

所以高“效”运维已死。唯高质运维，方可立于不败之地。

笔者虽然不是在什么大厂从事IT工作，但在职业生涯中远早于 DevOps、敏捷开发等理念成形之前，就已经在自己职能的范围内进行了充分的实践。

所以什么是高质运维？

除了人的技术能力这个因素不可忽视之外，还有一个关键因素：

运维文档的质量。

这也是这次关于网易云音乐故障的其中一个传言：按操作规程执行运维，结果却是把存储给干下线了。

如果这个传言最后确证为真，那么可想而知，这操作规程必定是没有及时按实际环境的变更同步更新。

笔者认为，运维文档的质量高低，应该至少基于：

1、可用性（或有效性）：文档内容真实有效，按文档进行的操作产生的结果符合文档本身的预期。

2、准确性（或及时性）：文档内容紧跟IT环境实际情况，在IT环境发生变更时及时进行变更，且保留历史档案。

3、完整性（或充分性）：文档内容足够完整，不仅包括对正常操作流程的详细描述，还包括对异常情况的提醒、警告和应急处置措施的详细描述。

而这三个属性能否达到具有高质量的水平，主要取决于：

1、管理者的技术水平高不高，懂不懂具体IT技术，能否判定相关文档的质量高低。

2、文档编写者的责任心强不强，能不能及时更新文档，使文档始终符合IT环境实际情况。

3、操作执行者的严谨度够不够，会不会浑浑噩噩地无脑执行规程描述的操作而无视任何。

如果企业片面地追求“降本增效”，总是想3个人能干5个人的活却只拿4个人的工资，就必然会导致以上三个决定性的因素转入下行趋势，正所谓：

“饥饱劳役，焉得其力”

这个时候，事故就必然在前面等着。

其他必不可少的技术因素，比如应该配置和生产环境始终一致的模拟测试环境，不可逆操作应先在模拟测试环境测试通过后再在生产环境操作，所有操作都应留有充足的日志记录等等，这些基本上就是 COBIT 和 ITIL 的内容，笔者认为已经不需要啰嗦了。

相关参考：

[1] 网易云音乐已经恢复

https://t.cj.sina.com.cn/articles/view/2022252207/78891eaf04001g9hs

[2] WPS回应“崩了”

https://finance.sina.com.cn/tob/2024-08-21/doc-inckkqse2677934.shtml

[3] 腾讯 329 故障（一级事故）

https://k.sina.com.cn/article_3172142827_bd130eeb0190120sh.html

[4] 唯品会公告329机房宕机故障处理结果

https://finance.sina.com.cn/wm/2023-06-05/doc-imywfxyf2156048.shtml

本站微信订阅号：

本页网址二维码：