デザインのための運用：指標とモニタリング

ここからは、本番から開発への フィードバックループを構成する モニタリング、測定の基本と、 リーンな取り組み方を解説します。 まずは理論的な話をしましょう。 ある医師が書いた『複雑なシステムは なぜ故障するか』という論考があります。 筆者が前提としたのは、 主に医療現場の問題ですが、 私たちが読むと、そのままITシステムの ことだと思える内容です。 印象的な記述を挙げてみます。 「変更は新たな形の故障を招く」 「複雑なシステムに内包される 故障の組み合わせは常に変化している」 「すべての複雑なシステムは 常に劣化したモードで動いている」 複雑なシステムに携わった経験が ある人には、どれも深く うなずける言葉でしょう。 複雑なシステムの管理が絡むと、 信頼性エンジニアリングは とても興味深いトピックになります。 その鍵は、運用から開発への フィードバックループを 前にも説明したリーンな方法で 確立することです。 構築、計測、学習のサイクルにしましょう。 大枠は、ある会議でアーネストが 紹介したリーンなモニタリングの手法です。 まず構築です。 本格的なものではなく、 モニタリングの目標を果たせる 最小限の仕組みにします。 計測は、指標を使って行います。 最初のうちは、計測する指標を 広めに選んでおきましょう。 学習では、アプリケーションと 現状のモニタリングの数値を分析し、 結果を元に目標を修正します。 以上を繰り返し、 必要に応じて深掘りします。 サービスパフォーマンスとアップタイム、 ソフトのコンポーネント、システム、 アプリ、パフォーマンス、 セキュリティの領域別に行います。 サービスパフォーマンスとアップタイムの モニタリングは、サービスやアプリの 最上層が対象です。 実際の顧客やトラフィックではないため 「合成チェック」とも呼ばれますが、 動作を確認する最も単純な方法といえます。 次は、ソフトウェアの コンポーネントのモニタリングです。 ここでは、主にホストに存在する ポートやプロセスを見ます。 サービス単位ではなく、レイヤー単位で 各ホストの動作を確認します。 次は、もう１段深い、 CPU（シーピーユー）やメモリといった システムリソースのモニタリングです。 グラフになっている時系列データで、 サービスやホストやプロセスが 正常に動作しているかを見ます。…