Operational Excellence (オペレーショナルエクセレンス)

優れた Salesforce ソリューションは一度構築すれば終わりではなく、継続的に改良されます。ソリューションのパフォーマンスを監視してその動作を調整することで、予測可能なビジネス価値を提供し、何かが壊れたときに迅速に復旧できるようにすることで、優れた運用性をシステムに組み込みます。

優れた運用性を怠ると、ソリューションに予測可能な影響があります。手動のリリースプロセスがボトルネックになり、機能の提供が遅くなり、エラーのリスクが高まります。監視が不十分な場合、ユーザーが問題を報告するまでインシデントの検出が遅れ、影響期間が長くなり、Trustが損なわれます。自動化の欠如により、運用チームはソリューションの複雑さに比例して規模を拡大しなければならず、維持できないコストの軌道が生じます。監視が不十分な一括処理ジョブが失敗すると、気づかないうちにデータや下流プロセスが破損する可能性があります。

優れた運用性を実現するように設計されたソリューションにより、チームは包括的な監視を通じてシステムの動作を監視し、自動化されたパイプラインを使用して変更を安全にリリースし、定義済みの手順でインシデントに効果的に対応し、責任のないレビューを通じて運用経験から学ぶことができます。これらの機能は、時間の経過とともに強化されます。運用基盤に早期に投資したチームは、本番環境で問題が発生して事後対応型の投資を余儀なくされるまで運用上の懸念事項を先送りしたチームよりも迅速かつ確実に機能を提供できます。

優れた運用性は、他のアーキテクチャの柱に直接つながります。信頼性は、障害を検出する監視と、迅速なリカバリを可能にする自動化に依存します。Trustには、運用の変更に関する安全な開発ライフサイクル プラクティスと監査証跡が必要です。リソースの最適化は、運用テレメトリによって提供される継続的な改善から利益を得ます。コストの最適化には、導入の効率性と、運用コストの増加を防止する自動化が必要です。これらの柱が連携して、持続可能な運用投資で継続的なビジネス価値を提供するソリューションを構築します。

Salesforce は、インフラストラクチャ (サーバー、データベース、ランタイム、ネットワーク) を操作します。操作するものは、ソリューションを定義するメタデータ、その動作を制御する設定、それを流れるデータ、それを接続するインテグレーション、その内部で機能するエージェントなど、その上で構築されたすべてのものです。

この責任分担によって、実行するすべての業務上の意思決定が形成されます。Salesforce はプラットフォームの可用性、パフォーマンス、安全性を確保しますが、監視可能、リリース可能、自動化可能、復旧可能なソリューションを設計する必要があります。プラットフォームのマルチテナントアーキテクチャでは、ソリューションの運用上の問題によって、個々のトランザクションが失敗するガバナ制限や、組織全体にカスケードされる行ロックやリソースの競合が発生する可能性があります。事後の観察可能性、リリースの安全性、またはインシデントの準備に追加の労力や手戻りは必要ありません。

このガイドでは、Salesforce ソリューションを信頼性の高い持続可能なシステムに変えるための運用方法 (監視、リリースの自動化、インシデント対応、継続的な改善) の設計と実装方法について説明します。

次の原則を使用して、プラットフォームで優れた運用を行うためのアーキテクチャ上の意思決定を導きます。

• **可観測性で進化します。**問題が発生した後に事後的に計装を改良するのではなく、初期バージョンから包括的な観測可能性を設計します。観測可能なシステムは、実際の条件下での実際の動作を明らかにし、データ主導のアーキテクチャの改善と迅速な問題診断を可能にします。可観測性は、ソリューション設計を最初から形成するアーキテクチャ上の懸念事項です。計装、監視、テレメトリー収集の決定は、データモデル、インテグレーションパターン、コンポーネント境界に影響します。

• **運用手順を標準化します。**アプリケーションコードと共にソース制御でバージョン設定と操作手順を行います。コード化された運用により、Salesforce DXの自動導入、Sandboxの更新の自動化、環境全体で一貫して実行されるメタデータの導入が可能になります。組織構成に関するTribal Knowledgeは、すべてのチーム メンバーが実行できる実行可能なスクリプトに変換されます。手順のバージョン管理では、アプリケーション機能と同じレビューおよび改善サイクルを経て手順が進化し、再現可能な運用パターンが作成されて設定のドリフトが大幅に軽減されます。Center of Excellence を実装する。

• **DevOps文化を受け入れる。**開発チーム、業務チーム、ビジネスチーム間の組織のサイロを解消します。解決策の結果に対する責任の分担は、壁を乗り越える作業に代わるものです。DevOps の文化は、摩擦を減らし、フィードバックループを加速し、業務への影響に対する説明責任を生み出します。アーキテクトは、コラボレーションをサポートするテクノロジーの選択肢や、共有責任を妨げる構造的な障壁を取り除いた組織の支持を通じて、DevOps を実現します。

• **自動化による効率化。**反復的な業務を自動化して、手作業を排除し、人為的ミスを減らし、コストとリソースの使用量を最適化しながら業務を拡張できるようにします。頻繁に繰り返される手動操作は、自動化に適しています。自動化の価値は、作業時間の短縮、エラーの削減、作成された業務量によって測定されます。

• **すべての操作イベントから学習します。**インシデント、パフォーマンスの異常、ヒヤリハット、成功した業務から組織の学習を抽出します。無責任な死後は、個人の過失ではなくシステムの改善に焦点が絞られるため、正直な評価のための心理的安全性が確保されます。オペレーショナルテレメトリにより、インシデント全体のパターンが明らかになり、プロアクティブな防止が可能になります。学習文化により、業務経験は経時的に複合する組織能力に変換されます。

Salesforce の操作を理解することで、制御するものに運用設計の労力を集中させることができます。このプラットフォームは、従来のIT環境では専任チームが必要だったインフラストラクチャの懸念事項に対応します。

• インフラストラクチャの信頼性とパフォーマンス: Salesforce は、すべてのインスタンスのサーバ容量、データベースパフォーマンス、ネットワークの可用性、およびストレージシステムを監視して管理します。プラットフォームの状況は status.salesforce.com に表示され、インシデントのリアルタイム更新と計画されたメンテナンス期間が表示されます。
• プラットフォーム更新およびパッチ: 年に 3 つのメジャーリリース (Spring、Summer、Winter) では、新機能、セキュリティパッチ、およびパフォーマンスの向上が提供されます。Salesforce は、リリースタイミング、API バージョンのサポートと非推奨、およびプラットフォームレベルの変更管理を管理します。本番リリースの前に、Sandbox 環境でリリースに対してソリューションをテストします。
• **マルチ テナント リソース管理:**共有インフラストラクチャを公平に保つためにガバナ制限が存在します。他のお客様と同じリソースで実行しているため、Salesforceでは、CPU時間、ヒープ サイズ、Salesforce Object Query Language(SOQL)クエリ、Data Manipulation Language(DML)ステートメント、APIコールなどに上限を適用し、1つのテナントが容量を過度に消費しないようにします。Salesforce は全体的な使用状況を追跡し、顧客がライセンス層を介していくつかの制限 (API コールなど) に対してより高い割り当てを要求できるようにしますが、トランザクションごとの Apex ガバナ制限自体は固定されており、すべてのユーザーに対して同じ方法で適用されます。
• コアプラットフォームセキュリティ業務: Salesforceセキュリティチームは、脅威の監視、脆弱性の開示とパッチ適用の管理、セキュリティ認定の維持、プラットフォームレベルのセキュリティインシデントへの対応を行います。この基本的なセキュリティにより、ソリューション固有のセキュリティ制御を構築するためのベースラインが作成されます。
• ディザスタリカバリとビジネス継続性: Salesforce は、地理的に分散したデータセンターを維持し、ディザスタリカバリ手順をテストして、お客様の手を煩わせることなくフェイルオーバを可能にする冗長システムを維持します。プラットフォームレベルのリカバリは、インフラストラクチャの障害時に透過的に実行されます。

これらのプラットフォーム操作は、構築の基礎となります。サーバーのプロビジョニング、データベースのパッチ適用、インフラストラクチャの災害復旧の設計は行いません。ただし、この基盤上で構築および設定するすべての責任は各自にあります。

Shared Responsibility Model (共有責任モデル) とは、Salesforce 内で作成するすべての業務に対して、優れた運用性を所有することを意味します。プラットフォーム操作によって作業は可能になりますが、置き換えることはできません。業務責任は、相互に接続された 5 つの領域にまたがっています。

