BLOG
インテリジェントなサービス設計

投稿:2022年7月25日   |    更新:2022年7月25日

共著者:PagerDutyデータサイエンティストVI、Chris Bonnell氏

EIアーキテクチャシリーズの第4回目、「Intelligent Alert Grouping(インテリジェント・アラート・グルーピング)」についてご紹介します。前回は、インシデント マージを使用して Intelligent Alert Grouping をトレーニングする方法(こちら)と、デフォルト マッチングを改善するためにアラート タイトルを設定する方法について説明しました。今回は、サービスデザインがIntelligent Alert GroupingやPagerDutyアプリの使用感にどのような影響を与えるかについて説明します。

サービスについて

サービスを設計したり、再設計したりする前に、組織で機能するサービスの定義を持つことが重要です。この定義は、理解できる程度に具体的である必要がありますが、複数のチームが抽象的なサービスとは何かを同じように理解できる程度には広範である必要があります。PagerDutyでは、次のような定義を使っています。

サービスとは、チームによって完全に所有される、価値を提供する機能の個別部分である。

所有チームは、サービスを構築し維持するチームであり、あらゆるインシデントに対応することも含まれるため、把握しておくことが重要です。サービスと所有権についての概説は、サービスの定義に関する完全なサービス所有権運用ガイドを参照してください。

サービスやその所有者について考えるだけでなく、サービス名にも気を配る必要があります。サービスディレクトリーに目を通すと、追加の制度的知識がなくても、それぞれのサービスが何であるか簡単に理解できるようになるはずです。簡単に言うと、「Payment Service」という名前のサービスがあるか、すべてのトランザクションサービスはギリシャ神話の神々にちなんで名付けられたという社内文書を知っているか参照して、どのギリシャ神話が支払いを処理するサービスに相当するかを調べるかの違いである。この点については、『フルサービス オーナーシップ運用ガイド』の「サービスのネーミング」のセクションで詳しく説明しています。

サービスやその所有者について考えるだけでなく、サービス名にも気を配る必要があります。サービスディレクトリーに目を通すと、追加の制度的知識がなくても、それぞれのサービスが何であるか簡単に理解できるようになるはずです。簡単に言うと、「Payment Service」という名前のサービスがあるか、すべてのトランザクションサービスはギリシャ神話の神々にちなんで名付けられたという社内文書を知っているか参照して、どのギリシャ神話が支払いを処理するサービスに相当するかを調べるかの違いである。この点については、『フルサービス オーナーシップ運用ガイド』の「サービスのネーミング」のセクションで詳しく説明しています。

PagerDutyアプリでは、サービスはビジネスサービスとは区別されます。ここまでは、すべてサービスに関連する話です。また、ビジネスサービスとの混同を防ぐため、弊社のドキュメントではテクニカルサービスと表記している場合があります。ビジネスサービスは、技術サービスや他のビジネスサービスの集合体であり、通常、ビジネスロジックおよび/または利害関係者に従います。Intelligent Alert Groupingは技術サービスのみを利用し、ビジネスサービスは利用しないため、この記事でサービスという場合、技術サービスのみを指します。

粒度

サービスをどのように分けるか、そのバランスを考えることは自明なことではありませんし、「一長一短」の解決策もありません。基本的には、粒度の高いものと低いもののバランスを取り、交換することになります。例えば、PagerDutyのアプリケーションでは、1つの監視ツールで、その構成機能をすべて別のサービスに分解しています。一方、より広範で粒度の低いサービスの使い方としては、iOSとAndroidの開発を別々のチームが担当している場合でも、すべてのモバイルアプリケーションを1つのサービスとして提供することが挙げられます。後者の例では、モバイルチームが1つしかない組織、モバイルチームがない組織、異なる基準で分割されたモバイルチームがあるため、サービスの構成方法について単一の推奨事項が存在しない理由もよくわかります。

では、どうすればよいのでしょうか。私たちは、サービス定義のナビゲートに役立ついくつかのアドバイスを抽出することができます。まず始めに、所有権について説明します。PagerDutyアプリケーションでサービスを定義する主な理由の1つは、インシデント対応のためです。つまり、サービスの問題に対処できるのは誰か、サービスを所有しているのは誰かを知ることで、組織内で誰がサービスを所有しているかによって、PagerDutyでサービスをどのように定義するかを決めることができます。これは、完全なサービス所有モデルではないものの、望ましいエスカレーションパスがわかっている既存のサービス構造がある場合、その知識を活用できる点で重要です。この場合、インテリジェント・アラート・グループがインシデントをグループ化すると、サービスが希望するエスカレーション・パスにのみ関連していても、このコンテキストではそれが重要であり、達成する最終結果になるのです。

また、現在のプロジェクトを見直して、どれが事実上機能単位になっているかを確認し、それらをPagerDutyで1つのサービスとして定義する必要があります。こうすることで、エスカレーションパスが同じプロジェクトは正しくグループ化されますが、エスカレーションパスの関係で複数のプロジェクトが単一のサービスとして定義され、可視性が損なわれるというシナリオを防ぐことができるはずです。もう少し踏み込んで、常にインシデントが同時に発生している2つ以上のサービスがある場合、それらを1つのサービスに集約する必要があるかもしれません。具体的な例として、メトリクス、ハートビート、ログなどの個別のコンポーネントを持つモニタリング・マイクロサービスがあるとします。これらがそれぞれPagerDutyサービスを持っている場合、ほとんどの場合、インシデントがこれらすべてのサービスに同時にまたがることになるので、代わりにモニタリングマイクロサービス自体として1つのサービスにまとめる必要があります。一方、同じ人が働いているからと言って、別々のプロジェクトが1つのサービスとして定義されている場合、そのサービスは十分に粒度が揃っていない可能性があります。このシナリオでは、PagerDutyアプリに関する限り、サービス内のエンティティはすべて1つの「もの」であるため、どのエンティティが他のエンティティよりも注意を払う必要があるかを判断することは困難です。

ここからどこへ行くべきか

既存のサービス、あるいはこれから作成されるであろうサービスを見て、それらをチェックすることから始めましょう。

  • エスカレーションパス
  • 名称
  • 機能単位

そして、PagerDutyアプリケーションでサービスを定義する際の指針として使用します。Intelligent Alert Groupingは、関連するサービスの下にアラートをグループ化することで、そこからの作業を行います。サービスをゼロから設計したり、サービスの定義を見直したりする場合は、「フルサービス オーナーシップ運用ガイド」で、レスポンスの命名と所有権に関するベストプラクティスを参照し、「(技術)サービス」と「ビジネスサービス」に関するドキュメントもご覧ください。次回は、このシリーズの最終回で、これまで取り上げた内容をすべて再録する予定です。ei-architecture-seriesタグを使って、このシリーズのどの記事もご覧ください。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

book-markタグ: