本⼈確認サービスにおける信頼性の定義とアラート対応の継続的改善

2024 TRUSTDOCK Inc. 株式会社TRUSTDOCK 技術開発部 SRE 五島宙也 2024 TRUSTDOCK Inc.
本⼈確認サービスにおける信頼性の定義とアラート対応の継続的改善 2024.08.04

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 会社紹介あらゆる本⼈確認業務を、オンラインで完結いたします。個⼈⾝元確認
マイナンバー取得法⼈確認リスク確認郵送業務事業者でのユーザー本⼈確認作業をすべてオンラインで完結することができます。さまざまな法律に準拠した KYC‧本⼈確認を、API経由で 24時間365⽇アウトソーシング可能となっております。

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 話すこと • 実際の事例を元に、本⼈確認のドメインにおいてアラート運⽤をどのように改善したか⽬次
1. アラートに対してちゃんと向き合う 2. 実際のアラートを元にお客様影響を考える 3. アラートのトリアージ体制の構築 4. ⻑期的に改善した⽅が良いものへの対処本⽇のテーマ

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. ⽬次 1. アラートに対してちゃんと向き合う 2.
実際のアラートを元にお客様影響を考える 3. アラートのトリアージ体制の構築 4. ⻑期的に改善した⽅が良いものへの対処アラートに対してちゃんと向き合う

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • Ruby on Rails
• モノリス • サーバーサイドエンジニアのみ • 専任SREなし • Sentryにて500エラー等が発⽣した際にアラートを通知 • 恒常的にアラートが出ている状況ではない • 利⽤状況が⼤きくなり、機能の増加につれて発⽣するエッジケースが増えてきていた当時(2021年)のサービス状況とアラート運⽤

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • アラートの⼀部を⾒逃し、本⼈確認が適切に進まない事象が発⽣ • それに伴い事業者への報告と謝罪を実施
• 明確なアラートの運⽤ルールがない状態であり、開発者に⼤きく委ねられている状態 • 全体の可⽤性は問題にはなっておらず、個別事象への対応に課題があった • お客様影響のあるアラートのみが上がってくる状況が理想 👉実際に発⽣したアラートと照らし合わせて分析し、現実解を探るきっかけ: アラートの取りこぼし

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • パッと⾒分けがつかない。同じに⾒える。 • BのアラートをAに誤認した結果、数件のアラートの取りこぼしが発⽣
• 別事象で問題がある、ということに後⽇に認知した • 単純なエラー率(99.9%等)のSLI/SLOを設定しても個別事象の取りこぼしの課題感はなくならなそう 👉それぞれのアラートがどう違うのかを、サービス上から分析してみる当時の取りこぼしたアラート A: こっちのActiveRecord::DeadLockedは、問題はなくはないが緊急性は⾼くない B: こっちのActiveRecord::DeadLockedはデータの不整合が発⽣し、問題がある

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. どこでエラーが発⽣したかライフサイクルが⻑く、複数のアクターが存在する 1. 事業者様からのAPIによる本⼈確認依頼
2. エンドユーザーが事業者様のwebを経由して確認書類を提出 3. ⽬視による本⼈確認を実施 4. 本⼈確認結果を返却エンドユーザー 1.本⼈確認依頼事業者 4. 本⼈確認結果を返却 2.確認書類を提出⽬視による本⼈確認オペレーター 3. 承認‧否認

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 1. 事業者様からのAPIによる本⼈確認依頼 2. エンドユーザーが事業者様のwebを経由して確認書類を提出
3. ⽬視による本⼈確認を実施 4. 本⼈確認結果を返却お客様影響どこでエラーが発⽣したかエンドユーザー事業者⽬視による本⼈確認オペレーター 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. どこでエラーが発⽣したか 1. 事業者様からのAPIによる本⼈確認依頼 2.
エンドユーザーが事業者様のwebを経由して確認書類を提出 <-- 緊急性の低いアラート 3. ⽬視による本⼈確認を実施 4. 本⼈確認結果を返却エンドユーザー⽬視による本⼈確認オペレーター A: アラート 👉緊急性が低い事業者 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • ⼆重送信等の通常では⾏われないリクエストで発⽣ • 事業者/エンドユーザーから⾒て回避⽅法が存在する
◦ 実際にエンドユーザーが再提出して、本⼈確認が正常に実施されていた ◦ UIで再提出を促せており、局所的(数件)に発⽣していた 👉緊急性が低いと判断 Aのアラートはなぜ緊急性が低いと判断したかエンドユーザー⽬視による本⼈確認オペレーター A: アラート 👉緊急性が低い事業者 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 1. 事業者様からのAPIによる本⼈確認依頼 2. エンドユーザーが事業者様のwebを経由して確認書類を提出
3. ⽬視による本⼈確認を実施 <-- 問題のあるアラート、4に遷移しなくなる 4. 本⼈確認結果を返却どこでエラーが発⽣したかエンドユーザー⽬視による本⼈確認オペレーター B: アラート 👉データの不整合が発生事業者 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • 2と3の間の⾮同期workerの処理でエラーが発⽣し、3が開始できない状態 • TRUSTDOCKにてデータ修正をしない限り3と4に進まず、本⼈確認結果を返却できない
• 事業者/エンドユーザーから⾒て回避⽅法が存在しない 👉回避策がなく1~4が正常に進まないため、局所的(数件)であっても問題ありと判断 1~4の全てが正常に進むことが当社にとって信頼性(お客様影響)に直結しそう 🤔 Bのアラートはなぜ問題あるかエンドユーザー⽬視による本⼈確認オペレーター B: アラート 👉データの不整合が発生事業者 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • 1~4の全てが正常に進むことが当社にとって信頼性(お客様影響)に直結しそう ◦ いわゆるクリティカルユーザージャーニーと⾔って良さそう
◦ 1~4が繋がっているため、どれか⼀つでも⽋けるとお客様影響がある • アラートによっては、影響度が⼩と判断できるものもありそう ◦ A: アラートなど緊急性が低いと判断したものアラートを分析してみて

