再流弊的技术，也抵不住一次事故：兼谈技术管理 | 高效运维最佳实践07

再流弊的技术，也抵不住一次事故：兼谈技术管理 | 高效运维最佳实践07

引言

今年已经连续出现了几起大的故障。究其根本原因，都是不应该的人为事故。本文从这些大故障说起，主要谈及运维管理相关的一些话题。本文的主要内容包括：

不太平的互联网为什么这么多人为事故？

为什么运维更容易发生事故？规范这么全，为什么还有事故？都自动化了，为什么还有事故？灰度这么好，为什么还有事故？

怎么规避人为事故？

选择合适的人培养安全意识让专业变成一种习惯

好吧，我们正式开始。

不太平的互联网

近期获悉的一些大故障，不仅来自于携程、阿里云，还有一些影响范围不是很大，但同样非常不应该的人为事故。

901阿里云故障

阿里云称因云盾升级触发bug，导致部分服务器的少量文件被系统误隔离。其已第一时间启动系统回滚，被误隔离的文件正在陆续恢复。

部分阿里云用户表示很受伤。

很多微信群朋友纷纷表示也已中招。从波及面及技术层分析来看（详见下文），应该是人为事故为主。

528携程故障

5月底的这次携程故障，在17小时后才恢复业务。官方更是直言为“员工错误操作导致”。

其他“令人发指”的故障

包括但不限于：

某公司技术人员大白天的给公司计费数据库服务器更换电源…某银行总行大型机，关键线路接反了…某银行关键交易系统，更新版本时SQL 脚本update 语句没写where 条件，然后所有网点信息都被重置…

根据笔者十多年的互联网从业经验，重大故障，究其根源，至少60%都是低级人为事故。真正因为复杂系统问题导致的严重故障，非常之少。

为什么这么多人为事故？

互联网发展至今，还没脱离草莽时代。技术上，从最开始的小米加步枪，到现在逐渐自助化、半自动化，或者利用开源产品修修补补形成自己的系统。

如果说技术上的发展尚可陈词、有些亮点，那么对人的管理和重视程度，就更加落后得太多。

可以佐证的是，微信技术社区里头，讨论技术热点的文章非常之受追捧；但技术管理类的文章，往往非常被冷落。

究其原因，还是在于广大互联网技术人员的“手艺人情结”。从我所在的运维行业来看，尤为突出：

大家都是从Linux、Shell开始学起，非常享受那种敲几行命令一回车，自动部署多台服务器的快感及成就感。并误以为这就是自己的全部。

技术人员梦想着身怀“绝技”，对Linux系统的某些压箱底活儿或对某项编程技术的独门秘籍，自此笑傲人生，并“不为五斗米折腰”，如认为公司或领导有让自己不爽的地方，即刻”潇洒”遁去。

虽然，这往往验证了一句话“最有才能的人，往往是最无效的”。

技术人员不愿受束缚，更多非常相信自己，觉得我的技术杠杠的。为什么需要别人来检查我的工作？我就是完美。

技术负责人往往工作年龄更长，可能经历过更野蛮生长的时代。

而且很多人潜意识地认为，技术可以解决一切问题，但问题是：

当系统越来越大、自动化和智能化程度越来越高，开飞机的人，水平跟不上，怎么办？

机器再强大，也需要人来操作。你说是不？

为什么运维更容易发生事故？

其实相比运维，开发人员还是幸福的。开发更多关注功能、怎么快速交付项目需求即可。程序有Bug？还好啦，后面还有测试在兜底。甚至，Bug多些也无妨，还能算做测试的绩效。

在这个时候，开发是操作人，测试实际上是检查人，两个岗位互补：

这就是为什么飞机驾驶舱会有两名飞行员的原因，即使副驾驶员看上去无所事事的样子。但，关键时候可是能救命的。

