System Risk Records を用いたシステムリスク管理
ダイニーの @urahiroshi です。
先日、SRE NEXT 2024にて「プロダクトのスケールによって顕在化しうるリスクをどう管理するか？」というテーマで登壇しました。この際に紹介した “System Risk Records” というドキュメントを用いた運用フローについて、この記事でも簡単に紹介するとともに、SRE NEXT の登壇後に挙がった質問などから補足情報を記載します。
System Risk Records とは
現在プロダクトが抱えているシステム上のリスクを一覧化するとともに、個々のリスクの対応状況を一元管理するためのものです。ダイニーでは、これを用いて潜在的なリスクを見つけたときに記録し、優先度を算定したうえでリスク対応を行っています。
個々のリスクをクリックすることでリスクの詳細が見えます。詳細画面では、「どのようにリスクを検出したか」「どのように原因を特定したか」「どのような対応を行い、どのような結果だったか」といったリスクに関するあらゆる情報が一元管理され、対応の担当者以外でもリスクの状況が終えるような形になっています。
Google Spreadsheet, Google Document を用いて System Risk Records のテンプレートを作成しているため、興味がある方はぜひこちらをご利用ください。
System Risk Records で解決したい課題
ダイニー では “Performance Review” という場で定期的にメトリクスのモニタリングをしており、メトリクスで異常が見られる場合には担当者をアサインして調査・報告するという対応を行っている中で、以下のような課題がありました。
潜在的なリスク対応が埋もれがち
例
暫定対策はすぐに行ったが、恒久対策は時間がかかるので開発チケットだけ作った
が、問題はいったん暫定対策で解消されており、他の開発チケットも多く作られる中で恒久対策のチケットが埋もれていく
対応の属人化
例
担当者の試行錯誤の後に問題を解消した
その後に類似の問題が発生した場合、他のメンバーは試行錯誤の詳細を把握していないので、同じ担当者がアサインされる
さらにその担当者に試行錯誤の経験が溜まっていき、難易度の高い問題は同じ担当者にアサインされがちになっていく
優先度がわからない
例
怪しいメトリクスを検出し、担当者が少し調べたが原因がわからなかった
深刻な問題の予兆だった可能性も考えられたが、その場の話し合いで様子見として対応終了となった
こうした課題を解消するために作成したのが System Risk Records であり、これらの課題は以下のように解決されています。
潜在的なリスク対応が埋もれがち ⇒ System Risk Records で潜在的なリスクを記録し、対応状況を一覧化できる
対応の属人化 ⇒ 詳細画面を見ると対象のシステムリスクに対するあらゆる情報が掲載しており、これを見るだけで誰でも詳細な状態が把握できる(引き継ぎもしやすい)とともに、将来的な類似の事象があった場合に過去の対応を振り返ってみることができる
優先度がわからない ⇒ System Risk Records ではリスクの優先度の計算方法 (潜在的なインパクト x 発生可能性) が定義されており、これに基づいて個々のリスクが優先度付けできる。
(補足) ダイニーでは影響範囲と影響度からインシデントスコアを算定しており、それを基に潜在的なインパクトを算定している
また、システムリスクに対処するため、時には大規模な修正を加えるケースもあります。大規模な修正は新しいリスク要因にもなりうるため、他の対処法との比較など含めて慎重に検討することが必要です。これまでであれば、そういった方針についての相談は担当者任せになっていたほか、これまでの調査内容の共有などに時間がかかるといった問題もありました。System Risk Records の詳細画面では対策方針やその代案を記載する項目もあり、対策方針のレビューを行うためのドキュメントとしても活用することができます。
System Risk Records をどのように作ったか・どう運用しているか
ここでは SRE NEXT での発表後に挙がった質問などから、補足情報を記載していきます。
System Risk Records のリスク評価について、セキュリティ文脈でのリスク評価との類似性があるという話があったのですが、まさにそのとおりで、現在自分はセキュリティのリスク評価にも携わっており、セキュリティ文脈でのリスク値の算定方法を参考にしています。具体的には、IPAが発行している 中小企業の情報セキュリティ対策ガイドライン (第3.1版) に記載されている詳細リスク分析の方法 (組織が保持する情報資産に対して、情報資産ごとの重要度と被害発生可能性をスコア付けし、 重要度 x 発生可能性 によりリスク値を算出) を参考とし、System Risk Records のリスク優先度スコアについても 潜在的なインパクト x 発生可能性 としました。
セキュリティの分野はインシデント対応においてもCSIRTやSOCのように専門の役割が定義されているなど、リスク対応全般に対してより進んだ取り組みがされているように感じており、技術領域的には異なるものの、SREの分野でも参考になるプラクティスは多いのではないかと考えています。
運用面については、開発組織においてSystem Risk Recordsのような仕組みを作ろうにもそれを適切に運用するためのコストをかけるのが難しく、どうやっているのかという質問がありました。
ダイニーでも、現在正社員のエンジニア数が10名強という体制であり、決して開発リソースが潤沢というわけではありません。その中でも System Risk Records のような運用フローを回せているのは、機能開発をミッションとする Feature Team とは別に、信頼性の向上などをミッションとする Platform Team があり、System Risk Records で検出したリスクの調査・対策も Platform Team メンバーを中心に実施できるという体制の要因が大きいです。少ない開発リソースの中で Platform Team に一定の人員を割けているのは、ダイニーが提供しているプロダクトが飲食店にとってクリティカルな機能を提供しており、信頼性への投資が不可欠だということが経営層まで浸透しているという背景もあります。
ただ、将来的にプロダクトの数や人数規模が大きくなっていくと、Platform Team のメンバーが直接個々のプロダクトの信頼性向上のためのアクションを取るのは難しくなってくるでしょう。その際には、以下２つのアプローチを考えています。
各プロダクトに専属のSREメンバー(Embedded SRE)を配置し、一定の人的リソースは信頼性向上に割り当てられる体制にする
各プロダクトのSLO (Service Level Objective) を定め、SLOを満たせなければ開発をストップして信頼性向上のためのアクションを取れるようにするなどの運用フローを確立する
個々の開発チームで機能開発と信頼性向上を天秤にかけるような判断をしなければならない場合、機能開発については顧客やビジネス部門などの要望が外発的動機づけとなる一方で、信頼性向上についてはインシデントが発生しない限りは外発的動機づけは起こりくいため、信頼性向上が後回しになりがちという構造的な問題があると考えています。そのため、個々のチームが個別判断することは避け、上のアプローチのように一定のリソースを信頼性向上に割けるような仕組みを導入することが必須と考えます。
We're hiring!
組織やプロダクトが拡大・分散していく中で、信頼性を高く保ち続けることはこれからのチャレンジと言えるでしょう。このようなチャレンジに興味を持たれた方は、ぜひカジュアル面談を通じてお話できればと思います。
