Update on the Atlassian outage affecting some customers

Published April 13, 2022 in How we build

Sri Viswanath

As of Apr 18, 2022, 23:57 UTC, all customers impacted by the outage have been restored.

On Monday, April 4th, 2022 PT approximately 400 Atlassian Cloud customers experienced a full outage across their Atlassian products. As of April 18th, 2022, we have now restored our customers impacted by the outage and have reached out to key contacts for each affected site.

Our support teams are working with individual customers through any site specific needs. If you need assistance, please reply to your support ticket so that our engineers can work with you as soon as possible.

To be clear, this incident was not a cyber attack nor was it a failure of our systems to scale. Additionally, the majority of restored customers have had no data loss, while some have reported data loss for up to 5 minutes prior to the incident.

Let me start by saying that this incident and our response time are not up to our standard, and I apologize on behalf of Atlassian. We know that our products are mission-critical to your teams and that your business is impacted when our services are unavailable. We are working around the clock to get our customers back up and running and this is the top priority.

What happened

One of our standalone apps for Jira Service Management and Jira Software, called “Insight – Asset Management,” was fully integrated into our products as native functionality. Because of this, we needed to deactivate the standalone legacy app on customer sites that had it installed. Our engineering teams planned to use an existing script to deactivate instances of this standalone application. However, two critical problems ensued:

Communication gap. First, there was a communication gap between the team that requested the deactivation and the team that ran the deactivation. Instead of providing the IDs of the intended app being marked for deactivation, the team provided the IDs of the entire cloud site where the apps were to be deactivated.
Faulty script. Second, the script we used provided both the “mark for deletion” capability used in normal day-to-day operations (where recoverability is desirable), and the “permanently delete” capability that is required to permanently remove data when required for compliance reasons. The script was executed with the wrong execution mode and the wrong list of IDs. The result was that sites for approximately 400 customers were improperly deleted.

To recover from this incident, our global engineering team has implemented a methodical process for restoring our impacted customers.

What we are doing to recover

Atlassian Data Management describes our data management processes in detail.

To ensure high availability, we provision and maintain a synchronous standby replica in multiple AWS Availability Zones (AZ). The AZ failover is automated and typically takes 60-120 seconds, and we regularly handle data center outages and other common disruptions with no customer impact.

We also maintain immutable backups that are designed to be resilient against data corruption events, which enable recovery to a previous point in time. Backups are retained for 30 days, and Atlassian continuously tests and audits storage backups for restoration.

Using these backups, we regularly roll-back individual customers or a small set of customers who accidentally delete their own data. And, if required, we can restore all customers at once into a new environment.

What we have not (yet) automated is restoring a large subset of customers into our existing (and currently in use) environment without affecting any of our other customers.

Within our cloud environment, each data store contains data from multiple customers. Because the data deleted in this incident was only a portion of data stores that are continuing to be used by other customers, we have to manually extract and restore individual pieces from our backups. Each customer site recovery is a lengthy and complex process, requiring internal validation and final customer verification when the site is restored.

Steps in the process

Our initial approach to restoring customer sites was only semi-automated. It involved a series of complex steps that were time-consuming, in part because it required us to manually validate customer data for each site that was restored.

We are now shifting to a more automated process, as follows:

Re-enable metadata for deleted sites in our centralized orchestration system
Restore customer data extracted from backups, including users, permissions, etc.
Re-enable ecosystem apps, billing data and other data not directly associated with customer-generated data

Because multiple data stores must be extracted and recovered for each site, we test the site and work closely with each individual customer to ensure the accuracy of their restoration.

Currently, we are restoring customers in batches of up to 60 tenants at a time. End-to-end, it takes between 4 and 5 elapsed days to hand a site back to a customer. Our teams have now developed the capability to run multiple batches in parallel, which has helped to reduce our overall restore time.

Restoring customers is our top priority

We know that incidents like this can erode trust. We are not meeting the high standards that we set for ourselves. This includes our communications efforts, which until now were entirely focused on reaching our impacted customers directly.

This incident remains the top priority for my engineering team and for our entire company. We will continue working around the clock until every single customer’s site is restored.

Here’s what you can expect next:

Restoring customer sites. We will continue to work directly with affected customers to restore their sites, communicating 1:1 via support tickets and through our Customer Support team. We are moving through this as fast as possible.
Daily updates. We are committed to daily updates to our impacted customers via their tickets – and via daily status page updates.
Post-incident review. Following this incident, we will conduct and share a post-incident review with our findings and next steps. This report will be public.

Finally to our customers: Thank you for your partnership as we navigate each and every step together. We know that you have stakeholders to answer to within your organization and that our failure has resulted in major disruptions to your business. My teams and I are committed to restoring service for each customer as soon as possible, and doing what we can to make this right for you.

This article is also available in the following languages.

Japanese (日本語)

日本語のブログ記事を読む

Simplified Chinese (简体中文)

关于影响部分客户的 Atlassian 中断的最新通报

仅为方便起见，我们提供了此翻译版本。如果翻译版本之间存在任何歧义或冲突，则以英语版本为准。

截至协调世界时 2022 年 4 月 18 日 23:57，所有受中断影响的客户均已恢复服务。

太平洋时间 2022 年 4 月 4 日星期一，约 400 名 Atlassian Cloud 客户的 Atlassian 产品遭遇全面中断。截至 2022 年 4 月 18 日，我们已为所有受中断影响的客户恢复服务，并联系了每个受影响站点的主要联系人。

我们的支持团队正在配合个人客户解决他们站点的具体需求。如果您需要帮助，请回复您的支持工作单，以便我们的工程师尽快与您联系。

需要明确的是，此次事件并非网络攻击，也不是我们的系统扩展失败。此外，大部分恢复服务的客户都没有丢失数据，部分客户反映在事件发生前丢失了约 5 分钟的数据。

首先，我想说的是，此次事件的发生以及我们的响应时间均不达标，我在此代表 Atlassian 致歉。我们知道，我们的产品对您的团队至关重要。一旦我们的服务不可用，您的业务就会受到影响。为此，我们正在昼夜不停地为客户恢复服务和运行，这是当务之急。

情况说明

我们为 Jira Service Management 和 Jira Software 开发了一个名为“Insight – Asset Management”的独立应用，该应用已作为原生功能全面集成到我们的产品中。因此，我们需要停用客户站点上安装的旧版独立应用。我们的工程团队原本计划使用现有脚本停用此独立应用的实例。但由此引发了两个重大问题：

沟通缺失。首先，请求停用的团队与运行停用的团队之间沟通缺失。团队没有提供标记为停用的目标应用的 ID，而是提供了待停用应用所在整个云站点的 ID。
脚本错误。其次，我们使用的脚本既提供了每日常规操作中会用到的“标记删除”功能（可恢复），也提供了“永久删除”功能，在出于合规性原因需要永久删除数据时，就要用到该功能。执行脚本时使用了错误的执行模式和错误的 ID 列表。结果造成约 400 个客户的站点被意外删除。

为了从此次事件中恢复，我们的全球工程团队正通过一个有条不紊的流程帮助受影响的客户恢复服务。

我们采取的恢复措施

Atlassian 数据管理详细介绍了我们的数据管理流程。

为确保高可用性，我们在多个 AWS 可用性区域 (AZ) 预置和维护一个同步备用副本。可用性区域故障转移为自动化程序，通常可在 60-120 秒内完成。我们会定期处理数据中心中断和其他常见中断问题，不会对客户造成影响。

我们还会维护不可变备份，以抵御数据损坏事件，从而能够恢复到过去的时间点。备份保留 30 天，Atlassian 会持续测试和审核存储备份以便恢复。

利用这些备份，我们可定期帮助意外删除自有数据的个别客户或小规模客户组回滚到过去的时间点。而且，必要时，我们可以一次性帮助所有客户恢复到新的环境。

我们目前尚未实现⾃动化的是，在不影响其他客户的情况下，将⼤量客户的⼦设备恢复到现有（和⽬前正在使⽤的）环境。

在我们的云环境中，每个数据存储都包含来自多个客户的数据。由于在此次事件中被删除的数据只是其他客户持续使用的数据存储的一部分，所以我们必须从备份中手动提取和恢复相应片段。每个客户站点的恢复都涉及一个漫长而复杂的过程，恢复站点时需进行内部验证和最终客户验证。

流程中涉及的步骤

我们最初采取了半自动化方式来恢复客户站点。这种方式涉及一系列复杂而耗时的步骤，部分原因在于我们需要手动去验证每个所恢复站点的客户数据。

现在，我们开始改用更加自动化的流程，具体如下：

在我们的集中编排系统中为删除的站点重新启用元数据
恢复从备份中提取的客户数据，包括用户、权限等。
重新启用生态系统应用、计费数据以及其他与客户产生的数据无直接关联的数据

由于每个站点都要提取和恢复多个数据存储，所以我们要对站点进行测试并与每个客户密切合作，以确保恢复的准确性。

目前，我们正在分批恢复客户，一次最多可恢复 60 个租户。从头至尾，我们需要 4 到 5 天的时间将站点交还客户。我们的团队现已具备并行运行多个批次的能力，这有助于缩短我们的总体恢复时间。

恢复客户站点是我们的第一要务。

我们知道此次事件会削弱客户对我们的信任。我们没有达到自己所设定的高标准。其中包括我们的沟通工作不到位，到目前为止，我们重点是直接联系受影响的客户。

此次事件仍是我们工程团队和全公司的重中之重。我们将继续连轴工作，直至每个客户的站点都恢复完毕。

我们的后续承诺：

恢复客户站点。我们将继续直接联系受影响的客户以恢复其站点，我们还将通过支持工作单和客户支持团队进行一对一的沟通。我们正在尽快推进这项工作。
每日更新。我们致力于通过受影响客户的工作单以及每日状态页面更新向受影响客户通报每日最新情况。
事后审查。事件发生后，我们将开展事后审查，并通报审查结果以及后续行动措施。该报告将会公开。

