Work Readiness 入社後に取り組みたいこと

かんたんに言うと「サイトが見られない」という知らせが来たとき、どんな順番で調べて直すかの練習です。実際のお客様の環境で対応した記録ではありません。

1. 01
   受付・影響確認

   アラート（異常を知らせる自動通知）が出た時刻、対象のサービス、利用者への影響、直前に行った変更、同時に出ている他のアラートを確認します。まず全体像をつかみ、影響の大きさを見誤らないためです。

2. 02
   作業前の状態を記録

   監視の数値、動いているプログラム、通信の待受（外からの接続を受け付けている状態）、ログ、関連サービスを確認して保存します。あとで「直したことで何がどう変わったか」を比べられるようにするためです。

3. 03
   原因の場所を絞る

   Webの受付、アプリ、サーバー本体、ネットワークのどこで止まっているかを順番に確認します。

4. 04
   承認された範囲で対応

   作業手順書と担当範囲を確認し、再起動や設定変更は必要な承認を得てから行います。よかれと思って行った操作が、別の障害を招くことがあるためです。

5. 05
   元に戻ったか確認

   プログラムの起動だけで終えず、Web画面の応答、監視表示、ログ、関連機能まで再確認します。

6. 06
   報告・次への改善

   起きたこと、影響、原因、対応、復旧時刻、残った心配を報告し、手順や監視の改善案を残します。

かんたんに言うと設定を変えるときの決まった進め方です。機械による自動の確認で不具合を先に見つけ、問題が出たときは前の状態へ戻せるようにしておきます。

公開作品は個人制作で、第三者によるコード確認は受けていません。入社後は、次の情報をそろえ、確認や引き継ぎを受けやすい形にします。

このサイトと関連作品では、文章整理だけでなくプログラム作成にもAIを使いました。AIが出した内容を、そのまま自分の実績とは呼びません。自分の言葉で説明でき、実際に動かして確認できた範囲だけを公開しています。あわせて、確認したときに保存した記録も公開しています。

かんたんに言うと面談の場で、実際に画面を動かしてお見せできる内容です。動かせるのは本人のパソコンに用意した環境の範囲に限られます。

再実演できるのは、本人PCのWindows上のLinux環境とDockerで行える範囲です。GitHubの一時テスト環境、実機（本物のパソコン）に入れたAlmaLinux（Linuxの種類の一つ）、継続利用するサーバーでの実演は対象外です。