可観測性とは、外部出力から内部システムの状態を把握する機能です。監視可能な Salesforce ソリューションを使用すると、オペレータは各調査で新しい計装をリリースすることなく、システムの動作に関する質問への回答、障害の診断、仮説の検証を行うことができます。監視 (定義済みのダッシュボードで既知の質問に回答) とオブザーバビリティ (包括的なテレメトリで任意の質問に回答) の区別は重要です。本番システムでは、設計時に想定していた動作を超える予期しない動作が発生するためです。

Salesforce ソリューションの場合、オブザーバビリティはプラットフォームのマルチテナントモデルに適応する 3 つの補完信号種別に及びます。

• Logs - 完全なコンテキスト情報を使用して個別のイベントを取得します。イベント モニタリングでは、APIコール、ログイン イベント、Apex実行、SOQLクエリ、Visualforceページ、Lightningページ、レポート実行をユーザーID、タイムスタンプ、期間、結果などの要求コンテキストと共に収集するイベント ログ ファイルが提供されます。ログでは、「このエラーが発生したユーザーは?」などの質問の回答を得ることができます。「実行の成功と失敗で何が変わったか」
• 総計値 - 経時的に集計された数値測定値で、トレンドとパターンを明らかにします。評価指標には、API 消費レート、Apex CPU 時間分布、一括処理ジョブの成功率、インテグレーション遅延のパーセント値、ユーザーフローの完了率が含まれます。総計値は、「パフォーマンスは経時的に低下しているか?」などの質問に回答します。「ガバナ制限に近づいているか」
• トレース - 分散システムを通過する要求パスを表示し、レイテンシの原因と障害ポイントを明らかにします。Salesforce ソリューションの場合、トレースでは同期 API コールを非同期処理チェーン、プラットフォームイベントを登録者の実行、インテグレーション要求を外部システム応答に接続できます。トレースは、「このフローのどこに遅延が蓄積されますか?」などの質問に回答します。「この複数ステップのプロセスで失敗したコンポーネントは?」

初期アーキテクチャからオブザーバビリティを考慮した設計。有効化するイベント監視イベント種別、運用の可視性を確保するためのプラットフォームイベントペイロードの構成方法、インテグレーションチェックポイントの配置場所、実装するカスタムログの決定により、ソリューションの長期的な操作性が決まります。既存のソリューションにオブザーバビリティを組み込むには、ほとんどのコンポーネントに触れる計器の変更が必要であり、業務改善作業中にバグが発生するリスクがあります。

Salesforce には、アーキテクトが最初から設計する必要がある専用の監視機能があります。

イベント監視では、組織全体の詳細な運用データが取得されます。イベント タイプには、API 使用状況、ログイン アクティビティ、ログアウト イベント、Apex 実行、SOQL クエリ、Visualforce ページの読み込み、Lightning ページ ビュー、レポート実行、ドキュメントの添付ファイル、コンテンツ転送、定義したカスタム イベントなどがあります。イベント監視は、セキュリティ分析、パフォーマンスの最適化、業務量計画、コンプライアンスレポートの基盤となります。

本番環境でイベント監視を有効にし、外部集計プラットフォームへのイベントログファイルの自動エクスポートを確立します。ほとんどのイベント種別でネイティブ保持が制限されており、トレンド分析、業務量計画、コンプライアンス要件には不十分です。外部集計により、履歴分析、他のシステムからのエンタープライズテレメトリとの相関関係、高度な分析、規制要件に一致する保持期間が可能になります。

Proactive Monitoringは、組織のパフォーマンスと拡張性のリスクを継続的に評価し、定義済みのシグナルがユーザーに表示されるインシデントになる前にアラートを表示します。Proactive Monitoringは、1日の割り当てに近づいているAPI要求制限の急増、共有リソースの競合を示すApex同時実行の失敗、ガバナしきい値に近いSOQL行制限、設計の改善を示唆する行ロックの競合などのパターンを検出します。

Proactive Monitoring では、Salesforce が管理する一連の定義済みの警告およびアラートしきい値が使用されます。パフォーマンスの可視性を深め、ベースラインとトレンドを調査する必要がある組織の場合、Scale Center では、CPU タイムアウト、同時実行および行ロック、ガバナ制限エラー、データベースパフォーマンスに関する詳細なランタイム分析が提供されます。

Data Detect(Salesforce Shieldが必要)は、標準オブジェクト項目とカスタムオブジェクト項目をスキャンして、テキスト、リッチテキスト、暗号化項目内の機密データ(PII(個人識別情報)など)を識別、分類、修正します。偽陽性を最小限に抑えるために、パターンマッチングとカスタム正規表現を使用したネイティブプラットフォーム処理が使用されます。新規または変更されたレコードを対象に定期的なスキャン (毎週または毎月) を実行します (分類済みの項目や非推奨の項目は除外)。

調査結果を使用して、コンプライアンス分類の更新、Shield Platform Encryptionの適用、イベント モニタリング セキュリティ ポリシーのトリガー、Sandboxデータ マスキングの適用をダウンストリーム ガバナンスで実行します。

Scale Centerでは、実行時間の長い操作、スループット パターン、例外ホットスポット、ガバナ制限消費量をトランザクション レベルで表示できます。Scale Center では、リソースを最も多く消費する操作、タイムアウトしきい値に近づいているトランザクション、および最適化投資によって運用に最も大きな影響がもたらされる操作を明らかにします。

ソリューションの安定化時にスケールセンターのベースラインを設定し、メジャーリリース後にベースラインを再確認します。コンテキストのないパフォーマンスは、解釈が困難です。ベースラインの比較により、変更によってパフォーマンスが改善されたか、または低下したかが明らかになり、さらなる最適化の意思決定の指針となります。

• **Setup Audit Trail (**監査履歴の設定): 権限の変更、メタデータの導入、管理アクション、セキュリティ設定の更新など、構成の変更を追跡します。保存期間はネイティブで最大 180 日間です。[設定変更履歴] では、誰がいつどの設定を変更したかを明らかにすることで、セキュリティ調査、コンプライアンス検証、インシデント事後がサポートされます。コンプライアンス要件や契約上の要件で履歴期間が長くなる場合、180 日を超えて保持できるように [設定] 監査履歴エントリをエクスポートします。
• 項目監査履歴: (Salesforce Shield が必要) は、項目値の履歴変更を追跡します。機密データ、変更履歴が必要な規制対象データ、または履歴値を理解することで業務やコンプライアンスレポートに役立つ重要なビジネスデータが含まれる項目に対して、項目監査履歴を選択的に有効にします。
• 状態チェック: 現在の設定を Salesforce セキュリティベースラインの推奨事項と比較する自動セキュリティ設定評価を提供します。四半期ごとの状態チェックレビューをスケジュールし、環境のリスク優先度に基づいて調査結果を修正します。補償制御がある場合や、デフォルトの推奨とは異なるリスク許容度がある場合、すべての調査結果で是正が必要とは限りませんが、すべての調査結果を慎重にレビューする必要があります。

プラットフォーム監視では、組織レベルの健全性は明らかになりますが、アプリケーション固有の問題は見逃されます。重要なビジネスジャーニーを測定することで、ユーザーの観点からアプリケーションの健全性を監視します。

ビジネスへの影響に基づいて重要なユーザープロセスを定義し、エンドツーエンドの成功率、完了時間、放棄ポイント、エラー率を監視します。通常、重要なフローには、収益を生み出す活動 (注文送信、契約締結、商談成立)、大規模活動 (ユーザーログイン、検索操作、レコード作成)、コンプライアンスが必要な活動 (同意取得、データ主体の権利履行、監査が必要なワークフロー) が含まれます。

重要な各ステップでの開始、完了、放棄、失敗を示すマイルストーンマーカーが表示された計装プロセス。フローの成功率が許容しきい値を下回った場合や、期間が遅延目標を超えた場合にアラートを表示します。プロセス・レベルの監視では、複数のApexクラス、複数のフロー、3つのプラットフォーム・イベント、2つの外部インテグレーションを操作するユーザー・ジャーニーは、どのトランジション・ポイントでも失敗する可能性があるため、コンポーネント・レベルの監視では認識されない問題が明らかになります。

インテグレーションの健全性を双方向で監視します。外部システムへの発信通話の成功率、遅延、再試行パターン、エラー種別を追跡します。外部システムからの着信通話の量パターン、認証失敗、データ検証エラー、処理時間を追跡します。インテグレーション監視では、多くの場合、オペレータが検知する前に外部システムの問題が特定され、プロアクティブなエスカレーションが可能になります。

外部パートナーとのインテグレーション SLA を確立し、コミットされた目標に対する実際のパフォーマンスを監視します。サービスレベル契約 (SLA) 違反が発生すると、テレメトリによって問題の原因が Salesforce、インテグレーションレイヤー、ネットワークパス、外部システムのどれであるかが区別されます。この区別は、インシデントのエスカレーションと契約交渉時に重要です。