最后，我们想对客户说：感谢您配合我们执行每一项工作。我们知道您需要对组织内的利益相关者负责，而我们的失职已经对您的业务造成了重大影响。我的团队以及我本人都致力于尽快为每个客户恢复服务，并尽我们所能为您解决问题。

Traditional Chinese (繁體中文)

Atlassian 停機最新情況

此翻譯僅供參閱。如果譯文有任何不清楚或矛盾之處，請以英文原文為準。

截至 2022 年 4 月 18 日 23:57 UTC (世界協調時間) 為止，我們已為受停機影響的所有客戶恢復服務。

2022 年 4 月 4 日 (星期一) PT (太平洋時間)，有大約 400 位 Atlassian Cloud 客戶因為 Atlassian 產品停機而受到影響。截至 2022 年 4 月 18 日止，我們已為受停機影響的客戶恢復服務，並與每個受影響網站的主要連絡人聯繫。

我們的支援團隊正在與個別客戶協作，處理網站的特定需求。如果您需要協助，請透過支援工單回覆，以便我們的工程師儘快與您協作。

我們必須澄清，這次事件並非出自網路攻擊，也非系統擴展問題。此外，大多數恢復服務的客戶都沒有遺失資料，有些客戶則在事件發生前回報資料遺失長達 5 分鐘。

首先，我必須承認，這次事件與我們的應對時間不符合我們的服務標準。我謹代表 Atlassian 致上歉意。我們深知 Atlassian 的產品對客戶至關重要，當我們的服務停擺，您的業務將受影響。修復工作是目前的當務之急，我們已全天候投入，希望盡快協助客戶。

事件始末

「Insight-資產管理」是 Jira Service Management 和 Jira Software 的獨立應用程式之一，現已透過原生功能的形式，完全整合到我們的產品中。因此，我們需要停用客戶網站上安裝的獨立舊版應用程式。工程團隊原本計劃使用現有的指令碼，停用此獨立應用程式的執行個體。然而，發生了兩個重大問題：

溝通落差。首先，請求停用的團隊與執行停用的團隊之間有溝通落差。請求停用的團隊沒有提供標記停用的目標應用程式 ID，反而提供了應用程式的整個雲端網站 ID。
指令碼錯誤。其次，我們使用的指令碼同時提供日常運作中使用的「標記供刪除」功能 (可復原)，以及永久刪除功能。因法規原因需要永久移除資料時才會使用永久刪除功能。執行指令碼時用了錯誤的執行模式和錯誤的 ID 列表。這造成了大約 400 位客戶的網站遭到不當刪除。

為了修復此事件，我們全球的工程團隊執行了嚴謹的流程，為受影響的客戶修復服務。

修復流程

Atlassian 資料管理詳細介紹了我們的資料管理流程。

為確保高度可用性，我們在多個 AWS Availability Zones (AZ) 中佈建並維護同步備用複本。AZ 的容錯移轉是自動的，通常需要 60-120 秒的時間。我們會定期處理資料中心停機和其他常見中斷，這不會對客戶造成影響。

我們同時也維護不可變備份，這些備份是可復原的，若遇到資料損壞事件，能夠復原到上一次的正確狀態。備份會保留 30 天，Atlassian 持續測試和審核備份儲存，以供恢復之用。

有了這些備份，我們就可以定期為誤刪資料的個人客戶或少數客戶復原資料。若有需要，我們也可以一次將所有客戶恢復到新的環境中。

我們尚未自動化的部分是在不影響其他客戶的情況下，將一大部分客戶恢復到我們現有使用的環境中。

在我們的雲端環境中，每個資料存儲區都包含來自多位客戶的資料。由於此事件中遭到刪除的資料只是其他客戶持續使用的一部分資料存儲區，所以我們必須手動從備份中一一提取和修復資料。每個客戶網站的復原過程皆耗時又複雜，需要在恢復網站時進行內部驗證和最終客戶驗證。

修復步驟

我們最初的修復方法只是半自動的。過程涉及一系列十分耗時的複雜步驟，部分原因是我們必須針對需要復原的每個網站，手動驗證客戶資料。

我們正在轉向更加自動化的流程，具體說明如下：

在我們的集中協作系統中重新啟用遭刪除網站的中繼資料
修復從備份中提取的客戶資料，包括使用者、權限等
重新啟用生態系應用程式、計費資料和其他與客戶生成資料無直接關聯的資料

由於修復過程必須提取和復原各個網站的多個資料存儲區，因此我們會測試網站，並與每個個人客戶密切合作，以確保復原工作的正確性。

目前，我們分批次修復，每次處理最多 60 個租戶。將網站端對端交還給客戶需要 4 到 5 天的時間。我們的團隊已能夠同時處理許多批次，因此縮短了整體恢復時間。

修復客戶網站是我們的首要任務

我們深知類似事件會降低客戶對我們的信任。我們沒有達到自己制定的高標準。包括我們所訂定的溝通標準。我們到目前為止一直全心地與受影響的客戶直接溝通。

處理此事件仍是我的工程團隊，乃至整個公司的當務之急。我們將繼續全天候投入修復工作，直到每位客戶的網站復原完成為止。

後續行動：

修復客戶網站。我們將繼續與受影響的客戶密切合作以修復網站，透過支援工單和客戶支援團隊進行一對一溝通。我們會盡快解決問題。
每日更新。我們將透過工單和每日狀態頁面更新，每日向受影響的客戶提供修復工作的最新資訊。
事件回顧檢討在此事件後，我們將進行回顧檢討並說明我們的想法和後續步驟。此報告將完全公開。

最後，親愛的客戶：感謝您的合作，與我們一起向前邁進。我們知道您必須向組織內部的利益關係人說明事件原委，我們的失誤導致您的業務發生嚴重中斷。我和我的團隊一定會盡快為您修復服務，並盡我們所能為您提供服務。

German (Deutsch)

Update zum einige Kunden betreffenden Atlassian-Ausfall

Diese Übersetzung wird nur zum besseren Verständnis bereitgestellt. Bei Unklarheiten oder Widersprüchen mit Übersetzungen hat die englische Originalversion Vorrang.

Alle vom Ausfall betroffenen Kunden-Sites wurden wiederhergestellt (Stand 18. April 2022, 23:57 UTC/19. April 2022, 01:57 CET).

Am Montag, den 4. April 2022 (PT) kam es zu einem vollständigen Ausfall von Atlassian-Produkten, der etwa 400 Atlassian Cloud-Kunden betraf. Wir haben mittlerweile alle vom Ausfall betroffenen Kunden-Sites wiederhergestellt und die jeweiligen Ansprechpartner kontaktiert (Stand: 18. April 2022).

Unsere Support-Teams arbeiten bei Site-Anforderungen aller Art persönlich mit unseren Kunden zusammen. Wenn Sie Hilfe benötigen, antworten Sie bitte auf Ihr Support-Ticket. Unsere Techniker setzen sich so schnell wie möglich mit Ihnen in Verbindung.

Bei dem Vorfall handelte es sich weder um einen Cyberangriff noch um einen Skalierungsfehler unserer Systeme. Die Mehrheit der Kunden waren nach der Wiederherstellung nicht von Datenverlust betroffen. Einige Kunden haben jedoch bis zu 5 Minuten vor dem Vorfall gemeldet, dass Daten verloren gegangen seien.

Zunächst möchte ich Ihnen versichern, dass dieser Vorfall und unsere Reaktionszeit nicht unseren Standards entsprechen. Daher möchte ich Sie im Namen von Atlassian um Entschuldigung bitten. Uns ist bewusst, dass unsere Produkte für Ihre Teams geschäftskritisch sind und dass Ihr Unternehmen betroffen ist, wenn unsere Services nicht verfügbar sind. Wir arbeiten rund um die Uhr daran, den Service für unsere Kunden wiederherzustellen. Dies hat höchste Priorität für uns.

Was passiert ist

Insight – Asset Management, eine unserer eigenständigen Apps für Jira Service Management und Jira Software, wurde vollständig als native Funktion in unsere Produkte integriert. Hierfür musste die entsprechende auf Kunden-Sites installierte Legacy-App deaktiviert werden. Unsere Entwicklungsteams wollten ein vorhandenes Skript verwenden, um die Instanzen dieser App zu deaktivieren. Es ergaben sich jedoch zwei kritische Probleme:

Kommunikationsmängel. Die Kommunikation zwischen dem Team, das die Deaktivierung veranlasst hatte, und dem Team, das mit der Durchführung der Deaktivierung betraut war, war nicht ausreichend. Anstatt die IDs der zu deaktivierenden Apps anzugeben, stellte das Team die IDs der gesamten Cloud-Site bereit, auf der die Apps deaktiviert werden sollten.
Fehlerhaftes Skript. Zudem stellte das genutzte Skript sowohl die Funktion “Mark for Deletion” (Zur Löschung kennzeichnen) bereit, die wir in unserem täglichen Betrieb verwenden (in Fällen, in denen Wiederherstellbarkeit erwünscht ist), sowie die Funktion “Permanently Delete” (Dauerhaft löschen), die erforderlich ist, um Daten aus Compliance-Gründen dauerhaft zu entfernen. Das Skript wurde mit dem falschen Ausführungsmodus und der falschen ID-Liste ausgeführt. Dies hatte zur Folge, dass Sites von rund 400 Kunden nicht ordnungsgemäß gelöscht wurden.

Um die Folgen dieses Vorfalls zu beheben, hat unser globales Entwicklungsteam einen methodischen Prozess zur Wiederherstellung für betroffene Kunden implementiert.

Abhilfemaßnahmen

Unter Atlassian Data Management erhalten Sie genaue Informationen über unsere Datenmanagementprozesse.

Um eine hohe Verfügbarkeit sicherzustellen, stellen wir ein synchrones Standby-Replikat in mehreren AWS Availability Zones (AZ) bereit und warten dieses. Das AZ-Failover ist automatisiert und dauert in der Regel 60 bis 120 Sekunden. Wir behandeln regelmäßig Rechenzentrumsausfälle und andere häufige Störungen, ohne dass diese Auswirkungen auf Kunden haben.

