はじめに

こんにちは。サメ映画をこよなく愛する梅木です。

先日、社内勉強会にて AWS Well-Architected フレームワークの「オペレーションエクセレンス」について発表する機会がありました。その準備のため、あらためてフレームワークのドキュメント(付録: 質問とベストプラクティス)を読み返したところ、思わず「あるある！」と頷いてしまうようなアンチパターンの例を見つけたので、共有したいと思います。

Well-Architected フレームワークってなに？

AWS Well-Architected フレームワークは、AWS上で安全かつ効率的なシステムを設計・運用するためのベストプラクティスを体系的にまとめたものです。クラウド利用を前提としていますが、その考え方はオンプレミス環境のシステムにも応用できます。

詳細については、以下の記事もご参照ください。

blog.serverworks.co.jp

メトリクスを活用した運用評価について

Well-Architected フレームワークには、システムの健全性だけでなく、運用業務を評価するためのベストプラクティスも含まれています。その中で、今回は「OPS09-BP01: メトリクスを使用して業務目標と KPI を測定する」に焦点を当てます。

概要

このベストプラクティスは、運用業務にも「ファクトベースアプローチ」を適用し、運用の状態を数値で把握し、KPIとして設定することを推奨するものです。

たとえは、次のようなアンチパターンが招待されています（一般的なアンチパターンを抜粋）

Tier 1 デスクが、ユーザーからの電話に対応するために設置され、時間が経つにつれて、ワークロードは増えましたが、Tier 1 デスクへの人員は追加されない。通話時間が長くなり、問題が解決されないまま問題が長引くと、顧客満足度は低下するが、経営陣にはそのような兆候が明らかでないため、対策がとられていない。

つまり

顧客対応が追いついておらず、ジワジワと顧客満足度が下がっている
経営陣は、それらに気づいていない

という、非常にリアルな話です。

ベストプラクティスの内容

このベストプラクティスは「運用の正常性を定義する」というカテゴリに分類されています。（OPS 9. 運用の正常性はどのように理解するのですか?参照）

サービスの死活監視やリソース使用率の監視は多くのシステムで行われていますが、この項目が重要視しているのは、運用業務そのものを数値で評価することです。

たとえば、問い合わせへの返答時間、対応したチケット数、平均通話時間などをメトリクスとして設定し、運用の状態をファクトベースで、経営陣にも伝えやすい形で把握することが推奨されています。

サービスの特性によって、運用業務自体を数字(ファクトベース)で評価することは重要な概念です。どんなに優れたサービスでも、問い合わせへの対応が遅れるだけで顧客体験は損なわれてしまいます。

まとめ

Well-Architected フレームワークのドキュメントは、一見すると難解な内容もありますが、この例のように「あるある！」といったアンチパターンを通じて、内容を分かりやすく伝えてくれるものもあります。（皆さんも、ECサイトなどを利用した際に、商品やサービスは素晴らしいのに、問い合わせの返信が遅くてがっかりした経験が一度はあるのではないでしょうか）

皆さんもお時間があれば、Well-Architected フレームワークに目を通してみてはいかがでしょうか。きっと、新たな発見があるはずです！