サービスレベルインジケーター (SLI) は、ユーザーが認識する品質を表す厳選された評価指標です。サービスレベル目標 (SLO) は、ユーザーの期待と運用投資のバランスを取る SLI の目標値です。Salesforce ソリューションの場合、効果的な SLI は次のとおりです。

• 可用性: ソリューションがユーザーの要求に正常に応答する時間の割合。インフラストラクチャではなく、ユーザーの観点から可用性を測定します。プラットフォームは使用可能だが、シングルサインオン (SSO) の設定ミスによりユーザーがログインできないソリューションは、プラットフォームの稼働時間に関係なく使用できません。
• 遅延: ユーザーアクションが開始されてから表示される応答までの時間。平均では要求が最も遅いため、遅延の目標が平均ではなく特定のパーセント (p50、p90、p99) で定義されます。p99 の遅延が 8 秒の場合、100 件に 1 件の要求に 8 秒以上かかることになります。これは、トラフィック量の多いソリューションで 1 日に何千件もの劣悪な環境が発生していることを意味します。
• Success rate: ユーザーに表示されるエラーのない完了した操作の割合。ユーザーに起因するエラー (無効な入力、権限が不十分) とシステムに起因するエラー (PfR 制限エラー、インテグレーションタイムアウト、未対応の例外) を区別します。成功率 SLO には、システムに起因するエラーのみが含まれます。
• スループット: 時間単位あたりの完了した操作の量。バッチ処理、データインポート、スケジュール済みジョブ、および処理能力によって業務期限の順守が左右される一括処理のスループットに関する事項。

技術的な能力ではなく、ユーザー要件に基づいて SLO を設定します。問題は 、 「 これをどれだけ速くできるか」ではありません。むしろ、「ユーザーが目標を達成するために、どの程度の速度でこれを実行する必要があるか?」ということです。ユーザーが 2 秒を許容できる場合、ページの読み込み目標は 200 ミリ秒では意味がありません。逆に、ユーザーが 500 ミリ秒後に破棄した場合、2 秒の目標は無意味です。ユーザー調査、セッション分析、ビジネス要件により、現実的な SLO 目標が把握されます。

SLI バーンレートを監視して、累積 SLO 違反でエラー予算が枯渇したときに検出します。エラー予算は、ユーザーエクスペリエンスと運用投資のバランスを取る許容失敗率を表します。バーンレートが持続可能なレベルを超えた場合、SLO が回復するまで機能作業を中断し、信頼性の向上に集中します。この規律により、チームが重大な障害によって緊急対応を迫られるまで機能の期限を遵守しながら信頼性の低下を無視する一般的なパターンを回避できます。

人間の判断やアクションが必要な問題が自動システムで検知されると、アラートによって人間に通知されます。効果的なアラートは、カバー率 (実際の問題の検出) と精度 (誤報の回避) のバランスを取ります。アラートが不十分な場合、インシデントを見逃すか (アラートが少なすぎる、しきい値が高すぎる)、アラートの疲労感 (アラートが多すぎる、しきい値が低すぎる) が生じ、オペレーターは通知を無視することを覚えます。

アクション性に関するアラートを設計します。各アラートは次の 3 つの質問に答える必要があります。

1. どうした?
2. それが重要な理由は?
3. どうすればよいですか?

明確な回答がないアラートは、オペレータが無視するようにトレーニングされます。たとえば、「API コールが制限の 80% を超えました」というアラートが、どの API、どのインテグレーション、またはどのアクションを実行するべきかに関するコンテキストなしで表示され、応答に十分な情報が提供されません。

業務エスカレーション手順に一致するアラート重要度レベルを実装します。

• 重要なアラート: 時間帯に関係なく、すぐに対応が必要なユーザー向けのサービスの低下を示します。重要なアラートページのオンコールエンジニア。たとえば、設定されたしきい値を超えるログインの失敗、可用性 SLO を下回る収益創出フロー、データ損失の検出などがあります。
• 警告アラート: 介入なしで重要になるが、ユーザーには影響しない問題を示します。警告により、営業時間調査のチケットが生成されます。たとえば、API 消費が 1 日の制限に近づいている、一括処理ジョブが完了しているが SLA 目標に達していない、インテグレーションエラーが増加しているが失敗しきい値を下回っている、などがあります。
• 情報アラート: アクションを実行することなく、運用の変更を把握できます。情報アラートは監視ダッシュボードに表示されますが、通知は生成されません。たとえば、リリースの成功、スケジュールされたメンテナンスの完了、設定変更などです。

アラートレビューケイデンスを設定してアラート品質を評価し、実際のインシデントパターンに基づいてしきい値を調整します。真陽性率 (実際の問題を示すアラート)、偽陽性率 (問題が発生しなかったアラート)、解決までの時間 (アラートがインシデントの解決にどれだけ早くつながったか) などのアラート総計値を追跡します。高い偽陽性率は、オペレータの Trust を復元するために調整が必要な、機密性が高すぎるしきい値を示します。

DevOps の文化では、最初のコードコミットから本番運用まで、ソリューションの結果を所有する統合チームでの開発と運用の責任を結合します。DevOps を使用すると、開発者が効率的に実行するコンテキストのない運用チームに作業を任せる従来のサイロ化された組織と比較して、迅速なデリバリ、高品質、運用成果の向上を実現できます。

ソース駆動型開発では、すべてのソリューションアーティファクト (メタデータ、設定、コード、ドキュメント) が、組織に存在するポイント & クリック設定ではなく、バージョン管理されたソースファイルとして処理されます。ソース管理により、再現可能なビルド、共同開発、変更追跡、自動化されたリリースパイプラインが可能になります。

Salesforce DXには、ソース駆動型開発用のツールチェーンが用意されています。メタデータ API では、組織設定が XML ファイルとして公開されます。スクラッチ組織は、ソース管理から作成された使い捨ての開発環境を提供します。CLI ツールを使用すると、スクリプト形式のリリースと組織の操作が可能になります。Git などのバージョン管理システムは、変更を追跡し、コラボレーションワークフローを実現します。

メタデータを意図的に構造化して、チームのコラボレーションを可能にします。モジュラーパッケージ構造により、チームはマージの競合なしで独立して作業できます。共有コンポーネント（ページ・レイアウト、権限セット、カスタム・フィールド）を機能固有のコンポーネント（Apexクラス、フロー、Lightningコンポーネント）から分離します。所有者の境界が明確になっていると、全員がすべて変更してしまう混乱を回避できます。

コード レビューにより、変更が本番環境に到達する前に品質管理、Knowledge Sharing、学習の機会が提供されます。効果的なコードレビューにより、徹底的なレビューとスピードのバランスが保たれ、リリースのボトルネックになることなく有意義なフィードバックが提供されます。

明確なレビュー条件を設定します。校閲者は以下を確認します。

• 正しさ - コードは要求どおりに動作しますか?
• メンテナンス性 - 将来の開発者はこの点を理解して変更できますか?
• Performance (パフォーマンス) - このアプローチは適切に拡張されますか?
• セキュリティ - インジェクションのリスクや権限のバイパスがありますか?
• Consistency (一貫性) - これは、プロジェクトのパターンと標準と一致しますか?

明示的な条件がない場合、レビューは主観的または表面的なものになります。

本番でバインドされた変更には 2 つの承認が必要です。1人のレビュー担当者による承認ではKnowledgeサイロが作成され、他の観点では把握できない問題が見逃されます。2 人のレビュー担当者の要件により、Knowledge を配布し、バス係数を 1 以上に保ち、より多くの不具合をキャッチできます。承認要件とチームの規模のバランスを取ります。5 人のチームで 3 つの承認を必要とすると、ボトルネックが発生します。

取り込み要求 (PR) は小さくします。レビュー担当者が認識の負荷が大きすぎるため、数百行が変更された PR はカーソルレビューを受け取ります。200 ～ 400 行の 1 つの機能を変更する PR は、微妙な問題を把握する徹底的なレビューを受けます。大きな機能を段階的に提供するレビュー可能なチャンクに分割します。

機械的なチェックを自動化します。コードの書式設定、命名規則への準拠、テストカバー率要件、静的分析チェックは、レビュー担当者の注意をひくのではなく、自動的に実行する必要があります。レビュー担当者は、ロジック、設計、メンテナンス性など、人間による判断が必要な質問に焦点を絞る必要があります。

テストにより、ソリューションが正しく機能し、変更が蓄積されても機能し続けるという確信が得られます。効果的なテストでは、カバー率 (コードおよび機能テストで実行する量)、実行速度 (テストスイートの完了までの時間)、メンテナンス負荷 (テストの維持に必要な作業時間) のバランスを取ります。