Zudem verfügen wir über unveränderliche Backups, die vor Datenbeschädigungen geschützt sind und eine Wiederherstellung auf einen früheren Zeitpunkt ermöglichen. Backups werden 30 Tage lang gespeichert und Atlassian prüft sie regelmäßig auf ihre Wiederherstellungsfähigkeit.

Mit diesen Backups können wir regelmäßig die Daten einzelner Kunden oder Kundengruppen wiederherstellen, die versehentlich ihre Daten gelöscht haben. Bei Bedarf können wir auch zeitgleich die Wiederherstellung für alle Kunden in einer neuen Umgebung durchführen.

Was wir (noch) nicht automatisiert haben, ist die Wiederherstellung einer großen Teilmenge von Kunden in unsere bestehende (und derzeit verwendete) Umgebung, ohne einen unserer anderen Kunden zu beeinträchtigen.

In unserer Cloud-Umgebung enthält jeder Datenspeicher Daten von mehreren Kunden. Da die bei diesem Vorfall gelöschten Daten nur ein Teil der Datenspeicher ausmachten, die weiterhin von anderen Kunden verwendet werden, müssen wir einzelne Teile aus unseren Backups manuell extrahieren und wiederherstellen. Jede Wiederherstellung einer Kunden-Site ist ein langwieriger und komplexer Prozess, der eine interne Überprüfung und eine abschließende Kundenverifizierung erfordert, nachdem die Site wiederhergestellt wurde.

Vorgehensweise

Unser bisheriger Ansatz zur Wiederherstellung von Kunden-Sites war nur teilweise automatisiert. Es umfasste eine Reihe komplexer Schritte, die zeitaufwendig waren, unter anderem, weil wir die Kundendaten für jede wiederhergestellten Site manuell prüfen mussten.

Aus diesem Grund weiten wir die Automatisierung unseres Prozesses wie folgt aus:

Erneute Aktivierung von Metadaten gelöschter Sites in unserem zentralen Orchestrierungssystem
Wiederherstellung von Kundendaten, die aus Backups extrahiert werden, darunter Benutzer, Berechtigungen usw.
Erneute Aktivierung von Ökosystem-Apps, Rechnungsdaten und anderen Daten, die nicht direkt mit von Kunden generierten Daten verknüpft sind

Da für jede Site mehrere Datenspeicher extrahiert und wiederhergestellt werden müssen, testen wir die Site und arbeiten eng mit den jeweiligen Kunden zusammen, um die Qualität der Wiederherstellung zu sicherzustellen.

Derzeit erfolgt die Wiederherstellung für Kunden in Batches von bis zu 60 Mandanten gleichzeitig. Insgesamt dauert es 4 bis 5 Tage, bis ein Kunde seine Site wieder wie gewohnt nutzen kann. Unsere Teams können jetzt mehrere Batches parallel ausführen, was ihnen hilft, die Gesamtwiederherstellungszeit zu verkürzen.

Die Wiederherstellung von Kunden-Sites hat höchste Priorität

Wir wissen, dass Vorfälle dieser Art das Vertrauen beeinträchtigen können. Es ist uns nicht gelungen, unsere hohen Standards zu erfüllen. Das betrifft zum Beispiel unsere Kommunikation, bei der es uns in der Vergangenheit ausschließlich darum ging, betroffene Kunden direkt zu kontaktieren.

Dieser Vorfall hat weiterhin höchste Priorität für mein Entwicklungsteam und unser gesamtes Unternehmen. Wir arbeiten rund um die Uhr, bis jede Kunden-Site wiederhergestellt ist.

So geht es weiter:

Wiederherstellen von Kunden-Sites. Wir arbeiten weiterhin mit betroffenen Kunden zusammen, um ihre Sites wiederherzustellen. Dabei treten wir persönlich über Support-Tickets und über unser Customer-Support-Team in Kontakt. Wir bearbeiten alle Anfragen so schnell wie möglich.
Tägliche Updates. Wir setzen alles daran, Kunden täglich über ihre Tickets zu informieren – zusätzlich zu den täglichen Updates auf der Statusseite.
Überprüfung nach dem Vorfall. Wir werden eine Überprüfung des Vorfalls durchführen und einen Bericht mit Ergebnissen und nächsten Schritten veröffentlichen. Der Bericht wird öffentlich zugänglich sein.

Ein letztes Wort an unsere Kunden: Vielen Dank, dass sie uns bei jedem Schritt zur Seite stehen. Wir wissen, dass Sie in Ihrem Unternehmen Verantwortung übernehmen und dass unser Fehler zu erheblichen Einschränkungen geführt hat. Meine Teams und ich setzen alles daran, den Service für alle Kunden so schnell wie möglich wiederherzustellen und Ihnen keine weiteren Unannehmlichkeiten zu bereiten.

Spanish (Español)

Información sobre la interrupción del servicio de Atlassian que afecta a algunos clientes

Esta traducción solo pretende servir de referencia. Si hubiera alguna ambigüedad o contradicción entre las versiones traducidas, prevalecerá la versión en inglés.

A fecha de 18 de abril de 2022 a las 23:57 (UTC), se ha restaurado el servicio a todos los clientes afectados por la interrupción del servicio.

El lunes 4 de abril de 2022 (PT), aproximadamente 400 clientes de Atlassian Cloud sufrieron una interrupción del servicio completa en sus productos de Atlassian. A fecha de 18 de abril de 2022, hemos restaurado el servicio a nuestros clientes afectados por la interrupción del servicio y nos hemos puesto en contacto con los contactos clave de cada sitio afectado.

Nuestros equipos de soporte están trabajando con clientes individuales para dar respuesta a cualquier necesidad específica de sus sitios. Si necesitas ayuda, responde a tu ticket de soporte para que nuestros ingenieros puedan trabajar contigo lo antes posible.

Queremos aclarar que este incidente no fue un ciberataque ni un fallo de escalado de nuestros sistemas. Además, la mayoría de los clientes para los que hemos restaurado el servicio no han sufrido pérdida de datos, mientras que algunos han informado de la pérdida de los datos de los 5 minutos previos al incidente.

Tanto este incidente como nuestro tiempo de respuesta no están a la altura de nuestros estándares, y me gustaría disculparme en nombre de Atlassian. Sabemos que nuestros productos son fundamentales para vuestros equipos y que vuestro negocio se ve afectado cuando nuestros servicios no están disponibles. Estamos trabajando sin descanso para que los clientes puedan volver a trabajar con normalidad, y esta es nuestra máxima prioridad.

Qué pasó

Una de nuestras aplicaciones independientes para Jira Service Management y Jira Software, llamada “Insight – Asset Management”, se había integrado completamente en nuestros productos como función nativa. Por este motivo, necesitábamos desactivar la antigua aplicación independiente en los sitios de los clientes que la tenían instalada. Nuestros equipos de ingeniería pensaban utilizar una secuencia de comandos existente para desactivar las instancias de esta aplicación independiente. Sin embargo, se produjeron dos problemas críticos:

Brecha de comunicación. En primer lugar, hubo una brecha de comunicación entre el equipo que solicitó la desactivación y el equipo que la ejecutó. En lugar de proporcionar los ID de la aplicación que se había marcado para su desactivación, el equipo proporcionó los ID de todo el sitio de Cloud en el que se iban a desactivar las aplicaciones.
Secuencia de comandos inadecuada. En segundo lugar, la secuencia de comandos que utilizamos proporcionaba tanto la función de “marca de eliminación” que se utiliza en las operaciones normales del día a día (en las que se quiere tener capacidad de recuperación) como la función de “eliminación permanente” que es necesaria para eliminar datos de forma permanente cuando sea necesario por motivos de cumplimiento. La secuencia de comandos se ejecutó con un modo de ejecución inadecuado y una lista de ID incorrectos. El resultado fue que los sitios de aproximadamente 400 clientes se eliminaron indebidamente.

Para recuperarse de este incidente, nuestro equipo de ingeniería global ha implementado un proceso metódico para restaurar el servicio a nuestros clientes afectados.

Qué estamos haciendo para restaurar el servicio

Atlassian Data Management refleja nuestros procesos de gestión de datos en detalle.

Para conseguir una alta disponibilidad, aprovisionamos y mantenemos una réplica en espera sincrónica en varias zonas de disponibilidad (AZ) de AWS. La conmutación por error de AZ está automatizada y suele tardar entre 60 y 120 segundos, y gestionamos regularmente las interrupciones del servicio de centros de datos y otras interrupciones habituales sin que esto afecte a los clientes.

También mantenemos copias de seguridad inmutables que están diseñadas para resistir eventos de corrupción de datos, lo que permite la recuperación a un punto anterior en el tiempo. Las copias de seguridad se conservan durante 30 días y Atlassian prueba y audita continuamente la restauración de copias de seguridad de almacenamiento.

Con estas copias de seguridad, revertimos habitualmente clientes individuales o un pequeño conjunto de clientes que eliminan accidentalmente sus datos. Y, si es necesario, podemos restaurar a todos los clientes a la vez en un entorno nuevo.

Lo que aún no hemos automatizado es la restauración de un gran subconjunto de clientes en el entorno que usamos actualmente sin afectar al resto de los clientes.

Dentro de nuestro entorno en la nube, cada almacén de datos contiene datos de varios clientes. Dado que los datos eliminados en este incidente eran solo una parte de los almacenes de datos que otros clientes siguen utilizando, tenemos que extraer y restaurar manualmente partes individuales de nuestras copias de seguridad. La recuperación del sitio de cada cliente es un proceso largo y complejo que requiere validación interna y verificación final del cliente una vez que se restaura el sitio.

Pasos del proceso

Nuestro proceso inicial para restaurar los sitios de los clientes solo estaba semiautomatizado. Implicaba una serie de pasos complejos que llevaban mucho tiempo, en parte porque nos obligaba a validar manualmente los datos de los clientes para cada sitio que se restauraba.

