前号: No 353 / 次号: No 355 / 一覧(note.com)へ / ブログページに戻る

メールマガジン「がんばりすぎないセキュリティ」No354 (24/05/06)

システム更新を年末年始やGWに行う理由


ゴールデンウィーク(GW)や年末年始には、大規模システムの更新がよく行われます。

「長期休暇は時間が要る更新に向いているのかな」とは考えつつも、「一体ナニに時間がかかるのだろう?」とお思いではないでしょうか?

今回は、大規模なシステムなどでGWや年末年始にシステム更新する理由についてお話します。


1. システム更新は大変

ゴールデンウィークや年末年始に、振り込みしようとして、各銀行のアプリでやろうとすると「システムメンテナンスです」というメッセージに出くわしたことはないでしょうか。 確かにGWというのは大規模システムにとって大きな更新が行える数少ないチャンスでることは確かです。 でもどうして、こういった大型休暇にシステム更新なんてことをするんでしょうか? システム更新という作業はそんなに時間がかかる作業なのでしょうか? これはシステム屋からするとごく当然で、GWやお盆は大型システム更新の数少ないチャンスなのです。 最大の理由はまとまった時間が取れるからなんですが、そもそもシステム更新に時間がかかるということ自体があまり知られていないように思います。 時間がかかる主なものというと以下の四つくらいでしょうか。  1. データベースの更新  2. トラブル発生時のバッファ  3. 切り戻し用のバッファ  4. 多数の関係者のタイミング合わせ 以下ではそれぞれについてお話をします。 なお、どれが一番時間を取られるかは、システムによりバラバラです。

2. データベースの更新

システムの大規模変更を行う場合、データベースも大きく変わることがあります。 プログラムの仕組みを変更しようとすると、現在のデータベースの構成では処理が複雑になったり、そのために速度が上げられないということが発生します。 新しいプログラムでも効率よく動作できるようにデータベースの構造もプログラムに合わせて改修することはよくあります。 ところが、この更新というのが大変なのです。 データベースに入っている既存データは組織にとって最重要データです。 システムの刷新したからといって捨てるわけにいきません。 新システムでも現行データを全て正しく更新することが大前提です。 このデータ更新作業を「移行」と呼びますが、ある程度の規模のシステムでは専任の移行担当者が設定されます。 大規模システムでは「移行チーム」のように複数メンバが担当することもごく普通です。 移行担当者は、データ更新の手順を考えるだけではありません。 データが移行作業前と後で一致していることをどうやって検証するかも大切な任務ですし、データ更新に要する作業時間を正確に求めることや、データ更新に必要なプログラムの作成なども重要な任務です。 データベースの更新作業というのは、更新そのものの時間に加えて、移行結果の検証作業も含まれます。 データベースの規模が大きくなればなるほど、そのデータ更新にも時間がかかるようになります。大規模データベースの更新となると、数時間かかることもザラです。 その後の移行検証プログラムを実行でも数時間かかるでしょうから、データ更新だけで半日かかるということも決して珍しいことではありません。

3. トラブル発生時のバッファ

システム規模に関わらず、多くのシステムでは更新前にリハーサルを行います。 リハーサルによって、気づいていなかった問題が見つかることも多いからです。 ですが、リハーサルはあくまでリハーサルです。 全てを本番と同じように実施することはできません。 例えば、サービス中のサーバやネットワークは止めるわけにいきません そんなことやったら、リハーサルではなく本番そのものです。 リハーサルは所詮リハーサルに過ぎません。 入念に検証を重ねていても、起きる時にはトラブルが起きます。 そのため、計画時にはある程度のトラブル対応時間を見込んでおきます。 具体的に何時間とは言えませんが、筆者の経験では全体時間の1割程度が相場でした。

4. 切り戻し用のバッファ

システム更新作業の途中でどうにもならない問題が生じる場合があります。  データベース更新に想定外の時間を要した。  更新後のシステムが意図しない動作をする。    こんなことは誰も起きてほしくありませんが、それでも発生する可能性がゼロとは言えません。 そのため、システム更新の計画立案時には「万一、システム更新作業で大きなトラブルが起きたときは全てを元に戻す」というサブ計画を立てます。 このサブ計画のことを「切り戻し」と呼びます。 問題なのは「切り戻し」をするにも時間が要る点です。 例えば、データベース更新で失敗した(処理時間がメチャクチャかかる、データ不整合が見つかった)場合は、データベースを更新前の状態に戻さなければなりません。バックアップから戻すにも時間が必要です。 また、プログラム更新やネットワーク設定変更後であれば、それを元に戻す時間も組み込まないといけません。 切り戻しする場合でも、その作業時間は全体計画に組み込んでおかないといけません。 万一とはいえ、この時間が計画に含まれていないと切り戻し中に業務時間になる、という目も当てられない事態にもなりかねません。 なお、切り戻しするかどうかは、「切り戻し判定」という手順で行います。 通常、切り戻し判定はスケジュールの複数箇所に組み込んでおき、システム責任者による判定を仰ぐルールとします。

5. 多数の関係者のタイミング合わせ

最後は人に関わる問題です。 特に大規模なシステム更新では、多数のシステムを同時更新します。 例えば、製造業であれば、生産管理システムを更新しようとすると、在庫管理システムや入出庫管理システム、受発注管理システム、といった関連システムも影響を受けることはよくあります。 こういった場合、関連するシステムを同時更新する場合も多いのですが、各システムの担当会社が違っていることもよくあります。 複数会社のシステム担当者がスケジュールに従って、協力しながら作業を進めることになります。 特にやっかいなのは、多数の関係者が連携しつつ順に作業を進めていく必要があるケースです。  Aさんがサーバのネットワーク設定を完了させる。  Aさんがサーバのネットワーク設定を変更する。  Bさんがそのネットワークを用いて別サーバからデータを取得する。  Cさんがそのデータを使って作業を行う。  DさんがCさんの作業結果をつかって継続作業を行う。 上述のように、ABCDの4名が別会社の人だったりすると、メールや電話での連携になることも多く時間がかかります。 運動会の二人三脚を思い浮かべください。 たった二人でも、それぞれが走るよりもずっとゆっくりしか走れません。 大規模システムでは当日参加者が10社以上で、数十人というのもザラです。 初めて出会った人だけでやる二人三脚(30人31脚など)を考えてみてください。 そりゃ時間もかかろうというものです。

6. まとめ

ゴールデンウィークや年末年始には大規模なシステム改修を行うことが多いようです。 これはまとまった時間をとりやすく、システム停止による影響が小さくできるタイミングであることが大きな理由です。 まとまった時間が必要なのは、データベースの更新のように高性能なコンピュータでも時間がかかるケースや、トラブル対応のバッファや切り戻しのバッファを確保したいケース、多人数の関係者間の連絡で時間がかかるケースなどがあるためです。 ちなみに、筆者の経験の範囲では、年末年始は避けて、GWやお盆休みにシステム更新を行うケースが多いです。 年末年始は、GWやお盆休みに比べて作業者の確保が大変なんです。誰だって年末年始はお休みしたいですものね。 余談ですが、今回のネタを思いついたのは、たまたま4月に自宅に車両税の支払い用紙が届き、「忘れんうちにやっとくか」と思ってりそな銀行のアプリからPayEasy(ペイジー)支払いをやろうとしたところ、「システムメンテナンス中です」といったエラーになったためです。 今回は、ゴールデンウィークにシステム更新が集中する理由をお話しました。 次回もお楽しみに。 (本稿は 2024年5月に作成しました)

前号: No 353 / 次号: No 355 / 一覧(note.com)へ / ブログページに戻る