#145:システムトラブル回顧録（１）締日がズレている！

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

初回はこの時期（期末決算期の４月）になると亡霊のように蘇るあの記憶。

トラブルの始まり

最初は業務部門の照会で気付くことになった。

かなり定番のトラブル検知の仕方ではあるが、システム側（IT側）で自ら気付くべきトラブルをある意味で社内の顧客から知らされるのは、トラブった上に検知できない二重の失態だ。

とはいえ、起こったことは仕方ない。

当時そのシステムの担当リーダーだった私は、早速メンバーと調査を開始。

この期末決算の真っ只中というタイミングで起きるトラブルは、危険過ぎる匂いしかしない。

初期動作

システム部門に居ない人にはピンと来ないかもしれないが（もしくは他社では違うかもだが）トラブル発生で初期動作は止血と報告である。

全容解明やら、原因は何か一刻も早く調べたい気持ちになるが、それは初期動作の後のこと。

システムトラブルと言っても、結局はビジネスを遂行する手段のひとつなので、如何にビジネス（顧客や社会、業務）に影響を与えるかで、トラブルの深刻度と対策が変わってくる。

まずトラブルを広げないような最低限の処置（止血）はしつつ、何が起きてるか、ビジネスにどのような影響が及ぶのか、社内関係者（自部門の上司やビジネス部門）に報告する。

少し前置きが長くなったが、この時のトラブルは社内全体を巻き込むかなりデカいものであり（不幸中の幸いで顧客影響はなし）、最終的なリカバリは次の月まで引きずった。

トラブル事象と影響

では、何が起きたのか。そして影響は。

簡単に言うと、期末の締日設定が誤っていた。うーむ…、たぶんこれだけでは何のことかまだよく分からないと思う。

前職では（トラブルの記憶は全て前職の話）、期末売上の最終締め切り日（締日と呼ぶ）を、その年度では仮に4/7と決めていたとしよう。

例えば、3月末にお客様から受注したら（契約は3月末日で締結済み）、社内に売上申請する手続きの最終締め切りが4/7といった感じ。

その締日には当該年度の売上が全て確定して、会社全体として年度末の決算処理が動くという最重要なイベント日のひとつ。

その日付設定が１日前にズレていた…。

ちょっとでもシステムに（もしくは会計や経理周りの業務に）関わったことのある方なら、このトラブルが引き起こす破壊力がもしかしたら想像つくかもしれない。

締日を意識して全社のシステムが動くため、自チームのシステムのみならず、他チームが担当するシステムも軒並み誤作動していることが判明した。

…血の気が引く、とはまさにこのことである。

影響調査と原因

しかし、そんな悠長に落ち込んでる暇はなく、関係する全チームを召集して起きていることを説明して、どれだけ影響が出ているのかを把握するための調査を依頼。

突然呼び出されて、とんでもないことが起きている事実と突発的な調査を依頼された各チームリーダー、責任者たち（部長や課長たち）から視線が突き刺さる。少し唖然とした空気。

ただ彼らはシステム部門にいる歴戦の猛者たちなので、すぐ飲み込んで淡々とメンバーに調査タスクを振る。いくつものトラブルを乗り越えてきたからこそ、今回のヤバさは即共有されて部門一丸となっての対応となった。

それにしても、影響調査と同時に、自チームでは原因を突き止めて締日を早急に修正しないといけない。すると程なく原因判明。

シンプルに言うと、メンバーの修正漏れ。

割と中堅に近いキャリアのメンバーだったが、締日設定の仕組みをきちんと理解しておらず、昨年末（12月）に仮設定した後、ビジネス部門から変更連絡が来ていたにも関わらず、対応が漏れていたという理由。

ガックリするが、まだ落ち込んでる場合でも、そのメンバーを責めている場合でもない。

とにかくビジネス影響を最小限に食い止めるために、各チームの調査結果をまとめつつ、必要な対応策を洗い出して、できることは全て手を打たないといけない。

今日の夜間にその締日当日の処理があるため、時間との勝負だ。

トラブル報告

このレベルのトラブル（全社影響あり）になると、ビジネス部門と連携した上で全社宛に一斉連絡する。全国でトラブルの影響を受けて売上計上ができない社員がいるので、一刻も早く、お詫びと障害の報告、復旧見込みを伝えないといけない。

ビジネス部門とのオンライン会議でももちろん謝り通しではあるが、もはや謝るのがどうとかではなく、如何にトラブル時として正しい動きが迅速に漏れなくできるか。

アドレナリンがドバドバ出て、目はバキバキである。この強烈な覚醒作用により、未だに記憶の中で鮮明に焼き付いているのかもしれない。何の記録も辿らずとも、ここまでサラサラと思い出すことができる。

それはともかくとして、厳密な影響範囲はどこまでであり、影響を受けた箇所の復旧見込みはいつで、各現場にはどういう依頼を出すのか、ヒリヒリとしたやり取りが続く。

この辺りがトラブル時、責任の一旦でも担う役割であれば1番シビアなパートかもしれない。

曖昧な答えは一切許されないし、普通に怒号が飛び交い、抜け漏れがないかのあらゆる角度から意見がガンガン出る。

夜間バックアップと早朝確認

そして、ひと通りトラブル報告が済んだ後に、今晩行う緊急対応の内容が大体見えてくる。（冒頭の写真のように、ホワイトボードに書き出す）

そして、誰が残って処理を見守るか、翌日早朝システムの正常稼働を誰がチェックするかなど分担を割り振る。翌日以降に持ち越した調査タスクやリカバリタスクも出揃っている。

ここまで来るとようやくひと息つく段階。

日中のハイテンションも収まり、どっと疲れが出てくるタイミングでもある。水しか飲んでないことに気づいて、誰かが買い出しに行ってきたおにぎりやスナック菓子を口にする。

まだまだ明日以降も長い。

詫び状もあれば、原因分析と再発防止策の検討と報告もある。果てしなく続くように思える。

しかし、あまりにも強烈な今日１日の出来事に脳はその先を想像する余地もなく、家に帰るとバタンと寝るだけ。

教訓もなく終わりに

…

サラッと書くつもりがだいぶオーバーして書き連ねてしまった。恐ろしいほどに覚えている。

もうかれこれ6、7年以上も前の記憶なのに。

これ以外にも大きなシステムトラブルは、片手では足りない数を経験している。どれもこうしてスッと引き戻せるのかと思うと少し怖い。

また果たしてこの記録は一体何の役に立つのだろうか。よく分からないまま吐き出してみた。

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