运维就没这么幸运了。运维往往苦逼地冲在第一线，手上掌握着的都是生产环境。而且一般情况下，文责自负，基本上没有谁来检查运维的工作。也少有人意识到这是个严重问题。

规范这么全，为什么还有事故？

规范是用来“制约”人的，技术是用来“简化”人的。But，系统再智能也得人来操作，不是么？

对于人本身，我们究竟做了哪些事情呢？这是值得扪心自问的。

规范再多，人也可以束之高阁。所以管理者一定不能觉得规范制度完善了，就已万事大吉。恰恰相反，放松警惕，放松对人的管理，放松贯彻执行，更大的悲剧可能将要来临。

规范制度不是技术管理的全部，规范可以理解为最低标准，用来杜绝不专业的人去会犯毁灭性错误。

规范更多是“术”，而不是“道”。虽然规范想体现“道”，但毕竟，“指向月亮的手不是月亮”。

重视选人、重视培养人的专业意识，才是王道。

都自动化了，为什么还有事故？

近期这几起严重故障定义为人为事故，我想应该没有人多少人反对。

自动化可以减少人员例行的、重复的登录服务器的操作，从而减少人为事故的发生。那么这又是闹哪样呢？

其实刚好相反，人为事故因为运维自动化平台的出现，其恶劣影响更是被无限放大。

之前小米加步枪的时代，大家都登录服务器进行操作，千百台服务器各自为政，想一次性搞瘫整个系统，还真的很难。

运维自动化平台的出现，很好的“解决”了这个问题。毕竟，平台再智能，也需要人来操作。而过分依赖平台，反而削弱对人员专业性的培养。

人的关系没协调好，问题的根源就没解决。压死我们的往往是最后一根稻草。

灰度这么好，为什么还有事故？

有人会说了，我们公司灰度发布非常完善，理应能控制各种事故发生。即使有，影响范围也应该非常之小。

这其实有两个问题。一则有了灰度发布，就可以忽略测试环境了么？如果模拟环境并不足够仿真，或没有在模拟环境充分测试过、直接在生产系统上进行灰度，这个也是非常值得商榷的：

一个朋友说，电信内部做运营，动用了九个机柜100%模拟生产环境，专门做测试。包括网络设备版本，也都充分的稳定性测试。

可能根本原因在于，互联网行业草根出身，长期野蛮生长，从乱到治，习惯试错和快速迭代，因此容易乱象丛生。而电信、银行这些行业，这些从一开始就视安全为命脉，循规蹈矩，谨小慎微。

还有，重大事故发生时，灰度范围内的用户，对他们而言，总归是无妄之灾。凭什么他们就应该蒙受此等“待遇”呢？他们何罪之有？

他们就理应是”小白鼠“么？

二则灰度策略，是否合适？版本发布平台往往汇聚众人智慧结晶设计架构而成，但可能没有定义具体的灰度策略（这不属于技术范围，而是业务范围）。

也就是说，一次更新100台服务器，还是一次更新10000台服务器，是可以被操作人员手工指定的。

最怕的就是，工具做得很流弊，使用者综合能力很一般。

使用者如果图个省事，所谓的灰度发布，一次性的更新成千上万台服务器，那么工具就不仅没有产生效率，反而变成了帮凶（就像刀磨快了，反而变成杀人利器）。

究其本质而言，灰度其实就是一种制度和意识。是希望通过灰度，唤醒人的安全意识。如果操作人员，不能觉悟到这一点，就是死路一条。

怎么规避人为事故？

在生产系统上更新版本（特别是如果没有同等模拟环境的话），就像在高速公路上换轮胎，各中危险，不一而足，特别是服务了成千上万台物理机的大系统而言。

人为事故的出现往往不是个例，是长期积累的结果，单个人为事故往往也只是呈现了问题的冰山一角而已。人为事故，是必然而非偶然。

想要有机会彻底的解决人为事故，建议从如下几方面着手。

选择合适的人

选好人，往往能做到事半功倍，反之亦然。

