こんにちは、エムスリーエンジニアリングGの榎田です。趣味は数学とゲームです。最近はFF14でエデン零式再生編を抜けたり加群と線型空間の振る舞いの違いを考えてあそんだりしています。
今日は、私たちのチームでの障害にまつわる取り組みの話をします。実際のところはじめたばかりの試みも多く、手探りな部分は多々あるのですが、現状の整理も兼ねてつらつらと述べてみることにします。
障害対応、しています
障害を起こしてから対応するよりも、できれば障害そのものを減らしたほうがよいですし、そのために社内では様々な取り組みをしています。例えば週次で不具合分析会をしたり、
それを踏まえて障害を起こしにくい仕組みを作ったり、という感じです。
しかし Web サービスという非常に複雑なものを扱っている以上、開発が盛んに行われている以上、そして人間は完璧ではない以上、万全を期したつもりでも障害はいつかどこかで必ず起きます。起きたときの対応も仕事のひとつです。
私たちのチームの障害対応に関する状況はどうかというと、
- 扱っているシステム数が多く、その中には歴史の古いものもあるので、障害に出くわす確率もそれなり。
- 障害が起きたとき、タテマエ上は全員が対応の役割を担うことになっている。
- 一方、障害が起きたときに動く人が固定化されつつある。
- 障害対応に追われるほどではない。たまに起きるものの、その都度対応で運用を回せてはいる。
という具合でした。
障害共有、しましょうか
この中で、 障害が起きたときに動く人が固定化されつつある というのは何か手を打てるだろうし、打つべきだろうと思っていました*1。試しにリーダーとの 1on1 やチーム内での話し合いで「障害対応をしたらそれを共有する場を持つのはどうですか」と提案してみました。いろいろ議論を経た結果、次のような感じに落ち着きました。
- かっちりとしたポストモーテムを書くような大きな障害が起きた場合は自然と共有するので、小規模な障害対応を共有する場をきちんと持つ
- 例1：「日次の社内用集計バッチがコケた」
- 例2：「メルマガが1種類だけ送信されていない」
- 毎日やっている zoom の朝会で「昨日やったこと」を共有しているが、その中に障害対応があったら、その原因と対応について説明する時間をとる
- 例1：「バッチの動いているシステムが古いせいでコケやすい。再実行の仕方は定型化されていて、その手順通りに実行すればよい からそうした」
- 例2：「メルマガの運用が変わったのに、エンジニアに共有がもれていた。設定はここに書かれていて、この部分を直すだけでよい からそうした」
中長期的には、根本的な対策で以て障害をなくしていくのがよいですし、そのための取り組みは冒頭に挙げたとおりです。しかしここでは、「とりあえず今急ぎで対応するにはどうするか・どうしたか」に一旦フォーカスしています。そもそもの問題と 対応の仕方、および関連する運用上の知見 を共有することで問題の抱え込みを排除し、属人性を減らすことがねらいです。
障害実況、はじめました
これを言い出した数日後に、狙ったように古いシステム上で障害が起きました。調査開始です。
調査しがてら、これは別に当日共有しない理由もないだろうと思い立ち、試しに対応・調査の様子を zoom で流すようにしてみました。ゲーム実況プレイヤーならぬ、障害実況エンジニアのはじまりです。
zoom を立てたところ、自然と何人か集まって通話する形になり、原因究明に向けてあれこれと共同で調査がはじまりました。その調査・議論の過程で、様々な「障害対応をする上での障害」があることに気づきました。例えば、
- 特にリモートで画面共有なしだと、他の人の対応の様子が本当に何も見えない
- 対応をしようとしても、サーバに入れない・入れてもコマンド実行の権限がないと、対応を任せるしかない
- 作りの古いアプリケーションだと、初見ではどこを見ればよいかわからない（ログファイルの場所はどこで、何が書かれている・いないのか、など）
- 社内に似た障害を対応したときのドキュメントがあるのに、知られていない場合がある
といった点です。これらの点が可視化できたので、
- 画面共有をして、実際の対応の様子を把握する
- どんな権限があればよいか調べて権限申請する
- 調査の取っ掛かりになることがらをドキュメントなどに書く
- zoom の画面共有でドキュメントのページを見せる
といった対応がその場で打てました。
障害対応、つづけます
これは多分に個人的な感覚を含むのですが、障害対応にあたっては、先程述べたような個別具体的な「障害」があることに加え、
- 上記のような引っかかりポイントがあることを、対応の場数を踏むうちに忘れてしまうことがあるので、放っておくと共有が進まない
という構造もまたあるように感じています。実際、先程あげた具体例たちは、この障害実況時に気づいたことでもある一方、過去の私が（そして恐らく、チームの同僚のみなさんも同様に）いろいろな場面で苦しみ、そして忘れていきつつあった点たちでもありました*2。この見立てが正しいとして、いま現在この構造に効く特効薬は見つかってはいません。もしかすると、地道に共有を続けること、そのような場を持ち続けることが一番効いてくるのかもしれません。
とりあえずは今のまま、共有を続けて様子を見てみよう、というのがチーム内での結論です。回数を重ねていくうちに、やり方は変わっていくかもしれません。
We are hiring!
最初に述べたとおり、私たちのチームでは数多くのプロダクトが盛んに開発され、運用されています。障害対応はそのような運用の一場面です。私たちと一緒に運用を担うエンジニアを募集しています。お気軽にお問い合わせください。
*1:もっと率直な話をすると、私は最初に述べたとおりゲームと数学が趣味で、外に出るのを億劫に感じるタイプなので、毎日ずっと家にいます。ということは、休日でも夜でもいつでも障害対応ができる状況です。そんな中、3週連続で週末に障害対応をしたことがありました。いずれもちょっとした対応で済んだので負担感は低かったのですが、とはいえ対応が属人化しはじめている兆候ではあるでしょう。この状況は誰にとってもまずいよなあ、と思った次第でした。
*2:こういう「過去に誰かが引っかかったポイント」を引っかからないで済ませるための、知見の共有なり教育なりの「仕組み」としてスタンダードなものがある気もしているのですが、私はそのような知見にあかるくないのが残念なところです。