Ahora estamos cambiando a un proceso más automatizado, que funciona de la siguiente manera:

Habilitamos de nuevo los metadatos de los sitios eliminados en nuestro sistema de orquestación centralizado
Restauramos los datos de los clientes extraídos de las copias de seguridad, incluidos los usuarios, los permisos, etc.
Habilitamos de nuevo las aplicaciones del ecosistema, los datos de facturación y otros datos no asociados directamente con los datos generados por los clientes

Debido a que se deben extraer y recuperar varios almacenes de datos para cada sitio, probamos el sitio y trabajamos en estrecha colaboración con cada cliente para conseguir que la restauración sea precisa.

Actualmente, estamos restaurando los sitios de los clientes en lotes de hasta 60 inquilinos al mismo tiempo. De principio a fin, se necesitan entre 4 y 5 días para restaurar un sitio a un cliente. Nuestros equipos han desarrollado la capacidad de ejecutar varios lotes en paralelo, lo que ha ayudado a reducir el tiempo de restauración general.

Restaurar los sitios de los clientes es nuestra máxima prioridad

Sabemos que incidentes como este pueden minar la confianza de los clientes. No estamos cumpliendo con los altos estándares que nos fijamos. Esto incluye nuestros esfuerzos de comunicación, que hasta ahora se centraban por completo en comunicarnos directamente con los clientes afectados.

Este incidente sigue siendo la máxima prioridad para mi equipo de ingeniería y para toda la empresa. Continuaremos trabajando de forma incansable hasta que hayamos restaurado los sitios de todos los clientes.

Esto es lo que podéis esperar a continuación:

Restauración de los sitios de los clientes. Seguiremos trabajando directamente con los clientes afectados para restaurar sus sitios, comunicándonos con ellos mediante tickets de soporte y a través de nuestro equipo de atención al cliente. Estamos progresando en este sentido lo más rápido que podemos.
Actualizaciones diarias. Nos comprometemos a comunicar cualquier novedad a nuestros clientes afectados a través de sus tickets y de actualizaciones diarias en la página de estado.
Revisión posterior al incidente. Después de este incidente, llevaremos a cabo y publicaremos una revisión posterior al incidente con nuestros hallazgos y las medidas que tomaremos al respecto. Este informe será público.

Por último, quiero dirigirme directamente a vosotros, nuestros clientes: gracias por vuestra colaboración para llevar a cabo todos y cada uno de los pasos juntos. Sabemos que tenéis partes interesadas a las que responder dentro de vuestra organización y que nuestro fallo ha provocado interrupciones significativas de vuestro negocio. Mis equipos y yo nos comprometemos a restablecer el servicio para todos los clientes lo antes posible y a hacer todo lo posible para subsanar este perjuicio.

French (Français)

Informations sur la panne Atlassian affectant certains clients

Cette traduction n’est fournie que pour des raisons de commodité. En cas d’ambiguïté ou de conflit entre les traductions, l’original en anglais prévaut.

En date du 18 avril 2022, à 23 h 57 UTC, tous les sites client touchés par la panne ont été restaurés.

Lundi 4 avril 2022 (heures ouvrables dans la région Pacifique ou PT), environ 400 clients Atlassian Cloud ont connu une panne complète de leurs produits Atlassian. En date du 18 avril 2022, nous avons restauré les sites de nos clients touchés par la panne et contacté les interlocuteurs clés pour chaque site affecté.

Nos équipes de support travaillent avec les clients individuels pour répondre à tous les besoins spécifiques du site. Si vous avez besoin d’aide, veuillez répondre à votre ticket de support afin que nos ingénieurs puissent collaborer avec vous dans les plus brefs délais.

Pour être clairs, cet incident n’était pas une cyberattaque ni une défaillance de nos systèmes à grande échelle. De plus, la majorité des clients auprès desquels le service a été restauré n’a subi aucune perte de données, mais certains clients ont signalé une perte de données jusqu’à 5 minutes avant l’incident.

Permettez-moi tout d’abord de dire que cet incident et notre temps de réponse ne sont pas à la hauteur de nos attentes, et que je vous présente nos excuses au nom d’Atlassian. Nous savons que nos produits sont stratégiques pour vos équipes et que votre entreprise est affectée par l’indisponibilité de nos services. Nous travaillons 24 h/24 pour que nos clients reprennent leurs activités, et c’est notre priorité absolue.

Que s’est-il passé ?

L’une de nos apps autonomes pour Jira Service Management et Jira Software, appelée « Insight – Asset Management », a été entièrement intégrée à nos produits en tant que fonctionnalité native. Pour cette raison, nous avons dû désactiver l’app autonome héritée sur les sites client sur lesquels elle était installée. Nos équipes d’ingénierie avaient prévu d’utiliser un script existant pour désactiver les instances de cette app autonome. Cependant, deux problèmes critiques se sont posés :

Communication insuffisante. Tout d’abord, la communication entre l’équipe qui a demandé la désactivation et celle qui l’a exécutée était insuffisante. Au lieu de fournir les identifiants de l’app prévue pour désactivation, l’équipe a fourni les identifiants de l’ensemble du site cloud sur lequel les apps devaient être désactivées.
Script erroné. Deuxièmement, le script que nous avons utilisé fournissait à la fois la capacité « marquer pour suppression » utilisée dans les opérations quotidiennes normales (lorsqu’il est souhaitable de pouvoir effectuer une restauration) et la capacité « supprimer définitivement » requise pour supprimer définitivement des données lorsque cela est nécessaire pour des raisons de conformité. Le script a été exécuté dans un mode erroné et la mauvaise liste d’identifiants. Résultat : les sites d’environ 400 clients ont été supprimés par erreur.

Pour résoudre cet incident, notre équipe d’ingénierie mondiale a implémenté un processus méthodique afin de restaurer le service pour nos clients affectés.

Notre solution de récupération

Notre page La gestion des données chez Atlassian décrit en détail nos processus de gestion des données.

Pour garantir la haute disponibilité, nous provisionnons et tenons à jour une réplique de secours synchrone dans plusieurs zones de disponibilité (ZD) AWS. Le basculement entre les différentes ZD est automatisé et prend généralement de 60 à 120 secondes. Par ailleurs, nous gérons régulièrement des pannes de data center et d’autres interruptions courantes sans impact sur le client.

Nous tenons également à jour des sauvegardes immuables pensées pour résister aux corruptions de données, ce qui permet une récupération à un point antérieur. Les sauvegardes sont conservées pendant 30 jours, et Atlassian teste et audite en permanence les sauvegardes de stockage à des fins de restauration.

À l’aide de ces sauvegardes, nous annulons régulièrement les suppressions accidentelles de leurs propres données par des clients individuels ou un petit groupe de clients. Et, si nécessaire, nous pouvons restaurer les sites de tous les clients en même temps dans un nouvel environnement.

Cependant, nous n’avons pas (encore) automatisé la restauration pour un large sous-ensemble de clients dans notre environnement existant (et actuellement utilisé) sans affecter aucun de nos autres clients.

Au sein de notre environnement cloud, chaque magasin de données stocke des données de plusieurs clients. Étant donné que les données supprimées au cours de cet incident ne concernaient qu’une partie des magasins de données qui continuent d’être utilisés par d’autres clients, nous devons extraire et restaurer manuellement des parties individuelles de nos sauvegardes. La récupération de chaque site client est un processus long et complexe, qui nécessite une validation interne et une vérification finale du client au terme de l’opération.

Les étapes du processus

Notre approche initiale pour restaurer les sites client n’était que partiellement automatisée. Elle impliquait une série d’étapes complexes qui prenaient beaucoup de temps, en partie parce que nous devions valider manuellement les données client pour chaque site restauré.

Nous passons maintenant à un processus plus automatisé, expliqué ci-dessous :

Réactiver les métadonnées pour les sites supprimés dans notre système d’orchestration centralisé
Restaurer les données client extraites des sauvegardes, notamment les utilisateurs, les autorisations
Réactiver les apps de l’écosystème, les données de facturation et d’autres données qui ne sont pas directement associées aux données générées par les clients

Étant donné que plusieurs magasins de données doivent être extraits et récupérés pour chaque site, nous testons le site et travaillons en étroite collaboration avec chaque client afin de garantir l’exactitude de sa restauration.

Actuellement, nous restaurons les sites client par lots de 60 locataires maximum à la fois. D’un bout à l’autre de l’opération, la restauration d’un site client dure entre 4 et 5 jours. Nos équipes ont maintenant trouvé comment exécuter plusieurs lots en parallèle, ce qui a contribué à réduire notre temps de restauration global.

La restauration des sites client est notre priorité absolue

Nous savons que de tels incidents peuvent ébranler la confiance. Nous ne respectons pas les normes élevées que nous nous sommes fixées. Cela inclut nos efforts de communication qui, jusqu’à présent, étaient entièrement axés sur la communication directe avec nos clients affectés.

Cet incident reste la priorité absolue de mon équipe d’ingénierie et de l’ensemble de notre entreprise. Nous continuerons à travailler 24 h/24 jusqu’à ce que le site de chaque client soit restauré.

Voici les prochaines étapes auxquelles vous pouvez vous attendre :

Restauration des sites client. Nous continuerons à travailler directement avec les clients affectés pour restaurer leurs sites, en communiquant en direct via des tickets de support et par l’intermédiaire de notre équipe de support client. Nous nous efforçons de faire avancer les choses le plus rapidement possible.
Mises à jour quotidiennes. Nous nous engageons à fournir des mises à jour quotidiennes à nos clients affectés via leurs tickets et en alimentant chaque jour la page d’état.
Revue post-incident. À la suite de cet incident, nous effectuerons une revue post-incident et partagerons nos conclusions ainsi que les prochaines étapes. Ce rapport sera public.