管理学的重要原则之一是发挥人的优势，尽量不要尝试着去改变一个人。特别是对于一线生产系统的操作岗位（其实非常重要）而言，找到合适的人，比什么都重要。

运维的首要工作职责是稳定性。因此需要找性格老实、谨小慎微的人来做更加合适。性格毛糙，甚至容易“幻听”的人，明显不合适，毕竟，“常在河边走，哪能不湿鞋”。

为什么非得要让二把刀来开飞机呢？

德才兼备是正途。这里所谓的才就是技术，德是人的德行、行为和意识。道和德是相通的，运维人员的意识增强了，综合能力提高了，规范了，是可以避免一些问题的。

这里顺序很重要，直接从规范切入，往往是失败的开始。需要首先提高意识水平，然后顺势而为。而不是生猛切入。

培养安全意识

“对运维操作要有敬畏之心”。这句话应该作为警世恒言，挂在每一个运维人员的心头。

脑子里牢记安全意识，比死记硬背规章制度更重要（当然，首先需要有规章制度）。

运维制度及规范体系的最大意义在于，控制死角可能的影响。每一次事故，都是一个盲点、一个死角又被发现的过程。运维最难之处在于，不可能做到没死角。

规范制度肯定落后于问题。为了规范而规范不是目的，根据诉求控制风险的规范，才是有意义的。

诚然，“安全没有捷径，该踩的雷都会踩到。”但这不是借口，不是免死金牌。同理，用技术来保障技术，也是不可取的。

让每一个运维人员脑海里都紧绷着安全这根弦，比什么都重要。毕竟，死角永远都存在。只能用未知来解决已知，而不是反之。

让专业变成一种习惯

先哲亚里士多德曾说：“人的行为总是一再重复。因此，卓越不是单一的举动，而是习惯。”

单次的刺激无法形成习惯，单次过猛的刺激，只会形成恐惧，变得畏手畏脚。

专业是否变成一种习惯，往往更多取决于管理者。因为管理者更能分清楚，哪些是重要紧急，哪些是不重要不紧急。专业首先应该是管理者的一种习惯，然后时时传递不松懈。

管理者应该选对人，然后对于有重大操作权限的人员，经常性的温习各类故障、事故，采取各种办法，让员工时刻具备安全意识，真正认识到责任重大。

“警钟常鸣”，各种震撼人心的模拟演练、演习和培训，也必不可少。

需要树立检查人机制，建立一个好的团队工作习惯，“结对运维”：

没有检查岗，单枪匹马做事情，平时还好，在情况复杂时，个人情绪波动和精神压力都可能非常大，容易错误决策，或使出“昏招”。

另外补充说下：对于公有云而言，如果参与云保险，这对于终端用户而言也是幸事。毕竟云厂商的赔偿，即使100倍又能多少呢？业务的损失，如果由第三方保险公司来做些承当，应该更好。

路漫漫其修远兮，吾将上下而求索。谨以此句，和天下运维同仁共勉。一起加油。

说明

本文在编写过程中，得到了高效运维微信群诸多朋友的启发，甚至部分文字就来源于他们的思想结晶。包括但不限于：周霖，尹国定，何博，栗蔚，王津银，智锦，文君和吕健等。谢谢大家。

作者介绍

萧田国高效运维社区发起人，开放运维联盟联合主席，复旦大学客座讲师，互联网专栏作者《高效运维最佳实践》。

运维如何不再苦逼？

来GOPS2016全球运维大会·深圳站看看，您就了然于心了。超豪华阵容！四大运维体系在引爆上海之后，携手20多位顶级运维专家，和您相聚深圳，共同期待和规划运维之春。

豪华阵容首度集体亮相 | GOPS2016全球运维大会·深圳站

想要了解更多，请长按并扫描以下图片，了解大会详细情况，内附报名链接。

http://gops2016-shenzhen-tcxtg.eventdove.com