障害の原因と種類
こんにちは、ninjinkunです。
今朝の近藤さんの声日記でもあがっていた通り、
昨日、リッスンで障害が起こって、
その障害対応を近藤さんと自分と純木さんの3人でやって、
何とか復旧したということがありました。
なので、今日はいい機会なので、
障害対応について、エンジニアの立場から話せることを話してみようかなと思うんですけど、
まず前提として、障害っていろんなことで起こるんですけど、
バグの場合もあるし、プログラマーがミスをして、
バグを押し込んでしまって、それで起こる場合もあるし、
何もしてなくても、例えばBotとか、
最近だとAIのデータを求めてやってくるBotやら、
昔からいる検索のデータを求めてやってくるBotやらが大量アクセスをしてくるとか、
あとは単純に愉快犯的なので大量アクセスをしてくるBotもあるし、
もしくはアクセスしてサイトを落とすことで何らかの脆弱性をついてきたり、
健全的な利益を狙ってくるそういう輩もいると、
もしくはハッキングですよね。
いろんな理由があってサイトにはアクセスが集まったりするんで、
障害というのは割といろんな確率で起こりますと。
障害対応の過程
僕の本業のケースだと、ユーザーさんが想定以上のデータを送ってきて落ちるとかあります。
何にせよ想定外のことが起こった場合に大体落ちるんですけど、
今回の場合は依存している外部のサービスの仕様変更で起こったという、
割とレアなケースかもしれないですね。
でもなくはない感じです。
有名なところでいうと、よくいろんなサービスを扱っているAWSというAmazon Web Serviceという、
いろんなサーバーを貸し出してくれるサービスが大元が落ちることが稀にあり、
そうするといろんなサービスが根っこ付き全部落ちるということになって、
これはもう割とどうしようもないという感じですね。
なのでクラウドサービスというのも割と時々落ちます。
そういう場合にクラウドサービスが落ちちゃうとはどうしようもないんですけど、
そのバグキーとかアクセスキーの場合はエンジニアが慌てて対応するという感じでありますね。
ある程度、そういう検知の仕組みがあると、
すごいエラーが出まくってますっていうアラートが上がって、
それでそこからエンジニアに連絡が自動的に行くような仕組みもありますし、
場合によっては電話がかかって寝てるところだけ起こされると、
そういうふうにシステムを組んでいるところもあります。
そこから障害対応が始まるんですけど、
まず私障害対応ってあんまり得意じゃないというか、
正直役に立たないことが多くて、
何でかっていうと、自分の専門性がユーザーインターフェースとかフロントエンドっていうユーザーさんに触れる部分に割と偏っていて、
障害が起こる本丸であるサーバーの中の方、
特に高負荷で障害が起こる場合はサーバーの中のデータ構造であったりとか、
あとはサーバーのリソース自体が食い潰されて死ぬとかね、
そういうことが多いんで、
私は普段サーバーに直接触るってことはほとんどないので、
なので正直ですね、みんながインシデントだって言って集まったときに、
割と見てるだけってことが多いんですよね。
対処の方法がわからないんですよね、そういうときはね。
当たりがつく場合もあるんですけど、
サーバーへの入り方がわからないとか、
ログの見方が普段から見てないからわからないとか、
そういう感じで役に立たないことが多く、
割といろんな場合で、一応仮設では見るけど、
例えば初期のようなことをしたりとか、
他のチームへのお知らせに回ったり、
そういうサポートに回ることは自分の職能柄は多いですね。
外部サービスの影響
これは結構悔しくて、やっぱりですね、
カジとケンカは江戸の花じゃないですけど、
障害対応をしている人はヒーローになりやすいんですよね。
やっぱりそういう場合に頼りになる人は人望を集めやすいんで、
端的に言うとかっこいいんですよね。
消防士さんが尊敬を集めるように、障害対応が上手い人は尊敬を集めるという傾向がありますので、
自分もかっこいいなと思いつつ、ぐぬぬと保存を噛むことが多い感じではありますね。
昨日のケースだとたまたまサーバーサイドではなくて、
外部の依存しているオブジェクトストレージというファイルを保存してくれるところが、
エラーを返すように仕様変更をしていて、
自分がその辺りを捨てることができたっていうのは一つ解決の基になったんで、
これに関しては我ながらグッジョブだなと思うんですけど、
これはどっちかというと普通のデバッグの範疇で、
どこにエラーがありそうかっていうのを探り当てる作業にプログラマーは就職してますんで、
要するに機能法ですよね。
ここがダメだったら次はここだろうっていう風にして当たりをつけていくと。
機能ケースでいうと画像と音声ファイルは両方上がらないと。
これは本来は別々の機能のはずだけど、
同時に止まったってことはアップロードの機構自体に問題があるか、
アップロード先に問題があるっていう風に考えられると。
あとコードは一通り調べたんでコードには問題がなさそうだとなると、
そういう風に絞られてきていって、
じゃあオブジェクトストレージ怪しいかもなと思って、
でも障害の情報はないよと。
じゃあと思って一応さくらインターネットっていう依存してる、
依存してるというか使ってるサービスの更新履歴を追っていったら、
オブジェクトストレージ、そして4月17日昨日のちょうどその時の日付なんだと思って見に行ったら、
そこに原因が書かれていたと。
それをチームにシェアして樹木さんが直してくれて、
パスを送ってゴールするみたいなことで直って、
最後は近藤さんがデプロイして終わったという感じのプレイができたんですけど、
自分としてはデバッグ技術を使って直したという感じですかね。
割とラッキーだったとは思いますが、自分で自分を褒めたいと思います。
よくやった。
そういう感じで障害対応はその時はあったんですけど、
こういう感じで、これはたまたま外部サービスキーですけど、
高負荷の場合とかはさっきも言ったように自分はあんまり役に立たずに見てるだけなんで、
もうちょっとそういうスキルを、
普段はサーバーサイドをタッチすることがないと慣れてないもんで、
どうしても慣れてる人に任せてしまうっていうね、
変なところを壊しちゃっても良くないからとか、
遠慮してると何もできなくなってくるんで、
そこは自分でもそっちの方向にスキルを伸ばしてこなかったけど、
そのせいで今手も足も出なくなってるんだよなっていうね、
そういうジレンマがあったりしますね。
結構ね、こういうのね、偉い人が障害対応うまいケースが結構あって、
やっぱりキャリアがあって、しかも昔からサービスを作ってる人たちって、
その低いレイヤーのことをね、
例えばサーバーの中の実装とかコンピューターの深い部分とかをよく知ってるんで、
こういう場合ですね、
よく映画であるベテラン兵が出てきて、
お前たちこんなことも知らんのかみたいな感じでアナログのケーキを動かすみたいなね、
ああいう感じでそういう非常に低レイヤーな部分を直していったりして、
新人たちはさすがっすみたいな感じに守るみたいな、
そういうこともあったりして、
自分が働いてきた、例えばCTOって呼ばれるクラスの人たちも結構そういうのがね、
とても上手だったりして、
いや、僕こういうのできないから多分CTOとかになれるんだろうなみたいな、
特になるつもりないんですけど、
障害対応のチームワーク
別にCTOの仕事は障害対応じゃないんですけど、経営者なんで、
でもね、それが一つ現場のエンジニアの尊敬を集める、
信頼を集める一つの手段にはなり得ると思うんで、
自分にはそういう武器がないなって思いますね。
あとね、近藤さんがチームで対応できてよかったっていうことを言っていて、
まさにね、障害対応ってのはチーム対応が肝になると思ってまして、
それはやっぱり一人でやってると本当に焦るんですよね。
やっぱりその裏に困っているユーザーさんがいるってことは、
エンジニアはとてもよく知ってますんで、
直さないとどんどん迷惑をかける人が増えるんで、
場合によってはもしかしたらもっと、
例えば人命に関わるところまでは我々の仕事はなかなか普段は関係ないんですけど、
そういうことも起こり得る仕事ももちろんあるので、
となると一刻も早く直さなくちゃいけないけど、
例えばそれをユーザーさんに告知する必要もあるし、
他にもいろんなところに気を配っていく必要があるけど、
とても焦る状態になるっていうことで、
そもそも問題の特定自体が非常にとても注意深くやらなくちゃいけないし、
時間がかかることですけど、
そこに対してプレッシャーがすごいのしかかると、
それだけで認知能力っていうのはすごい下がってしまうので、
そういうときにチームで役割分担をして、
そしてこの人は第一線で調査する人、
この人は他の人に連絡する人、
この人はユーザーさんに告知を書く人みたいな感じで分担できるっていうのが、
結構障害対応の肝かなと思いますね。
確かこれプラクティスがあるんですよね。
自分はちょっとこの辺疎いんでウロウロですけど、
ドライバーとそれをノートを取り続けたり調べたりする人みたいに分けるみたいなね。
人で分けるみたいな。
もう一人何点だったかな。
何か多分ね、これもっと詳しい人がいるんですけど、
インフラに近い人とか。
そういうふうにしてね、
とにかく人を焦らせないようにするっていうのが、
一つ肝なんじゃないかなと思いますね。
あとはもっと世界中にチームがいると、
オンコール対応っていって、
この時間はこの人が何か起こったら仮説出ますっていうふうに決めておいて、
その時間はその人が叩き起こされると。
それが例えばタイムゾーンが分かれているチームがあったら、
この時間は起きているこのチームが対応して、
そのチームが対応しきれなかったら、
次のタイムゾーンのチームに渡すみたいなことをして、
24時間で体制で保守をしているっていう、
そういう体制を組んでいる会社もあると聞きますね。
Googleとかいろいろそういうことをしていると思うんですけど、
そういう感じでいろいろなレイヤーで障害対応が行われていますね。
なので障害対応というのは一種のアートなんですよね、
エンジニアリングの世界では。
ソフトウェアエンジニングとかウェブアプリケーションの世界ではっていうことですね。
なのでもちろん迷惑がかかっている人いっぱいいるんで、
そういうものをアートと呼んでいいかわからないですけど、
少なくともエンジニアの内輪では、
そういういろいろヒーローが生まれたり、
後から華々しく語られたりする、
そういう一つの大きなトピックではあるというのは事実だと思いますね。
障害対応で言うと私が思い出すのは、
Twitterの役割と進化
例えば311の時にTwitter、今Xになってだいぶアレな感じになっちゃってますけど、
当時のTwitterがかなり被災地の人たちの情報の共有に役に立った、
デマとかもいっぱい流れたんで、
全部が全部良かった良かったではないんですけど、
少なくとも電話が通じない環境でやり取りをする時に、
微小なデータ通信でもやり取りができるTwitterがとても役に立って、
その時にTwitterって構造的にとても落ちやすくてですね、
当時はまだかなりの交付がかかると、
まだバルスとかで落ちてた時代の終わりぐらいじゃないかな。
ちょうどたぶん彼らが必死でそのアーキテクチャを見直してた時代だったと思う、
たぶん自分の理解ではそう、2011ぐらいだと。
2012ぐらいから劇的に良くなった記憶があるんですけど、
昔は鯨とかが出てて、そのエラーページですね、出てたんですけど、
確か31の時はそういうふうに使われてるっていうのをTwitterの仲の人たちも知ってて、
必死でそれを落とさないように報酬してくれたっていうのを確か聞いたことがあって、
Twitterの本社に当時は日本出身の人もいたんで、私も個人的に知ってる人なんですけど、
そういう人たちが頑張ってくれたっていう事実を知ってますんで、
そういう保守とか障害対応というのは時に人の人命を救うこともあるし、非常に重要な仕事だと思いますんで、
私はさっきも言った通り関わることは少ないんですけど、
こういう裏側で活躍してる人たちがいるよってことは、システムを使ってる人に時々伝えていきたいなと思いますね。
という感じで結構お喋っちゃいましたね。
今日は障害対応についてお話ししました。
ありがとうございました。