Enfin, je souhaite remercier nos clients pour leur partenariat alors que nous traversons chacune de ces étapes ensemble. Nous savons que vous devez répondre à des parties prenantes au sein de votre organisation et que notre défaillance a entraîné des perturbations majeures pour votre entreprise. Mes équipes et moi-même nous engageons à rétablir le service pour chaque client le plus rapidement possible et à faire tout ce qui est en notre pouvoir pour vous aider.

Italian(Italiano)

Aggiornamento sull’interruzione di Atlassian che ha interessato alcuni clienti

Questa traduzione è fornita solo per comodità dell’utente. In caso di ambiguità o conflitto tra le traduzioni, prevale la versione originale in inglese.

A partire dalle 23:57 UTC del 18 aprile 2022, tutti i clienti interessati dall’interruzione sono stati ripristinati.

Lunedì 4 aprile 2022 (PT), circa 400 clienti Atlassian Cloud hanno subito un’interruzione completa dei loro prodotti Atlassian. A partire dal 18 aprile 2022, abbiamo ripristinato i clienti interessati dall’interruzione e abbiamo informato i contatti chiave per ogni sito interessato.

I nostri team di assistenza stanno lavorando con i singoli clienti per qualsiasi esigenza specifica del sito. Se hai bisogno di aiuto, rispondi al tuo ticket di assistenza in modo che i nostri ingegneri possano lavorare con te il prima possibile.

Per essere chiari, questo imprevisto non è stato causato da un attacco informatico né da un malfunzionamento della scalabilità dei nostri sistemi. Inoltre, la maggior parte dei clienti ripristinati non ha subito alcuna perdita di dati, mentre alcuni hanno segnalato una perdita di dati fino a 5 minuti prima dell’imprevisto.

Vorrei iniziare dicendo che questo imprevisto e il nostro tempo di risposta non sono all’altezza del nostro standard e mi scuso a nome di Atlassian. Sappiamo che i nostri prodotti sono fondamentali per i tuoi team e che la tua azienda subisce un impatto negativo quando i nostri servizi non sono disponibili. Stiamo lavorando 24 ore su 24 per far tornare operativi i nostri clienti e questa è la nostra priorità assoluta.

Cosa è successo

Una delle nostre app standalone per Jira Service Management e Jira Software, chiamata “Insight – Asset Management”, è stata integrata completamente nei nostri prodotti come funzionalità nativa. Per questo motivo, avevamo bisogno di disattivare l’app legacy standalone sui siti dei clienti su cui era installata. I nostri team di ingegneri hanno pianificato di utilizzare uno script esistente per disattivare le istanze di questa applicazione standalone. Tuttavia, sono emersi due problemi critici:

Mancanza di comunicazione. In primo luogo, c’è stata una mancanza di comunicazione tra il team che ha richiesto la disattivazione e il team che l’ha eseguita. Anziché fornire gli ID dell’app da contrassegnare per la disattivazione, il team ha fornito gli ID dell’intero sito cloud in cui le app dovevano essere disattivate.
Script difettoso. In secondo luogo, lo script che abbiamo utilizzato forniva sia l’opzione “contrassegna per l’eliminazione” utilizzata nelle normali operazioni quotidiane (dove è auspicabile la recuperabilità), sia l’opzione “elimina definitivamente” per rimuovere definitivamente i dati quando necessario per motivi di conformità. Lo script è stato eseguito con la modalità di esecuzione errata e l’elenco di ID errati. Il risultato è stato che i siti di circa 400 clienti sono stati eliminati in modo improprio.

Per risolvere l’imprevisto, il nostro team globale di ingegneri ha implementato un processo metodico per ripristinare i clienti interessati.

Cosa stiamo facendo per risolvere l’imprevisto

Atlassian Data Management descrive in dettaglio i nostri processi di gestione dei dati.

Per garantire un’elevata disponibilità, eseguiamo il provisioning e manteniamo una replica di standby sincrona in più zone di disponibilità (AZ) AWS. Il failover AZ è automatizzato e richiede in genere 60-120 secondi e gestiamo regolarmente le interruzioni nel data center e altre interruzioni comuni senza alcun impatto sui clienti.

Manteniamo anche backup immutabili progettati per resistere agli eventi di corruzione dei dati, che consentono il ripristino a un punto nel tempo precedente. I backup vengono conservati per 30 giorni e Atlassian testa e verifica continuamente i backup di archiviazione per il ripristino.

Utilizzando questi backup, eseguiamo regolarmente il rollback di singoli clienti o di un piccolo gruppo di clienti che eliminano per errore i propri dati. Inoltre, se necessario, possiamo ripristinare tutti i clienti contemporaneamente in un nuovo ambiente.

Ciò che non abbiamo (ancora) automatizzato è il ripristino di un ampio sottoinsieme di clienti nel nostro ambiente esistente (e attualmente in uso) senza avere un impatto su nessuno dei nostri altri clienti.

All’interno del nostro ambiente cloud, ogni archivio di dati contiene dati di più clienti. Poiché i dati eliminati in questo imprevisto costituivano solo una parte degli archivi di dati che continuano a essere utilizzati da altri clienti, dobbiamo estrarre e ripristinare manualmente i singoli dati dai nostri backup. Il ripristino di ogni sito dei clienti è un processo lungo e complesso, che richiede la convalida interna e la verifica finale del cliente quando il sito viene ripristinato.

Fasi del processo

Il nostro approccio iniziale al ripristino dei siti dei clienti era solo semi-automatico. Comprendeva una serie di passaggi complessi che richiedevano molto tempo, in parte perché dovevamo convalidare manualmente i dati dei clienti per ogni sito ripristinato.

Ora stiamo passando a un processo più automatizzato, che si articola come segue:

Riattivazione dei metadati per i siti eliminati nel nostro sistema di orchestrazione centralizzato
Ripristino dei dati dei clienti estratti dai backup, inclusi utenti, autorizzazioni, ecc.
Riattivazione delle app dell’ecosistema, dei dati di fatturazione e di altri dati non direttamente associati ai dati generati dai clienti

Poiché è necessario estrarre e recuperare più archivi di dati per ogni sito, testiamo il sito e lavoriamo a stretto contatto con ogni singolo cliente per garantire l’accuratezza del ripristino.

Attualmente, stiamo ripristinando i clienti in gruppi fino a 60 tenant alla volta. In totale, sono necessari da 4 a 5 giorni per restituire un sito a un cliente. I nostri team hanno ora sviluppato la capacità di eseguire più batch in parallelo, il che ha contribuito a ridurre i tempi di ripristino complessivi.

Ripristinare i clienti è la nostra priorità assoluta

Sappiamo che imprevisti come questo possono intaccare la tua fiducia nei nostri confronti. Non stiamo rispettando gli standard elevati che ci siamo prefissati. Ciò include i nostri sforzi di comunicazione, che fino ad ora erano interamente concentrati sul raggiungere direttamente i nostri clienti interessati.

Questo imprevisto rimane la priorità assoluta per il mio team di ingegneri e per tutta la nostra azienda. Continueremo a lavorare 24 ore su 24 finché non avremo ripristinato il sito di ogni singolo cliente.

Ecco cosa puoi aspettarti:

Ripristino dei siti dei clienti. Continueremo a lavorare direttamente con i clienti interessati per ripristinare i loro siti, comunicando attraverso i ticket di assistenza e tramite il nostro team di assistenza clienti. Ci stiamo muovendo il più velocemente possibile.
Aggiornamenti giornalieri. Ci impegniamo ad aggiornare quotidianamente i nostri clienti interessati attraverso i loro ticket e tramite aggiornamenti giornalieri della pagina di stato.
Revisione post-imprevisto. A seguito di questo imprevisto, condurremo e condivideremo una revisione post-imprevisto con i nostri risultati e le fasi successive. Questo report sarà pubblico.

Infine vogliamo ringraziare i nostri clienti per la collaborazione mentre affrontiamo ogni singolo passaggio insieme. Sappiamo che ci sono stakeholder a cui devi render conto all’interno della tua organizzazione e che il nostro fallimento ha provocato gravi interruzioni per la tua azienda. I miei team e io ci impegniamo a ripristinare il prima possibile il servizio per ogni cliente e a fare tutto ciò che serve per soddisfare le tue esigenze.

Korean (한국어)

일부 고객에게 피해를 드린 Atlassian 중단에 대한 업데이트

이 번역본은 편의를 위해서만 제공됩니다. 번역본 간에 모호성이나 충돌이 발생할 경우 원본 영어 버전이 우선합니다.

2022년 4월 18일 23:57(UTC) 기준으로, 서비스 중단으로 인해 영향을 받은 모든 고객 사이트가 복구되었습니다.

2022년 4월 4일 월요일(태평양 표준시), 약 400개의 Atlassian Cloud 고객 사이트가 Atlassian 제품 전체를 이용하지 못하는 완전한 서비스 중단을 경험했습니다. 2022년 4월 18일부로 서비스 중단의 피해를 입은 고객 사이트가 복구되었으며 피해를 입은 각 사이트의 주요 담당자는 곧바로 복구 소식을 전달 받았습니다.

Atlassian의 지원 팀은 사이트별 요구 사항에 따라 개별 고객과 협력하고 있습니다. 지원이 필요한 경우 엔지니어가 최대한 빨리 도와드릴 수 있도록 지원 티켓에 회신해 주세요.

명백히 해당 인시던트는 사이버 공격이 아니었고 우리의 시스템 확장 실패도 아니었습니다. 또한, 복구된 고객의 대다수는 데이터 손실을 경험하지 않았으며, 일부 고객은 인시던트 발생 전 최대 5분 동안 데이터 손실을 보고했습니다.

해당 인시던트와 응답 시간이 저희 표준에 미치지 못하는 것을 인지하고 있으며, Atlassian을 대신하여 사과드립니다.저희 제품은 귀하의 팀에 매우 중요하며, 저희 서비스를 이용할 수 없을 때 귀하의 비즈니스에 영향을 미친다는 사실을 잘 알고 있습니다. 저희는 고객 사이트의 복구를 최우선 과제로 삼으며 노력하고 있습니다.

인시던트 개요