• 単体テスト: 個々のコンポーネントを個別に検証します。Apex 単体テストでは、既存の組織のデータや外部の連動関係から分離してメソッドとクラスを検証します。Lightning Web コンポーネント テストでは、バックエンド API を使用せずにコンポーネントのロジックと表示を検証します。適切に設計された単体テストは数秒で実行され、開発中に即座にフィードバックが提供されます。単体テストだけで最小要件コードカバー率を 75% 以上とし、カバー率を天井ではなく床として扱います。
• 統合テスト: コンポーネント間のインタラクションを検証します。インテグレーションテストでは、実際のデータベース操作、疑似外部システムへの実際のコールアウト、および認証ガバナ制限の動作が実行されます。インテグレーションテストでは、単体テストで見逃される前提条件 (予期しないデータ状態、権限の問題、一括操作の制限、トリガー順序の連動関係) がキャッチされます。インテグレーションテストは、テストあたり数秒から数分で実行されます。
• エンドツーエンド (E2E) テスト: ログインから ToDo の完了までのユーザージャーニーの完了を検証します。E2EテストはFull Sandbox環境に対して実行され、UIインタラクション、バックエンド プロセス、非同期操作、インテグレーション タッチポイントを使用します。E2E テストでは、システム全体の実行時にのみ現れる問題 (競合状態、予期しないユーザーワークフロー、環境設定の問題) を検出します。E2E テストは、包括的なスイートでは数分から数時間で実行されます。
• パフォーマンステスト: 負荷時のソリューションの動作を検証します。パフォーマンステストでは、現実的なトラフィックパターンでの応答時間、スループット、リソース消費、ガバナ制限の近接性を測定します。パフォーマンステストでは、パフォーマンスを低下させ、本番稼働前に N+1 クエリパターンを捕捉し、ピークシーズン前に業務量の余裕を検証する変更のリリースを回避します。パフォーマンステストには本番同様のデータ量が必要で、専用のテスト環境で実行されます。

テストピラミッド戦略を実装する: 多数の高速単体テスト、より少ないインテグレーションテスト、選択的な E2E テスト、負荷時に個別に検証されたパフォーマンステスト。このバランスにより、インテグレーションポイントが正しく機能し (インテグレーションテストでコンポーネント間の問題が捕捉され)、ユーザーエクスペリエンスが許容される (E2E テストで完全なジャーニーが検証される) と同時に、迅速な反復 (高速な単体テストですぐにフィードバックが提供される) が可能になります。

CI パイプラインでのテスト実行を自動化します。コミットの前にテストスイートを手動で実行するのではなく、CI ですべてのコミットの前にテストスイートを自動的に実行できるようにします。自動テストでは、回帰がすぐに検出され、品質標準が一貫して適用されます。また、期限内に手動テストが省略可能になった場合に発生する品質の徐々に低下を防ぎます。

継続的インテグレーション (CI) および継続的リリース (CD) パイプラインにより、コードコミットから本番リリースまでのパスが自動化されます。CI/CD は、人為的ミスを減らし、フィードバックを迅速化して、一貫した品質チェックを提供し、迅速なリリースケイデンスを可能にします。

• 継続的インテグレーションでは、すべてのコードコミットが自動的に構築、テスト、検証されます。開発者がバージョン管理にコミットをプッシュすると、CI システムは新しい組織の立ち上げ、変更のリリース、自動化されたテストスイートの実行、静的コード分析の実行、テストカバー率の要件の確認、結果のレポートを数分で実行します。迅速なフィードバックにより、開発者は数日後に手動でインテグレーションテスト中に問題を発見するのではなく、コンテキストが新鮮なうちに問題を修正できます。

メインブランチへのマージを許可する前に CI の成功を要求します。この規則 (多くの場合「メインの保護」と呼ばれる) により、他の開発者をブロックする共有ブランチに破損したコードが蓄積されるのを防ぐことができます。CI ゲートを使用する保護されたブランチは、メインブランチを常にリリース可能にし、Release When Main Happens to Work (メインがリリース時に出社する) ではなく、リリースオンデマンドでリリースできるようにします。

• 継続的リリースでは、検証済みの変更が本番環境に自動的にリリースされます。CI が分離された環境の変更を検証したら、CD パイプラインはインテグレーション Sandbox にリリースされ、追加のテストが実行され、ステージングにリリースされ、最終検証が実行され、必要に応じて本番に自動または手動承認ゲート後にリリースされます。

本番リリース中のブラスト半径を制限する段階的なリリース戦略を実装します。

• 青緑の導入: 2 つの同じ本番環境を維持します。トラフィックは青い環境に転送され、緑の環境は新しいリリースを受信します。検証後、トラフィックは緑の環境に切り替わります。青い環境はインスタントロールバック対象として実行されたままです。
• Canary リリース: 完全なリリースの前に小さなユーザーサブセットへの変更をリリースします。エラー率、遅延、ユーザー行動を監視している間、最初のカナリアはわずかな割合のトラフィックを受信します。成功したカナリアは段階的に拡大します (例: 5% から 25%、50%、100%)。Canary リリース中に検出された問題は、すべてのユーザーに影響する前にリリースを中止します。Canary リリースは、外部ルーティングレイヤーまたは機能フラグを使用して機能の公開を選択できるようにする Salesforce ソリューションに適しています。
• 機能フラグ: リリースのタイミングに関係なく、機能表示のランタイム制御を有効にします。新機能は本番にリリースされますが、明示的に有効化されるまでフラグの陰に隠れます。機能フラグでは、コードをリリースするのではなくフラグを切り替えて、カナリアのリリース、A/B テスト、段階的なロールアウト、インスタントロールバックがサポートされます。

注意: Canary と青緑の導入パターンは、リソース割り当てとトラフィック分散制御を介して CloudHub 2.0 にリリースされた Heroku または MuleSoft アプリケーションでホストされるカスタムアプリケーションに適用されます。Salesforce Platform のコアメタデータリリースは、オールオアナッシングトランザクションです。

コードとしてのインフラストラクチャ (IaC) では、環境の定義 (組織の形状、メタデータ、連動関係、および機能させるための設定とシードデータ) を、各組織で手動で設定するのではなく、バージョン管理されたソースとして扱います。Salesforce では、プロビジョニングするサーバーがないため、IaC は環境を構成する方法を管理し、その環境のハードウェアを管理しません。コード化された環境は、再現性があり、比較可能で、使い捨てであり、それこそが漂流を防ぐ要因です。

環境は、手動設定ではなくソースから定義されます。スクラッチ組織定義ファイルでは、エディション、有効化された機能、設定が指定されるため、誰でも (パイプラインでも) 同じ破棄可能な組織をオンデマンドでスピンアップできます。Sandbox は、コピー種別とテンプレートの名前を指定する定義からプロビジョニングされ、コピー先の本番組織から設定を継承するため、インテグレーションとステージングに忠実度の高い環境が提供されます。パッケージ定義では、ソリューションのコンポーネントと連動関係が宣言されるため、長期間使用されている組織の累積状態に依存するのではなく、ソースからビルドを複製できます。

すべての環境で想定されるベースラインもバージョン管理されます。カスタムメタデータ、指定ログイン情報設定、カスタム設定定義はメタデータとしてリリースされ、設定値と参照レコードはバージョン設定されたシードデータから読み込まれます。両方の環境をコードと共にソース管理することで、各環境は手動で設定されたベースラインではなく、既知の一貫したベースラインから開始されます。

このように環境をコーディングすると、そのソースで設定ドリフトが攻撃されます。環境の定義がバージョン管理にある場合、環境間の違いはサイレント発散ではなく目に見える相違として表示され、ドリフトした環境をデバッグするよりも迅速にクリーンな環境を再構築できます。ソースからの再プロビジョニングにより、環境が破損した場合のリカバリが短縮され、パイプラインで変更ごとに使い捨ての環境を構築できます。手動設定は必要ありません。

Sandbox は、本番データや設定を危険にさらすことなく、開発、テスト、トレーニング用の分離された環境を提供します。効果的な Sandbox 戦略では、環境の忠実度 (Sandbox と本番の一致度) とコストおよび更新頻度のバランスを取ります。