実際のアラートを元にお客様影響を考える 3. アラートのトリアージ体制の構築 4. ⻑期的に改善した⽅が良いものへの対処実際のアラートを元にお客様影響を考える

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • 1~4の全体が全件数、進まない • 1,2,3,4のいずれかが全件数、進まない
• 1,2,3,4のいずれか局所的(数件)に進まない • 1,2のいずれか局所的(数件)に進まないが、回避策がある 👉全体かつ全件のため影響度は⼤ 1~4が正常に進まないパターンの影響度を考えるエンドユーザー⽬視による本⼈確認オペレーター 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認事業者

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • 1~4の全体が全件数、進まない • 1,2,3,4のいずれか全件数、進まない
• 1,2,3,4のいずれか局所的(数件)に進まない • 1,2のいずれか局所的(数件)に進まないが、回避策がある 👉結果的に1~4が正常に進まず、全件のため影響度は⼤ 1~4が正常に進まないパターンの影響度を考えるエンドユーザー⽬視による本⼈確認オペレーター 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認事業者

• 1,2,3,4のいずれか局所的(数件)に進まない • 1,2のいずれか局所的(数件)に進まないが、回避策がある 👉例として3のみだが局所的(数件)のため影響度は中 1~4が正常に進まないパターンの影響度を考えるエンドユーザー⽬視による本⼈確認オペレーター B: アラート 👉データの不整合が発生 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認事業者

• 1,2,3,4のいずれか局所的(数件)に進まない • 1,2のいずれか局所的(数件)に進まないが、回避策がある 👉再提出が可能であり、局所的(数件)のため影響度は⼩と判断でき、リスク受容ができそう 1~4が正常に進まないパターンの影響度を考えるエンドユーザー⽬視による本⼈確認オペレーター A: アラート 👉緊急性が低い事業者 1.本⼈確認依頼 4. 本⼈確認結果を返却 2.確認書類を提出 3. 承認‧否認

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. まとめると... プロセス件数回避策
影響度 1~4全体全件なし⼤ 1,2,3,4のいずれか全件なし⼤ 1,2,3,4のいずれか局所的(数件) なし中 1,2のいずれか局所的(数件) あり⼩

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. TRUSTDOCKではプロセス件数回避策
影響度 1~4全体全件なし⼤ 1,2,3,4のいずれか全件なし⼤ 1,2,3,4のいずれか局所的(数件) なし中 1,2のいずれか局所的(数件) あり⼩ 👉ある程度アラート設定ができており、覚知ができている