“Insight — 자산 관리”라고 불리는 Jira Service Management 및 Jira Software Software용 독립 실행형 앱 중 하나가 기본 기능으로 제품에 완전히 통합되었습니다. 이로 인해 기존 앱을 설치한 고객 사이트에서 독립형 레거시 앱을 비활성화해야 했습니다. 저희 엔지니어링 팀은 기존 스크립트를 사용하여 이 독립 실행형 애플리케이션의 인스턴스를 비활성화할 계획이었습니다. 그러나 두 가지 중요한 문제가 발생했습니다:

커뮤니케이션 격차.첫째, 비활성화를 요청한 팀과 비활성화를 실행한 팀 간에 커뮤니케이션 격차가 있었습니다. 팀은 비활성화로 표시된 앱 ID를 제공하는 대신 앱을 비활성화할 전체 클라우드 사이트의 ID를 제공했습니다.
잘못된 스크립트.둘째, 저희가 사용한 스크립트는 일상적인 작업(복구가 필요한 경우)에 사용되는 “삭제 표시” 기능과 규정 준수를 위해 필요시 데이터를 영구적으로 제거하는 “영구 삭제” 기능을 모두 제공했습니다. 스크립트는 잘못된 실행 모드와 잘못된 ID 목록으로 실행되었습니다. 그 결과 약 400개의 고객 사이트가 예기치 않게 삭제되었습니다.

이 인시던트를 복구하기 위해, 글로벌 엔지니어링 피해를 입은 고객 사이트를 복구하기 위한 체계적인 프로세스를 실행했습니다.

복구를 위해 진행중인 일

Atlassian Data Management는 데이터 관리 프로세스에 대해 자세히 설명합니다.

고가용성을 보장하기 위해 여러 AWS 가용 영역(AZ)에 동기식 대기 복제본을 프로비저닝하고 유지 관리합니다. AZ 장애 조치는 자동화되며 일반적으로 60-120초가 소요됩니다. 저희는 고객에게 영향이 가지 않도록 Data Center 가동 중단 및 기타 일반적인 중단을 정기적으로 처리합니다.

또한 데이터 손상 이벤트에 대한 복구력을 갖도록 설계된 변경 불가능한 백업을 유지 관리하여 이전 시점으로 복구할 수 있습니다. 백업은 30일 동안 보관되며, Atlassian 복구를 위해 스토리지 백업을 지속적으로 테스트하고 감합니다.

백업을 이용하여, 개인 고객 사이트 또는 실수로 자신의 데이터를 삭제한 소수의 고객 사이트를 정기적으로 롤백합니다. 또한 필요한 경우 모든 고객 사이트를 새로운 환경으로 한 번에 복구할 수 있습니다.

아직 자동화하지 않은 것은 다른 고객 사이트에 영향을 미치지 않고 많은 고객 사이트를 기존(현재 사용 중인) 환경으로 복구하는 것입니다.

클라우드 환경 내에서 각 데이터 저장소에는 여러 고객 사이트의 데이터가 포함되어 있습니다. 이 인시던트에서 삭제된 데이터는 다른 고객이 계속 사용하는 데이터 저장소의 일부일 뿐이므로 백업에서 개별 조각을 수동으로 추출하고 복구해야 합니다. 각 고객 사이트 복구는 길고 복잡한 프로세스이므로 사이트 복구 시 내부 검증 및 최종 고객 확인이 필요합니다.

프로세스의 단계

고객 사이트를 복구하기 위한 초기 접근 방식은 단지 반자동이었습니다. 복구된 각 사이트의 고객 데이터를 수동으로 검증해야 했기 때문에 시간이 많이 걸리는 일련의 복잡한 단계가 포함되었습니다.

이제 다음과 같이 보다 자동화된 프로세스로 전환하고 있습니다.

중앙 집중식 오케스트레이션 시스템에서 삭제된 사이트에 대한 메타데이터 재활성화
사용자, 권한 등을 포함하여 백업에서 추출한 고객 데이터를 복구합니다.
에코시스템 앱, 청구 데이터 및 고객 생성 데이터와 직접 연관되지 않은 기타 데이터 재활성화

각 사이트에 대해 여러 데이터 저장소를 추출 및 복구해야 하므로 사이트를 테스트하고 각 개별 고객과 긴밀하게 협력하여 복구의 정확도를 보장합니다.

현재 한 번에 최대 60명의 테넌트를 일괄 처리하여 고객 사이트를 복구하고 있습니다. 엔드 투 엔드 방식으로 사이트를 고객 사이트로 다시 전달하는 데 4~5일이 소요됩니다. 우리 팀은 이제 여러 배치를 병렬로 실행할 수 있는 기능을 개발하여 전반적인 복구 시간을 단축하는 데 도움이 되었습니다.

고객 사이트의 복구가 최우선 과제입니다.

저희는 이와 같은 인시던트로 인해 신뢰도에 금이 갈 수 있다는 것을 알고 있습니다. 저희는 저희 스스로 설정한 높은 기준을 충족하지 못하고 있습니다. 여기에는 지금까지 피해를 입은 고객 사이트에 직접 도달하는 데 전적으로 집중했던 커뮤니케이션 노력이 포함됩니다.

이 인시던트는 엔지니어링 팀과 회사 전체의 최우선 과제로 남아 있습니다. 모든 고객의 사이트가 복구될 때까지 계속해서 작업할 것입니다.

앞으로 기대할 수 있는 사항은 다음과 같습니다.

고객 사이트 복구 저희는 계속해서 영향을 받는 고객과 직접 협력하여 사이트를 복구하고 지원 티켓과 고객 지원 팀을 활용하여 1:1 로 커뮤니케이션할 것입니다. 저희는 이 문제를 최대한 빨리 처리하고 있습니다.
매일 업데이트.저희는 티켓과 매일 상태 페이지 업데이트를 통하여 피해를 입은 고객에게 매일 업데이트를 제공하기 위해 최선을 다하고있습니다.
인시던트 사후 검토이 인시던트 이후, 저희는 조사 결과 및 다음 단계를 포함한 인시던트 사후 검토를 수행하고 공유할 것입니다. 이 보고서는 공개될 예정입니다.

마지막으로 고객분들께 모든 단계를 함께 탐색하는 파트너십을 발휘해 주신 데 대한 감사의 인사를 전합니다. 고객사 조직 내에 해명을 원하는 이해 관계자가 있으며, 저희의 실패로 인해 비즈니스에 큰 혼란이 발생했음을 알고 있습니다. 저와 저희 팀은 가능한 한 빨리 각 고객에 대한 서비스를 복구하고 이를 위해 최선을 다하고 있습니다.

Polish (Polski)

Aktualizacja dotycząca awarii Atlassian, która dotknęła niektórych klientów

Niniejsze tłumaczenie zostało udostępnione wyłącznie dla wygody. W przypadku jakichkolwiek niejasności lub konfliktów między tłumaczeniami pierwszeństwo ma oryginalna wersja angielska.

18 kwietnia 2022 r. o godzinie 23:57 czasu UTC przywrócono działanie produktów u wszystkich klientów, których dotyczyła awaria.

W poniedziałek 4 kwietnia 2022 r. czasu PT około 400 klientów Atlassian Cloud doświadczyło awarii wszystkich swoich produktów Atlassian. Na dzień 18 kwietnia 2022 r. działanie produktów u wszystkich klientów, których dotyczyła awaria, zostało przywrócone i nawiązaliśmy kontakt z kluczowymi osobami kontaktowymi każdej witryny, na którą to wydarzenie miało wpływ.

Nasze zespoły wsparcia współpracują z poszczególnymi klientami w zakresie wszelkich potrzeb związanych z konkretnymi witrynami. Jeśli potrzebujesz pomocy, odpowiedz na swoje zgłoszenie dotyczące wsparcia, aby nasi inżynierowie mogli jak najszybciej nawiązać z Tobą współpracę.

Celem wyjaśnienia, incydent ten nie był cyberatakiem ani nie wynikał z niedostatecznej skalowalności naszych systemów. Ponadto większość klientów, u których przywrócono działanie produktów, nie odnotowała utraty danych, choć niektórzy klienci zgłosili utratę danych z okresu do 5 minut poprzedzających incydent.

Na wstępie należy zaznaczyć, że ten incydent oraz czas naszej reakcji nie są zgodne z naszymi standardami, za co w imieniu firmy Atlassian przepraszam. Wiemy, że nasze produkty mają krytyczne znaczenie dla Twoich zespołów, a brak dostępu do naszych usług wpływa na funkcjonowanie Twojej firmy. Pracujemy przez całą dobę, aby umożliwić naszym klientom powrót do pracy, i stanowi to dla nas najwyższy priorytet.

Co się stało

Jedna z naszych samodzielnych aplikacji dla Jira Service Management i Jira Software o nazwie „Insight — Asset Management” została w pełni zintegrowana z naszymi produktami jako funkcja natywna. W związku z tym musieliśmy dezaktywować starszą, samodzielną wersję aplikacji w witrynach klientów, w których była ona zainstalowana. Nasze zespoły inżynierskie planowały użyć istniejącego skryptu do dezaktywacji instancji tej samodzielnej aplikacji. Wystąpiły jednak dwa krytyczne problemy:

Luka komunikacyjna. Po pierwsze, wystąpiła luka komunikacyjna między zespołem, który złożył wniosek o dezaktywację, a zespołem, który tę dezaktywację przeprowadził. Zamiast podania identyfikatorów wspomnianej aplikacji, która miała zostać dezaktywowana, zespół podał identyfikatory całej witryny Cloud, w której miały zostać dezaktywowane aplikacje.
Błędny skrypt. Po drugie, zastosowany przez nas skrypt zawierał zarówno funkcję „oznaczenia do usunięcia” stosowaną w standardowych codziennych operacjach (w których możliwość odzyskania jest pożądana), jak i funkcję „trwałego usunięcia” wymaganą do trwałego usuwania danych, gdy zachodzi taka potrzeba w związku z zachowaniem zgodności z przepisami. Zastosowano zatem skrypt, który zawierał niewłaściwy tryb wykonania i niepoprawną listę identyfikatorów. W rezultacie witryny około 400 klientów zostały błędnie usunięte.

