夜明けまで再起動しない

クラウドサービスの監視室で、千種紅葉の夜勤は午前六時に終わる。五時二分、最後の依頼がチャットへ届いた。

〈検索が遅い。六時のキャンペーン前にデータベースを再起動してください〉

依頼主は営業本部長だった。大型広告の公開まで一時間を切り、商品担当が何人も同じスレッドで「至急」と書いている。隣の後輩は手順書を開き、再起動申請へ必要なチェックを埋め始めた。

紅葉は検索遅延のグラフより先に、バックアップ欄を見た。完了を示す緑ではなく、二時間前から灰色の〈検証中〉が続いている。複製側のデータも、本番より七分遅れていた。

「再起動は止めて。読み取りだけ複製側へ逃がすのも今はなし」

「でも、手順書では遅延時は再起動です」

「その手順書は、バックアップが完了している前提」

紅葉は直前に開始された集計処理を一つずつ確認した。新しい販促ダッシュボードが、全商品の履歴を毎分読み直している。停止すれば検索は戻るが、営業側の集計画面は更新されなくなる。

彼女は本部長へ、検索を守るためダッシュボードの更新を一時間止めること、数字は五時時点のまま表示されることを短く書いた。了承を待つあいだに、処理へ上限を設定する変更案と復旧手順を作る。返事は〈それで進めて〉だった。

集計を止めると、赤かった遅延グラフがゆっくり下がった。六時の広告公開後も注文は途切れない。再起動せず、失われたデータもなかった。営業の集計画面には古い時刻を示す帯が出たが、数字が最新ではないことも利用者へ明示できた。

紅葉は後輩へ、手順書の最初に「バックアップ状態と複製遅延を確認」と追記してもらった。

「手順を守らなかったことになりませんか」

「守るための前提が崩れたら、止まって理由を書く。それも手順だよ」

朝の引き継ぎで、紅葉は原因と判断を一枚にまとめた。三か月前から勧められていた信頼性エンジニアの社内ローテーションは、夜勤が増えるのが怖くて保留にしていた。

けれど夜を減らすかどうかより、夜に決めたことを設計へ戻せる席に行きたい。

紅葉は応募画面を開き、今回の記録を実績欄へ添えて提出した。