運用保守から設計構築へ進みたい。でも、手順どおりの作業ばかりで、職務経歴書へ書ける経験が増えないと感じることもありますよね。
今の仕事の中で、調査、変更の準備、試験を一つずつ広げる方法があります。この記事ではバックアップ障害の説明例を使い、再実行から原因の確認、改善と試験へつなぐ考え方を紹介します。
アラート後に、自分がしたことを整理する
通知を受けて再実行した、ログを取得した、影響を確認した、上位担当へ連絡した。まず事実として行ったことを分けます。「運用保守」という一言にまとめないようにします。
判断した内容も、自分で決めたことと、手順や指示に従ったことを区別します。担当が限られていても、必要な記録をそろえた工夫は説明できます。
| 普段の作業 | 経験として分けること | 構築へつながる成果物 |
|---|---|---|
| アラート対応 | 影響、時刻、直前変更、正常地点を確認 | 調査記録、確認手順、監視改善 |
| 定期変更 | 対象、差分、事前取得、実施後の判定 | 設定差分、手順、試験表 |
| 障害復旧 | 原因候補、選んだ対応、承認、再確認 | 復旧手順、証跡、再発防止案 |
| 台帳・手順更新 | 実機との不一致、反映する値、レビュー | 現行構成、パラメータ、変更履歴 |
直近の対応一件を、対象、時刻、確認、連絡、結果へ分けてみてください。次に担当したい作業も、その流れの中から探せます。
再実行の成功だけで、原因が分かったとはしない
ここからは説明用の例です。定期バックアップが失敗し、再実行では成功したとします。再実行の成功は確認できた事実ですが、最初の失敗原因が容量不足だったとまでは分かりません。
ログの時刻、空き容量、保存先、同時実行のジョブ、直前の変更を調べます。容量不足、一時的な接続不良、競合など、考えられる原因を証拠と照合します。
| 段階 | 確認・作成すること | 次へ進む条件 |
|---|---|---|
| 事実整理 | 失敗時刻、対象、保存先、空き容量、ログ、同時処理 | 再実行の成功と失敗の条件を比較できる |
| 原因候補 | 容量、権限、接続、競合、直前変更を分ける | 確認済みと推測の部分が分かる |
| 改善案 | 保持期間、保存先、処理時間、監視の変更案 | 要件、費用、データ保持、影響を説明できる |
| レビュー・変更 | 設定差分、操作、停止、切り戻しを確認 | 担当者の承認と実施範囲が明確 |
| 試験・引継ぎ | 次の定期実行、復元、通知、手順を確認 | 実結果と未確認事項を残せる |
図はこの例の整理方法で、筆者や読者の実績を示すものではありません。結果がまだ分からない部分は、推測として残します。
どの情報が不足しているかを説明できれば、次の担当へ調査を依頼しやすくなります。原因を一つに決める前に、確認した範囲をそろえましょう。
変更は、期待値と中止・切り戻しを先に考える
仮説を調べて改善案を作るなら、対象、変更差分、影響、期待する結果を整理します。自分の権限で実施できるかも確認し、レビューと承認を受けます。
切り戻しは、変更を取り消して以前の状態へ戻す手順です。実施後に考えるのでなく、中止する条件と戻し方を変更前に用意します。
- 障害チケットへ、影響、時刻、ログ、正常な地点を整理する。
- 既存手順へ、事前取得と異常時の連絡・中止条件を追加する。
- 変更差分を調べ、対象以外の設定が変わらないか確認する。
- 正常・拒否・復旧の試験と証跡の保存先を用意する。
- 台帳と実機の違いを確認し、更新案をレビューへ出す。
| 資料 | 書く内容 |
|---|---|
| 変更案 | 目的、対象、原因の根拠、変更値、影響、代替案 |
| 作業手順 | 事前取得、操作、期待結果、中止、連絡、判断者 |
| 切り戻し | 元の状態、戻す操作、所要時間、戻した後の試験 |
| 試験表 | 条件、操作、期待結果、実結果、合否、証跡 |
| 引継ぎ | 監視、定期実行、復元、未確認事項、次の担当 |
バックアップの例なら、次の定期実行だけでなく、復元、通知、他のジョブへの影響も試験対象になります。一回成功したことを、今後も障害が起きない証明にしません。
手順作成や試験項目のレビューから参加できないか相談すると、いきなり本番変更を任されなくても担当を広げられます。
自動化は、対象確認と停止できる仕組みから
最初はログ収集や差分の整理など、確認しやすい作業を候補にします。入力、対象、権限、出力を決め、失敗したときに何が起きるかを調べます。
設定を変更する自動化なら、対象の取り違えや途中停止、再実行まで考えます。処理が終わったという表示だけで、環境が期待どおりになったと判断しません。
| 説明が浅い状態 | 追加で説明すること |
|---|---|
| スクリプトを作成 | 何を入力し、何を出力し、誰が使ったか |
| 作業時間を短縮 | 対象、計測条件、実行前後、確認時間も含むか |
| 自動で全件実施 | 途中失敗、再実行、停止、対象外への影響 |
| ログを保存 | 時刻、対象、操作、判定と次の確認が追えるか |
時間短縮を成果へ書く場合は、同じ対象と条件で測った結果を使います。見込みの時間を、実際に削減した時間へ置き換えないようにします。
自動化した処理と確認した結果を残すと、道具の名前より、仕事をどう改善したかを説明できます。
書類では、経験の範囲と次の担当をつなぐ
調べたこと、提案したこと、作った資料、実施した作業、確認した結果を分けて書きます。改善がチームで行われたなら、自分が担当した部分を先に示します。
個人検証をした場合は実務と別の欄へ書きます。運用を設計経験へ言い換えるより、変更の準備や試験へ関わった範囲を具体化します。
| 質問 | 確認したいこと |
|---|---|
| 最初に作る資料は何ですか | 手順・パラメータ・試験の具体的な担当 |
| 設計値は誰が決めますか | 自分の判断と他担当の判断の境界 |
| どのレビューを受けられますか | 担当者、頻度、指摘の反映まで |
| 運用経験者の担当拡大例はありますか | 調査から変更・構築へ進んだ実績 |
| 初回配属と勤務はいつ決まりますか | 希望の扱い、夜間、待機、勤務地 |
応募先では、最初に作る成果物、レビューする人、設計や構築を担当する条件を聞きます。夜勤から日勤へ変わる場合は、手当を含めて給与を比較します。
まず今の仕事で、一件の対応を調査から結果まで説明してみましょう。説明が途切れる部分が、次に確認したいことや担当したい作業になります。
関連する動画・筆者の投稿：YouTubeで見る
