お客様と一緒にシステムの潜在的リスクの洗い出しをやってみた話 #プレモーテム

安心してシステムの本番稼働を迎えるため、お客様と合宿形式でプレモーテムを行い、システムに起こりうる障害を予測しました。

#障害対応

Kyo

2024.02.21

こんにちは。CX事業本部のKyoです。

現在私が担当しているシステムは今年2024年に本番稼働を迎えます。安心して本番稼働を迎えるため、お客様との合宿形式でプレモーテムを行い、システムに起こりうる障害を予測しました。このエントリはそのレポートです。

目的: システムの弱点を前もって見つけ出す

昨年末のふりかえりで、システムの本番稼働には潜在的な障害の特定と対策が必要である、というチーム全体の共通認識に至りました。これを実現するためにプレモーテム的なアプローチをやってみることになりました。

一般的にプレモーテムではプロジェクトやシステムに起こりうる問題を想像し、それらに繋がる要素を洗い出します。今回は特にシステムに焦点を当てた形で行いました。

事前準備: 現状理解と分析

合宿の前に1ヶ月ほどかけて以下の事前準備を行いました。

構成図の作成

対象となるシステム(以下では仮にシステムZと呼びます)はサーバーレスなIoT関連システムで、IoTデバイスとサービス提供サーバー群の中継という役割を持っています。

各APIで実現している内容をもとに機能の単位でグルーピングを行いました。これによって各種機能が、デバイス側が利用する機能、サービス提供サーバー側が利用する機能、両側から利用される機能といった形で整理された全景図を作成しました。

これに加えて機能の単位で図を作成し、どのAPIが、どのAWSリソースに、どのようなアクセスを行っているかを可視化しました。これを詳細図としました。詳細図の作成においては、今まで揺れがちであったAPI名やリソースの和名の統一も行いました。以下の図では省略されていますが、実際の詳細図にはこれらの名前や機能の備考が記入されています。

最終的には1枚の詳細図と10数枚の全景図を作ることができました。作図はdraw.IOで行い、Gitでバージョン管理しています。

なお、これらの図はチーム総出で既存コードをリバースエンジニアリングする形で作成しました。結構なボリュームでしたが、日々の業務で利用される頻度も高いので、作っておいて損はないと思います（直近だとオンボーディングでとても役立ちました）。

障害記録の分析

システムZは、現行システムを置き換えるものとして位置づけられています。現行システムには長い運用実績があり、しっかりと障害記録も残っていたため、これの読み合わせを行いました。障害記録は以下の様なフォーマットでした。

特に重要なのはビジネスインパクトの大きな障害で、システムの提供価値を考える重要な手がかりになります。

システムの提供価値の再確認

詳細構成図と障害記録を元に、システムの提供価値を再考しました。なるべく客観的に「何がうれしいのか」を整理するためにプレスリリース風に書いてみました。文言はダミーですが、イメージは以下のような感じです。

「システムZ」はA社におけるIoT基盤です。

「システムZ」は従来のIoT基盤に変わり、以下の価値を提供します。

1. ユーザーが高速処理を享受できる
2. 管理者がセキュリティを強化できる
3. システムが省エネルギーで運用可能

開発メンバーだけでなく、ステークホルダーを含めてこれの読み合せ会を実施することで、システムが有する機能およびAPIのうちのどれが提供価値を支えているか（つまりコア機能であるか）をクリアにすることができました。また、これをもとにビジネスメトリクスについても定めることができました。

実際にやってみると、どの機能も重要に見えてくるので、1つに絞るとしたら？包含関係はないか？などと考えてみるのがコツだと思います。

プレモーテム合宿

お客様のオフィスにお邪魔して2日間かけて行いました。

DAY1: 障害仮説の洗い出し -質より量で-

DAY1のおおよその流れは以下の通りです。カオスエンジニアリングの事前準備である仮説バックログ作成と非常に近い内容と判断し、方法を流用しました。

DAY1のゴールとしては、以下を設定しました。

起こり得る障害と影響度を洗い出したリスト（上記のブログでいうところの仮説バックログ）が完成している
- 質より量でとにかく多くの仮説が出ること

事前準備の成果物をインプットに、ステークホルダーを含めた5人で20分の仮説出しを行い、60個程度の仮説が出ました。その後、仮説を読み合わせを行い、影響度をプランニングポーカーの形式で整理しました。プランニングポーカーはオンサイトの方がやりやすいですよね。

DAY2: 障害仮説の精緻化

DAY2ではDAY1の成果物をブラッシュアップしました。

具体的には、仮説を以下のような項目に整理しました。

アクター
発生する事象
システムへの影響
事象発見のためのメトリクス

まず全員で数件の整理を行い、整理方法の認識合わせを行った後、個別で整理を行いました。その後、成果物をマージして、全員での読み合わせを実施しました。読み合わせの中では、2つの仮説の類似性が高い場合の統合、1つの仮説が複数の内容を含んでいる場合の分割などを行いました。最後に、整理された仮説に対して発生確率をプランニングポーカーで決めました。

これによって、「影響度 x 発生確率」で仮説1つ1つのリスクスコアを求めることができるようになりました。例えばAWSのリージョン障害のようなものは影響度は最大の5ですが、発生確率は最小の1で、リスクスコアとしては5となります。アバウトなスコアではありますが、降順ソートすることで、システムにとってリスクの高い順に並べることができます。

※ 一部を切り出し

最終的に40個の仮説となりました。

気になったポイント

出てくる障害仮説の数が読めない

社内の有志に協力してもらいワークのリハーサルを行ったところ、「障害仮説を出すこと自体がそれなりに難しいのでは？」というフィードバックをいただきました。

確かに参加者のスキルセットによって出てくる仮説の量はかなり違ってきそうです。多く出る分にはグルーピングでなんとかできそうですが、全然出てこなかったらどうしよう...というのはヒヤヒヤしました。

対策として、合宿の1ヶ月ほど前から事前準備をしっかりと行い、参加者の頭の中には情報が揃った状態で挑むことにしました。また、まずはとにかく数を出したいという狙いを伝えるなどもしました。

結果としては、十分な量の仮説が得られたので良かったと思います。

時間に余白を作ることは重要

「出てくる仮説の数が読めない」に起因することですが、全体の時間配分を考えるのが大変でした。仮説がたくさん出た場合には読み合わせに時間が必要ですし、逆もまたしかりです。色々考えた挙句、全体の枠としての時間は多めに確保、最低限のゴールだけを決めて、それ以外は臨機応変に対応することにしました。

これは我々のチームにとっては合っていたようで、仮説の読み合わせの中で、「そういえばあの話題どうなってる？」とか「昔こういう話があったね」等の広がりが生まれました。こういった広がりがオンサイトでの合宿の醍醐味なのかもしれません。

ドキュメント管理がツラかった

組織を跨いだイベントを行う際にあるあるなお悩みです。クラスメソッド側はGoogle Workspace、お客様側はMicrosoft 365、と普段使っているツールが異なり、アクセス権の都合からも1つのファイルを同時編集することが難しい状態でした。 DAY1はとにかく多くの仮説を出すためにリアルタイムに皆が書き込んでいく、という形式で行いたかったので、唯一共通で使えるツールとしてSlackのcanvasを利用しました (DAY2はファシリテーターの私がGoogle Spreadsheetを投影する形になりました)。 canvas自体は良い機能だと思いますが、今回のユースケースではやはりソートやカウントなどの機能が欲しく、共通で使えるスプレッドシート系のツールを準備する方が望ましいと感じました。