影響度 1~4全体全件なし⼤ 1,2,3,4のいずれか全件なし⼤ 1,2,3,4のいずれか局所的(数件) なし中 1,2のいずれか局所的(数件) あり⼩ 👉ある程度アラート設定ができており、覚知ができているヘルスチェックによる外形監視リクエスト全体の中のエラー率によるアラート(アクセスログを集計してアラート)

影響度 1~4全体全件なし⼤ 1,2,3,4のいずれか全件なし⼤ 1,2,3,4のいずれか局所的(数件) なし中 1,2のいずれか局所的(数件) あり⼩ 👉ある程度アラート設定ができており、覚知ができている全体のエラー率の監視の場合だと引っかからない場合がある特定アラートが頻発した際にアラート(SentryのEscalating機能等)

影響度 1~4全体全件なし⼤ 1,2,3,4のいずれか全件なし⼤ 1,2,3,4のいずれか局所的(数件) なし中 1,2のいずれか局所的(数件) あり⼩ 👉影響度が中or⼩のトリアージに課題感冒頭のActiveRecord::DeadLocked等のアラートの中⾝を確認しないと分からないもの

実際のアラートを元にお客様影響を考える 3. アラートのトリアージ体制の構築 4. ⻑期的に改善した⽅が良いものへの対処 👉ここまで過去事例の分析と、お客様影響の分析アラートのトリアージ体制の構築

実際のアラートを元にお客様影響を考える 3. アラートのトリアージ体制の構築 4. ⻑期的に改善した⽅が良いものへの対処 👉ここから現在のTRUSTDOCKの運⽤状況の説明になりますアラートのトリアージ体制の構築

実際のアラートを元にお客様影響を考える 3. アラートのトリアージ体制の構築 4. ⻑期的に改善した⽅が良いものへの対処アラートのトリアージ体制の構築

影響度 1~4全体全件なし⼤ 1,2,3,4のいずれか全件なし⼤ 1,2,3,4のいずれか局所的(数件) なし中 1,2のいずれか局所的(数件) あり⼩ 👉影響度が中or⼩のトリアージに焦点をあてます

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 運⽤⽅針 • 全てを機械的に判断するのは諦める ◦
全ての個別のエラーを想定できるなら、そもそもエラーは発⽣しない ◦ (より良い⽅法があれば知りたい...) • 開発者がアラートの中⾝を⾒て、影響度が中or⼩を判断 ◦ ドメイン上の制約 ◦ ⼀定の誤判断は割り切る • 影響度が中のものは、トリアージ~暫定対応までの時間の弾⼒性を持たせる ◦ 例) oo営業⽇以内にトリアージ対応など ◦ トリアージまでの時間設定がSLIに近い • 影響度が⼩のものは、次回からアラートを通知しない。無視する。 • アラートをクリーンに保つ ◦ 影響度が中or⼩のものの確認をすることで、影響度が⼤のものを⾒逃す、というのは避ける影響度が中or⼩のトリアージ

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 運⽤体制 • サーバーサイドチーム +
SREで曜⽇ごとに分担 • Slackに通知のあったSentryのアラートを都度確認して判断する ◦ Sentryのアラートに対応ログを紐づけする ◦ 影響度が⼩の場合はSentry上でアーカイブし、次回発⽣時には通知されないようにする影響度が中or⼩のトリアージ

SREで曜⽇ごとに分担 • Slackに通知のあったSentryのアラートを都度確認して判断する ◦ Sentryのアラートに対応ログを紐づけする ◦ 影響度が⼩の場合はSentry上でアーカイブし、次回発⽣時には通知されないようにする 👉3⼈以上が推奨、トイルの性質も強いので負荷を分散できると良い現状だと0-2件 / ⽇程度負荷がかかり過ぎない範囲の運⽤体制になるように⼈員を配置する影響度が中or⼩のトリアージ

SREで曜⽇ごとに分担 • Slackに通知のあったSentryのアラートを都度確認して判断する ◦ Sentryのアラートに対応ログを紐づけする ◦ 影響度が⼩の場合はSentry上でアーカイブし、次回発⽣時には通知されないようにする 👉判断をする箇所に⼀定のスキルが求められるのが課題感特に⼊社から⽇が浅くドメイン理解が浅いメンバーへの⼿当ては必要影響度が中or⼩のトリアージ

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. ⼼理的な部分 • 1⼈で完璧に判断ができる、よりも全員でカバーを重視 •
#dev-アラート疑惑相談というチャンネルを作成 ◦ ⼼理的ハードルを下げる ◦ とりあえず相談する、の⽂化 ◦ ⾮難をしない適切なアラートのトリアージができるような⼯夫

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. ドキュメントの整備 • 判断基準 /
定型作業などをesaにまとめて、標準化を図っている適切なアラートのトリアージができるような⼯夫

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 障害対応訓練の実施 • アラートのトリアージから障害の判断、顧客への通知までを演習 •
カスタマーサポート等、他グループを巻き込んで実施 • ドキュメント通りに動けるか、などを確認を通して、個⼈/チームの対応能⼒の向上が狙い適切なアラートのトリアージができるような⼯夫

