百家 | 华数叶翔：那些年经历过的大故障
撰稿 | 叶翔
编辑 | 图图
叶翔 华数数字电视传媒集团安全管理部总经理
华数集团是广电行业的龙头企业，科技实力和网络安全水平均处于行业领导地位。集团下属1家上市公司，70多家广电网络公司，拥有近3000万数字电视用户，全国1亿以上的互联网电视用户和5600万手机电视用户。
本人从业十多年，一直奋战在运维一线，(脸红一下) ，其实早就退到二线三线了，干起了运维管理和运维监督的工作，但是经历和处理的故障还是非常多的。10多年来，这些问题还是一直存在，总是要有人前赴后继的来把坑填掉。有些故障诸如光缆双向挖断、停电后发电机起不来，或者有人恶意破坏等，虽然都是大故障，但不是轻易能预防的，该发生还是会发生的，这里就不提了。
本文我总结了多年来我遇到过的9个具有代表性的问题，是可以吸取教训从而避免的，本文就是将这些实际的经历和读者分享，希望达到两个目的：
一是希望大家看了吸取教训，让少点人掉进坑，也算是积德行善了。
二是培养你的胆量，临场不会慌乱，处变不惊，沉着冷静，搞运维搞安全，干久了，看多了，心会变大，全国性故障都经历过的话，几万户的小故障，眼皮都不抬一下。
手抖一抖，路由器交换机，配错总是有的。先说一个我当年亲手干的，为了避免配错，我们一般都把配置写在文件里，双人检查无误，复制粘贴。但是配置里有个全角空格，没看出来，路由器无法执行这一行，导致后面好些配置都没有执行成功，那真要命，然后就只能手工一步步配置，我打算删一行配错的ACL，结果整个ACL表都被删了，导致一个省的互联网出口断掉，当时我脸色都变了，连忙喊旁边的老员工，他电脑里存了上个月的路由器配置，打开来对比一下，配回去，断了十来分钟。幸好那会儿也没人监督，受影响的省打电话过来问咋回事，答复说路由器故障，意外重启了。我那会儿手都在抖，幸好有人帮我摆平，还帮我一起瞒报了。
再说一个十年以后的故障，我早就不用亲自配路由器了，一个小弟在配路由器，还是老办法，配置写好，双人审核，但是不知道哪个环节出了岔子，反正是配错了，断网，导致某银行电子渠道全瘫，配置自动同步，导致备用交换机配置也出错，然后就抓狂了，找原始配置，找不到，没有我运气好，边上没有沉着应对的老员工，呼叫大牛们赶过来，北京那么大，大牛们赶到1个小时出去了，七搞八搞，2小时才恢复业务。客户电话都打爆了，瞒是瞒不住了，通报批评，操作员工降级(其实操作一线的员工本来就很低级，降成应届生级别了)，他的主管也降级还加罚1万，中心分管主任罚2万。
小结一下，配错在所难免，变更前一定要做好配置备份，备下来放在硬盘里，重要配置段甚至打印出来，心理素质要好，真的出事赶紧恢复就好了。不过很多人那会儿手都会抖的啦，就看你边上有没有沉着冷静的同事了。
我们曾经把某个全国性业务分成七个大区，北京上海广州武汉沈阳西安成都，哪个大区的设备坏了，那么它的流量就会被指向相邻的两个大区，这样的冗余设计很完美吧？
然后有一天，北京大区设备坏了，流量去了沈阳和西安，但是调度系统有一点点问题，这个可能当初就没有设计好，或者因为后来形势发生了变化，不管怎么说，30%流量去了西安，70%去了沈阳，然后沈阳大区的网关就受不了了，经过一段时间苦撑，被搞瘫了… 然后70%的北京流量和全部的沈阳流量去了上海，上海网关分分钟就挂了，这些流量又去了广州和武汉，很快，全国都玩完了。
时钟同步服务器这个东西，通常不受人重视，有些公司甚至没有这个设备。但是如果你的业务需要计费，或者经常需要查找日志来排除故障，那就必须要时钟同步。
这种故障其实挺隐蔽的，因为所有设备都有自己的时钟，NTP掉线后，可能要一个月，全网设备的时间就不太不同了，这时候你才发现原来NTP死机一个月了，因为时钟不同步产生的计费和日志问题，已经是不可逆的了。
这种情况其实还蛮常见的，设备在当地，但归集团总部管理，当地没有技术能力维护，最多就是断电重启一下。有一次我们把远程管理设备上唯一的上联网口admin down了，完蛋，由于是带内网管，端口down了，再也连不上这个设备了，好吧，赶紧买飞机票，派人飞过去唤醒这个设备… 后来我们建立了带外网管，这样万一设备死机或者什么异常情况，也可以从带外登上去看一眼了。
如果你是为小路由器、机顶盒、摄像头这种设备服务的，现在的物联网中心也有类似问题，这些设备的设计人员都很不专业的，认证不通过的话，重试间隔很短的，简直就是ddos攻击，只要上面的服务器有问题，下面的客户端设备就像一群小鬼在那嚷嚷，拼命来连服务器，服务器的并发是没问题的，但是新建连接能力根本达不到这个量，很快就会被海量的新建连接请求压瘫，而且往往是一重启就瘫，业务长时间无法恢复，运维人员束手无策。
我们在实践钟摸索出的解决方法是：如果前面有负载均衡，就要控制新建连接请求的数量，用负载均衡挡一挡；如果没有负载均衡，只能在防火墙上动脑筋，写ACL，一路一路的permit 放进来，一片一片的地区恢复。这个说到底是个设计问题，根本的解决方案就是客户端设备要放缓重试的频率，开始可以高频重试，几次之后要逐渐降低频率，改为5分钟一次重试。服务侧也要用重启恢复机制，能够应对高强度的新建连接。
这也是个常见故障，应用负载均衡的配置绝对是一门学问，也极易引起全系统瘫痪。经常是1台服务器的应用程序死了，负载均衡觉得死机这个负载最低，就拼命给它送，所有新建都送给它，结果所有新上来的用户都玩完。
这种例子很多，我说一个2G和3G那会儿的上网卡的事，是要拨号的，拨号的认证协议一般有PAP或者CHAP可以选，前者明文，后者加密，安全性好，不易被窃听。某一天管理员拍脑袋，没有发布任何通知，没有做任何调研，决定提升安全级别，在局端设备强制使用CHAP，把PAP禁掉了。然后，投诉电话直接打爆，还都是大客户，西门子，GE，各大银行，都追杀过来了，第二天就改回去了。那会儿运维管理比较乱，没处理那个管理员，要搁现在得杀了祭天。
当时，其实我也不理解，为什么这么多设备必须用PAP，只是我有一种朴素的运维理念，就是改现网任何参数，都必须调研，发布公告，把未知风险降到最低。后来我去了银行才知道，由于银行往往需要转发这个密码到统一认证系统，只有PAP的明文才能转发，CHAP这种挑战应答机制的密码是没法转发的，而且这种密码泄漏并没有多大意义，设备没丢单一个密码还是过不了认证，设备丢了的话，这种密码都是写入在设备上的，坏人根本不需要知道密码是啥。
另外一个案例是给互联网散户加防火墙，怎么说呢，这还是个参数变更问题，变更前完全没有考虑到客户需求，没有调研，没有通告就在现网开干。和前面那个故障异曲同工，实际上也是同一伙人干的。这帮人吃饱撑着想要提升网络安全，但水平有限，搞出好多破事来。众所周知，我们很多用户会用“花生壳”开个私服啥的，甚至很多物联网设备也都是有被访问的需求的，突然放个墙不允许由外向内的连接，又是一片投诉。
这种系统其实我很少看到，但是最近看到一个，叹为观止。一个系统居然由70多种组件组成，8个厂商开发的，紧耦合(任何一个组件出问题，影响全系统，而不是部分功能缺失)，多瓶颈其实是紧耦合的副产品，由于任何一个组件都不能出问题，那一旦需要扩容，就需要大家一起扩，只扩了其中一些组件，另外组件就成了瓶颈。每次扩容都要进行大量的计算，还很难保证没有瓶颈。
这种系统完全没有可维护性，或者说需要大量的人来运维，需要极其牛B的监控系统才能完全把这个系统的运行状态监控起来，除非这套系统能带来极大的经济价值，否则，咱们尽量选购结构简单一点的系统，易维护绝对是做项目需要重点考虑的指标。
先说个例子，2005年那会儿，天津有个IDC机房被DDOS 攻击，我们没有任何的检测手段，更没有流量清洗设备，根本就不认识这是啥，只知道流量突增，造成端口满了，把思科和朗讯工程师都叫来，他们也不认识，说是不是设备坏了。抓包分析，发现就是有很多的包发过来，你知道广域网路由器抓包有多麻烦吗？折腾了好久，找到目标地址，指向黑洞路由，总算搞定。现在这种攻击，值班工程师都一眼能认出来，监测直接就能告警，鼠标点点就解决了，可是10多年前，大家就是没手段。
如果你能知识常新，多阅读国外的论坛或者期刊，就好比从未来回来，这些攻击都不是事。如果你知识陈旧，以10年前的手段解决现在的故障，那必然痛苦不堪。
最后，以运维监督的名义给运维人员几条意见：
1.千万不要提前割接，万一割接失败，追查起来，按规定操作多大故障都可以商榷，不按规定操作，就算不是因为提割接导致故障，也要处分你。
2.保存好对你有利的日志和截屏，以证明你没有违规操作，避免设备重启或日志量太大覆盖，但是你不要去删除对你不利的日志，蓄意删日志是犯罪行为，查到了开除。
3.不要去运维第8种设备，你会背锅的，或者因此失业。
4.老师傅要带好菜鸟，菜鸟会了你就轻松了，别藏着掖着，没必要，早就不是徒弟学会饿死师傅的年代了。
5.遇到故障不要紧张，不要紧张，咱又不是故意的，怕啥，大不了找工作去嘛，沉着冷静的搞定它。
「推荐阅读」
人物 ∣ 热点∣ 互动 ∣ 传播
投稿及商务合作请在后台回复关键字即可