14天才恢復，業界近年最大SaaS當機事件

　　如果你用來管理所有開發專案的平臺，企業內部檔案的共享知識庫，還有業務、銷售、和行政部門合作的專案平臺，突然都當機了，甚至廠商告訴你，要2周後才能修復，這段期間，所有資料無法存取，也沒有備份版本可用，你會怎麼辦？這正是775家企業在Atlassian四月大當機事件，所遭遇的處境。

　　Atlassian是20歲的澳洲老牌軟體開發商，旗下擁有知名的企業專案管理平臺Jira，企業檔案協作平臺Confluence，還有看板協作工具Trello。許多大型企業都採用Jira來管理公司的敏捷開發專案，甚至Atllassian還推出給非技術團隊用的敏捷專案平臺，不少企業用於業務、銷售、商業分析團隊的敏捷管理。

　　根據Atlassian今年3月財報資料，超過75%的財富五百強企業都是他們的企業使用者，全球更有23萬家企業採用，光是用Jira Service Management服務來進行企業內部大型系統開發專案生命週期管理的企業，就超過了4萬家，不少是大型企業，更有178家企業每年授權訂閱費用超過百萬美元，相當於有數千人訂閱授權數的規模，甚至訂閱數最多的一家超大型企業，訂閱了5萬個授權。Atlassian一年光是訂閱費用的營收就超過了13億美元。

　　雖然Atlassian沒有公開這次事故受影響的企業名單，只披露受影響企業家數是775家，但其中有400家是活躍使用的企業。根據國外媒體採訪受影響企業的結果，小則有150個授權，大則有訂閱多達4千個授權的企業。根據非官方估算，775家受影響企業下，累積受到衝擊的個人使用者超過了5萬人。這起事件也大大重挫了Atlassian市值，從當機事件到完全復原這2週期間，Atlassian股價足足下滑了近2成，後續到5月下旬仍持續下滑中。

　　Atlassian擁有十多年SaaS服務的運維經驗，6年SRE經驗，以及雲上業界標準常見的災備和恢復計劃，都無法事前發現，及時阻止4月大當機，無法在99.9%服務水準承諾（SLA） 承諾的8.76小時內復原，甚至有不少企業遲遲等到14天后，才能開啟自己的敏捷專案資料。

　　為何這家雲服務廠商，SRE運維專家，無法避免這次大當機的發生？

　　大當機事件發生過程追追追，一隻刪除程式的誤用而釀災

　　回到事件發生當天，4月5日早上，這一天是Atlassian年度大會Team22的前一天，Atlassian要淘汰一些舊版App，在4月5日這一天刪除這些舊版應用的程式。正是這支刪除舊版AP的指令碼程式造成了這起當機事故。早在實際執行刪除之前，Atlassian測試過這隻指令碼沒有問題，甚至在正式環境中試刪除了30個顧客所用的舊版Ap，也沒有發生問題。

　　提出刪除申請的業務團隊，提供了一份目前還在使用這些舊版AP的企業顧客名單，作為指令碼自動執行刪除的目標清單。但是，關鍵的出錯環節是，他們提供的ID清單，不是直接提供要刪除AP的ID，而是給了這些待刪除AP ID所在的網站ID清單，再告訴執行刪除指令的工程團隊，要刪除這些網站ID中的老舊AP。但是，雙方發生了溝通落差，工程團隊誤以為，這批網站ID就是要刪除的清單，直接套用到刪除指令碼來執行。到了4月5日，這隻指令碼刪除的不是舊版AP，而是刪除了那些還在使用舊版AP的企業的全部網站資料。

　　釀災起因：想刪除老舊App，為何反而刪除顧客全站資料？

　　要了解誤刪的影響，得先知道用APP ID來刪除，和使用網站ID來刪除，有何差別？這得從Atlassiant技術架構說起。

　　Atlassiant所有服務都部署在AWS上，在資料儲存上和服務架構上，都採取了高度分散式架構，以及容易組合再利用的微服務架構，並在雲上基礎架構上來設計了書架管理層和共用的平臺服務層，也透過API串連到許多第三方廠商的應用。所有微服務都布建在AWS的容器化服務上，更搭配了一套PaaS服務，稱為Micros，來提供內部微服務的自動化構建。從公共服務部署、基礎架構資源排程、資料儲存管理、合規性管制都靠這個平臺自動完成。

　　另外在管理架構上，Atlassian採取了多租戶架構，並以網域作為單一使用者的最基本管理單位，這就是網站ID。企業要指定一個網址作為登入Atlassian服務的主要入口網站，也把他們所訂閱的所有Atlassian服務，都登記到這個網址下。Atlassian也稱這個網址是一個網站容器，用來容納屬於這個企業顧客的所有資料、配置和所用的APP。網站ID就是用來識別一家企業的網站容器的代號。

　　Atlassian的技術架構採取了分散式架構，不只在雲端基礎架構採取分散式架構來提高可用性，在應用系統層次，也採取了多租戶微服架構設計來兼顧彈性和可用性。圖片來源／Atlassian

　　

　　Atlassian的網站ID（企業顧客網站URL網址）也是一個網站容器，將一家企業的所有資料、配置和所用的APP，都登記到這個網站ID來管理。圖片來源／Atlassian

　

　　Atlassian也用這個網站ID來作為識別一個企業使用者帳號的代號，所有與這家企業有關的資料、表單、帳單，也都用這個網站ID來作為識別客戶的索引，例如企業顧客提出支援工單時，這張工單就會用網站ID作為所屬客戶的代號。