W celu odzyskania sprawności po wystąpieniu tego incydentu nasz globalny zespół inżynierów wdrożył metodyczny proces przywracania działania produktów u naszych klientów.

Czynności podejmowane w celu odzyskania sprawności

Dokument Zarządzanie danymi w Atlassian zawiera szczegółowy opis naszych procesów zarządzania danymi.

W celu zapewnienia wysokiej dostępności aprowizujemy i utrzymujemy synchroniczną replikę rezerwową w wielu strefach dostępności (Availability Zone, AZ) AWS. Przełączenie awaryjne strefy AZ odbywa się automatycznie i zazwyczaj trwa 60–120 sekund, a my zwykle radzimy sobie z awariami centrów danych oraz innymi typowymi zakłóceniami w sposób nieodczuwalny dla klienta.

Przechowujemy również niezmienialne kopie zapasowe zaprojektowane w taki sposób, aby były odporne na zdarzenia uszkodzenia danych, umożliwiając przywrócenie do poprzedniego punktu w czasie. Kopie zapasowe są przechowywane przez 30 dni, a Atlassian stale testuje i kontroluje kopie zapasowe pamięci masowej pod kątem możliwości przywrócenia.

Korzystając z tych kopii zapasowych, regularnie przywracamy przypadkowo usunięte dane pojedynczych klientów lub małych grup klientów. W razie potrzeby jesteśmy w stanie przywrócić za jednym razem wszystkich klientów w nowym środowisku.

Tym, czego (jeszcze) nie zautomatyzowaliśmy, jest przywracanie dużego podzbioru klientów w naszym istniejącym (i aktualnie używanym) środowisku bez wpływu na innych naszych klientów.

W naszym środowisku chmurowym każdy magazyn danych zawiera dane pochodzące od wielu klientów. Dane usunięte w trakcie tego incydentu stanowiły jedynie część magazynów danych, z których inni klienci nadal korzystali, dlatego musieliśmy ręcznie wyodrębniać i przywracać poszczególne elementy z naszych kopii zapasowych. Przywracanie danych każdego klienta jest procesem długotrwałym i złożonym, wymagającym wewnętrznego sprawdzania poprawności i ostatecznej weryfikacji przez klienta po przywróceniu witryny.

Kroki w procesie

Nasze pierwotne podejście do przywracania witryn klientów było tylko częściowo zautomatyzowane. Obejmowało ono szereg złożonych kroków, których wykonanie było czasochłonne częściowo ze względu na to, że wymagały one od nas ręcznego sprawdzania poprawności danych klientów każdej przywracanej witryny.

Obecnie przechodzimy na bardziej zautomatyzowany proces obejmujący następujące kroki:

Ponowne włączenie metadanych dla usuniętych witryn w naszym scentralizowanym systemie orkiestracji.
Przywrócenie danych klientów wyodrębnionych z kopii zapasowych, w tym użytkowników, uprawnień itp.
Ponowne włączenie aplikacji ekosystemu, danych rozliczeniowych i innych danych niepowiązanych bezpośrednio z danymi wygenerowanymi przez klienta.

Każda witryna wymaga wyodrębnienia i przywrócenia wielu magazynów danych, dlatego testujemy witrynę i ściśle współpracujemy z poszczególnymi klientami, aby zapewnić dokładność przywróconych danych.

Obecnie przywracamy klientów partiami po maksymalnie 60 dzierżaw na raz. Cały proces przekazania witryny klientowi trwa od 4 do 5 dni. Nasze zespoły opracowały obecnie możliwość równoległego uruchamiania wielu partii, co pomogło skrócić całkowity czas przywracania.

Przywrócenie działania produktów klientów jest dla nas najważniejsze

Zdajemy sobie sprawę, że podobne incydenty mogą prowadzić do utraty zaufania. Nie spełniamy wysokich standardów, które sami sobie wyznaczyliśmy. Obejmuje to również nasze działania komunikacyjne, które do tej pory w całości koncentrowały się na bezpośrednim kontakcie z klientami, których dotyczył incydent.

Ten incydent wciąż ma najwyższy priorytet w moim zespole inżynierskim oraz w całej firmie. Będziemy kontynuować pracę przez całą dobę, aż do przywrócenia witryn wszystkich klientów.

Czego się spodziewać w następnej kolejności:

Przywracanie witryn klientów. Wciąż będziemy bezpośrednio współpracować z poszkodowanymi klientami w celu przywrócenia ich witryn, komunikując się indywidualnie za pośrednictwem zgłoszeń o wsparcie i naszego zespołu obsługi klienta. Postaramy się możliwie jak najszybciej zamknąć ten etap.
Codzienne aktualizacje. Zobowiązujemy się do codziennego przekazywania naszym poszkodowanym klientom aktualizacji za pośrednictwem ich zgłoszeń oraz codziennego zamieszczania aktualizacji na stronie stanu usług.
Przegląd po incydencie. Po incydencie przeprowadzimy przegląd i udostępnimy jego wyniki wraz z wnioskami i kolejnymi krokami. Ten raport będzie dostępny publicznie.

Na końcu pozwolę sobie zwrócić się do naszych klientów z podziękowaniem za partnerską współpracę i wspólne pokonywanie każdego kroku. Zdajemy sobie sprawę, że w Twojej organizacji są interesariusze, przed którymi odpowiadasz, a nasza awaria doprowadziła do poważnych zakłóceń w działalności Twojej firmy. Wraz z moimi zespołami dokładamy wszelkich starań, aby jak najszybciej przywrócić działanie usług wszystkim klientom, i podejmujemy wszelkie możliwe kroki w celu rozwiązania tego problemu.

Portuguese (Português)

Atualização sobre a interrupção da Atlassian que afeta alguns clientes

Esta tradução é disponibilizada apenas por conveniência. No caso de qualquer ambiguidade ou conflito entre as traduções, a versão original em inglês prevalece.

Em 18 de abril de 2022, 23:57 UTC, todos os sites de clientes afetados pela interrupção foram restaurados.

Na segunda-feira, 4 de abril de 2022 (PT), cerca de 400 clientes do Atlassian Cloud sofreram uma interrupção total em seus produtos da Atlassian. Desde 18 de abril de 2022, os sites dos clientes afetados pela interrupção estão restaurados e a gente está em comunicação com os principais contatos de cada site afetado.

As equipes de suporte da Atlassian estão trabalhando com clientes individuais para qualquer necessidade específica do site. Se precisar de ajuda, responda ao seu ticket de suporte para que os engenheiros possam trabalhar com você o mais rápido possível.

Para deixar claro, esse incidente não foi um ataque cibernético nem uma falha de escala dos sistemas da Atlassian. Além disso, a maioria dos clientes restaurados não teve perda de dados, enquanto alguns relataram perda de dados por até 5 minutos antes do incidente.

Deixe-me começar dizendo que esse incidente e o tempo de resposta não estão de acordo com o padrão e peço desculpas em nome da Atlassian.Sabemos que os produtos da Atlassian são essenciais para suas equipes e que seus negócios são afetados quando os serviços não estão disponíveis. Estamos trabalhando 24 horas por dia para colocar os clientes de volta em funcionamento e essa é a principal prioridade.

O que aconteceu

Um dos aplicativos independentes para o Jira Service Management e o Jira Software, chamado” Insight – Asset Management”, foi integrado por completo aos produtos como funcionalidade nativa. Por causa disso, precisávamos desativar o aplicativo legado autônomo nos sites dos clientes que o tinham instalado. As equipes de engenharia planejaram usar um script existente para desativar instâncias desse aplicativo independente. No entanto, dois problemas críticos se seguiram:

Falha de comunicação.Primeiro, havia uma falha de comunicação entre a equipe que solicitou a desativação e a equipe que executou a desativação. Em vez de oferecer os IDs do aplicativo pretendido marcado para desativação, a equipe disponibilizou os IDs de todo o site da nuvem em que os aplicativos deveriam ser desativados.
Script com falha.Segundo, o script que usamos disponibilizou o recurso “marca para exclusão” de exclusão usada nas operações diárias normais (onde a capacidade de recuperação é desejável) e “exclusão permanente ” que é necessário para remover dados para sempre quando necessário por motivos de conformidade. O script foi executado com o modo de execução errado e a lista errada de IDs. O resultado foi que os sites de por volta de 400 clientes tiveram exclusão indevida.

Para se recuperar desse incidente, a equipe global de engenharia implementou um processo metódico para solucionar o problema dos clientes afetados.

O que estamos fazendo para recuperar

O Atlassian Data Management descreve os processos de gerenciamento de dados em detalhes.

Para garantir a alta disponibilidade, providenciamos e mantemos uma réplica síncrona em espera em várias Zonas de Disponibilidade (AZs). O failover para AZ é automatizado e, via de regra, leva de 60 a 120 segundos, e lidamos com regularidade com paralisações do data center e outras interrupções comuns sem impacto para o cliente.

Também mantemos backups imutáveis que são projetados para serem resilientes contra eventos de corrupção de dados, o que permite a recuperação para um ponto anterior no tempo. Os backups são mantidos por 30 dias, e a Atlassian testa e audita sempre os backups de armazenamento para restauração.

Usando esses backups, revertemos com regularidade clientes individuais ou um pequeno conjunto de clientes que excluem seus próprios dados por acidentes. E, se necessário, podemos restaurar todos os clientes de uma só vez em um novo ambiente.

O que ainda não automatizamos (ainda) é restaurar um grande subconjunto de clientes no ambiente existente (e em uso atual) sem afetar nenhum dos outros clientes.

No ambiente na nuvem, cada armazenamento de dados contém dados de vários clientes. Como os dados excluídos neste incidente eram apenas uma parte dos armazenamentos de dados que continuam sendo usados por outros clientes, precisamos fazer a extração e restauração manual de partes individuais dos backups. Cada recuperação do local do cliente é um processo demorado e complexo, exigindo validação interna e verificação final do cliente quando o local é restaurado.

