由中行IBM大型機當機談銀行系統運維

12月15日中行IBM大型機當機，系統沒有第一時間切換到熱備或者異地容災上，直接影響中行的信用卡支付相關業務，直到4小時之後才恢復服務。由於銀行業務的特殊性，對於系統的可用性要求極高，就此事件，我們採訪了興業銀行系統分析師周偉然、支付寶應用運維架構師陸惟凱（花名：近南），請他們談一下對於銀行系統運維的一些看法。

InfoQ：作為一名銀行金融行業的IT技術專家，您認為本次中行IBM大型機當機的體現出哪些問題和教訓？

陸惟凱：主要的問題是災備或大型故障的演練與決策，對於硬體或者機房故障的大型故障，需要有經過驗證演練的切換方案來保證切換風險可控。對於故障決策來說是否啟動災備切換是個艱難的決定，不過確實也要能夠下決策去切換。其實一切的根源還是在切換方案是否足夠可靠、是否經過演練。只要切換風險可控，切換得決策其實不會太糾結。

周偉然：對於本次中行事件，具體原因不瞭解得情況下不好直接評論。但所謂相關金融系統的運維是一個複雜的系統功能，不能單純的從main frame的穩定性一概而論。裝置執行的穩定性也只是整體系統穩定性的很小部分。除了環境保障中包含的網路環境、硬體資源、儲存裝置、作業系統資料庫等基礎軟體環境以外，應用執行、系統間互操作等事件都可能產生重大影響。而風險是無法完全避免的，這才顯示的出災難備份和應急預案的重要性，最大程度降低風險暴露後的影響是驗證應急體系有效性的重要指標。

InfoQ：是否在您所在的組織中使用？對於類似事故，ITIL流程的處理應該是什麼樣子？

陸惟凱：使用，不過不是標準的ITIL流程。我們有一個應急響應的Team在處理相關決策以及應急事務。對於特別重大的問題會在應急響應TEAM內進行決策。

周偉然：我行使用ITIL。無論是ITIL還是各級監管機構，乃是內部風險機構，對於銀行應急處理的流程均有嚴格的要求，基本上是系統分類，根據不同等級重要性提出不同的風險要求。對於重要系統，需要建設完備的災備體系，建立完善的應急預案 並且需要確保災備和應急預案的有效性。對此，監管和內部審計透過演練進行確認。 所謂的演練非模擬實際環境的演練，而是在實際的生產環境進行的模擬災難，各機構對演練的頻度和內容均有嚴格的要求，並且重大演練時，監管官員將進行現場檢查 透過各銀行每年發出的停業公告可以看到這些演練資訊。

InfoQ：在你們的系統中，“桌面模擬演練”和“Call Tree演練”是如何進行的？

陸惟凱：模擬演練比較少吧。方案定了之後模擬其實都是沒問題的，定期的review是需要的。演練相關主要是定期組織運維的容災演練與應急演練以及網購節（雙11大促）之前的演練。

周偉然：據我所知，在股份制銀行或規模以上銀行，重要系統演練多以實際生產系統的方式進行，模擬演練主要用於系統正式上線之前的驗證，在實際生產執行時並不採用也不符合監管要求。所有實際生產系統，即實際生產後臺、實際渠道系統，但限定範圍，例如，在演練時，可能關閉網銀入口，使使用者無法直接登入，控制演練本身造成的二次風險。

InfoQ： 相對網際網路行業來說，銀行金融行業的IT運維人員的素質和技能具體有哪些不同？

陸惟凱：個人感覺是比較接近的。可能是我在支付寶工作的緣故，IT相關企業的運維人員根據企業的性質不同（門戶，電商，遊戲，SNS）等會有一些各自有特色的容災以及流控方案。所以需要相關的運維人員更多的瞭解前端業務，能夠根據不同的故障情況進行不同的處理。（例進行功能的刪減控制，流量開關，流量切換等）。另外IT企業運維人員遇到的外部故障會更多一些比方外部攻擊，或運營商，或應用異常出現的故障。。另外傳統IT業的系統更新頻率會比金融業快上很多。相關應用釋出帶來的一些故障處理也會對運維人員提出更高的需求。傳統金融行業的容災方案相對來說就比較單純一些。在資料備份方面IT企業根據企業特性不同，資料備份的重要性也會不同。金融行業對可用率以及資料備份的要求會更高。

周偉然：由於不太瞭解網際網路的運維素質所以不好比較。但對於金融行業運維，制度性準確性和規範性是很重要的。由於銀行設計大量資金和重要隱私，在制度規範上有著較為嚴格的規定，例如業務、研發人員與生產系統嚴格分離、生產資料完全無法接觸的到、需要檢查分析時需要透過嚴格的審批流程。在研發軟體下發生產也必須嚴格進行內容審查和審批，操作步驟必須清晰描寫，而對於運維把控的是對於審批結果的執行，精確執行審批結果而不能自行改動丁點，而且執行過程被記錄，可被審計 在風險發生時，則應依照預案進行各項操作。運維人員對於應急預案的制定的維護，需要基於大量運維經驗，並且透過不斷最佳化驗證的。

InfoQ：能否介紹下：在您所在的組織中，關鍵業務系統的備份是怎麼做的？

陸惟凱：同城容災加異地災備吧..同城容災包括機房內單點容災（備份）以及機房間的相互備份。

周偉然：備份方式對於重要系統均需多方面考慮，例如某關鍵系統，首先在執行時就使用應用叢集的方式確保可用性，通訊接入採用埠和地址複用進行多重備份。執行體系基本需要確保無單點故障，即單一功能點在2個或以上並行執行的節點。其他裝置採用熱備或冷備方式。該資料庫備份基於資料庫引擎和高階引擎進行遠端災備同步的功能，為單資料來源熱備份，資料的儲存備份對於非監管要求資料，根據內部管理規定製定備份儲存時間，備份至專用資料平臺、對於監管要求的資料，在一定時間內線上儲存至資料平臺，長時間後轉磁帶長期儲存。

InfoQ：在網友評論中看到一句話：“最關鍵的是一般都是隻有裝置容災，沒有人員組織架構的容災。”請問您覺得“人員組織架構的容災”應該如何理解？

陸惟凱：人員組織架構的容災分兩部分來看，一部分是操作以及一線的處理人員的備份，這塊要保證相關的運維的操作技能與許可權到位，在第一聯絡人沒有聯絡到的情況下可以聯絡第二聯絡人來進行處理。

第二是決策人員的備份對於決策的人員存在聯絡不上的情況下，可以聯絡備份決策人員來進行決策。

當然這裡的人員組織架構容災基本還沒有考慮到一個異地或者其他的成分，如果遇到毀天滅地型的地震或者更極端的災難的時候，可能會缺乏異地的人手來處理問題。。

周偉然：人員組織的架構在銀行來說有著明確的規定。首先對於每個系統對應的負責人員需要報送管理，並且做到A、B角等多角定義，在系統故障和重大事件保障時均遵循流程對應具體人員。日常工作時，大家對ab角等也有一定的注意，例如某集體全體不宜同一趟飛機出行等來降低風險。

InfoQ：能否介紹一些國外銀行金融企業對類似問題和事故的處理經驗？

陸惟凱：沒有相關的經驗。

周偉然：處理經驗其實之上各題中均有提到，即功夫在平時。好的應急預案和備份需要大量前期工作和定期最佳化維護，並且驗證，每次處理之後透過仔細的分析、審計、故障報告等方式探討不足，不斷地最佳化和改進。