shiodaifuku.io

障害振り返り会はいいぞ

僕の所属している組織では、システム障害が発生すると振り返り会が行われます。 正直、僕は若い頃この障害振り返り会が嫌いでした。 でも、その当時は振り返り会の目的を勘違いしていたのです。 障害振り返り会とは、本来はポジティブに取り組むべきものなのです。

というわけで、障害振り返りの際に気をつけるべきだと僕が勝手に思っているポイントをまとめてみることにしました。

障害の復旧にかかる対応とか障害報告とかの話は書きません。 また、この記事はWebエンジニアとかアプリエンジニアのみなさまを読者に想定して書いています。 障害を起こしたら人がお亡くなりになってしまうような業界の方とは障害に対する考え方が根本的に違うと思われますので、そっ閉じでお願いします。

障害振り返り会とはなにか

システム障害を起こしてしまった際に招集される、主に障害の原因と対策について議論する会です。 だいたいは障害を起こした当人、障害対応に参加した人、有識者、上司などが参加します。

僕がこれまで所属してきた組織では100%の割合で障害発生後に振り返り会を開催することがルールになっています。 サンプル数は多くないので一般的なのかどうかはわかりませんが、個人的には開催すべきだろうなと思います。

こんな障害振り返り会は嫌だ

本題です。

障害が起こってしまうこと自体はあまりうれしくないですが、僕は障害振り返り会というイベントは割と好きです。 その理由は、システム上の問題にしろ組織的な課題にしろ、自分たちの働く環境を改善するわかりやすいチャンスだからです。

そんな素晴らしい機会も、参加者の心構えと準備次第では台無しになってしまいます。 ダメな障害振り返り会の例をいくつか紹介しますので、参考にしていただければと思います。

障害を起こした人を吊るし上げる場になっている

新人エンジニアの頃は僕も勘違いしていて、自分が障害を起こしたあとの振り返り会が本当に憂鬱でした。 先輩とか偉い人があつまって(障害を起こした張本人である)僕を取り囲んで、根掘り葉掘り詰められて1最終的に怒られるんだろうなぁとか思っていました。 そんなことしたって誰も幸せにならんということに気づくまでに2年くらいかかりました。

これは全エンジニアに理解してほしいことですが、障害振り返り会というのは障害を起こした当人を吊るし上げる場ではありません。 そんなことをしても障害はなかったことにはなりませんし、発生した損失が返ってくるわけでもありません。

障害を起こした当人ならば、深刻そうな顔をしておいたほうが場の収まりはよいでしょうが、変にしおらしく振る舞う必要はありません。 振り返り会はあなたを糾弾する場ではありません2。 ただし、起こした障害とは真摯に向き合ってください。 これは障害を起こした人間の最低限の義務です。

あなたが先輩、有識者、または偉い人に該当する場合は、日頃から「障害振り返り会というのは障害の責任を追求して誰かになすりつける場ではない」とチームメンバーに理解してもらうための啓蒙活動をしてください。 また、振り返り会は辛気臭い雰囲気になりがちなので、ポジティブな空気を醸成するよう努めてください。

障害の発生原因の掘り下げが雑

振り返りの場をネガティブな空気にしてはいけない理由がこれです。 障害を起こした当人の心理的安全性が損なわれて「振り返り会をなんとかやり過ごそう、丸く収めよう」とか考えてしまうパターンが最悪です。 原因の追求が疎かになり、結果として組織が得られるはずだった改善のチャンスを失います。

雑な原因分析からは雑な対応策しか生まれません。 多くの人に迷惑をかけておきながら、何の成果も得られませんでした、で終わることだけは絶対に避けなければなりません。

あなたが障害を起こした当人の場合は、詳細に障害の原因を分析してください。 そして、その分析した結果を他人におもねることなく、正直に誠実に説明してください。

