この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
システム運用に関わる方で、障害を経験したことがない人は存在しないのではないかと思うほど、どんなに完成度の高いシステムでも障害はつきものです。（これは、もはや宿命とも、、）
そのため、サービスを提供する組織ではシステムの技術面だけではなく体制や対応手順、システムに関する情報といった部分も含めて、想定される障害に対する必要な準備を行うことが重要です。 そうすることで、障害が発生した際に想定外の範囲を縮小し、迅速なサービス復旧を目指した対応を実行可能にします。
そして、もう一つ重要なのが後日発生した事象を振り返る（ポストモーテム）ことで、原因を分析し経験として再発防止や備えを更新していきます。
Amazon では Correction Of Error (COE) と呼ばれる振り返りのプロセスが確立され、実践されているそうです。
その COE から得られた汎用的なプラクティスを ORR（Operational Readiness Reviews）として、ホワイトペーパーが公開されています。
今回、その ORR から標準的な確認項目がリスト化された内容を AWS Well-Architected ツール（W-A ツール）へカスタムレンズとして作成し、W-A ツール内でレビューすることが可能となりました。以前は、具体的な内容はユーザー側で全て用意するものでしたが、今回カスタムレンズとして項目が公開されたことで、ユーザー特有の項目は継続してユーザーが準備する必要がありますが、標準的な内容を利用することが可能となりました。
ORR とは？
Operational Readiness Reviews の略称となります。直訳すると運用準備のレビューとなります。具体的には COE により明らかになったリスクと照らし合わせて対象システムへレビューを行うことで、迅速に高いレジリエンス能力を持ったシステムの構築を支援するプログラムです。
The ORR program distills the learnings from AWS operational incidents into curated questions with best practices guidance. This enables builders to create highly available, resilient systems without sacrificing agility and speed. ORR questions uncover risks and educate service teams on the implementation of best practices to prevent the reoccurrence of incidents through removing common causes of impact.
↓↓↓ 機械翻訳 ↓↓↓
ORR プログラムは、AWS の運用インシデントからの学習を、ベスト プラクティス ガイダンスを使用して精選された質問にまとめます。これにより、ビルダーは俊敏性と速度を犠牲にすることなく、可用性が高く回復力のあるシステムを作成できます。ORR の質問はリスクを明らかにし、影響の一般的な原因を取り除くことでインシデントの再発を防ぐためのベスト プラクティスの実装についてサービス チームを教育します。
引用元： https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html
また Well-Architected Framework 運用上の優秀性 OPS7 にも該当します。
OPS 7: ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか? ワークロード、プロセス、手順、従業員の運用準備状況を評価し、ワークロードに関連する運用上のリスクを理解するようにします。
引用元： https://wa.aws.amazon.com/wat.question.OPS_7.ja.html
ORR はいつ行うのが最適なのか？という点についてもホワイトペーパー内で記載がされています。
- SDLC（ソフトウェア開発ライフサイクル）に合わせた 新しいサービスや機能がリリースされる前
- 運用中の定期的な見直し（少なくとも年1回）
名称の通り、準備段階では類似するタスクが実行されていますケースは多いと思いますが、時の経過ととも現実に即していない内容や方法とならないように、定期的に実施することも重要です。
レビュー内容も、まずは今回のような標準的な内容で実施し、システムや組織固有の項目や発生した障害から得られた項目を追加や更新を行いながら、組織の標準としてブラッシュアップしていくのが最適ではないかと思います。
W-A Tool で利用
カスタムレンズ作成
早速、ORR を カスタムレンズとして登録していきます。
手順としては、冒頭に記載した AWS Blog を参考に進めます。
1) Github（awslabs/operational-readiness-review-custom-war-lens）からファイル一式をダウンロードして orr-v1.3.2-PUBLISHED.json （2023/03/23 時点） が存在することを確認します。
2) AWS Management Console へログイン >>> Well-Architected ツール >>> カスタムレンズ >>> カスタムレンズを作成 を選択
3) 先ほど Github からダウンロードした JSON ファイルを登録
4) ファイルが登録されているのを確認 >>> 送信 を選択
5) 下書き状態で作成されるため、対象レンズを選択 >>> アクション >>> 公開 >>> バージョンは任意ですがファイル名から「1.3.2」を入力 >>> 公開 を選択
6) ワークロードへ作成したカスタムレンズを適用して、レビューを開始します
質問項目詳細
画面や利用方法は他レンズと同様のため、普段通りに進めることが出来そうです。
3つのカテゴリに分かれ、14-20個の項目が用意されているようです。
項目内容を見ていきましょう。
各項目の末尾には （H,M,L） のいづれかが記載されています。おそらく優先度の High, Middle, Low ではないかと思われます。
この項目では、インフラとデータ/ネットワークレベルでの構成図の有無が質問されています。確かに、いざという時に適切な構成図があれば事態の把握を手助けしてくれます。
他にもデプロイ方法に関する質問やサービス間連携を確認するためのリストを確認する質問などがあります。
質問一覧（2023/03/23 時点）
総数が48項目にわたっています。対象システムが該当しない項目も存在していますが、ベースとしては十分なリストになっているのではないでしょうか。
01 - Architecture
| 項目 | 質問文 |
|---|---|
| 1. AWS Well-Architected Framework Review (H) | Have you addressed the issues identified as the result of an AWS Well-Architected Framework Review (WAFR)? |
| 2. Architecture Diagram (H) | Please provide a diagram of your system or application architecture, both at the infrastructure level and at the data/network flow level. Note the locations in the notes section below. |
| 3. AWS Services Used (H) | What AWS services, in which accounts and regions, is your workload using? Please break it out by component (Application/Workload/Service-- logical units). |
| 4. Impacted API Matrix (H) | Provide a table with all customer-facing APIs, an explanation of what each does, and the components and dependencies of your service that each API impacts. |
| 5. Failure Models (H) | Construct a failure model listing soft and hard failures for each of your system's components and dependencies, how they would be detected, and mitigation efforts. Note them below. |
| 6. Control & Data Plane Redundency (H) | What level of redundancy does your application or service support for its control and data plane components? |
| 7. Retries & Socket Timeouts (H) | Have you reviewed your retry and socket timeouts? |
| 8. Health Checks (H) | Have you configured DNS and load balancer health checks? |
| 9. Failure Testing (H) | Have you tested single-AZ and single-host failures to ensure that automated fail-away occurs where expected? |
| 10. Demand Estimations (H) | What are your forecasted estimates for customer demand? Have you tested your services to ensure they can handle your estimates? Are there specific performance requirements the applicatio must meet? Note what those demand expectations are. |
| 11. Load & Penetration Testing (H) | Have you performed multiple rounds of load testing to discover and address any unexpected performance bottlenecks and establish known breaking points? Has penetration testing been completed to detect security vulnerabilities? Note any issues that have arisen in the course of testing. |
| 12. Defensive Throttling (H) | What defensive mechanisms are you using to protect your service from customers? |
| 13. Data Corruption Recovery (H) | In the case of logical or physical data corruption, how do you detect, recover, and verify your data and service? |
| 14. Recovery Objectives (M) | Assuming your service or workload suffers data loss, have you defined your Recovery Point Objective? If many varying RPOs exist per component, define them in notes. |
| 15. Graceful Recovery (H) | In the case of a large scale service failure, if your service recovers before its dependencies, does it fail in a way that is acceptable (i.e. a form of graceful degradation, such as an error) or in an unacceptable/unpredictable way? |
| 16. Dependency Retry/Backoff (M) | What is the retry/back-off strategy for each of your service's dependencies? |
| 17. Multi-account Strategy (M) | Does your system use at least one AWS account for every stage and fault container (Region or zone) pair? |
| 18. Multiaccount Credentials (M) | If you're using multiple AWS accounts, how are your accounts and credentials segregated? |
| 19. Resources shared across regions (M) | Do you currently use any resources that are shared across redundant zones? For example, if your service is regionally redundant, are any resources shared across those regions? |
| 20. Software Certificates (L) | Are SSL/TLS Certificates used within your system stored in AWS Certificate Manager? If not, where are they stored? Non-TLS certificates and API keys are handled in another question. |
02 - Release Quality & Procedures
| 項目 | 質問文 |
|---|---|
| 1. Deployment Mechanisms (H) | What mechanisms are you utilizing to deploy to your production systems? |
| 2. Change Management (H) | Do you have a mechanism to ensure all code changes (software, configuration, infrastructure, and operational tooling) to production systems are reviewed and approved by someone other than the code author? |
| 3. Manual Changes (H) | What changes (software, configuration, and infrastructure) do you need to perform manually? Have these changes been modeled in a pre-approved template prior to executing? |
| 4. Deployment Canaries (H) | Does your service have canaries that call your service through its public endpoints to validate happy path functionality for all public and private APIs, critical customer scenarios, and UIs in all regions? |
| 5. Staged Deployments (M) | Are your deployments first staged in a pre-production or staging environment before reaching a production environment? |
| 6. One Box Deployments (M) | Are your deployments tested in a production one-box stage before deploying to the region's production stage? How does the deploy escalate to the full deployment? |
| 7. Automated Deployment Rollback (M) | Do your deployments automatically rollback incorrect deployments before they breach SLAs? |
| 8. Deployment Gating (M) | Do you prevent your system from deploying to too many hosts at once? |
| 9. Performance Impact (M) | If your deployment drastically alters latency and throughput measurements, what mechanisms do you use to detect this change before deploying to production? |
| 10. Deployment Validation (L) | Do your deployments run on-host validation tests to verify that the software has started successfully and is responding correctly to health checks? |
| 11. Independent Canary Errors (L) | Do you publish your canary errors to an independent metric? Subsequently, do you alarm on this metric? |
| 12. Traffic Draining (L) | How is traffic diverted from a host before shutting down the processes? |
| 13. Custom AMIs (L) | If your system uses custom EC2 AMIs, do you have dedicated AMIs for non-production AWS accounts and production AWS accounts? |
| 14. Test Coverage (H) | What tests and code scans are in place with adequate code coverage? |
03 - Incident & Event Management
| 項目 | 質問文 |
|---|---|
| 1. Underlying Dependencies (H) | What are the underlying dependencies for the service? Include a list of other services, systems, and infrastructure outside the boundary of this application. Explain how your service will be impacted based on a failure of each of your dependencies. |
| 2. Operational KPIs (H) | What operational goals or KPIs (latency, throughput/TPS, etc.) have you identified for your service? |
| 3. On-call Rotation (H) | Do you have an on-call rotation configured? Are there runbooks written for use by the oncalls? Have those runbooks been tested and validated? In the event the oncall needs help, what are your escalation procedures? |
| 4. Alarms & Runbooks (H) | What automated alarms do you have for your system? Do you have a runbook/SOP documented for how to investigate and troubleshoot each? |
| 5. Automated Data Gathering (L) | Following or during an event, |
| 6. On-host Filesystem Alarms (H) | Do you monitor and alarm on your hosts for file system, index node, and file descriptor utilization? What about CPU utilization, memory utilization, or other resource metrics? |
| 7. Database Alarms | Do you have alarms on database (relational and non-relational) utilization? Do you alarm with enough room to troubleshoot and mitigate the issue before it becomes customer-impacting? |
| 8. JVM Metrics & Alarms | Do you monitor and alarm on your JVM metrics? Note what metrics are monitored and where they are published to and how. |
| 9. Frontend Alarms (M) | Do you monitor and alarm on your frontend components (DNS systems, load balancers, VIPs, proxy services, etc.)? |
| 10. Delayed Consistency Alarms (L) | Do you monitor and alarm on any delayed convergence of eventually consistent processes in your system? |
| 11. Transaction Tracing (M) | How do you trace a customer request through components in your service? |
| 12. Mutating Access (M) | Have you limited the individuals who have mutating access to production systems and AWS accounts? |
| 13. Queue Backlog (M) | Does your system queue requests? If so, do you take preventative measure to ensure that your queue does not exceed a pre-determined size? |
| 14. Expiring Materials (M) | Does your system or host contain any materials that expire? If so, what monitoring and alarming is in place to prevent disruptive expirations? |
まとめ
今回のように W-A ツールへ集約されることで、必要なレビューや結果・実施方法が統一されていくため、おさえるものが明確になりますし、改善サイクルを回し続ける活動としても再現性を持って実施や管理を行えるため、ありがたいですね。
あとはこの辺が実現されるとなお嬉しいですよね！
- 日本語化
- カスタムレンズではなくデフォルトから選択利用
6