• Developer Sandbox は、個々の機能開発用の軽量な分離環境を提供します。開発者は、Developer Sandbox を使用して、共有連動関係を使用したインテグレーションテストを行い、日常業務のためにソース管理からスクラッチ組織を作成します。Developer Sandbox とスクラッチ組織は頻繁に更新され、設定が本番と同期されます。
• Integration Sandbox (Developer Pro または Partial Copy) は、複数の機能が統合およびやりとりされる共有環境を提供します。Integration Sandbox には、完全なデータコピーのコストと複雑さなしで現実的なワークフローをテストするのに十分な本番データが含まれています。インテグレーションテストは、ステージングに昇格する前に Integration Sandbox に対して実行されます。
• ステージングSandbox(フルコピー)は本番環境の構成とデータをミラーリングし、本番環境への導入前の最終検証を行います。ステージング Sandbox は本番環境よりも前にリリースを受け取るため、リリース手順、パフォーマンス特性、データ移行スクリプトを本番環境でテストできます。ステージング Sandbox は四半期ごとまたはメジャーリリース前に更新されます。
• トレーニングSandboxは、実際の顧客データを公開することなく、ユーザーのトレーニングとデモのための現実的な環境を提供します。Training Sandbox には、合成データや匿名化された本番データが含まれている場合があります。トレーニング環境は長期間安定したままで、一貫したトレーニング資料と認定プロセスをサポートします。

Sandbox の更新とデータの読み込みを自動化します。手動の Sandbox 更新はボトルネックになり、本番のようなデータで頻繁にテストできません。データ読み込みスクリプトと組み合わされた自動更新手順により、オンデマンドの環境リセットが可能になり、継続的なインテグレーションパイプラインと手動テストのニーズの両方がサポートされます。

注意: エージェントエンタープライズでは、「Sandbox」には 2 つの異なる意味があります。上記の Sandbox は環境であり、変更が本番環境に到達する前にチームが構築およびテストする組織の独立したコピーです。エージェントのアクションのサンドボックス化は異なります。これは、自律アクションの実行場所と実行方法を、範囲設定済み権限、制限されたオブジェクトおよびインテグレーションアクセス、制御された実行によって制限するランタイム境界であり、エージェントが意図した範囲を超えるアクセスができないようにします。この 2 つは補完的です。Developer Sandbox は本番以外のデータに対してエージェントのアクションを検証するものであり、アクション Sandbox は本番でそれらのアクションを含むものです。

自動パイプラインを使用しても、リリースにはリスクが伴います。安全な導入方法: 検証、監視、制御された実行によってリスクを軽減します。

• 導入の検証: 変更を確定せずに、導入をドライランとして実行します。検証では、実際のリリースの前にリリースエラー (欠落している連動関係、コンポーネントの競合、無効な参照) が検出されます。Salesforce では、UI と CLI の両方を使用した検証リリースがサポートされているため、実際のリリースがメンテナンスウィンドウを待機している場合でも、本番環境で営業時間中に検証できます。
• リリース監視: リリース中およびリリース後に主要な評価指標を監視します。エラー率、パフォーマンス評価指標、ユーザーフロー成功率、API 消費を監視します。リリース後に突然変更されると、調査が必要な回帰が発生し、ロールバックされる可能性があります。自動監視では、リリース前とリリース後の総計値が比較され、統計的な偏差がしきい値を超えた場合にアラートが表示されます。
• リリースランブック: 前提条件、実行ステップ、検証チェック、ロールバック手順、コミュニケーション計画などのリリース手順を文書化します。Runbooks は、ストレスの多い部族のKnowledgeの儀式から誰でも実行できる定期的な手順にリリースを変換します。Runbook は、学んだ教訓を把握し、問題の再発を防止するリリースの振り返りを通じて進化します。
• ロールバック機能: リリースに失敗した場合のエスケープパスを提供します。Salesforce メタデータのロールバックでは、ネイティブのロールバックコマンドではなく以前のバージョンを再リリースする必要があるため、バージョン管理が重要になります。すべての本番バージョンのリリースパッケージを管理し、迅速な再リリースを可能にします。データの変更については、復元を有効にするリリース前のバックアップを維持します。設定変更については、[設定変更履歴] で以前の値を追跡します。

リリースの影響がより少ないユーザーに影響するトラフィックの少ない期間にリリースをスケジュールします。週末や夜間のリリースでは、ビジネスリスクは最小限に抑えられますが、運用負荷は増加します。ユーザーへの影響とチームの持続可能性のバランスを取ります。堅牢な導入方法と包括的な監視機能を備えたソリューションは営業時間内に安全に導入できますが、実績のないソリューションでは信頼性が確立されるまで営業時間外の導入のメリットを得られます。

構成は、ソリューションの動作 (組織の設定、機能、権限、インテグレーション、カスタマイズ) を制御するメタデータです。構成の変更は、コードをリリースすることなくすぐに実行中のソリューションに影響するため、構成管理は運用の安定性にとって不可欠です。

コードと共にソース管理でバージョン設定。プロファイル定義、権限セットの割り当て、カスタム設定、プラットフォームイベント定義、指定ログイン情報、リモートサイト設定はすべてバージョン管理に属します。バージョン管理された設定により、リリースの自動化、変更追跡、環境の一貫性、ロールバック機能が有効になります。

設定ドリフトを検出して修正します。時間が経つにつれて、管理者が直接変更を加えたり、ホットフィックスが通常のリリースプロセスをスキップしたり、文書化されていない回避策が蓄積されたりするため、本番組織は文書化された設定からずれていきます。本番設定とバージョン管理の自動比較によりドリフトが明らかになります。四半期ごとのドリフト検出と修正をスケジュールして、リリースが予測不能になるほど設定負債が累積しないようにします。

設定の決定とその根拠を文書化します。将来のメンテナは、何が設定されているかだけでなく、その理由も理解する必要があります。組織の共有設定を [取引先] の [非公開] に設定し、[取引先責任者] の [公開] に設定するには、この決定につながったビジネス要件を説明するドキュメントが必要です。文書化した根拠がないと、将来の変更でビジネスプロセスに埋もれている前提が破綻するリスクがあります。

自動化により、反復的な手作業が排除され、人為的ミスが減少し、人員の増加に比例することなく業務を拡張できます。Salesforce ソリューションの場合、自動化の商談は宣言型プラットフォーム機能、プログラムによる自動化、運用手順に及びます。

Salesforce の宣言型自動化ツールである Flow Builder、数式項目、入力規則、承認プロセスを使用すると、開発者以外のユーザーがコードなしで複雑なビジネスロジックを実装できます。宣言型自動化により、ガバナンスのメリット (システム管理者はリリースなしで変更可能)、透明性 (ビジュアル設計ドキュメント自体)、プラットフォームの最適化 (多くの場合、宣言型操作は同等のコードよりも効率的に実行されます) が提供されます。

• Flow Builder: ユーザー操作、データ操作、ビジネスロジック、統合を組み合わせた複雑なプロセスを自動化します。フローは、連動ルックアップを使用したレコードの作成、条件付き承認ルーティング、複数ステップのデータインポート、スケジュール済みクリーンアップジョブ、エラー通知ワークフローなどの一般的なパターンを処理します。自動起動フローは、レコードの変更、スケジュールされた間隔、またはコードからの明示的な呼び出しで実行されます。画面フローでは、ユーザーの入力に基づいて分岐ロジックを使用して、複数ステップのプロセスを実行できます。

再利用性とメンテナンス性のためのフローを設計します。サブフローは、複数の親フローで再利用される一般的なパターン (エラー処理やレコードのロックロジックなど) をカプセル化します。適切な名前のフロー変数と説明によって、将来のメンテナが理解できるセルフドキュメントロジックが作成されます。モジュラーフロー設計により、インテグレーション前に個々のコンポーネントをテストできます。

• 数式項目: コードやデータベースを更新することなく、他の項目から動的に値を計算します。数式では、複雑な計算、条件付きロジック、日付算術、テキスト操作がサポートされます。数式項目は、レポート、リストビュー、入力規則、フローで機能し、さまざまなコンテキストで一貫した計算を実現します。数式は、データベースストレージを消費しず、レコードアクセス中にその場で計算されるため、効率的に実行されます。
• 入力規則: 保存時にデータ品質を適用します。入力規則は、データ入力エラーを検出し、ビジネスルールを適用して、無効な状態遷移を防止します。データソース (UI、API、データローダー、インテグレーション) に関係なく、標準オブジェクトとカスタムオブジェクトに入力規則を配置してエラーを検出します。巧妙に作成された入力規則のエラーメッセージは、分かりにくい技術メッセージでユーザーをストレスにさせるのではなく、問題を修正するようにユーザーを導きます。
• 承認プロセス: 状況を進める前に、必要な承認を通じてレコードを転送します。承認プロセスでは、署名機関階層、コンプライアンスレビュー、法的承認、複数関係者の同意ワークフローを実装します。承認プロセスでは、カスタム開発なしで誰がいつ何を承認したかを記録する監査履歴が自動的に提供されます。

宣言型の自動化では多くのシナリオが処理されますが、複雑な要件やパフォーマンスの制約により、Apexでプログラムによる自動化が必要になる場合があります。Apex の効果的な自動化により、保守性とガバナンスの課題に対してパワーと柔軟性のバランスを取ることができます。