Etapas do processo

A abordagem inicial para restaurar os locais dos clientes foi apenas semiautomatizada. Envolveu uma série de etapas complexas que eram demoradas, em parte porque exigia a validação manual dos dados do cliente para cada local que foi restaurado.

Agora estamos mudando para um processo mais automatizado, da seguinte forma:

Reative metadados para sites excluídos no sistema de orquestração centralizado
Restaure os dados do cliente extraídos dos backups, incluindo usuários, permissões etc.
Reative aplicativos do ecossistema, dados de faturamento e outros dados não associados direto aos dados gerados pelo cliente

Como vários armazenamentos de dados devem ser extraídos e recuperados para cada site, testamos o site e trabalhamos em estreita colaboração com cada cliente individual para garantir a precisão de sua restauração.

No momento, estamos restaurando os sistemas dos clientes em lotes de até 60 inquilinos por vez. De ponta a ponta, leva entre 4 e 5 dias decorridos para entregar um site de volta a um cliente. Agora, as equipes desenvolveram a capacidade de executar vários lotes em paralelo, o que ajudou a reduzir o tempo geral de restauração.

Restaurar os sites dos clientes é a principal prioridade da Atlassian

Sabemos que incidentes como esse podem balançar a confiança. Não estamos atendendo aos altos padrões que estabelecemos para a gente mesmo. Isso inclui os esforços de comunicação, que até agora estavam focados por inteiro em alcançar os clientes afetados.

Esse incidente continua sendo a principal prioridade para minha equipe de engenharia e para toda a empresa. Vamos continuar trabalhando 24 horas por dia até que o site de cada cliente seja restaurado.

Veja o que você pode esperar a seguir:

Restaurar os sites dos clientes. Vamos continuar a trabalhar direto com os clientes afetados para restaurar seus sites, comunicando cada um por meio de suporte a chamados e por meio da equipe de suporte ao cliente. Vamos superar essa situação o mais rápido possível.
Atualizações diárias. Atualizações diárias. Estamos comprometidos com atualizações diárias para os clientes afetados por meio de seus chamados – e por meio de atualizações diárias na página de status.
Análises pós-incidentes.Após esse incidente, vamos conduzir e compartilhar uma revisão pós-incidente com as descobertas e próximas etapas. Este relatório vai ser público.

Para os clientes: Obrigado por sua parceria enquanto navegamos em cada etapa juntos. Sabemos que você tem partes interessadas para responder dentro de sua empresa e que o fracasso por nossa parte resultou em grandes interrupções em seus negócios. Minhas equipes e eu estamos comprometidos em restaurar o serviço para cada cliente o mais rápido possível e fazer o possível para fazer isso certo para você.

Russian (русский)

Информация о сбое в обслуживании со стороны Atlassian, затрагивающем некоторых клиентов

Данный перевод предоставлен исключительно для удобства. В случае любых неопределенностей или противоречий между переводами английская версия имеет преимущественную силу.

По состоянию на 18 апреля 2022 года, 23:57 UTC, восстановлено обслуживание всех клиентов, пострадавших от сбоя.

В понедельник, 4 апреля 2022 года по тихоокеанскому времени, примерно 400 клиентов Atlassian Cloud столкнулись с полным отказом своих продуктов Atlassian. По состоянию на 18 апреля 2022 года мы восстановили обслуживание клиентов, пострадавших от сбоя, и связались с основными контактными лицами для каждого пострадавшего сайта.

Наши команды поддержки работают отдельно с каждым клиентом в соответствии с конкретными требованиями для его сайта. Если вам требуется помощь, ответьте на заявку, которую вы отправляли в службу поддержки, чтобы наши специалисты могли как можно скорее начать работу с вами.

Следует уточнить, что этот инцидент не был кибератакой или сбоем во время масштабирования систем. Кроме того, после восстановления большинство клиентов не потеряли данные, хотя некоторые сообщили о потере данных, охватывающей период за 5 минут до инцидента.

Начну с того, что этот инцидент и время реакции на него не соответствуют нашим стандартам, и я приношу извинения от лица компании Atlassian. Мы знаем, что наши продукты критически важны для ваших команд и недоступность служб отрицательно сказывается на вашем бизнесе. Мы работаем круглые сутки, чтобы решить главную задачу — восстановить обслуживание клиентов.

Что случилось

Одно из наших отдельных приложений для Jira Service Management и Jira Software под названием Insight — Asset Management было полностью интегрировано в наши продукты в виде встроенной функциональности. В связи с этим нам требовалось деактивировать отдельное устаревшее приложение на тех сайтах клиентов, где оно было установлено. Наши команды инженеров планировали использовать существующий скрипт для деактивации экземпляров этого отдельного приложения. Однако возникли две критические проблемы:

Отсутствие взаимопонимания. Во-первых, между командой, которая запрашивала деактивацию, и командой, которая ее проводила, возникло недопонимание. Вместо того чтобы предоставить идентификаторы деактивируемого приложения, команда предоставила идентификаторы всего облачного сайта, на котором необходимо было деактивировать приложения.
Некорректный скрипт. Во-вторых, используемый скрипт предоставлял возможность работы в двух режимах: «пометить для удаления» (используется в обычных повседневных операциях, где желательно иметь возможность восстановления) или «удалить безвозвратно» (требуется для окончательного удаления данных, когда это необходимо для соответствия нормативным требованиям). Скрипт был запущен в неправильном режиме со списком неверных идентификаторов. В результате сайты примерно 400 клиентов оказались ошибочно удалены.

Для восстановления данных клиентов, пострадавших вследствие этого инцидента, наша глобальная команда инженеров разработала методический процесс.

Что мы делаем для восстановления

В статье Управление данными в Atlassian подробно описаны процессы управления данными.

Для обеспечения высокой доступности мы предоставляем и поддерживаем синхронную резервную репликацию в нескольких зонах доступности AWS. Аварийное переключение между зонами доступности выполняется автоматически и обычно занимает 60–120 секунд. Мы регулярно устраняем перебои в работе центров обработки данных и другие распространенные нарушения без последствий для клиентов.

Кроме того, мы поддерживаем неизменяемые резервные копии, которые обеспечивают устойчивость к событиям, вызывающим повреждение данных. Это позволяет восстанавливать данные на предыдущий момент времени. Резервные копии хранятся в течение 30 дней, и Atlassian постоянно тестирует и проверяет возможность восстановления резервных копий из хранилища.

С помощью этих резервных копий мы регулярно выполняем возврат к предыдущей версии для отдельных клиентов или небольших групп клиентов, случайно удаливших собственные данные. При необходимости мы можем одновременно восстановить данные всех клиентов в новой среде.

Процесс, который мы (пока) не автоматизировали, — это восстановление данных большого количества клиентов в существующей (и используемой в настоящее время) среде без влияния на других клиентов.

В нашей облачной среде в каждом хранилище данных находятся данные множества клиентов. Поскольку данные, удаленные во время этого инцидента, составляют лишь часть данных в хранилищах, которыми продолжают пользоваться другие клиенты, нам приходится вручную извлекать и восстанавливать отдельные фрагменты из резервных копий. Восстановление сайта каждого клиента — это длительный и сложный процесс, требующий внутренней проверки, а затем окончательной проверки со стороны клиента.

Этапы процесса

Изначально мы вели восстановление сайтов клиентов полуавтоматизированным методом. Для этого требовался ряд сложных шагов, которые отнимали много времени, отчасти потому, что нам приходилось вручную проверять клиентские данные по каждому восстановленному сайту.

Теперь мы перешли к более автоматизированному процессу, который состоит из следующих этапов:

Повторное включение метаданных для удаленных сайтов в централизованной системе оркестрации.
Восстановление данных клиентов из резервных копий, в том числе пользователей, прав и т. д.
Повторное включение приложений экосистемы, платежной информации и других данных, не связанных напрямую с теми, которые создают сами клиенты.

Поскольку для каждого сайта необходимо извлечь и восстановить множество хранилищ данных, мы тестируем сайт и тесно сотрудничаем с каждым клиентом, чтобы обеспечить точность восстановления.

В настоящее время мы восстанавливаем данные клиентов партиями до 60 держателей одновременно. На полный возврат сайта клиенту уходит от 4 до 5 дней. Наши команды разработали возможность параллельного запуска множества партий, что помогло сократить общее время восстановления.

Наша основная задача — восстановление обслуживания клиентов

Мы понимаем, что подобные инциденты могут подорвать доверие. Мы не соответствуем тем высоким стандартам, которые установили сами для себя. Это касается и наших действий по информированию, которые до сих пор были направлены исключительно на непосредственное оповещение пострадавших клиентов.

Этот инцидент остается приоритетом моей команды инженеров и всей компании. Мы продолжим круглосуточную работу, пока сайт каждого клиента не будет восстановлен.

Далее вы можете ожидать от нас следующих действий.

Восстановление сайтов клиентов. Мы продолжим работу непосредственно над восстановлением сайтов пострадавших клиентов и будем поддерживать связь с ними напрямую с помощью заявок в службу поддержки и через нашу команду поддержки клиентов. Мы стараемся выполнить эту задачу в максимально сжатые сроки.
Ежедневное информирование. Мы обязуемся ежедневно информировать затронутых клиентов через их заявки и ежедневные обновления нашей страницы статуса.
Обзор результатов реакции на инцидент. По итогам этого инцидента мы проведем обзор результатов реакции и поделимся своими выводами и планами. Этот отчет будет публичным.

Напоследок мы хотели бы поблагодарить своих клиентов за сотрудничество на каждом этапе. Мы понимаем, что вы несете ответственность перед заинтересованными лицами и сбой с нашей стороны серьезно подорвал работу вашего бизнеса. Я и мои команды стремимся как можно скорее восстановить обслуживание каждого клиента и исправить нанесенный ущерб.