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

2018年7月2日

チャットサービスを提供する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の大規模障害

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

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

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

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

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

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

Tags: 業務アプリケーション Slack

このエントリーをはてなブックマークに追加
ツイート
follow us in feedly




タグクラウド(β版)

クラウド / AWS / Azure / Google Cloud
コンテナ / Docker / Kubernetes
クラウドネイティブ / サーバレス
クラウド障害 / 運用・監視

プログラミング言語 / 開発ツール
JavaScript / Java / .NET / WebAssembly
HTML/CSS / Web標準

アジャイル開発 / スクラム / DevOps / CI/CD
ソフトウェアテスト・品質
ローコード/ノーコード開発

データベース / RDB / NoSQL / 機械学習・AI
Oracle Database / MySQL / PostgreSQL
Office / 業務アプリケーション

ネットワーク / HTTP / QUIC / セキュリティ
OS / Windows / Linux / VMware
ハードウェア / サーバ / ストレージ

業界動向 / 働き方 / 給与・年収
編集後記 / 殿堂入り / おもしろ

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本