• トリガーフレームワークは、データベーストリガーロジックの一貫した構造を提供します。適切に設計されたトリガーフレームワークは、懸念事項 (ロジックを実行するタイミング、実行するロジック、連動関係の順序) を分離し、コードを変更することなく個々のハンドラーを有効化/無効化し、コンテキスト追跡によって再帰の問題を防止します。トリガー フレームワークにより、関連のないロジックがメンテナンス不可能な単一要素に蓄積される「1 つの大きなトリガー」アンチパターンを回避することで、Apex 自動化のメンテナンス性が向上します。
• Batch Apexは、大量のデータをチャンクで非同期に処理し、同期実行でタイムアウトする操作はガバナ制限に従います。一括処理ジョブでは、データのクリーンアップ、オブジェクトの境界を越えた一括更新、レコードごとに複数のクエリが必要な複雑な計算、データ移行操作を処理します。一括処理ジョブを緊急用に設計します。同じジョブを 2 回実行すると、重複作業や破損がなく、同じ結果になるはずです。
• キュー可能 Apex チェーンは、明示的なジョブ シーケンスを介して非同期で動作します。future メソッドが起動して忘れられるのに対し、Queueable Apex では、あるジョブの完了で次のジョブがトリガーされる構造化された順序を使用できます。キュー可能ジョブでは、API コールアウトに続いてデータ処理、複数フェーズのデータ変換、指数バックオフによる再試行ロジックなど、複雑なオーケストレーションがサポートされます。
• スケジュール済み Apex は、ジョブを一定の間隔で実行します。スケジュール済みジョブは、定期的なクリーンアップ、夜間のデータ同期、1 時間ごとのインテグレーションアンケート、終業時の処理を処理します。トラフィックの少ない期間にジョブをスケジュールし、実行されなかったことを検出する監視を実装します。スケジュールされた間隔がビジネスニーズに真に対応しているか、イベント駆動型トリガーの方が応答時間が短いかを検討します。

業務可視化のためのプログラムによる自動化を設計します。ログの開始時刻/終了時刻、処理されたレコード件数、発生したエラー、パフォーマンス評価指標。一括処理ジョブがサイレントで失敗すると、数日後にユーザーがデータの問題に気付くまで気付かないことが多くあります。プロアクティブなログとアラートにより、サイレント障害が診断可能なインシデントに変換されます。

プラットフォームイベントにより、生産者が消費者を知らずにイベントを公開し、消費者は生産者に依存せずにイベントを登録するイベント駆動型アーキテクチャが可能になります。イベント駆動型アーキテクチャでは、コンポーネントが分離され、非同期処理が可能になり、複数言語の統合パターンがサポートされます。

• **プラットフォームイベント公開:**重要なビジネス発生について関心のある登録者に通知します。注文の実行、支払処理、履行の完了、SLA 違反、エラー条件はすべて、公開する価値のあるイベントを表します。イベントペイロードには、登録者が追加のクエリなしで適切に反応するための十分なコンテキストが含まれます。トリガー、フロー、Apex、APIコールからイベントを公開することができるため、イベントの調達を柔軟に行うことができます。
• **プラットフォーム イベント登録:**Apex トリガー、フロー、または外部インテグレーション プラットフォームを介して公開済みイベントに応答します。登録者はイベントを非同期で処理します。つまり、パブリッシャーは登録者の完了を待機しません。イベント駆動型処理では、大量の同期トランザクションで制限を消費するのではなく、別々の実行コンテキストに作業を分散することで、ガバナ制限を尊重します。
• **イベント再生:**登録者が過去のイベントを処理できるようにします。プラットフォームイベントリプレイ ID を使用して、特定の地点のイベントをリプレイします。外部登録者は、自分の再実行 ID の状態を管理する必要があります。配信は少なくとも 1 回行われるため、重複処理が可能です。登録者ロジックで処理します。登録者の復旧要件に基づいてイベント保持を設定します。大規模なプラットフォームイベントの場合は 72 時間、従来の標準イベントの場合は 24 時間あれば迅速な復旧が可能です。長期間の保持で災害復旧シナリオがサポートされます。

イベントの安定性を設計します。イベントスキーマは、プロデューサーとコンシューマー間の契約になります。スキーマの変更には、複数のチームやシステム間の調整が必要です。行動を拡張するときに、既存の項目を変更するのではなく、新しい項目を追加します。変更を破棄するときにイベントを明示的にバージョン管理します。

インシデントとは、通常の業務を復元するために対応が必要な、サービスに対する予期しない中断または低下です。効果的なインシデント管理では、問題をすばやく検出し、適格な対応者に転送して効率的に解決し、学習を抽出して再発を防止します。

• 検出速度: インシデントの影響期間を決定します。問題を迅速に検出すればするほど、対応を開始する前に蓄積される被害が減少します。検出メカニズムには、自動監視アラート (観測システムから)、ユーザーレポート (サポートチケットと直接エスカレーション)、外部監視 (ネットワーク外からの合成トランザクションとアップタイムサービスチェック) が含まれます。

技術的な重要度ではなくユーザーへの影響でインシデントに優先度を付けます。たとえば、内部一括処理ジョブに影響する API エラーの緊急度は、ログインの失敗によってすべてのユーザーアクセスが妨げられる緊急度とは異なります。

インシデントの重大度によって、応答のタイミングとエスカレーションパスが決まります。

対応担当者、エスカレーション方法、維持するコミュニケーションケイデンス、チーム間の調整方法など、明確なインシデント対応手順を確立します。高ストレスインシデント時にオンコールエンジニアが従うことができるランブックの手順を文書化します。文書化されていないTribal Knowledgeは、問い合わせ先と実行する手順を把握している間に対応の遅れを生み出します。

• **オン コール ローテーション:**すべてのインシデントに対応する少数のヒーローを焼き尽くすのではなく、チーム メンバー間で運用の負荷を分散します。オンコールローテーションでは、補償範囲の要件 (常に対応可能なユーザー)、エクイティ (全員が負担を分担)、持続可能性 (激しいインシデント後の復旧時間が必要) のバランスを取ります。

明確な引き継ぎと文書化した責任を使用して、オンコールのローテーションを構築します。プライマリオンコールは初期応答を処理し、セカンダリオンコールはプライマリが支援を必要とする場合にエスカレーションを行い、プライマリが対応できない場合は引き継ぎます。オンコールシフトは適切なサイズにする必要があります。たとえば、1 週間から始めて 2 週間を超えないようにします。シフトが短いほどコンテキストの切り替えが頻繁に行われ、シフトが長いほど燃え尽きるリスクが高まります。個人の債務を事前に計画できる循環をスケジュールします。

• **エスカレーション パス:**追加のリソースを含めるタイミングと方法を定義します。明確なエスカレーション条件により、2 つの失敗モードを回避できます。早すぎるエスカレーションではシニアエンジニアが下級生が処理できる問題に時間を浪費し、上級生が経験を超える問題に苦労してエキスパートのサポートが空回りする遅延エスカレーションです。通常、エスカレーション条件は 3 つのカテゴリに分類されます。進行状況が 30 分経過していないなどの時間ベースのトリガー、現在通話中でない専門知識を必要とする問題などの複雑さトリガー、重大度 1 インシデントなどの重大度トリガーです。重大度 1 インシデントは常にリーダーにエスカレーションされます。

オンコールエンジニアに必要なアクセス権、ツール、情報を提供します。本番アクセス権のないオンコール状況では、ユーザーがアクセスを待機している間にストレスが発生し、インシデント期間が延長されます。On-call Toolkit には、本番アクセスログイン情報、ランブックアクセス、ダッシュボードリンクの監視、エスカレーション取引先責任者、ベンダーサポート手順、コミュニケーションテンプレートが含まれます。

オンコールの義務に公平な報奨を与える。オンコール作業では個人の時間が中断され、ストレスが生じます。報酬方法には、追加報酬、代替休暇、または他の責任を軽減するローテーションクレジットが含まれます。公平な報酬がない場合、オンコールのローテーションは恨みを買い、品質エンジニアはワークライフバランスを尊重する組織から去ります。

• 無責任な死後: 正直な議論を妨げる恐れを生じさせることなく、インシデントから最大限の学習を引き出します。責任のない文化は、複雑なシステムで人々がミスをすることを認め、過去のインシデントで個人を罰するのではなく、将来のインシデントを防止するシステムの改善に焦点を当てています。

すべての重大度 1 と重大度 2 のインシデント、および新しいパターンや全身の問題が明らかになったインシデントに対して事後調査を実施します。死後のタイミングは重要です。レビューの実施が早すぎると不完全な情報になり、遅すぎると記憶が薄れるリスクがあります。インシデントの解決後、合理的な期間 (24 ～ 48 時間) 内に事後のスケジュールを設定し、詳細を最新の状態に保ちながらデータ収集の時間を確保します。

