フランスの現場で使う監視ダッシュボード、現地時刻とUTCを並べたら誤読が減った話

フランスの小規模チームで、社内ツールの監視ダッシュボードを直したときの話です。対象はGrafana 9系、データ源はPrometheus、ホストはパリ近郊のVMで、EC2に近い構成のオンプレ2台。1日あたりのメトリクスは約40万サンプル。障害対応のたびに「グラフの時刻がずれている」と言われ、実際にはずれていないのに調査が長引く状態が続いていました。原因は表示で、ダッシュボードの時刻がUTCのまま、現場の会話は現地時刻（Europe/Paris）で行われていました。とくに夏時間の切り替え週は、ログの時刻とグラフの時刻を頭の中で変換する必要があり、当番の人が別の障害と結びつけてしまう誤読が起きていました。

まずGrafana側のタイムゾーンを固定しました。ダッシュボードの設定ではなく、プロビジョニングで配るJSONに直接書いています。

{
  "timezone": "Europe/Paris",
  "time": { "from": "now-6h", "to": "now" },
  "panels": []
}

そのうえで、パネルのクエリはUTCのまま保持し、表示だけを現地時刻に寄せました。Prometheusのクエリにtimezoneは効かないので、変換は表示層だけに閉じ込めるのが安全です。加えて、障害メモのテンプレートに「UTC / 現地」の2列を用意し、当番が両方書く運用にしました。テンプレートはプレーンテキストで、こんな形です。

時刻(UTC): 2024-03-31T01:23Z
時刻(Europe/Paris): 2024-03-31 03:23
症状:
影響範囲:

これで会話と画面の単位が揃い、変換の手間が減りました。

なぜ表示だけ変えたかというと、保存とクエリをUTCに固定しておけば、夏時間の切り替えでデータの連続性が崩れないからです。現地時刻を保存に使うと、切り替えの1時間が飛んだり二重に現れたりします。代わりに、現地時刻でしか意味を持たない運用（当番の引き継ぎ、顧客への連絡）は別欄で管理しています。コストは、ダッシュボードのJSONを配布し直す手間と、テンプレートの2列を埋める習慣づけです。

ただ、この方法が効かない場面もあります。複数拠点のデータを1画面で見るとき、表示をEurope/Parisに固定すると他の拠点の人が誤読します。実際、リヨンのメンバーから「自分の感覚と合わない」と言われました。そのため拠点別のダッシュボードを分け、共通画面はUTCのままにしています。また、秒単位の障害では表示の丸めが原因で前後関係が逆に見えることがあり、その場合は生のタイムスタンプを併記しています。

同じように、表示時刻と保存時刻を分けている現場はありますか。とくに夏時間の切り替え週に、どんな運用で誤読を防いでいるのか知りたいです。