2016-2017年のサービス障害を振り返る

memo

最近全然ブログとか書けてないなーと思いつつ 2018 年を迎えてしまいました。本年もよろしくお願いいたします。

以前、DC/クラウド/通信事業者サービスの障害事例よせあつめ という記事を書いたところ意外と反響があったので、続きを書こうかなと年末考えていたのですが、結局 2017 年中は書けませんでしたね。いろいろあったんですよ。個人的な話なんで別にどうでもいいんですけど。そんなわけで年明けに書きます。

この記事は 2016 年アタマの GMO の障害とか github のサービス障害をきっかけに書いたものでした。その後、世の中的にはどんなサービス障害が起きているのかをざっとおさらいしてみたいと思います。いまシステムやサービスを作っていく中で、こういう原因で死ぬのか…というのを見ていくことは、ひいては「そこまで予見できなかった」あるいは「そこからは回復させられなかった」ってことを考えることなんですよね。落ちた = ダメじゃん、という話でおわるのはなくて、ここまでやられて初めて落ちるんか…とか、こういう可能性まで見込んで何か考えないとイカンのか…とか、こういう状況でもうまく逃げ切るための方法って何なのか…とか、発展的な話を考えるための材料だと思っていただければ。

挙げる事例については私がウォッチして見つけているものなので当然偏りがあります。その点はご承知おきください。他にもこういう事例があるよってのがあったら是非教えていただきたく。

参考資料

ニュースソース

ツイッターとかでも拾っていますがこの辺を見ることが多いですね。いろいろ時事ネタや速報だしてくれています。ありがたや。

参考記事

2016年の事例

2017年の事例

おわりに

個人的な所感としてはこんな感じです。

  • 相変わらず DC 設備系のトラブルはおきる : 停電・ケーブル切断などファシリティ・設備レベルの話はやっぱりゼロにはならない。
  • パブリッククラウド・クラウド上のサービス(XaaS)ではソフトウェアで自動化されることによって障害が増幅される : 自動化してレバレッジをかける……一度に大量のサーバを操作したり処理を実行できる。ただ、これは誤った手順・オペミスのリスクを拡大する方向にも働く。実行するツールの選択ミス・パラメタ設定ミスなどをどう防ぐか → オペレーションの妥当性・正当性をどう保証するか、というのは課題になるだろう。それと大規模にやらかしたときにどうやって復旧するか、という話。両面での対策検討が必要になると思われる。
    • 複数のサイト(リージョン)やサービスをまたがるような障害にどう対処するか?
  • ネットワークエンジニア的には、この 1-2 年は BGP 操作による大規模障害が目立つのが気になるところ。とはいえこれ、upstream でやられちゃうと、エッジにいる側からはなかなか対処ができないんだよな。せめて問題検知や切り分け・状態の把握を早期にやれるようにするくらいか?