以下を捕捉して、一貫した形式で死後を文書化します。

• タイムライン: 初期検出から解決までのイベントの時系列順。タイムスタンプ、実行されたアクション、観察された結果、行われた決定を含めます。タイムラインの再構築により、対応の有効性が明らかになり、遅延が特定されます。
• 根本原因: インシデントの発生を可能にしたシステムの脆弱性。近接原因 (直接トリガー) から、システム原因 (トリガーを結果的とした設計またはプロセスのギャップ) に移行します。「エンジニアによる不正なコードのリリース」がおおよその原因です。「Deployment pipeline lacks automated testing catch this error class (リリースパイプラインでこのエラークラスを捕捉する自動テストがありません)」がシステム的な原因です。
• 影響: ユーザーへの影響期間、影響を受けるユーザー数、収益への影響、データ整合性の懸念、評価の低下。数値化された影響ガイドでは、防止作業の優先度が付けられます。つまり、10 万ドルの影響があるインシデントの防止は、10 万ドルの影響があるインシデントの防止よりも多くの投資が必要です。
• 防止: 再発を防止する特定のアクション項目。効果的な防止項目は具体的であり、アクション、割り当て先、スケジュール済み完了が含まれます。たとえば、インテグレーションスモークテストを CI パイプライン (所有者: Jane、完了者: next sprint) に追加します。漠然とした防止項目 (「テストの改善」など) は、誰も実行すべきアクションを知らないため無視されます。
• 検出の改善: 類似インシデントをより迅速に検出する方法。ユーザーレポートで検出されたインシデントは、監視ギャップを示します。改善項目には、新しいアラート、より適切な計装、クリティカルパスの統合監視が含まれる場合があります。

死後の所見を広く共有する。組織の学習には、直属のチームを超えた共有が必要です。会社全体で共有される事後情報では、システムの動作、一般的な障害パターン、効果的な対応手順に関するKnowledgeが提供されます。公開検死 (外部に公開) は透明性を示し、顧客がサービス品質へのコミットメントを理解するのに役立ちます。

オペレーショナルエクセレンスは、測定、学習、改善への継続的な投資を必要とする継続的なプラクティスです。運用を1回限りの設定として扱うチームは、システムが複雑になり、Operational Knowledgeが拡散するにつれて、時間の経過とともに機能が低下していきます。継続的な改善を受け入れるチームは、継続的な努力で価値を高め、運用能力を高めます。

「2025 State of AI-Assisted Software Development Report (2025 年 AI 支援ソフトウェア開発状況レポート)」に基づく DevOps Research and Assessment (DORA) プログラムの DORA 評価指標では、ソフトウェアデリバリと運用パフォーマンスについて研究で検証された基準が提供されます。優れたデリバリパフォーマンスのチームは、次の 5 つの主要な評価指標で非常に優れた結果を示します。

DORA では、これらの 5 つの総計値をスループットと不安定性の 2 つの要素に分類しています。スループットは、変更のリード タイム、導入頻度、失敗した導入リカバリ時間で構成され、本番に移行する変更の量を測定します。不安定性には、残りの変更失敗率と再作業率の総計値があり、これらのリリースの進捗を測定します。

• リリース頻度: 本番組織にリリースする頻度を測定します。最も変化の早いチームは、オンデマンドでリリースします。多くの場合、1 日に複数回リリースされます。頻繁なリリースにより、迅速なフィードバックが可能になり、小さな変更によるリリースリスクが軽減され、より迅速な機能提供との相関関係が得られます。リリース頻度が低いと、チームがリリースの手間を省き、リリース頻度が低いと各リリースのリスクが高まるという悪循環が発生します。
• 変更のリードタイム: コードのコミットから本番リリースまでの時間を測定します。1 日未満のリードタイムは配送パフォーマンスが高いことを示す強力なシグナルであり、1 時間以内のリードタイムは優れた配送能力を示します。短いリードタイムにより、ユーザーのニーズ、競合の脅威、セキュリティの脆弱性に迅速に対応できます。長いリードタイムは、過剰なプロセスオーバーヘッド、不十分な自動化、組織の機能不全を示します。
• 変更失敗率: 修正が必要な本番インシデントの原因となったリリースの割合を測定します。最も信頼性の高いチームは、この率を一貫して低く保ちます。これは、すべてのリリースのほんの一部です。変更の失敗率が高い場合は、テストが不十分であるか、リリースの検証が不十分であるか、適切な品質チェックが行われずに変更が急がれていることを示します。
• Failed Deployment Recovery Time (FDRT): 即座の介入が必要なリリースの失敗から回復するまでの時間を測定します。1 時間以内の復旧は、配送の成熟度を示す強力なシグナルです。復旧時間が短いということは、インシデント対応が成熟していること、効果的なロールバック機能があること、ランブックが熟練されているということです。復旧時間が長い場合は、リリースの検証が不十分である、自動ロールバックがない、本番インシデントの所有者が不明瞭であることを示します。
• Deployment Rework Rate: 本番インシデントが原因で計画外のリリースが実行される頻度を測定します。手戻り率が低いと、下流の修正作業が発生しない安定した十分にテストされたリリースになります。手戻り率が高いということは、本番インシデントが緊急リリースを頻繁に促進し、本番前のテスト、リリース検証、または変更管理プラクティスにギャップが生じているということです。

DORA 評価指標を継続的に測定し、経時的なトレンドを把握します。改善の軌道は絶対値よりも重要です。品質を維持しながら月次リリースから週次リリースに改善しているチームは、進歩を示しています。組織全体に表示される運用ダッシュボードで総計値を追跡し、運用パフォーマンスと改善目標への進捗に関する透明性を確保します。

• Sprint retrospectives: 運用インシデント、導入の課題、プロセスの摩擦、チームの原動力など、最近の作業から学習した内容を抽出します。遡及は、危機を待つのではなく、定期的 (1 回または 1 か月ごと) に実行し、継続的な反省のリズムを生み出す必要があります。

参加とアクション可能な結果を奨励する構造化された形式を使用して、振り返りを実行します。一般的な形式は次のとおりです。

• Start/Stop/Continue (開始/停止/続行) - 何を開始すべきか、やめるのか、続けるべきか?
• Mad/Sad/Glad - 最近の経験に関する感情的な考察
• タイムライン - スプリントイベントを再構築し、パターンを特定します)。

所有者と完了日を使用して、遡及的インサイトを具体的なアクション項目に変換します。長い議論は生まれるが、何も行動しない回顧展は時間を浪費し、皮肉を生む。効果的な振り返りにより、セッションごとに 2 ～ 3 個のアクション可能な改善がもたらされます。チームがフォローアップの責任を負うように、遡及全体でアクション項目の完了を追跡します。1 人のユーザーがディスカッションを独占できないように、進行役を必ず交代してください。

• **運用レビュー:**四半期または月次のビジネスレビューを通じて、運用の健全性を集計します。運用レビューでは、トレンドデータを検証し、目的と比較し、改善の機会を特定して、改善投資を割り当てます。また、これらのレビューはリーダーシップも関与し、機能開発に対抗できる業務改善作業のリソースを確保します。

レビューに業務評価指標を含める:

• 可用性: ユーザージャーニーおよび全体的な実績と目標の比較
• パフォーマンス: パーセントフローおよびクリティカルフロー別の遅延トレンド
• インシデント: 重要度、平均検出時間、平均解決時間別に件数
• リリースの健全性: 頻度、成功率、ロールバック頻度
• 運用負荷: オンコールページ、手動介入、作業時間

レビューにより、危機発生時にのみ注意を引く目に見えないバックグラウンド作業として業務を扱うのではなく、優れた運用性に関する説明責任が創出されます。定期的な業務レビューは、持続可能な業務への組織のコミットメントを示します。

遡及的に最近の作業の進捗状況を確認し、業務レビューで健康状態を集計してリーダーに報告します。エンジニアリングレビューは、チームが業務のシグナルを配送の決定に変換する定期的なケイデンスです。ダッシュボード、インシデントのトレンド、およびシステムで生成されるエラー予算をリリース計画とバックログの優先度に結び付けます。このレビューを実行することで、作業者が所有する業務状態が維持され、後付けではなく計画に組み込まれます。

• リリース計画: 機能範囲と共に運用準備状況を第一級の入力として扱い、順序を変更してブラスト半径を制限し、エラーバジェットがなくなったらリリースを保留します。これにより、リリースの規律とビジネスの優先度が、期限のプレッシャーを受けることなく意図的に調整されます。
• バックログトリアージ: 業務作業 (インシデントアクション項目、防止タスク、技術的負債、ギャップの監視など) を機能作業と同じバックログに配置して、業務量で競合させます。定期的なトリアージによって所有者と優先度が割り当てられ、死後の作業から確定作業へのループが閉じられます。