　　當Atlassian業務單位提出了一份要刪除老舊APP的網站ID，希望刪除他們所用的老舊AP。但是負責執行的團隊，誤以為要刪除這一批AP ID所在的網站ID。這就不只是刪除了AP，而是刪除了採用這些AP的企業所擁有的全部AP和資料。

　　4月5日7:38，開始執行舊版AP刪除指令碼，工程團隊也沒有接到任何通知，警告有企業顧客的網站遭刪除，因為這是一隻獲得合法授權的刪除。但是，不到10分鐘，就有企業發現自己所用的Jira網站失聯，提出第一張當機支援工單。刪除指令碼在8點多執行完畢，事後調查，一口氣刪除了775家企業所擁有的883個網站。受影響的產品包括了Jira 產品系列、Confluence檔案協作平臺、Atlassian Access登入機制、Opsgenie 事件應變服務，甚至是網站狀態查詢頁Statuspage。這些受影響企業，不只無法連線登入，甚至連要檢視所用服務的運作狀態頁都打不開。

　　接連有不少顧客提出當機工單，Atlassian決定在8:17啟動重大事件管理流程，也組織了跨部門事件管理團隊，找來工程部門、客戶支援團隊、專案管理團隊和對外溝通部門，聯手展開事故調查，每3小時開會一次，並在8:24將事件狀態提升到「危急」狀態。不到20分鐘，工程團隊就發現了事故的根本原因，是指令碼誤刪資料而非駭客攻擊，9:03時首度在服務狀態網頁中揭露發生當機事故。

　　找出事故原因之後，下一步就是要儘快解決問題，恢復顧客所訂閱的服務。Atlassian開始嘗試建立一套標準化的復原方法，但卻發現，要復原一個遭到刪除的網站，得建立新網站、復原每個下游產品、服務及還原資料所需的資料，還須與各網站所用第三方生態系廠商重建連結，相關復原步驟高達70個。他們才發現，要復原這些網站的複雜性遠超過他們的想像，所以在12:38時將這起事件的嚴重等級提升到「最高等級」，這時距離事故發生，已經超過了5小時。

　　Atlassian當機後不久，越來越多顧客在Twitter上抱怨，因為Jira是許多企業用來管理敏捷開發專案的主要平臺，無法使用，就等於無法進行敏捷專案的開發，連要開啟專案工單來知道該處理哪些工作都沒有辦法。這股抱怨聲浪越來越大，越來越多人發現，這起當機事件持續時間越來越久，超過了8、9個小時，Atlassian所承諾的99.9%可用性承諾已經失守。

　　不少受影響的企業使用者在Twitter上抱怨，他們連要向Atlassian通報當機問題，或是申請支援工單都做不到，也有人是發出申請後，遲遲沒有得到官方回應，彷彿Atlassian的服務視窗失聯一樣，無法透過原本的線上管道來接觸。

　　直到事故發生後17個小時，Atlassian才發電子郵件通知受影響顧客，並開始打電話聯絡，對他們說明，而這時已經引起不少媒體的關注，開始大舉報導這起大當機事件。

　　直到事件發生後快2天，Atlassian才釋出第一份當機事件的官方公開宣告。而Atlassian的合作伙伴，則還等到事故後第2天快結束時，才開始接到通知。因為當機事故遲遲無法解決，Atlassian共同創辦人也以個人名義發信，親自向顧客說明覆原進度緩慢的原因。

　　4月8日，也就是事件發生後的第四天，Atlassian終於成功復原了第一家受影響顧客的網站。可是，復原團隊這才發現，採用第一版復原方法，需要48小時才能恢復一批網站，因為需要大量人工操作，只能分批覆原，若要全面復原剩下的網站，還需要3周時間，所以，也開始改良復原程式。同一天，Atlassian也對所有工程部門實施程式碼凍結，禁止任何異動，來降低顧客資料不一致的變更風險

　　過了一天，4月9日開始啟用第二套復原方法，將原本70道程式，大幅減少到只剩下30道程式。第二套做法重建顧客網站時，不是建立新的網站ID，而是直接沿用了顧客的舊網站ID，因此，大幅減少新舊ID比對的步驟，也不用再逐一與第三方程式供應商溝通，節省大量時間。這時有771個誤刪網站，可以改用第二套方法來複原。

　　不過，第二套方法還是需要大量手動操作，直到4月11日，Atlassian工程團隊打造出自動化復原工具，來加速第二套方法的時間，才將復原時間縮短到12小時，這時候，Atlassian才在工單中向顧客承諾，可以在事故後2周內復原。

　　到了4月14日，採用第一版復原方法復原的網站達到112個網站，不再繼續使用。Atlassian也打造出復原網站的完整驗證指令碼，不再需要人工驗證，更加快了其他網站的復原速度，到了4月16日10:05 ，就完成所有網站的復原和自動驗證，但還沒經過顧客確認。隔天21:48，最後一位受影響顧客完成復原確認。Atlassian就在4月18日1:00宣佈，受影響網站100%復原。這時，距離事故發生已經近14天，不過，宣佈當時，仍有57個網站，因為復原資料的時間點過早，比原訂「當機前5分鐘」的復原時間點，還要更早，還需要追補後來異動的資料。

　　到了4月底，Atlassian釋出了四月大當機事件的完整事後分析報告。