良い原因追求を行うために重要なポイントは原因を人に帰着させないことです。 知識不足、スキル不足、手順の誤り、ヒューマンエラーといった内容でまとめるのは避けたほうがいいです。 なぜそんな高度な知識・スキルを要求するのかとか、なぜヒューマンエラーが起きる構造が放置されているのかとか、そのあたりまで掘り下げるのが望ましいと思われます。

あなたが先輩、有識者、または偉い人に該当する場合は、障害振り返り会を有意義なものにするために甘っちょろい原因分析を見逃さずに指摘してください。 障害振り返り会は障害が起こったことを咎める場ではありませんが、障害と真剣に向き合うことを避けるような態度は許してはいけません。 もちろん、日頃からの障害振り返り会の意義を啓蒙しておくことが重要になることは言うまでもありません。

できもしない、あるいは実効性のない再発防止策

障害振り返りの会で最も重要なポイントが、障害からどのような学びを得て、得た学びをどのようにシステムや組織の改善につなげるかです。 そして、改善の核となるのが振り返り会に提出される再発防止策です。

再発防止策は大きく分けて暫定対応と恒久対応の2つに分けることができます。 暫定対応は、必ずしも同様の障害を根絶できるわけではないが、恒久対応が施されるまでの間ある程度の抑制効果が認められ、かつその実施に必要なリソースが合理的に少ない3対策のことを言います。 対して、恒久対応とは原則として必要なリソースを度外視して同様の障害を根絶できるような対策です。

それぞれの対応に求められる特性は異なりますが、総じて言うと理想的な対策は人が介在しないものです。 逆にあまりうまくいかない対応の典型例としては、安易に新しいルールを定めたり、それまでの業務プロセスを変更するような方策を恒久対応に定めることがあげられます4

長期間に渡ってよく機能するルールを設計することは思っているよりもはるかに難しいタスクです。 法律と比べるのが妥当かどうかはわかりませんが、大多数の人の日常生活には過剰なストレスをかけず、他の既存の法律と矛盾や競合を起こさず、 将来的な環境の変化にもそれなりに適応し、それでいてなんらかの改善効果が感じられる新法を作るのには多大な時間を要します。 それでいてなお、実際の運用と解釈にはある程度の幅をもたせているのが常です。

障害の恒久対策としてのワーキングルールに解釈の幅、すなわち人間の判断の余地が残っているとそこが新たな脆弱性となってしまいがちです。 また、働く現場を取り巻く環境の変化やシステムの仕様変更によりルールを守ること自体が難しくなることもあります。 多くのケースでは、こうして作られたルールを見直すためのプロセスを設けないので、時間が経つとルールが形骸化してしまいます。

その昔、障害を頻発させては振り返りのたびに新しいルールやプロセスを恒久対策として自らの働き方をどんどん縛っていった先輩がいたような気がします。 もちろんそれによって障害が減ることはなく、疲弊している現場を横目に見たような気もしますが、たぶんあれは悪い夢だったのでしょう。 ええ。きっと。

人力によるダブルチェックが無意味であることはいろいろなところで語られて久しいですが、 これに限らず人や組織に依存する手段を恒久対策として用いてもよい結果にはつながりにくいです。 たとえば、周知徹底とかメンバーの教育とか運用手順の改定とかなんかそういうのはだいたい恒久対策としては役不足です。

あなたが障害を起こした当人の場合は、自分よりもスキルの低い人や知識の少ない人が同様の作業を行うことを想定して、それでも類似の障害が発生しないような対策を考えましょう。 人は覚えたことを忘れますし、この業界では数年したら入れ替わりますし、運用手順の変更はシステムの変化の速度にはついていけません。 やはり、恒久対応としてはシステムの一部として組み込めるものや人の手が介在しない自動化などが望ましいと思います。

あなたが先輩、有識者、または偉い人に該当する場合は、原因分析と同様によい再発防止策が出るように担当者を導いてあげてください。

