撰稿 | 葉翔
葉翔，華數數字電視傳媒集團安全管理部總經理，國際信息系統審計師(CISA)，高級工程師，曾就職於中國聯通、中國電信及中國建設銀行總部。目前負責華數集團和下屬子公司浙江華數、華數傳媒、中廣有線、地鐵電視、華數雲的網絡安全、播出安全和安全生產工作。
葉翔 華數數字電視傳媒集團安全管理部總經理
華數集團是廣電行業的龍頭企業，科技實力和網絡安全水平均處於行業領導地位。集團下屬1家上市公司，70多家廣電網絡公司，擁有近3000萬數字電視用戶，全國1億以上的互聯網電視用戶和5600萬手機電視用戶。
正文
本人從業十多年，一直奮戰在運維一線，(臉紅一下) ，其實早就退到二線三線了，幹起了運維管理和運維監督的工作，但是經歷和處理的故障還是非常多的。10多年來，這些問題還是一直存在，總是要有人前赴後繼的來把坑填掉。有些故障諸如光纜雙向挖斷、停電後發電機起不來，或者有人惡意破壞等，雖然都是大故障，但不是輕易能預防的，該發生還是會發生的，這裡就不提了。
本文我總結了多年來我遇到過的9個具有代表性的問題，是可以吸取教訓從而避免的，本文就是將這些實際的經歷和讀者分享，希望達到兩個目的：
一是希望大家看了吸取教訓，讓少點人掉進坑，也算是積德行善了。
二是培養你的膽量，臨場不會慌亂，處變不驚，沉著冷靜，搞運維搞安全，幹久了，看多了，心會變大，全國性故障都經歷過的話，幾萬戶的小故障，眼皮都不抬一下。
1配錯+變更前沒有備份配置，小故障變大故障
手抖一抖，路由器交換機，配錯總是有的。先說一個我當年親手乾的，為了避免配錯，我們一般都把配置寫在文件裡，雙人檢查無誤，複製粘貼。但是配置裡有個全角空格，沒看出來，路由器無法執行這一行，導致後面好些配置都沒有執行成功，那真要命，然後就只能手工一步步配置，我打算刪一行配錯的ACL，結果整個ACL表都被刪了，導致一個省的互聯網出口斷掉，當時我臉色都變了，連忙喊旁邊的老員工，他電腦裡存了上個月的路由器配置，打開來對比一下，配回去，斷了十來分鐘。幸好那會兒也沒人監督，受影響的省打電話過來問咋回事，答覆說路由器故障，意外重啟了。我那會兒手都在抖，幸好有人幫我擺平，還幫我一起瞞報了。
再說一個十年以後的故障，我早就不用親自配路由器了，一個小弟在配路由器，還是老辦法，配置寫好，雙人審核，但是不知道哪個環節出了岔子，反正是配錯了，斷網，導致某銀行電子渠道全癱，配置自動同步，導致備用交換機配置也出錯，然後就抓狂了，找原始配置，找不到，沒有我運氣好，邊上沒有沉著應對的老員工，呼叫大牛們趕過來，北京那麼大，大牛們趕到1個小時出去了，七搞八搞，2小時才恢復業務。客戶電話都打爆了，瞞是瞞不住了，通報批評，操作員工降級(其實操作一線的員工本來就很低級，降成應屆生級別了)，他的主管也降級還加罰1萬，中心分管主任罰2萬。
小結一下，配錯在所難免，變更前一定要做好配置備份，備下來放在硬盤裡，重要配置段甚至打印出來，心理素質要好，真的出事趕緊恢復就好了。不過很多人那會兒手都會抖的啦，就看你邊上有沒有沉著冷靜的同事了。
2互為備份造成連鎖反應，導致某業務全國癱瘓
我們曾經把某個全國性業務分成七個大區，北京上海廣州武漢瀋陽西安成都，哪個大區的設備壞了，那麼它的流量就會被指向相鄰的兩個大區，這樣的冗餘設計很完美吧？
然後有一天，北京大區設備壞了，流量去了瀋陽和西安，但是調度系統有一點點問題，這個可能當初就沒有設計好，或者因為後來形勢發生了變化，不管怎麼說，30%流量去了西安，70%去了瀋陽，然後瀋陽大區的網關就受不了了，經過一段時間苦撐，被搞癱了… 然後70%的北京流量和全部的瀋陽流量去了上海，上海網關分分鐘就掛了，這些流量又去了廣州和武漢，很快，全國都玩完了。
3NTP掉線，造成全網計費出錯，長時間難以發現
時鐘同步服務器這個東西，通常不受人重視，有些公司甚至沒有這個設備。但是如果你的業務需要計費，或者經常需要查找日誌來排除故障，那就必須要時鐘同步。
這種故障其實挺隱蔽的，因為所有設備都有自己的時鐘，NTP掉線後，可能要一個月，全網設備的時間就不太不同了，這時候你才發現原來NTP死機一個月了，因為時鐘不同步產生的計費和日誌問題，已經是不可逆的了。
4從帶內網管遠程admin down唯一上聯端口，飛過去恢復設備
這種情況其實還蠻常見的，設備在當地，但歸集團總部管理，當地沒有技術能力維護，最多就是斷電重啟一下。有一次我們把遠程管理設備上唯一的上聯網口admin down了，完蛋，由於是帶內網管，端口down了，再也連不上這個設備了，好吧，趕緊買飛機票，派人飛過去喚醒這個設備… 後來我們建立了帶外網管，這樣萬一設備死機或者什麼異常情況，也可以從帶外登上去看一眼了。
5客戶端設備不間斷重試就像鬼壓身，導致局端設備趴了起不來
如果你是為小路由器、機頂盒、攝像頭這種設備服務的，現在的物聯網中心也有類似問題，這些設備的設計人員都很不專業的，認證不通過的話，重試間隔很短的，簡直就是ddos攻擊，只要上面的服務器有問題，下面的客戶端設備就像一群小鬼在那嚷嚷，拼命來連服務器，服務器的併發是沒問題的，但是新建連接能力根本達不到這個量，很快就會被海量的新建連接請求壓癱，而且往往是一重啟就癱，業務長時間無法恢復，運維人員束手無策。
我們在實踐鍾摸索出的解決方法是：如果前面有負載均衡，就要控制新建連接請求的數量，用負載均衡擋一擋；如果沒有負載均衡，只能在防火牆上動腦筋，寫ACL，一路一路的permit 放進來，一片一片的地區恢復。這個說到底是個設計問題，根本的解決方案就是客戶端設備要放緩重試的頻率，開始可以高頻重試，幾次之後要逐漸降低頻率，改為5分鐘一次重試。服務側也要用重啟恢復機制，能夠應對高強度的新建連接。
6負載均衡配置失誤，把死機的服務器當成了空閒服務器
這也是個常見故障，應用負載均衡的配置絕對是一門學問，也極易引起全系統癱瘓。經常是1臺服務器的應用程序死了，負載均衡覺得死機這個負載最低，就拼命給它送，所有新建都送給它，結果所有新上來的用戶都玩完。
7以安全的名義盲目升級，不調研不公告就改變現網配置
這種例子很多，我說一個2G和3G那會兒的上網卡的事，是要撥號的，撥號的認證協議一般有PAP或者CHAP可以選，前者明文，後者加密，安全性好，不易被竊聽。某一天管理員拍腦袋，沒有發佈任何通知，沒有做任何調研，決定提升安全級別，在局端設備強制使用CHAP，把PAP禁掉了。然後，投訴電話直接打爆，還都是大客戶，西門子，GE，各大銀行，都追殺過來了，第二天就改回去了。那會兒運維管理比較亂，沒處理那個管理員，要擱現在得殺了祭天。
當時，其實我也不理解，為什麼這麼多設備必須用PAP，只是我有一種樸素的運維理念，就是改現網任何參數，都必須調研，發佈公告，把未知風險降到最低。後來我去了銀行才知道，由於銀行往往需要轉發這個密碼到統一認證系統，只有PAP的明文才能轉發，CHAP這種挑戰應答機制的密碼是沒法轉發的，而且這種密碼洩漏並沒有多大意義，設備沒丟單一個密碼還是過不了認證，設備丟了的話，這種密碼都是寫入在設備上的，壞人根本不需要知道密碼是啥。
另外一個案例是給互聯網散戶加防火牆，怎麼說呢，這還是個參數變更問題，變更前完全沒有考慮到客戶需求，沒有調研，沒有通告就在現網開幹。和前面那個故障異曲同工，實際上也是同一夥人乾的。這幫人吃飽撐著想要提升網絡安全，但水平有限，搞出好多破事來。眾所周知，我們很多用戶會用“花生殼”開個私服啥的，甚至很多物聯網設備也都是有被訪問的需求的，突然放個牆不允許由外向內的連接，又是一片投訴。
8幾十個組件緊耦合多瓶頸的系統，遲早完蛋
這種系統其實我很少看到，但是最近看到一個，歎為觀止。一個系統居然由70多種組件組成，8個廠商開發的，緊耦合(任何一個組件出問題，影響全系統，而不是部分功能缺失)，多瓶頸其實是緊耦合的副產品，由於任何一個組件都不能出問題，那一旦需要擴容，就需要大家一起擴，只擴了其中一些組件，另外組件就成了瓶頸。每次擴容都要進行大量的計算，還很難保證沒有瓶頸。
這種系統完全沒有可維護性，或者說需要大量的人來運維，需要極其牛B的監控系統才能完全把這個系統的運行狀態監控起來，除非這套系統能帶來極大的經濟價值，否則，咱們儘量選購結構簡單一點的系統，易維護絕對是做項目需要重點考慮的指標。
9要保持知識常新，能識別新的故障和新的攻擊手段
先說個例子，2005年那會兒，天津有個IDC機房被DDOS 攻擊，我們沒有任何的檢測手段，更沒有流量清洗設備，根本就不認識這是啥，只知道流量突增，造成端口滿了，把思科和朗訊工程師都叫來，他們也不認識，說是不是設備壞了。抓包分析，發現就是有很多的包發過來，你知道廣域網路由器抓包有多麻煩嗎？折騰了好久，找到目標地址，指向黑洞路由，總算搞定。現在這種攻擊，值班工程師都一眼能認出來，監測直接就能告警，鼠標點點就解決了，可是10多年前，大家就是沒手段。
如果你能知識常新，多閱讀國外的論壇或者期刊，就好比從未來回來，這些攻擊都不是事。如果你知識陳舊，以10年前的手段解決現在的故障，那必然痛苦不堪。
最後，以運維監督的名義給運維人員幾條意見：
1.千萬不要提前割接，萬一割接失敗，追查起來，按規定操作多大故障都可以商榷，不按規定操作，就算不是因為提割接導致故障，也要處分你。
2.保存好對你有利的日誌和截屏，以證明你沒有違規操作，避免設備重啟或日誌量太大覆蓋，但是你不要去刪除對你不利的日誌，蓄意刪日誌是犯罪行為，查到了開除。
3.不要去運維第8種設備，你會背鍋的，或者因此失業。
4.老師傅要帶好菜鳥，菜鳥會了你就輕鬆了，別藏著掖著，沒必要，早就不是徒弟學會餓死師傅的年代了。
5.遇到故障不要緊張，不要緊張，咱又不是故意的，怕啥，大不了找工作去嘛，沉著冷靜的搞定它。
閱讀更多 安在信息安全新媒體 的文章
