AS400 / IBM i の本番対応で一番怖いのは、コマンドを知らないことではありません。私が一番怖いと思っているのは、テスト環境と本番環境を間違えたまま、更新系・削除系の作業をしてしまうことです。
特に初心者がやってしまいがちな危険な例として、テスト環境のつもりで本番環境に入り、CLRPFM のようなコマンドを実行してしまうケースがあります。AS400は安定していて扱いやすい反面、業務データに対する操作は非常に強力です。だからこそ、本番対応では「早く直す」よりも先に「間違えない」ことが重要になります。
この記事では、25年以上AS400 / IBM i の現場に関わってきた経験から、本番対応で初心者に伝えたい確認ポイントをまとめます。
本番対応で初心者が一番やりがちなミス
一番危ないのは、環境を取り違えることです。
テスト環境で作業しているつもりが本番環境だった。本番のつもりで確認していたら、実は検証環境だった。こういう取り違えは、慣れていない人ほど起こしやすいです。
AS400の現場では、ライブラリー名やジョブ環境、サインオン先、ライブラリーリストの状態によって、見えているデータや更新先が変わります。画面の見た目が似ていると、本人は正しい環境で作業しているつもりでも、実際には別環境を触っていることがあります。
WRKLIB LIB(TESTLIB)
WRKOBJ OBJ(TESTLIB/*ALL)
DSPLIBL上のような確認コマンドは、ただ打てばよいわけではありません。今どのライブラリーを見ているのか、これからどのライブラリーを更新するのかを確認するために使います。
CLRPFMのようなコマンドは特に慎重に扱う
CLRPFM は物理ファイルメンバーのレコードをクリアするコマンドです。便利な場面もありますが、本番環境で対象を間違えると大きな事故につながります。
CLRPFM FILE(TESTLIB/TESTFILE)このようなコマンドを使う前には、少なくとも次の確認が必要です。
| 確認項目 | 見る理由 |
|---|---|
| サインオンしている環境 | 本番・検証・開発を取り違えていないか確認する |
| ライブラリーリスト | 意図しないライブラリーが優先されていないか確認する |
| 対象ライブラリー | 更新先・削除先が本当に正しいか確認する |
| 対象ファイル | 同名ファイルや似た名前のファイルを取り違えていないか確認する |
| バックアップ | 戻せる状態を作ってから作業しているか確認する |
初心者ほど「コマンドを覚えたら作業できる」と考えがちですが、本番対応ではコマンドそのものより、実行前の確認の方が大事です。
データリカバリーで最初に確認すること
データリカバリー作業で最初に見るべきものは、やはり環境です。
ライブラリーリストを点検し、SQLでリカバリーする場合も、更新先のライブラリーを絶対に確認します。SQLは便利ですが、対象指定を誤ると一瞬で本番データを書き換えてしまいます。
DSPLIBL
SELECT * FROM TESTLIB.TESTFILE FETCH FIRST 10 ROWS ONLYリカバリー時は、次の順番で考えると落ち着いて確認しやすくなります。
- どの環境で作業しているか確認する
- どのライブラリーを更新するか確認する
- 更新前のデータを退避する
- 更新対象件数を確認する
- 作業手順をメンバーとレビューする
- 実行後に結果件数と業務影響を確認する
特に本番障害中は「すぐ直してほしい」という空気になります。ですが、急いでいるときほど、更新先の確認を省略してはいけません。
焦っている人がやりがちな行動
焦っている人は、とにかく急いで作業しようとします。確認を飛ばす、手順を書かない、周りに見せない、ログを残さない。こういう行動が出ると危ないです。
本番対応では、一度落ち着いて作業手順を作成し、メンバーとレビューする方が結果的に早いことが多いです。障害対応中に手順書を書く時間が惜しいと感じるかもしれませんが、手順がないまま作業して二次災害を起こす方が、はるかに時間を失います。
できるPMとできないPMの違い
本番障害時は、PMの判断によって現場の疲弊度が大きく変わります。
できるPMは、まず障害状況を確認します。そして、いきなり完全解決を狙うのではなく、まずは止血をします。暫定対応で業務影響を止め、落ち着いてから本格対応に進める方向へ持っていきます。
一方で、よくないPMは、その場しのぎの変な対応をしてしまうことがあります。目の前の問題だけを消そうとして、後で二次災害につなげてしまう。現場で一番つらいのは、このパターンです。
| 場面 | 良い進め方 | 危ない進め方 |
|---|---|---|
| 障害発生直後 | 状況・影響範囲・優先度を整理する | 原因が曖昧なまま作業を急がせる |
| 暫定対応 | 止血を優先し、後で本格対応する | その場しのぎで複雑な修正を入れる |
| 作業指示 | 手順と確認者を決める | 担当者に丸投げする |
| 対応後 | 原因と再発防止を整理する | 動いたから終わりにする |
若手に守ってほしい3つのこと
若手や初心者に伝えたいことは、次の3つです。
単体テストを怠らない
単体テストは地味ですが、ここを軽く見ると後工程で必ず苦しくなります。自分が作ったものが本当に想定通りに動くのか、異常系でどうなるのか、データが0件のときにどうなるのか。最低限の確認を自分でやる習慣が大事です。
納品先は上司ではなくエンドユーザーだと考える
上司に言われた通りに作るだけでは足りません。実際に使うのはエンドユーザーです。画面、帳票、バッチ、エラー時の運用まで含めて、使う人が困らないかを考える必要があります。
運用を意識した作りにする
言われたものを言われた通りに作るだけでは、保守しづらいシステムになりがちです。障害時に調査しやすいか、ログは追えるか、再実行できるか、リカバリーしやすいか。AS400の業務システムでは、運用を意識した作りがとても重要です。
大変な現場から得られるものもある
本番稼働前後は本当に大変なことがあります。トラブルが起きれば、待ったなしでデータを直さなければいけない場面もあります。失敗すれば多くの店舗や業務に影響するかもしれない。その責任の重さで精神的に疲れることもあります。
ただ、若い頃にそういう現場を経験すること自体は、悪いことばかりではありません。もちろん無茶な働き方を肯定するつもりはありませんが、厳しい局面を経験すると、次の現場で落ち着いて動けるようになります。経験値として残るものはあります。
大事なのは、ただ耐えることではありません。何が危なかったのか、どの判断が良かったのか、どこで二次災害を防げたのかを振り返り、次につなげることです。
本番対応前のチェックリスト
本番対応の前には、最低限このチェックリストを確認しておきたいです。
- 本番・検証・開発のどの環境で作業しているか確認したか
- ライブラリーリストを確認したか
- 更新先ライブラリーを明示しているか
- 対象ファイル・対象メンバーを確認したか
- 更新前データを退避したか
- 更新対象件数を事前に確認したか
- 作業手順を文章にしたか
- メンバーまたは責任者とレビューしたか
- 実行後の確認方法を決めているか
- 戻し手順を用意しているか
本番対応を怖がっている初心者へ
本番対応は怖くて当然です。むしろ、怖さがまったくない方が危ないと思います。業務データを触る以上、緊張感は必要です。
ただし、焦ってはいけません。
あせるな。おちつけ。
本番対応で大事なのは、特別な度胸ではありません。環境を確認すること、手順を作ること、レビューすること、戻せる状態を作ること。この基本を守るだけで、防げる事故はかなりあります。
AS400 / IBM i の現場は、今でも止められない業務を支えています。だからこそ、初心者のうちから「作る力」だけでなく「安全に運用する力」を意識しておくと、現場で信頼されるエンジニアに近づけると思います。
AS400の基礎から順番に学びたい方は、AS400学習ロードマップもあわせて確認してみてください。
本番トラブルでデータリカバリーが必要になったら
本番対応中にデータ修正や戻し作業が必要になった場合は、環境確認だけでなく、影響範囲、リハーサル、ライブラリー名の確認も重要です。具体的な考え方は、AS400のデータリカバリーで焦らないための確認手順にまとめています。
本番対応で初心者が一番怖いミス
私が本番対応で一番怖いと思うのは、テスト環境と本番環境を取り違えたまま、更新系のコマンドやSQLを実行してしまうことです。特に CLRPFM のようなコマンドは、対象を間違えると一瞬で大きな事故になります。
作業前に必ず見るもの
- 接続先が本番かテストか
- ライブラリーリストが想定通りか
- 対象ファイル、対象メンバー、対象キーが合っているか
- SQLの更新先ライブラリーを明示しているか
- 作業手順をメンバーや上司がレビューしているか
焦っている人は、とにかく早く作業を始めようとします。しかし本番障害時ほど、いったん止まって手順を書き、対象環境と更新先を確認し、メンバーとレビューする方が結果的に早いです。
できるPMは、まず障害の状況を確認し、暫定対応で止血してから恒久対応へ進めます。逆にその場しのぎの対応を重ねると、後で二次災害になります。若手ほど「早く直す」より「間違った場所を触らない」を優先してほしいです。