実際のアラートを元にお客様影響を考える 3. アラートのトリアージ体制の構築 4. ⻑期的に改善した⽅が良いものへの対処⻑期的に改善した⽅が良いものへの対処

影響度 1~4全体全件なし⼤ 1,2,3,4のどれか全件なし⼤ 1,2,3,4のどれか局所的(数件) なし中 1,2のどれか局所的(数件) あり⼩ 👉影響度が⼩の⻑期的に改善に焦点をあてます

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • ⾃動テスト • E2E
• Staging環境での品質保証 • CI/CD、など継続的な改善活動をする前提

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • Sentry上でアーカイブにして無視することの副作⽤として、アラートの総数が⾒えにくくなる • 定期的にアラート種類‧総数を点検するのが⼤事
• コードを修正しない限り、アラートの種類‧総数は変わらないし、可⽤性は向上しない 👉影響度が⼩のものにも、継続的な改善活動が必要アラートの影響度を割り振りする際の副作⽤

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. • エラー率‧エラー詳細‧応答時間を週1で定期確認 ◦ Sentry上のダッシュボードや、BigQueryでControllerレベルで集計等
👉対応のコスパが良さそうなものから、優先度を⾼くして取り組むアラートの定期的な確認

アラートの定期的な確認

アラートの定期的な確認時間のかかっている定期ジョブを先に把握

アラートの定期的な確認上位2Controllerでエラー率の大半を占めている先週はなかった Controllerでエラーが発生している 🤔

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. エラーバジェット？ • 組織のサイズによってはエラーバジェットを設定して品質改善に対して強制⼒を働かせるのも1案 •
TRUSTDOCKでは厳密に設定していない ◦ 機能開発と天秤にかけた時に、優先順位を決めるのが難しい ◦ 特に影響度が⼩の場合の優先度が難しい継続的な改善活動へのリソース

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 現状の体制 • 影響度が⼤きいアラート ◦
発⽣した場合の恒久対応は基本的には最優先 • 影響度が⼩さいアラート ◦ 実装者へエスカレーションを⾏い、修正して貰う ▪ 作った⼈が修正していくのが基本 ◦ 実装者がいないケースも多々あるので、アラートの改善活動のためのリソースを事前に確保する ▪ 副業の⽅に緩く⻑く、対応を続けて貰っている(≒ リソースをかけ過ぎない) ▪ 機能開発と天秤にかけるより、先にリソースを確保した⽅が楽 ▪ 経営層含めて品質改善への理解は必要継続的な改善活動へのリソース

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. 影響度が⼩さいアラートにて改善を⾏った例 • Embedded SREっぽくインフラに限らず改善している
◦ 外部連携APIへのリトライ最適化 ◦ 不正なリクエストへのバリデーション強化(500系 -> 400系に) ◦ Railsの楽観的ロックを利⽤して、Deadlockの解消 ◦ パフォーマンス改善、など • インフラ関連 ◦ AWSの上限引き上げ ◦ 可観測性の向上、など 👉継続的に改善を⾏い、アラートの返済を続けることが重要結果的にアラートのトリアージの負担削減、将来の影響度が⼤きい不具合への予防策

2024 TRUSTDOCK Inc. 2024 TRUSTDOCK Inc. まとめ • お客様影響を考慮したアラートのトリアージ ◦
影響度が中or⼩のものの、トリアージが課題 • 運⽤負荷を考慮した運⽤体制の構築 ◦ 全部をやろうとしない ◦ 仕組み + オペレーションで現実解を探る • トリアージのみでは、可⽤性は向上しないため、継続的な改善もセットで

本⼈確認サービスにおける信頼性の定義とアラート対応の継続的改善

本⼈確認サービスにおける信頼性の定義とアラート対応の継続的改善

Featured

Transcript