ちなみに、このような機械的な対策も単に障害の発生点をずらしているに過ぎません5。 だからといって意味がないというわけではなく、障害によって被害を小さくできているなら対策としては有用であると言えます。 どのようなリスクが想定されて、そのリスクが発現してしまったときにどれくらいの影響が見込まれるのか、といった観点まで評価・検討されている再発防止策が理想的です。

恒久対策は実現可能でありさえすればいい

たまにですが、よい恒久対策を思いついていながら「(工数的に)あまり現実的じゃないなぁ」とか考えて振り返り会に持ち込んでくれない人がいます。 これは非常にもったいないので、構わず持ち込んでほしいです。 ぜひ本来システムがあるべき姿について議論する機会を提供してください。

実際問題として、本当に根本的なところから問題を解決しようとすると大規模なシステム改修が必要になってしまうケースが少なくありません。 しかし、恒久対応は直ちに実施する必要はないのです。 システムの問題点を情報として記録して残しておくことは、将来システムのリニューアルをやらなければならない日が来たときに役に立ちます。 「このシステムはこれだけの課題をかかえている」ということを可視化しておくことは非常に重要であり、投資を渋るビジネス部門を説得する材料にもなります。

できもしない対策はダメだと上の方に書きましたが、できなくはないけど費用面とか工数面とか考えたら現実的ではない対策はダメではありません。 忖度せずに理想を追いかけてください。 長い目で見るとそうして積み上げたものがチームの動力源になる日が必ず来ます。 お願いします。

(余談) 障害振り返りの思い出

あまり詳しくは書きませんが、とあるエンジニアが若き時分にトラディショナルな組織とイケイケなWeb開発組織の狭間のようなところで仕事をしていました。 籍は後者にありましたが、システムで何かやらかすとトラディショナルな組織のほうにもご迷惑をかけるようなところです。

ある日、彼が起こしたヤバめの障害の振り返り会が開かれることになりました。 そこには、普段は出てこないトラディショナルな偉い人が出席し、まさに上述したようなダメな振り返り会が繰り広げられそうな気配が濃厚でした。 現実の障害の後始末にはめんどくさい(社内)政治判断とか、障害の規模によっては外向きにどう見せるかみたいな話もついてまわったりもするので、ダメな振り返り会の発生がときどき避けられないこともあります。 このときの振り返り会はそのひとつだったのですが、若さゆえの正義感にあふれる彼は細かいことなどお構いなしに正論パンチを繰り出して、トラディショナルな方々をドン引きさせたそうです。

同席した上司が話の段取りとか責任の所在の持って行き方とかいろいろ作戦を立ててくれていたらしい、ということに彼が気づいたのはそれからしばらく経ってからのことだったとか。 たぶんその上司は火に油を注いだ無鉄砲な部下の後始末に追われたのだろうと思いますが、 彼は「あの場で言うべきことを言ってくれてよかったよ」と苦笑いしながらと褒めてもらったことを(そのときの上司の辛そうな顔とセットで)未だに覚えているらしいです。

この話には特にオチはないのですが、部下に仕事を任せる・何かあったら責任をとる・合理的な行動を正当に評価してくれる上司というのは本当に素晴らしいですね。 願わくば、この上司のような人間になりたいものです。


  1. 詰められるは詰められるんですけど。
  2. 障害振り返りの場が当事者を糾弾するような組織にいる場合は直ちに逃げることを強くおすすめします。
  3. たとえば少ない工数で改修できるとか、運用の変更である程度カバーできるとか。
  4. 一方でこのような対策は短期的にはそれなりに有効なので、暫定対応としては有用である可能性があります。
  5. たとえば、デプロイフローを自動化してもCI/CD環境に障害が発生する可能性はあります。

最新記事

  1. Cloud RunでgRPC streamingができるようになったので動かしてみたりした
  2. 2020年の執筆業まとめ
  3. アーキテクチャを設計する仕事とは
  4. 決済システムを設計するときに忘れてはならないたった1つの大切なこと
  5. third-party cookieと2020年