Slack、全ユーザーが接続できなくなった大規模障害の原因はバッチ処理にバグがあったためと報告

チャットサービスを提供するSlackは、太平洋夏時間の6月27日午前6時30分（日本時間6月27日午後10時30分）頃から約3時間、全てのユーザーでSlackが利用できなくなる深刻な障害に見舞われました。

同社はその後、障害についての報告をステータスページに掲載。障害の原因が、データのバッチ処理に含まれていたバグであったことを明らかにしました。

同社の報告の一部を引用します。

On June 27th (yesterday) between 6:33 a.m. and 9:49 a.m. PDT Slack experienced an outage where people could not connect to their workspaces. The network problems were caused by a bug included in an offline batch process of data, which resulted in unexpected network spikes and led all of our customers to become disconnected and unable to reconnect.

6月27日（昨日）の太平洋夏時間午前6時33分から午前9時49分のあいだ、Slackにおいてユーザーがワークスペースに接続できなくなる障害が発生しました。これはネットワーク障害がオフラインバッチによるデータ処理に含まれていたバグによって起こったもので、予期せぬネットワークのスパイクが発生し、それが全ユーザーへの接続断と再接続障害の原因となりました。

オフラインバッチ処理がどのようなものかは説明されていません。定期的なバックアップあるいはデータ分析に伴う前処理かなにかだったのでしょうか。

半年前にも数時間にわたる大規模障害

Slackは、約半年前の2017年11月にも全ユーザーが2時間以上Slackに接続できなくなる大規模障害が発生しています。

• Slack、11月1日に発生した大規模障害の原因は、定期デプロイによるソフトウェア障害が原因 － Publickey

このときは定期デプロイによってサーバにデプロイされたソフトウェアに含まれていたバグが原因で障害が発生し、復旧のために急きょハードウェアの増強を行ったことが報告されています。

前回も今回も共通しているのは、何らかのソフトウェアのバグが原因であることと、その影響が全ユーザーに影響する深刻な障害に結びついていることです。

Slackはちょうど先週、日本への本格展開を宣言したばかりのタイミング。障害の発生を完全に防ぐことはできないにしても、できるだけ局所的に押さえ込むような仕組みにしてほしいところです（と書くのは簡単でも、実現するのは容易ではないと思いますが）。

• Slackが日本でローンチイベント開催、本格展開スタート。日本法人の増員、国内サービスとの連携拡充、コミュニティの支援を約束 － Publickey