保守を考慮したバッチ処理設計(その2)
こんにちは、商品開発部の北崎です。
そろそろアジサイの季節ですね。アジサイの花は、リトマス試験紙のように土の酸性度で花の色が変わります。
きれいに咲かせるには、土の酸性度や肥料、水やりなど日頃のお手入れが大事です。買ってきてほったらかしでは、可哀そうですね。
システムも同じく、日々の保守や環境変化に応じてチューニングすることで、長く私たちの業務を支えてくれます。
自分の関わったシステムが長く利用されていると、苦労して開発した時のことも懐かしく思えます。
さて今回も前回からの続きで、保守効率の良いバッチ処理設計のノウハウについて「4:障害対応」からご紹介したいと思います。
No | 分類 | 考慮点 |
1 | 監視、日常点検 | Logの自動集計、重要度に応じたエラー通知 |
2 | 問い合わせ | ユーザー側での運用マニュアルの整備と共有 |
3 | データ抽出、修正 | ユーザー側で変更可能にする |
4 | 障害対応 | 素早い原因特定と復旧処置 |
5 | 機能追加 | 全体像、データ流れ、影響範囲の把握がしやすい |
4・障害対応
システム担当者の不在や締日とか、障害は起こってほしくない時に発生します。
主担当でないからよくわからないけど何とか復旧しなくてはいけない、そんな経験はないでしょうか?
障害対応は、以下のような手順です。
1:影響範囲の特定、業務影響確認
2:原因の特定
3:復旧処置、暫定対策
4:恒久対策
障害の経過時間が長くなるほど、業務影響も大きくなるので、できるだけ早く検知し、素早い復旧が望まれます。
「1:監視、日常点検」でご紹介しましたが、異常終了時は、Log出力と同時にシステム担当者と運用担当者にメール通知します。日々山のようなメールに埋もれてしまわないよう、事前に自動振分け設定で障害がすぐに認識できるようにしておきましょう。素早い検知は、事態の悪化を防いでくれます。また、運用担当者と状況を共有することで、運用面の協力体制もできます。
次に通知メールをトリガにどの処理で異常終了したか確認し、システム全体像やバッチ処理概要から影響範囲を特定します。
この時、メール本文に、発生した日時、メソッド、対象データ、原因等が記載されているといいですよね。バッチ処理の場合は、前提条件が異なる場合やデータ不整合、DBの更新エラーが想定されます。これは、実装時に想定してコーディングするしかありません。想定外のエラーを無くすようif文は、指定条件以外のケースを必ず考慮するようにします。DBからの読み込みも0件、1件、1件以上のケースで処理するなど、ロジック上の抜けが無いように、コーディングやソースレビューを行います。
もし自分がメールを受け取ったら、すぐに原因箇所や異常データの特定ができるか、想像してみるといいですね。
原因の特定ができたら、復旧処理を行います。復旧処置は、暫定でもユーザー業務が再開できることを最優先に考えます。想定外の入力データであれば、データ修正、もしくは、対象データを一旦除外します。バグの場合、恒久対策に時間がかかるようであれば、ユーザー業務の再開を最優先にした処置を行います。時間的な猶予を確保してから心を落ち着けて、恒久対策とテストを行います。担当者1人が焦って対応しても考慮不足で2次災害を起こすだけです。気持ちはわかりますが、慌ててはいけません。
重要度に応じて関係者を招集し、経緯、現象、影響範囲、暫定処置を確認し利用者へ周知します。混乱を避ける上で周知は大切です。システムだけに目が行きがちですが、システム停止は、ユーザー業務も停止していることを忘れてはいけません。
バッチ処理の再開は、単純リランできるように設計します。
DBのロールバックで処理前の状態に戻すこともできますが、直接データ確認ができない為、原因の特定ができなくなる場合があります。私は、異常終了した状態で、ユーザー業務の影響が少なければ、ロールバックは使わないようにしています。一時的にデータの不整合が発生しても、すぐにバッチ処理で整合性が維持できれば問題ないはずです。
逆にロールバックを使わない場合、リランするために、各テーブルのデータを手動で戻すのは、確認作業を含めとても時間がかかるので、避けたいですよね。
この為、必ず上から下へデータが流れるように入力と出力のテーブルを分け、入力データはステータス管理することで単純リランできるようにしています。
大したノウハウでもないですが、障害調査や復旧処置が考慮されているかどうかで、保守する側からすると大きな違いが出てきます。
5・機能追加
機能追加する場合は、現状システムを把握し、ユーザー要件に対して、期間、コスト、現状データの影響を考慮し、どのような実装が最適かを検討します。
この時、どうやって現状システムの全体像、データ流れ、影響範囲の把握をすればいいでしょうか?
詳細設計書といいたいところですが、数年もすれば、作った人、変更した人も千差万別で、結局はソースを解読しテスト環境で動作確認することになります。
バッチ処理の場合、必要なドキュメントは、
1:他システムとの連携を含めたシステムの全体像
2:バッチ処理の概要フロー
3:ER図とテーブル定義
全体像とデータの流れを理解し、機能追加の要件から変更範囲と影響範囲を明確にしていきます。よく失敗するのは、変更範囲だけ見て影響範囲を考慮してないケースです。
ユーザー業務フローはもちろん、ちょっとした疑問や、違う視点からの意見を無視せず、影響範囲を検討しましょう。
詳細のドキュメントを常に最新に維持するのは大変です。特にソースレベルに近い詳細設計は、細かい変更依頼に追従するのに、かなり工数がかかります。しかも文章で書かれた細かい処理手順から動作を理解するのも大変です。
私は、入力項目の組合わせに対して出力がどうなるのかを表形式で整理し、設計書を作成するようにしています。その方が開発者も分かりやすく、テスト仕様として兼用もできます。また導入後、処理の動作を簡単に理解することができます。
箇条書きの文章を細かく書くよりは、ドキュメント地獄に落ちないよう基本設計レベルのドキュメントが維持できていれば、十分ではないでしょうか。
詳細ロジックは、上記資料と一緒に、直接ソースを確認します。
それでは解読しやすいソースコードは、どのようなものでしょうか?
その言語に精通していなくても、斜め読みとかできるといいですよね。
私の考慮点は、以下のとおりです。
1:特異な関数は使わない。
2:細かいロジックを見なくていいようにコメントを記述する
3:コメントは、目的を記述する
4:if文は、指定条件以外のケースを考慮する
5:使わない変数、メソッドは、削除する
必ずしもその言語に精通した人が、システムを保守するとは限りません。
ブラックボックスにならないよう、他の人が解読しやすいソースコードとコメントを念頭にコーディングしましょう。
最後に
いかがだったでしょうか?
「期限があるから、とりあえず導入まで頑張って、保守は後で考えましょう」とかよくある話しですが、経験上、稼働後の改善は優先度も下がるので、なかなか実行されません。保守が困難になると環境の変化に対応できず、再構築か廃止の道をたどります。
システムは、コーディングが目的ではなく、利用者に長く貢献できるようにすることが目的です。
どう保守するかについて設計時から考慮しておくことで、将来にわたってユーザーに貢献し続けるシステムになるといいですね。