無気力生活 (ノ ´ω`)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

突発的な障害対応のいろは

皆様、夜分遅くいかほどお過ごしでしょうか。
株主優待が届き始めるシーズンですね。私めのところにも商品券がいくつか届き始めるので、この時期だけ外食が豪華になったりします。 はい、完全に余談ですね_(:3」∠)_



さて、はてブを巡回している時に、障害対応について書いている記事が上がってきていたので、私めのやっている障害対応方法について書いてみたいと思います。

「いろは」とかいいつつ、早速他人頼りになってしまうのですが、

qiita.com

うん、自分が基本的にやっていることもこれと非常に近しいですね。若干の違いはあるので、以下後述していきます。

なにはともあれ、まずは報告です

障害対応で真っ先にやる必要があるのが、「すでに着手しているよアピール」です。
焦っているので割と忘れられがちですが、チームとして何かサービスを運用している場合、エンジニアだけの話では収まりません。サービスの責任者や、実際にユーザーと向き合っている問い合わせ担当といった、後で障害のケツを拭くメンバーがいるわけですね。彼らにとっても自分の仕事に直結するため、実際に着手されているかわからないと不安ですよね。

なので、まずやることは障害発生の報告です。この時点ではまだ何もわかってないので、「障害が発生している模様。調査中」みたいな感じで簡潔に伝えます。

最近だとslack使っているところ多いと思うので、障害用のチャンネル作っておいてそこで連絡すると良いです。窓口が一元化されているとすごく便利(障害のこと書いていい場所があると、気づいた他の人が報告してくれる副次的なメリットも大きいです)

サービスメンテナンスの判断

常に実施するか微妙なケースもあるので、あえてこちらを最初のタスクには書きませんでしたが、例えば。「サービスが全然応答しない」、「決済に不都合が生じている」みたいな重大な事象においては、報告と同時にサービスメンテナンス入れてください。

メンテナンスには、問題あるサービスを使わせないことに加え、「ユーザーに問題が起きている」ことを伝える意味があります。
ローディング出したまま固まるみたいな現象が起きると、一部のユーザーはまず再起動なり、アプリの場合であれば再インストールを行ったりします。「あなたの方には問題ないですよ」を早めに伝えてあげる。運営者も不安ですが、サービスを利用しているユーザーはもっと不安です。早めに対応中であることを伝えて安心してもらいましょう。 これやらないと、さらに問題が複雑になったり、問い合わせ窓口が爆発して後処理がクッソ面倒くさくなります。

なので、止めなきゃいけない事象であれば、さっさとメンテやりましょう。1コマンドでやれる環境を常に用意しておくことを推奨します。やつらは突然やってくる。

前職ではbastionサーバーでcap maintenance:inで、nginxの管理化にmainte.html配置。ファイルが存在していれば、すべてのアクセスをそこに飛ばす設定にしていました。この辺参考になるかと思います。

hacknote.jp

原因調査

ここまでやってから、原因調査を開始します。一番頭痛くなる時間ですね。
まずは発生している問題から何が起きている可能性があるか仮説立てます。闇雲に動いても大体ロクな結果にならないので、アタリを付けて。冒頭で挙げたQiitaの記事にもありますが、見なくてもいいものを削っていくアプローチの方が効率がいいです。かつ検証可能性が高いものから潰していきます。

ある時間から急に発生しているのであれば施策開始やデプロイが起因していることがほとんど。エラーを検知する仕組みがあるとわりかしスムーズに進みます。ないところはさっさと立てましょう。エンジニアが死にます(´・ω・`)

まずはエラーログを見る。ここで要因がアプリ側なら、ディスクを見る。メモリを見る。CPU負荷を見る。デプロイされているコードバージョンを確認する。DBの可能性が疑われるなら、接続できるかを見る。スロークエリを見る。データ不整合を見る。

だいたいこの過程で「何が問題でサービスが機能していないのか」がわかります。 サーバーの状態は時系列で追えるといいですね。サービス運用するならモニタリングできる環境は必至です。仮にモニタリングしてないところがあれば今すぐ https://mackerel.io の門を叩きましょう
(自前でやる気があるなら、 https://prometheus.io/ が良さそうです)

mackerel.io

prometheus.io

なお、調査で調べたことがあれば都度報告するようにしましょう。「DBみた、つながる」、「クエリ詰まってる感じなさげ」、「APPのメモリが普段よりスパイクしてる」みたいな雑な感じでいいです。 他エンジニアに対する報告と、エンジニア外の人へちゃんと対応してる感が出てればOKで、整える時間があるなら調査に回しましょう。

障害対応

原因がわかりましたね?では次は障害を解消していくフェーズになります。

ここで重要なのが、「この障害はどこまで解消しているべきかのか?」を真っ先に詰めることです。
サービスにもよるのですが、止まっていることで不利益が生まれるのですばやく再開することが重視されるものや、完全に対応完了して事後対応まで要求されるものまで、対応のスコープが異なります。

この辺は事業責任者と話をして真っ先に決めましょう。エンジニアだけで判断するのはリスクが高いので必ず責任者巻き込んでください。稀に責任者と連絡つかないケースも生まれますが、事前に、この障害が起きたらこう!みたいなユースケースを責任者と握っておくと連絡取れないリスク減らせるので、ぜひやってください。

ゴールが握れていれば、後はそこに向かって作業するだけです。ここまでくれば後はうまいこと解消できると思います。



あとはほぼQiitaの記事と同じ流れですね。起きた障害を記録する、起きない対策を入れる、起きない環境を作る。ここ非常に大事です。もれなくやっていきましょう。

長くなってしまったので、今日はこのへんで。後日気が向けば「障害対応できるエンジニアの育て方」みたいなエントリ書いてみたいと思います(`・ω・´)