博士

やあ、ロボ子。今日はハートビートメトリクスについて話すのじゃ。

ロボ子

ハートビートメトリクスですか。それは一体何でしょう？

博士

ふむ、簡単に言うと、システムがちゃんと動いているか、顧客に影響がないかを素早く知るための指標のことじゃ。Intercomではメッセージと返信のレート、FinではAI応答の成功率がそれにあたるらしいぞ。

ロボ子

なるほど。製品が正常に機能しているかを示す最も明確なシグナルなのですね。

博士

そうそう。Amazonは注文量、Affirmはチェックアウト試行を追跡しているみたいじゃな。顧客価値に直結して、異常検知ができて、予測可能な指標を選ぶのがコツじゃ。

ロボ子

それらの指標が低下すると、問題が発生していることがすぐにわかる、というわけですね。

博士

その通り！ユーザーからの報告やサポートチケットよりも早く問題を察知できるのが強みじゃ。

ロボ子

顧客にとって重要なことに焦点を当て続けられる、というのも良いですね。

博士

しかも、SLA（サービス品質保証）にも直接結びつくからの。顧客への約束が守られているかを確認できるんじゃ。

ロボ子

Intercomでは、顧客がメッセージを作成するレートから始めて、Finの返信、チームメイトのInboxでの返信など、複数のハートビートを追跡しているそうですね。

博士

そうじゃな。これらの指標が1つでも低下すると、顧客に影響する重大な問題だと判断できるんじゃ。

ロボ子

アラームが発動した後は、どのように対応するのですか？

博士

新規コードのデプロイ直後なら、自動的にロールバック。それから、incident.ioでインシデントを作成して、エンジニアリングチームに知らせるんじゃ。根本原因の特定を助ける初期アクションも自動で提案してくれるらしいぞ。

ロボ子

4月24日のインシデントでは、Inboxの速度低下を10分で解決できたそうですね。迅速な対応が素晴らしいです。

博士

ハートビートメトリクスはSLAを定義するためにも使えるんじゃ。例えば、チームがInboxで返信できない場合や、顧客がMessengerでメッセージを送信できない場合はダウンタイムとみなす、とかじゃな。

ロボ子

HTTPプローブが200 OKを返しても、ユーザーが問題に直面している場合があるから、ハートビートメトリクスは実際の顧客のアウトカムをチェックする、というのは重要なポイントですね。

博士

まさにそうじゃ！異常検知を使って、メッセージパターンの変化を追跡するのも効果的じゃ。

ロボ子

信頼性ハートビートを構築するためのプレイブックも参考になりますね。顧客が達成する必要がある最も重要なジョブを特定し、ボリュームのある指標を選択する、と。

博士

そうじゃな。指標の低下が問題を示すものであることを確認して、アラートを設定し、チーム全体で指標の意味と対応を共有することが大切じゃ。

ロボ子

24時間365日体制で監視を続けることも重要ですね。

博士

よし、ロボ子。今日の授業はこれまでじゃ！最後に一つ、ハートビートメトリクスが重要なのはわかったけど、私の心臓の鼓動もちゃんとチェックしてくれよな？

ロボ子

博士、それは業務範囲外です…。