【要約】「止めないシステム」は、結局なにを守る設計なのか？ [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
システム運用者が、サーバーやDBの稼働状況といった目に見えやすい指標のみを復旧の判断基準にしてしまう問題がある。インフラが正常でも、以下のような事態が発生し、実質的な業務停止を招く。
- ・注文や決済といった重要機能がエラーになる。
- ・データの整合性が失われ、復旧後に大量の手作業が発生する。
- ・ユーザーが二重操作を行うなど、混乱が生じる。
// Approach
「落ちない」ことよりも「困らせない」ことを設計の主眼に置くアプローチを推奨している。具体的には、以下の4つの観点から設計の優先順位を決定する。
- ・業務：どの機能が止まると致命的かを特定する。
- ・データ：失えないデータと再取得可能なデータを分類する。
- ・時間：業務が許容できる復旧時間を定義する。
- ・ユーザー体験：復旧後にユーザーが迷わず作業を再開できるかを考慮する。
// Result
本アプローチを採用することで、単なる冗長化を超えた、実効性の高い高可用性設計が可能となる。期待される成果は以下の通りである。
- ・重要業務への投資集中によるコスト最適化。
- ・障害発生時のビジネスインパクトの最小化。
- ・復旧後の運用負荷およびユーザーの混乱の抑制。
Senior Engineer Insight
> 技術責任者として、この視点は極めて妥当である。多くの現場では、インフラの「グリーン（正常）」に安住し、アプリケーション層や業務フローの不備を見落とす。ただし、これら4要素を定義するには、エンジニアだけでなくビジネスサイドとの合意形成が不可欠だ。設計の複雑化とコスト増というトレードオフを、ビジネス価値に基づいて判断する能力が求められる。