Slide 1
Slide 1 text
2024 TRUSTDOCK Inc.
株式会社TRUSTDOCK
技術開発部 SRE 五島宙也
2024 TRUSTDOCK Inc.
本⼈確認サービスにおける信頼性の定義と
アラート対応の継続的改善
2024.08.04
Slide 2
Slide 2 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
会社紹介
あらゆる本⼈確認業務を、
オンラインで完結いたします。
個⼈⾝元確認 マイナンバー取得
法⼈確認
リスク確認
郵送業務
事業者でのユーザー本⼈確認作業
をすべてオンラインで完結するこ
とができます。
さまざまな法律に準拠した
KYC‧本⼈確認を、API経由で
24時間365⽇アウトソーシング
可能となっております。
Slide 3
Slide 3 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
話すこと
● 実際の事例を元に、本⼈確認のドメインにおいてアラート運⽤をどのように改善したか
⽬次
1. アラートに対してちゃんと向き合う
2. 実際のアラートを元にお客様影響を考える
3. アラートのトリアージ体制の構築
4. ⻑期的に改善した⽅が良いものへの対処
本⽇のテーマ
Slide 4
Slide 4 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
⽬次
1. アラートに対してちゃんと向き合う
2. 実際のアラートを元にお客様影響を考える
3. アラートのトリアージ体制の構築
4. ⻑期的に改善した⽅が良いものへの対処
アラートに対してちゃんと向き合う
Slide 5
Slide 5 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● Ruby on Rails
● モノリス
● サーバーサイドエンジニアのみ
● 専任SREなし
● Sentryにて500エラー等が発⽣した際にアラートを通知
● 恒常的にアラートが出ている状況ではない
● 利⽤状況が⼤きくなり、機能の増加につれて発⽣するエッジケースが増えてきていた
当時(2021年)のサービス状況とアラート運⽤
Slide 6
Slide 6 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● アラートの⼀部を⾒逃し、本⼈確認が適切に進まない事象が発⽣
● それに伴い事業者への報告と謝罪を実施
● 明確なアラートの運⽤ルールがない状態であり、開発者に⼤きく委ねられている状態
● 全体の可⽤性は問題にはなっておらず、個別事象への対応に課題があった
● お客様影響のあるアラートのみが上がってくる状況が理想
👉実際に発⽣したアラートと照らし合わせて分析し、現実解を探る
きっかけ: アラートの取りこぼし
Slide 7
Slide 7 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● パッと⾒分けがつかない。同じに⾒える。
● BのアラートをAに誤認した結果、数件のアラートの取りこぼしが発⽣
● 別事象で問題がある、ということに後⽇に認知した
● 単純なエラー率(99.9%等)のSLI/SLOを設定しても個別事象の取りこぼしの課題感はなくならなそう
👉それぞれのアラートがどう違うのかを、サービス上から分析してみる
当時の取りこぼしたアラート
A: こっちのActiveRecord::DeadLockedは、問題は
なくはないが緊急性は⾼くない
B: こっちのActiveRecord::DeadLockedはデータの
不整合が発⽣し、問題がある
Slide 8
Slide 8 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
どこでエラーが発⽣したか
ライフサイクルが⻑く、複数のアクターが存在する
1. 事業者様からのAPIによる本⼈確認依頼
2. エンドユーザーが事業者様のwebを経由して確認書類を提出
3. ⽬視による本⼈確認を実施
4. 本⼈確認結果を返却
エンド
ユーザー
1.本⼈確認依頼
事業者
4. 本⼈確認結果を返却
2.確認書類を提出
⽬視による本⼈確認
オペレーター
3. 承認‧否認
Slide 9
Slide 9 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
1. 事業者様からのAPIによる本⼈確認依頼
2. エンドユーザーが事業者様のwebを経由して確認書類を提出
3. ⽬視による本⼈確認を実施
4. 本⼈確認結果を返却 お客様影響
どこでエラーが発⽣したか
エンド
ユーザー
事業者
⽬視による本⼈確認
オペレーター
1.本⼈確認依頼
4. 本⼈確認結果を返却
2.確認書類を提出
3. 承認‧否認
Slide 10
Slide 10 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
どこでエラーが発⽣したか
1. 事業者様からのAPIによる本⼈確認依頼
2. エンドユーザーが事業者様のwebを経由して確認書類を提出 <-- 緊急性の低いアラート
3. ⽬視による本⼈確認を実施
4. 本⼈確認結果を返却
エンド
ユーザー
⽬視による本⼈確認
オペレーター
A: アラート
👉緊急性が低い
事業者
1.本⼈確認依頼
4. 本⼈確認結果を返却
2.確認書類を提出
3. 承認‧否認
Slide 11
Slide 11 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● ⼆重送信等の通常では⾏われないリクエストで発⽣
● 事業者/エンドユーザーから⾒て回避⽅法が存在する
○ 実際にエンドユーザーが再提出して、本⼈確認が正常に実施されていた
○ UIで再提出を促せており、局所的(数件)に発⽣していた
👉緊急性が低いと判断
Aのアラートはなぜ緊急性が低いと判断したか
エンド
ユーザー
⽬視による本⼈確認
オペレーター
A: アラート
👉緊急性が低い
事業者
1.本⼈確認依頼
4. 本⼈確認結果を返却
2.確認書類を提出
3. 承認‧否認
Slide 12
Slide 12 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
1. 事業者様からのAPIによる本⼈確認依頼
2. エンドユーザーが事業者様のwebを経由して確認書類を提出
3. ⽬視による本⼈確認を実施 <-- 問題のあるアラート、4に遷移しなくなる
4. 本⼈確認結果を返却
どこでエラーが発⽣したか
エンド
ユーザー
⽬視による本⼈確認
オペレーター
B: アラート
👉データの不整合が発生
事業者
1.本⼈確認依頼
4. 本⼈確認結果を返却
2.確認書類を提出
3. 承認‧否認
Slide 13
Slide 13 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● 2と3の間の⾮同期workerの処理でエラーが発⽣し、3が開始できない状態
● TRUSTDOCKにてデータ修正をしない限り3と4に進まず、本⼈確認結果を返却できない
● 事業者/エンドユーザーから⾒て回避⽅法が存在しない
👉回避策がなく1~4が正常に進まないため、局所的(数件)であっても問題ありと判断
1~4の全てが正常に進むことが当社にとって信頼性(お客様影響)に直結しそう 🤔
Bのアラートはなぜ問題あるか
エンド
ユーザー
⽬視による本⼈確認
オペレーター
B: アラート
👉データの不整合が発生
事業者
1.本⼈確認依頼
4. 本⼈確認結果を返却
2.確認書類を提出
3. 承認‧否認
Slide 14
Slide 14 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● 1~4の全てが正常に進むことが当社にとって信頼性(お客様影響)に直結しそう
○ いわゆるクリティカルユーザージャーニーと⾔って良さそう
○ 1~4が繋がっているため、どれか⼀つでも⽋けるとお客様影響がある
● アラートによっては、影響度が⼩と判断できるものもありそう
○ A: アラートなど緊急性が低いと判断したもの
アラートを分析してみて
Slide 15
Slide 15 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
⽬次
1. アラートに対してちゃんと向き合う
2. 実際のアラートを元にお客様影響を考える
3. アラートのトリアージ体制の構築
4. ⻑期的に改善した⽅が良いものへの対処
実際のアラートを元にお客様影響を考える
Slide 16
Slide 16 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● 1~4の全体が全件数、進まない
● 1,2,3,4のいずれかが全件数、進まない
● 1,2,3,4のいずれか局所的(数件)に進まない
● 1,2のいずれか局所的(数件)に進まないが、回避策がある
👉全体かつ全件のため影響度は⼤
1~4が正常に進まないパターンの影響度を考える
エンド
ユーザー
⽬視による本⼈確認
オペレーター
1.本⼈確認依頼
4. 本⼈確認結果を返却
2.確認書類を提出
3. 承認‧否認
事業者
Slide 17
Slide 17 text
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. 承認‧否認
事業者
Slide 18
Slide 18 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● 1~4の全体が全件数、進まない
● 1,2,3,4のいずれか全件数、進まない
● 1,2,3,4のいずれか局所的(数件)に進まない
● 1,2のいずれか局所的(数件)に進まないが、回避策がある
👉例として3のみだが局所的(数件)のため影響度は中
1~4が正常に進まないパターンの影響度を考える
エンド
ユーザー
⽬視による本⼈確認
オペレーター
B: アラート
👉データの不整合が発生
1.本⼈確認依頼
4. 本⼈確認結果を返却
2.確認書類を提出
3. 承認‧否認
事業者
Slide 19
Slide 19 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● 1~4の全体が全件数、進まない
● 1,2,3,4のいずれか全件数、進まない
● 1,2,3,4のいずれか局所的(数件)に進まない
● 1,2のいずれか局所的(数件)に進まないが、回避策がある
👉再提出が可能であり、局所的(数件)のため影響度は⼩と判断でき、リスク受容ができそう
1~4が正常に進まないパターンの影響度を考える
エンド
ユーザー
⽬視による本⼈確認
オペレーター
A: アラート
👉緊急性が低い
事業者
1.本⼈確認依頼
4. 本⼈確認結果を返却
2.確認書類を提出
3. 承認‧否認
Slide 20
Slide 20 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
まとめると...
プロセス 件数 回避策 影響度
1~4全体 全件 なし ⼤
1,2,3,4のいずれか 全件 なし ⼤
1,2,3,4のいずれか 局所的(数件) なし 中
1,2のいずれか 局所的(数件) あり ⼩
Slide 21
Slide 21 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
TRUSTDOCKでは
プロセス 件数 回避策 影響度
1~4全体 全件 なし ⼤
1,2,3,4のいずれか 全件 なし ⼤
1,2,3,4のいずれか 局所的(数件) なし 中
1,2のいずれか 局所的(数件) あり ⼩
👉ある程度アラート設定ができており、覚知ができている
Slide 22
Slide 22 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
TRUSTDOCKでは
プロセス 件数 回避策 影響度
1~4全体 全件 なし ⼤
1,2,3,4のいずれか 全件 なし ⼤
1,2,3,4のいずれか 局所的(数件) なし 中
1,2のいずれか 局所的(数件) あり ⼩
👉ある程度アラート設定ができており、覚知ができている
ヘルスチェックによる外形監視
リクエスト全体の中のエラー率によるアラート(アクセスログを集計してアラート)
Slide 23
Slide 23 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
TRUSTDOCKでは
プロセス 件数 回避策 影響度
1~4全体 全件 なし ⼤
1,2,3,4のいずれか 全件 なし ⼤
1,2,3,4のいずれか 局所的(数件) なし 中
1,2のいずれか 局所的(数件) あり ⼩
👉ある程度アラート設定ができており、覚知ができている
全体のエラー率の監視の場合だと引っかからない場合がある
特定アラートが頻発した際にアラート(SentryのEscalating機能等)
Slide 24
Slide 24 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
TRUSTDOCKでは
プロセス 件数 回避策 影響度
1~4全体 全件 なし ⼤
1,2,3,4のいずれか 全件 なし ⼤
1,2,3,4のいずれか 局所的(数件) なし 中
1,2のいずれか 局所的(数件) あり ⼩
👉影響度が中or⼩のトリアージに課題感
冒頭のActiveRecord::DeadLocked等のアラートの中⾝を確認しないと分からないもの
Slide 25
Slide 25 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
⽬次
1. アラートに対してちゃんと向き合う
2. 実際のアラートを元にお客様影響を考える
3. アラートのトリアージ体制の構築
4. ⻑期的に改善した⽅が良いものへの対処
👉ここまで過去事例の分析と、お客様影響の分析
アラートのトリアージ体制の構築
Slide 26
Slide 26 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
⽬次
1. アラートに対してちゃんと向き合う
2. 実際のアラートを元にお客様影響を考える
3. アラートのトリアージ体制の構築
4. ⻑期的に改善した⽅が良いものへの対処
👉ここから現在のTRUSTDOCKの運⽤状況の説明になります
アラートのトリアージ体制の構築
Slide 27
Slide 27 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
⽬次
1. アラートに対してちゃんと向き合う
2. 実際のアラートを元にお客様影響を考える
3. アラートのトリアージ体制の構築
4. ⻑期的に改善した⽅が良いものへの対処
アラートのトリアージ体制の構築
Slide 28
Slide 28 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
TRUSTDOCKでは
プロセス 件数 回避策 影響度
1~4全体 全件 なし ⼤
1,2,3,4のいずれか 全件 なし ⼤
1,2,3,4のいずれか 局所的(数件) なし 中
1,2のいずれか 局所的(数件) あり ⼩
👉影響度が中or⼩のトリアージに焦点をあてます
Slide 29
Slide 29 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
運⽤⽅針
● 全てを機械的に判断するのは諦める
○ 全ての個別のエラーを想定できるなら、そもそもエラーは発⽣しない
○ (より良い⽅法があれば知りたい...)
● 開発者がアラートの中⾝を⾒て、影響度が中or⼩を判断
○ ドメイン上の制約
○ ⼀定の誤判断は割り切る
● 影響度が中のものは、トリアージ~暫定対応までの時間の弾⼒性を持たせる
○ 例) oo営業⽇以内にトリアージ対応など
○ トリアージまでの時間設定がSLIに近い
● 影響度が⼩のものは、次回からアラートを通知しない。無視する。
● アラートをクリーンに保つ
○ 影響度が中or⼩のものの確認をすることで、影響度が⼤のものを⾒逃す、というのは避ける
影響度が中or⼩のトリアージ
Slide 30
Slide 30 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
運⽤体制
● サーバーサイドチーム + SREで曜⽇ごとに分担
● Slackに通知のあったSentryのアラートを都度確認して判断する
○ Sentryのアラートに対応ログを紐づけする
○ 影響度が⼩の場合はSentry上でアーカイブし、次回発⽣時には通知されないようにする
影響度が中or⼩のトリアージ
Slide 31
Slide 31 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
運⽤体制
● サーバーサイドチーム + SREで曜⽇ごとに分担
● Slackに通知のあったSentryのアラートを都度確認して判断する
○ Sentryのアラートに対応ログを紐づけする
○ 影響度が⼩の場合はSentry上でアーカイブし、次回発⽣時には通知されないようにする
👉3⼈以上が推奨、トイルの性質も強いので負荷を分散できると良い
現状だと0-2件 / ⽇程度
負荷がかかり過ぎない範囲の運⽤体制になるように⼈員を配置する
影響度が中or⼩のトリアージ
Slide 32
Slide 32 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
運⽤体制
● サーバーサイドチーム + SREで曜⽇ごとに分担
● Slackに通知のあったSentryのアラートを都度確認して判断する
○ Sentryのアラートに対応ログを紐づけする
○ 影響度が⼩の場合はSentry上でアーカイブし、次回発⽣時には通知されないようにする
👉判断をする箇所に⼀定のスキルが求められるのが課題感
特に⼊社から⽇が浅くドメイン理解が浅いメンバーへの⼿当ては必要
影響度が中or⼩のトリアージ
Slide 33
Slide 33 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
⼼理的な部分
● 1⼈で完璧に判断ができる、よりも全員でカバーを重視
● #dev-アラート疑惑相談 というチャンネルを作成
○ ⼼理的ハードルを下げる
○ とりあえず相談する、の⽂化
○ ⾮難をしない
適切なアラートのトリアージができるような⼯夫
Slide 34
Slide 34 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
ドキュメントの整備
● 判断基準 / 定型作業などをesaにまとめて、標準化を図っている
適切なアラートのトリアージができるような⼯夫
Slide 35
Slide 35 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
障害対応訓練の実施
● アラートのトリアージから障害の判断、顧客への通知までを演習
● カスタマーサポート等、他グループを巻き込んで実施
● ドキュメント通りに動けるか、などを確認を通して、個⼈/チームの対応能⼒の向上が狙い
適切なアラートのトリアージができるような⼯夫
Slide 36
Slide 36 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
⽬次
1. アラートに対してちゃんと向き合う
2. 実際のアラートを元にお客様影響を考える
3. アラートのトリアージ体制の構築
4. ⻑期的に改善した⽅が良いものへの対処
⻑期的に改善した⽅が良いものへの対処
Slide 37
Slide 37 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
TRUSTDOCKでは
プロセス 件数 回避策 影響度
1~4全体 全件 なし ⼤
1,2,3,4のどれか 全件 なし ⼤
1,2,3,4のどれか 局所的(数件) なし 中
1,2のどれか 局所的(数件) あり ⼩
👉影響度が⼩の⻑期的に改善に焦点をあてます
Slide 38
Slide 38 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● ⾃動テスト
● E2E
● Staging環境での品質保証
● CI/CD、など
継続的な改善活動をする前提
Slide 39
Slide 39 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● Sentry上でアーカイブにして無視することの副作⽤として、アラートの総数が⾒えにくくなる
● 定期的にアラート種類‧総数を点検するのが⼤事
● コードを修正しない限り、アラートの種類‧総数は変わらないし、可⽤性は向上しない
👉影響度が⼩のものにも、継続的な改善活動が必要
アラートの影響度を割り振りする際の副作⽤
Slide 40
Slide 40 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● エラー率‧エラー詳細‧応答時間を週1で定期確認
○ Sentry上のダッシュボードや、BigQueryでControllerレベルで集計等
👉対応のコスパが良さそうなものから、優先度を⾼くして取り組む
アラートの定期的な確認
Slide 41
Slide 41 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● エラー率‧エラー詳細‧応答時間を週1で定期確認
○ Sentry上のダッシュボードや、BigQueryでControllerレベルで集計等
アラートの定期的な確認
Slide 42
Slide 42 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● エラー率‧エラー詳細‧応答時間を週1で定期確認
○ Sentry上のダッシュボードや、BigQueryでControllerレベルで集計等
アラートの定期的な確認
時間のかかっている
定期ジョブを先に把握
Slide 43
Slide 43 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
● エラー率‧エラー詳細‧応答時間を週1で定期確認
○ Sentry上のダッシュボードや、BigQueryでControllerレベルで集計等
アラートの定期的な確認
上位2Controllerで
エラー率の大半を占めている
先週はなかった Controllerで
エラーが発生している 🤔
Slide 44
Slide 44 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
エラーバジェット？
● 組織のサイズによってはエラーバジェットを設定して品質改善に対して強制⼒を働かせるのも1案
● TRUSTDOCKでは厳密に設定していない
○ 機能開発と天秤にかけた時に、優先順位を決めるのが難しい
○ 特に影響度が⼩の場合の優先度が難しい
継続的な改善活動へのリソース
Slide 45
Slide 45 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
現状の体制
● 影響度が⼤きいアラート
○ 発⽣した場合の恒久対応は基本的には最優先
● 影響度が⼩さいアラート
○ 実装者へエスカレーションを⾏い、修正して貰う
■ 作った⼈が修正していくのが基本
○ 実装者がいないケースも多々あるので、アラートの改善活動のためのリソースを事前に確保する
■ 副業の⽅に緩く⻑く、対応を続けて貰っている(≒ リソースをかけ過ぎない)
■ 機能開発と天秤にかけるより、先にリソースを確保した⽅が楽
■ 経営層含めて品質改善への理解は必要
継続的な改善活動へのリソース
Slide 46
Slide 46 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
影響度が⼩さいアラートにて改善を⾏った例
● Embedded SREっぽくインフラに限らず改善している
○ 外部連携APIへのリトライ最適化
○ 不正なリクエストへのバリデーション強化(500系 -> 400系に)
○ Railsの楽観的ロックを利⽤して、Deadlockの解消
○ パフォーマンス改善、など
● インフラ関連
○ AWSの上限引き上げ
○ 可観測性の向上、など
👉継続的に改善を⾏い、アラートの返済を続けることが重要
結果的にアラートのトリアージの負担削減、将来の影響度が⼤きい不具合への予防策
Slide 47
Slide 47 text
2024 TRUSTDOCK Inc.
2024 TRUSTDOCK Inc.
まとめ
● お客様影響を考慮したアラートのトリアージ
○ 影響度が中or⼩のものの、トリアージが課題
● 運⽤負荷を考慮した運⽤体制の構築
○ 全部をやろうとしない
○ 仕組み + オペレーションで現実解を探る
● トリアージのみでは、可⽤性は向上しないため、継続的な改善もセットで