0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

NewRelicを使ってFour Keysを可視化してみる(④サービス復元時間編)

Posted at

こんにちは!
ポーラ・オルビスホールディングスのITプロダクト開発チームでスクラムマスターをしている川田です。

引き続き、Four Keysの各指標についてNewRelicを利用して可視化することを目指します。前回までの記事はこちらです。今回で最終回です!:wave:

サービス復元時間とは

今回は、Four Keysで定義された4つの指標のうち「サービス復元時間」について可視化を行います。最初にパフォーマンスレベルの定義を確認します。

Elite High Medium Low
1時間未満 1日未満 1日~1週間 6か月より多い

DORAの定義ではLowは「6か月より多い」となっていますが、今回はMediumの上限である1週間より多ければLowとする判定ロジックにします。

サービス復元時間は、その名前の通りユーザーに影響を与えるような障害や不具合が発生してから、サービスが復旧するまでの時間です。前回の変更障害率と同じく、サービスが停止したり、エラーが発生したりするような障害であればログ等から容易に判断できますが、そのような機械的な判断が難しい場合は「ユーザーに影響を与える障害・不具合の定義」を定め、それをどの情報から収集するか設計するところから考える必要があります。

私たちのチームでは前回と同じく、問題に対して発生確率や影響度の指標を定め、一定の基準を超えたもの=ユーザーに影響を与えた問題、と定義することにしました。そのため、Backlogの内容をNewRelicに連携する形で検討します。

前回と同様に本記事ではDORAの定義をそのまま利用しますが、実際のチームに適用する際にはチームの状況にあった定義をあらためて検討しましょう。

Backlogに入力された内容をNewRelicに連携する

BacklogからNewRelicにデータ連携する部分については、前回の変更障害率で連携したBugカスタムイベントの内容をそのまま流用します。
今回はいったん、Backlogのチケットが作られてから閉じられるまでをインシデントの発生から収束までと考えて後続の集計作業を行います。インシデントの内容次第では復旧作業を優先し、その後に管理や記録のためにチケットを残すケースもあると思います。そのためBacklogのチケットをベースに可視化する場合はチケットに発生時刻や対応完了時刻を入力できるようなカスタム属性を追加し、それらに時刻が入力されていたらそちらを優先するようなロジックにしておくとスムーズに運用ができると思います。

NewRelicでパフォーマンスレベルを判定し可視化する

それでは、NewRelicでパフォーマンスレベルを判定した結果を可視化する部分を実装します。改めてNewRelicのクエリビルダーでデータを確認してみます。

SELECT *
FROM Bug
SINCE 3 months ago

以下のようにデータが表示されました。

image.png

続けて、同じチケット番号(key_id)のレコードについて FACET を利用してグルーピングした後、latest関数 を用いて最終的なチケットの内容を取得するようにします。
また、operated_atclosed_at については earliest関数 を用いて最も古い内容を取得するようにします。これは、

  • 最も古い operated_at=チケットの作成時間=インシデントの発生時間
  • 最も古い closed_at=チケットの完了時間=インシデントの収束時間

とするためです。なお closed_at についてはチケット完了後に何らかの情報更新を行う可能性を考慮し、latestではなくearliestの方を利用しています。
実際のクエリで試してみます。

SELECT
  earliest(operated_at) AS created_at,
  earliest(closed_at) AS closed_at,
  latest(bug_kind) AS bug_kind
FROM Bug
FACET key_id
SINCE 3 months ago

以下のように、key_idでグルーピングしたデータが取得できました!

image.png

あとは、ユーザーに影響を与えたインシデントとしている bug_kind=1 でフィルタリングしてから、チケット番号単位に operated_atclosed_at の差分を計算し、全体の平均を取ってからパフォーマンスレベルを判定すれば完成です。最終的には以下のようなクエリとなりました。

SELECT
  if(convert(average(closed_at - created_at), 'second', 'hour') < 1,
    'Elite',
    if(convert(average(closed_at - created_at), 'second', 'day') < 1,
      'High',
      if(convert(average(closed_at - created_at), 'second', 'day') <= 7,
        'Medium',
        'Low'
      )
    )
  )
AS ''
FROM (
  SELECT
    earliest(operated_at) AS created_at,
    earliest(closed_at) AS closed_at,
    latest(bug_kind) AS bug_kind
  FROM Bug
  FACET key_id
)
WHERE bug_kind = 1
SINCE 3 months ago

FROM句で指定しているサブクエリの結果はデフォルトでLIMIT 10の制限がかかっています。そのため、データ量が多い場合はデフォルトのままだと正しい結果にならない場合があるので、必要に応じて LIMIT の値を調整してください。

こちらを実行すると、無事レベルが表示されました!

image.png

さいごに

Four Keysの可視化の4回目として、今回はサービス復元時間をNewRelic上で可視化してみました。参考になれば幸いです。
これで全ての可視化が完了しましたが、ここからがスタートです。可視化した内容をもとにチームの状態を客観的に把握し、改善につなげていきたいと思います!:muscle:

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?