#146:システムトラブル回顧録（2）全社データ1/3消失

システムに関わり約20年。徐々に仕事の記憶も薄れるのだが、なぜかシステムトラブルは今も鮮明に記憶が蘇る。その記憶の引き出しから思い出深いトラブルを棚卸しする記録。
なお前職での経験を元に書くが、諸々特定されないよう適度にフィクションを挟む。

続けて2回目となる。（また長文となり失礼）

その昔、2000年問題というシステム屋泣かせのイベントがあったらしい。ただ2000年は入社前であり、当時のゴタゴタを言い伝えとしてしか知らない。

しかし同じようなイベントである新元号対応、つまり令和に元号が変わることが決まり、当時のシステム担当者は日本中で対応に追われた。

そして無事に乗り切ったぞと思った矢先、我々は全く思わぬところでトラブルに見舞われる。

新元号対応（令和対応）

どの業界にいても当時日本でエンタープライズのシステムを担当していたら、逃れられなかったであろうこの対応。

しかしながら、実はそれほどシビアな対応ではなかった。昭和から平成に切り替わった過去もあり、和暦や元号を使っている箇所を特定することもそれほど難しくはない。

またあまりに全システム共通で同じ処理となるため（例:いつまでが平成で、いつからが令和かを判定する処理）、共通プログラムでひとつのチームが開発することになった。

我々は、その共通部品が自分たちのシステムで正しく動作するか（令和表示）のテストのみ。テスト結果も一目瞭然であまり難しくはない。

しかし、問題はそこではなかった。

思わぬ伏兵

令和表示に切り替える対応は、順調に進んで、結果的にも大きな問題は発生しなかった。

2019年5月1日の切替えの時に、休日出社して対応したメンバーからも、特に問題なしの連絡を受けてひと安心。

しかし、問題は令和への切替えではなかった。

思わぬ伏兵は10連休だった。

令和初日はゴールデンウィーク。普段は平日の5/1や5/2も国民の祝日となる特殊なカレンダーで、土日合わせて10連休となった。

これがトラブルの引き金。

とはいえ、我々はもちろんこの特殊なカレンダーにも備えてテストを重ねていた。しかし今回は全システムが関わる対応。その中のひとつ、システム運用部門でトラブルが発生した。

トラブル内容を端的に言うと、5月最初の営業日に全社データの約1/3が突然消失したのだ。

…

…

夜中のピタゴラスイッチ

ところで、急に話は変わるが、皆さんはピタゴラスイッチをご存知だろうか。（参考↓）

理由は省くが、金融系システムでは夜中に大量の処理をまとめて行う。（バッチ処理と呼ぶ）データ件数（100万件↑）も処理行程も多い。

バッチ処理が順々に動作していく様子はまるでピタゴラスイッチのようなイメージだ。

ただし、これは100万個の球が一斉に転がる、夜中のピタゴラスイッチだ。本家の仕掛けとは比較にならない正確性と堅牢性が求められる。そのため、予め仕掛けを準備して何度も問題なく流れることを検証する必要がある。

そして1番重要なことは、一度、球が流れれば全部完了するまでは全て自動で動いてくれる。

全自動が大前提になる。

…だいぶ話が脱線した。

即興ピタゴラスイッチ

話をトラブルに戻す。

全社データの1/3が消失した。

ただデータ消失そのものは、そこまで致命的ではなかった。消えたデータには、元となる他のデータ（マスターと呼んだりする）があるため時間をかければほぼ復元可能だった。

その時の真の問題は時間がないことであった。

データ消失が起きたのが、夕方5時頃。
それに全社で気付いて招集されたのが6時前。

この時点で、最初の夜間バッチ処理が開始する8時まであと2時間しかない。

もし夜間バッチ処理までに消失した全データが復元できれば何ら問題はない。

しかし、この時点でもうそれは絶望的である。消失したデータの数は恐らく一万個以上あり、自分の担当システムだけでも数百個はある。

そして、当時の偉い人は決断した。

今日の夜間バッチ処理は全て止める、と。

ただ処理しない訳にはいかないので（それをすると明日以降の業務が全部止まる）、全自動で夜間バッチ処理を流すこと、を止めたのだ。

流すデータもないのに、全自動で流し始めたら至る所で処理が止まったり壊れたりするので、それはまあ当たり前の判断ではあった。

問題は代わりにどうするか。

全部手動で処理するのである。データが復元できたところから順番に人海戦術で流していく。

まるで大規模な即興ピタゴラスイッチである。

アナログ人海戦術

これまであらゆる種類のシステムトラブルに見舞われたことはあるものの、この時に経験したトラブルリカバリほど大変だったことはない。

まずやったこと。

6時過ぎて既に帰宅していたチームメンバーを全員電話で捕まえて事情を話して会社に戻ってもらった。（理解を得て全員集合）

自チームが担当している夜間バッチ処理フローを全て紙で印刷。（※処理フロー：データ名、処理の流れ、依存関係等が記載されている）

たぶん1000ページ近い紙に対して、若手中心に消えたデータを全部○で囲んで印をつける。

先頭処理フローから順に、私とベテラン（ワーママ:夕食中に呼び出される）の2人が手分けして、消失データの復元方法をペンで書き込む。

書き込んだ方法で中堅社員達がデータを復元し完了したら、それ以降の処理を全部流すように運用部門へ連絡。

そうやって、全部で1000ページ分ある処理を、夜中かけてひとつひとつ流していった。

…この説明では、結局のところ何をやったのかイマイチ分からないかもしれない。

ただこれと同じことをあらゆる場所で他のチームも同時に行っており、その時のオフィスはさながら戦場のような熱気であった。

最初に書いたが、バッチ処理は正確性と堅牢性が肝である。普段はこんなアナログかつ即興で処理を動かすことは決してない。

何重にも確認や承認手続きを経て処理の変更が認められる。しかもデジタルな申請システムで証跡を残すのが基本である。

しかしこの時ばかりは、アナログな人海戦術で乗り切るしか手立てはなかった。

朝がまた来る

何とか制限時間内に処理は流れ切った。まさに奇跡的としか言いようがない。

朝を迎える時、誰しもが疲れ切っていた。

無事に流れ切ったことを確認して、チームメンバーは徐々に帰って行った。リーダーの私は、システムトラブルの原因となった事象を聞く為朝の6時からの会議にそのまま出席した。

誰しもが徹夜明けで不機嫌と眠気がMAXの中、原因を作った部署の責任者はさすがに居心地が悪そうな顔をしていた。

詳しくは書かないが、要するに考慮漏れと作業ミスが重なり、10連休明け消してはいけないデータまで削除する処理を動かした、とのこと。

皆の怒りのピークは既に昨晩越えていて、誰も強くは言わなかったが、どうやってビジネス側に説明するのか等いくつか質問が出たと思う。

しかし疲れ切っていて、ほとんど記憶がない。

ただ朝が無事来たことに心底ほっとしたのは、今でもよく覚えている。

…

このシステムトラブルを乗り越えた後、かなり自分が強くなったように感じた（良いか悪いかは分からないが）、思い出深いものである。

長文お読みいただきありがとうございます。