社内on-call引き継ぎダッシュボード

私のチームのon-call引き継ぎはぐちゃぐちゃでした。引き継ぐ側のエンジニアがSlackにサマリを貼るのですが、進行中のインシデント、直近のデプロイ、ミュート済みアラートがそれぞれ別の場所にあって、みんなコンテキストを見落としていたんです。私のインターンプロジェクトは、この3つを1ページに集約する小さな社内ダッシュボードでした。フロントエンドはReactで作り、薄いNode/Expressのバックエンドから社内のインシデントAPIとデプロイサービスを呼び、レスポンスはRedisにTTL 60秒でキャッシュして、リフレッシュのたびにそれらのAPIを叩きまくらないようにしました。データモデルは実質、リクエスト時に3つのソースから組み立てる1つの「引き継ぎ」ビューだけです。source of truthとなるシステム側がすでにデータを持っているので、あえて自分では保存しませんでした。一番難しかったのはコードではなく、on-callの人が実際に最初に何を見るのかを突き止めることで、実際の引き継ぎを2回シャドーイングして、彼らが挙げた4項目までページを削ぎ落としました。インターン終了までに約9人のエンジニアからなる自チームにリリースされ、他の2チームからも試したいと声がかかりました。書き込みを頼られるシステムにならないよう、意図的にread-onlyのままにしました。