はじめに
日付：2026年8月4日（火）/ 86日目
週次作業2件を問題なく完了し、
アラート4件への対応も実施した。
監視業務にすっかり慣れてきた一日。
作業①：ポイント未付与状況確認（週次作業）
アンケートに回答したにもかかわらず
ポイントが付与されていない会員がいないかを確認する週次作業を実施した。
作業の流れ
① SQLツールで対象リストを抽出
↓
② BastionサーバーからDBに接続（psql）
↓
③ 照会SQLを実行
↓
④ 結果をCSVでダウンロード・内容確認
↓
⑤ 結果をメールで送付・完了報告
作業②：TRANS-AM連携リカバリ
RETRY_COUNTが上限に達したfinish_answer再実行対象データを
照会・更新する作業を実施した。
作業の流れ
① SQLツールでSELECT・UPDATE用SQLを生成
↓
② BastionサーバーからDBに接続（psql）
↓
③ SELECT SQLを実行して対象件数を確認
↓
④ UPDATE SQLを実行してRETRY_COUNTを0に更新
↓
⑤ SELECT・UPDATEの件数が一致していることを確認
↓
⑥ commitして作業完了・中間管理チームへ報告
2件ともに問題なく完了。
この作業の流れも体に染み込んできた。
本日のアラート対応（4件）
| No | 受信時刻 | 優先度 | 内容 | 状態 |
|---|---|---|---|---|
| 1 | 03:03 | P2 | モニターサービスの応答時間p90が高い（レイテンシ回帰の可能性） | OPEN |
| 2 | 06:34 | P4 | 外部API通信失敗・プロフィール取得エラー検知 | OPEN |
| 3 | 07:40 | P4 | 同上（再発・重複アラート） | OPEN |
| 4 | 09:25 | P2 | クライアントサービスの応答時間p90が高い | CLOSED |
アラート対応の流れ
① 電話でアラートを受信
↓
② Datadogで内容・優先度を確認
↓
③ Compassでステータスを更新（3→0）
↓
④ Slackで担当者にエスカレーション
↓
⑤ スプレッドシートに記録
アラートが4件来ても、もはや慌てることなく対応できるようになった。
「慣れた」という感覚が自信につながっている。
一方で、自分が直接原因を解決する場面が少ないことに
少し物足りなさも感じている。
次のステップとして、原因調査・解決まで担えるようになりたい。
感想
週次作業もアラート対応も、
もはや「当たり前の業務」として淡々とこなせるようになった。
これが適応するということだと実感しながらも、
「次は自分でもっと深く原因を調査・解決したい」
という新たな目標も生まれてきた。
疲れた一日ではあったが、
着実に経験が積み上がっていることは間違いない。