• 運用準備状況レビュー (ORR) は、本番稼働の開始前に新機能またはシステムが運用要件を満たしているかどうかを評価します。ORR は、稼働開始後の修正よりもコストが低い場合に開発中に運用上のギャップを把握することで、運用上の災害を回避します。

新しいソリューションの本番稼働開始、主要な機能、運用上の影響を含むアーキテクチャの変更の前に ORR を実施します。ORR のタイミングは重要です。実装が早すぎる、実装が不完全、遅すぎる、運用上の懸念事項がリリースを阻害し、修正をスキップする圧力がかかっているように感じます。

ORR を実施するときに留意すべき懸念事項と質問は次のとおりです。

• 監視とアラート: 十分な評価指標が測定されているか?障害シナリオのアラートは存在しますか?ダッシュボードに健康状態が表示されるように設定されているか?
• ドキュメント: Runbook は一般的な操作に対応していますか?アーキテクチャが文書化され、回答者がシステムを理解できるようになっていますか?エスカレーション手順は明確ですか?
• 導入とロールバック: 導入を確実に実行できますか?ロールバック手順が存在するか?ステージングでリリースが検証されているか?
• パフォーマンスと拡張性: パフォーマンス目標は現実的な負荷で検証されていますか?拡張の余地があるか?ガバナ制限のリスクはありますか?
• セキュリティとコンプライアンス: セキュリティレビューは完了していますか?監査要件を満たしているか?アクセス制御が要件に一致するか?
• 連動関係: 外部連動関係は特定されていますか?インテグレーションパートナーには SLA がありますか?連動関係の失敗に対するフォールバック動作はありますか?

ORR 完了時に本番稼働を開始します。チームは、最善を尽くした環境ではなく、リリース要件になったときに運用上の懸念を真剣に受け止めます。ORR ゲートは、将来のオペレーショナルエクセレンスをますます困難にするオペレーショナル負債の累積を防止します。

学習組織は、業務経験を体系的に取得し、改善された実践に変換します。学習文化は、人々が恐れることなく問題を報告できる心理的安全性、データからパターンを明らかにできるメジャメント、改善のための時間を割り当てるリーダーシップによって決まります。

• 心理的安全性: 問題、ミス、ヒヤリハットについて、処罰を恐れることなく正直に話し合うことができます。心理的安全性に欠けるチームは、破滅的になるまで問題を隠蔽し、早期介入を妨げます。責任のない死後、問題の発見を祝福し、自身の誤りについて話し合うことでリーダーシップのモデル化の脆弱性を通じて心理的安全性を構築します。
• メジャメント: 動作状態を表示します。業務評価指標、インシデントトレンド、DORA インジケーター、ユーザー満足度スコアにより、業務のパフォーマンスと目的のパフォーマンスを比較できます。メジャメントにより、大きな苦情や最近のインシデントではなく、影響に基づいて改善作業の客観的な優先順位付けが可能になります。
• 改善時間: 優れた運用には投資が必要であることを認識します。業務量の 100% を機能に費やしているチームには業務改善のための時間がないため、技術的および業務的な負債が発生し、最終的に危機対応を迫られます。業務改善、技術的負債の削減、ツールおよび自動化への投資のためにエンジニアリング能力を慎重に確保します。この領域は、長期的な特性の劣化を防ぎながら、持続的な特性速度を可能にします。

運用環境を設計上の意思決定に結び付けるフィードバックループを作成します。インシデントによってアーキテクチャの弱点が明らかになった場合は、類似インシデントが発生しないようにアーキテクチャの改善を優先します。監視によってパフォーマンスの低下が明らかになった場合は、最適化作業に優先順位を付けます。リリースの失敗によってテストのギャップが明らかになった場合は、テストカバー率の改善に優先順位を付けます。フィードバックループは、業務が徐々に劣化するのではなく継続的に改善されるという好循環を生み出します。

Operational Excellence では、可観測性に関するソリューションを設計し、自動化されたパイプラインを使用してリリースし、インシデントに効果的に対応し、運用経験から継続的に学習する必要があります。次のチェックリストを確認して、運用の成熟度を評価します。

オブザーバビリティと監視

• ソリューションには、分散トレース用の包括的なログ取得の相関関係 ID が含まれます。
• イベント監視が有効になっており、イベントログファイルがネイティブ制限を超えて保持されるように外部プラットフォームにエクスポートされている
• 組織のベースラインに合わせて調整されたしきい値でProactive Monitoringを設定
• 各リリース後に設定およびレビューされたScale Centerベースライン
• 180 日を超える保持のための監査履歴のエクスポートの設定
• 機密データ項目と規制データ項目の項目監査履歴の有効化 ]
• Data Detect スキャンでは、項目内の機密データが識別および分類され、コンプライアンスの分類と修正を促進する発見があります。
• セキュリティベースラインに対して四半期ごとに状態チェックをレビューし、リスク優先度によって修復された所見を確認
• マイルストーンマーカーと成功率の監視で計測される重要なユーザープロセス
• インテグレーション監視では、すべての外部連動関係の双方向の健全性を追跡します。
• 可用性、遅延、成功率、スループットについて定義されたサービスレベル目標
• アラートアーキテクチャには、重要度レベル、アクション可能なコンテキスト、明確なエスカレーションが含まれます。

DevOpsプラクティス

• ソースからの再現可能なビルドを有効にするすべてのメタデータバージョン管理
• スクラッチ組織または Developer Sandbox による分離された開発のサポート
• 設定変更は、コード変更と同じレビュープロセスに従う
• 設定ドリフト検出は四半期ごとに実行され、修正が文書化されている
• Sandbox 戦略には、開発者、インテグレーション、ステージング、トレーニング環境が含まれます。
• Sandbox の更新とデータ読み込みの自動化
• CI パイプラインが自動テストですべてのコミットを検証する
• 保護されたメインブランチではマージ前に CI の成功が必要
• CD パイプラインは順次検証を使用する環境でリリースされます。
• 本番リリースの前にリリース検証が実行される
• リリース監視では、リリース中およびリリース後の主要な総計値を追跡します。
• リリースランブックでは、手順、検証、ロールバックを文書化します。
• テストピラミッドには、単体テスト、インテグレーションテスト、エンドツーエンドテストが含まれます。
• CI パイプラインでのテスト実行の自動化
• コードレビューには、明示的なレビュー条件を含む 2 つの承認が必要です。
• 徹底的な確認のためにプル要求は小さく (200 ～ 400 行) 維持

自動化と効率化

• 該当する場合に使用される宣言型自動化 (フロー、数式、検証、承認)
• 再利用可能なサブフローを使用してモジュール化されたフロー
• トリガー フレームワークにより、Apex自動化の一貫した構造を実現
• 一括処理ジョブで緊急性と包括的なログ機能を実装
• スケジュール済みジョブは、監視を使用してトラフィックの少ない期間に実行される
• プラットフォームイベントにより、非同期処理のためのイベント駆動型アーキテクチャを実現
• バージョン管理戦略で安定性を確保するために設計されたイベントスキーマ
• 自動化の運用表示には、ログ、監視、アラートが含まれる

インシデント管理

• 自動監視でプライマリインシデント検出を提供
• 明確な応答タイミング要件で定義されたインシデント重要度レベル
• Runbooks で文書化されているインシデント対応手順
• オンコールのローテーションにより、業務負荷をチーム全体に公平に分散
• 時間ベースのトリガーと複雑さベースのトリガーでエスカレーションパスが明確
• オンコールエンジニアに必要なアクセス権、ツール、情報がある
• On-call duty compensationed fair (公正に報酬が支払われるオンコールの義務)
• 重大度 1 および 2 のすべてのインシデントに対して行われた無責任な事後調査
• 死後のドキュメントタイムライン、根本原因、影響、検知の改善、および特定の予防アクション
• 組織の学習のために広く共有されている死後の発見

継続的な改善

• 継続的に追跡される DORA 評価指標 (リリース頻度、リードタイム、変更失敗率、復元時間、再作業率)
• 構造化された形式とアクション可能な結果で定期的に発生する
• 運用レビューでは、四半期ごとまたは月ごとに集計された健全性を評価
• 運用準備状況レビューでは、本番環境で新機能の稼働を開始します。
• 心理的安全性により、問題や間違いについて正直に話し合うことができる
• 業務改善のために意図的に確保されたエンジニアリング業務量
• フィードバックループは、運用環境を設計の改善に結び付ける
• 運用チームだけでなく、全員の責任として捉えられる優れた運用性

適切に構築されたフレームワークに関するフィードバックを共有する。