こんにちは、ファインディ株式会社で機械学習エンジニアをしていますsasanoshouta(@Edyyyyon)です。この記事は、ファインディでインシデントが発生した際に行なっているポストモーテムの運用とその様子について、先日発生したインシデントを元に紹介をする記事となっています。
今回発生したインシデントについて
まず、今回発生したインシデントについて軽く紹介をさせていただきます。一言で表現すると、サービスの機能の1つを一時的に停止させてしまいました。
ポストモーテムの様子
弊社ではインシデントが発生した際にポストモーテムを実施して再発防止に努めております。
ポストモーテムとは？
そもそもポストモーテムとはなんだ？と言う方もおられるかもしれませんので、簡単にご紹介いたします。
ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。 *1
一般的にポストモーテムを実施するには一定の基準があり、基準を超えた障害が起きたときに実施するものです。
しかし弊社ではまだポストモーテムに対する知見や歴史が浅く、文化として根付かせるために、現在は練習も兼ねて小さい障害でもポストモーテムを実施するようにしています。
ポストモーテムの流れ
今回のインシデントを例に、ポストモーテムの流れを見る形で実施の様子をご紹介します。弊社の場合のポストモーテムは、以下の順序で実施されます。
- 当事者が事前に障害までのアクションを振り返る
- ミーティングで集まりアクションについてのフィードバックを実施する
- ネクストアクション決定とウォッチ
1. 当事者が事前に障害までのアクションを振り返る
この手順について特筆する事はありませんが、弊社の場合はGoogle docsにてインシデントごとに管理をしているので、以下画像のように主催者からdocsの案内が来たタイミングで覚えている事が新鮮なうちに時系列での出来事の詳細を記載しています。
2. ミーティングで集まりアクションについてのフィードバックを実施する
以下画像のような形で、事前に当事者が書き記した時系列でのイベントを振り返りながら、各イベントに関連するアクションの中で良かった点と改善点について参加者で話し合います。
少しだけインシデントの事について触れますが、「機能が利用不可になっている事が発覚してから復旧までをスムーズに行えた」と言う振り返りがありました。当日はゴールデンウィークの狭間時期と言う事もあり、本来のバックエンド担当者が不在の間に起きた出来事でもありました。しかし、日頃からサービス上で提供している機能のIaC化をコツコツ進めていた事で担当者不在の中でもスムーズな復旧対応が行えました。
3. ネクストアクション決定とウォッチ
2で行なったイベント・アクションに対する振り返りをもとに、ネクストアクションを決定します。
以下は今回のインシデントにおけるネクストアクションにもなります。今回起きた事は、機能開発者が開発に必要なサービスとその権限をバックエンド運用者と十分な意思疎通をしきれなかった事で起きたインシデントだと捉えています。ヒューマンエラーを起こしてしまった開発者目線のネクストアクションを今回は以下のように定めました。
- 開発に着手する前に管理者側と十分に意思疎通を図れるフローを制定し、運用する
- フローの中で定める項目
- 開発したい要件について運用者に事前共有する
- 開発の為に必要最低限の適切な権限を要求する
- フローの中で定める項目
- 上記フローをポストモーテム実施後3日以内に作成し、次回週次の全体確認会で案内。
また、運用者目線でも開発時に「今自分がどちらの環境を開いているのか目視で分かりづらいのでは」との意見もあり、「どの環境にいるのか分かりやすくする為の視覚情報を導入」する事で同様のヒューマンエラーを防ぐ仕組みを導入する事になりました。
ポストモーテム後のネクストアクションを作成はしたものの、形骸化するものも中には少なからず存在すると思います。
なので、弊社ではネクストアクションを議論する際に意識するポイントとして、
- 具体性を持たせて明確なアクションにすること
- それを定期的にウォッチして進んだのか進んでないのかを確認し続けて放置しないこと
の2点を常に意識してポストモーテムを実施するようにしています。
余談ですが、弊社では全エンジニアが直近の取り組みを持ち回りで定期的に共有する全体会のようなものを設けています。
その全体会の場でポストモーテムの内容と得られた知見を包み隠さず共有し、エンジニア組織全体の共有知見とすることを文化としています。
ネクストアクションにはインシデントを受けてどんな対策を打つか？を考える事に焦点が集中しがちだと思いますが、「当事者でないエンジニアも含む組織全体に対して共有する」という事も再発防止策の一つとして機能している事を実感しています。
ポストモーテム実施時に気をつけている事
上記弊社でのポストモーテムの様子を実際のインシデントを例に紹介しました。最後に、実施の際に気をつけている事について共有します。
犯人探し、批判をしない
ポストモーテムで最も重要視している項目です。 ポストモーテムの目的は学びにあり、犯人探し、批判を行うとそれを恐れ当事者が真実を語らなくなり、その背後にある本当の原因に気づくことができなくなる為です。 批判ではなく、根本原因の追求と分析に徹する事を心がけるようにしています。
障害の根本原因を分析し、理解する
原因の分析が不十分だと、誤った再発防止策になり、結果として同じ障害が再発することに繋がりかねません。 客観的な視点で、原因がシステムやプロセスにあることを意識して分析をするようにしています。
人ではなく、仕組みで解決する
再発防止策が頑張る、気をつけるだけだと、再発防止を人に依存することになりますが、人はミスをする生き物です。 システムやプロセスを修正して、人がミスしても被害を最小限にくい止めるように努めるようにしています。
問題点だけでなく、良かった点も指摘、称賛する
犯人探し、批判はご法度ですが、良かった点があれば何回でも称賛する事も大切にしています。
さいごに
改めまして、ご不便をおかけしましたユーザーの皆様に深くお詫びをするとともに、再発防止に努めてまいります。 今回のポストモーテムを通じて、開発を進める上で足りていなかった観点・過剰だった点を浮き彫りにする事ができたことは非常に個人として学びになりました。 この学びを活かして、より良いサービス創りに貢献できるよう個人・組織として精進してまいります。
