【障害記録】No.10：システムリリース直前に発覚した1億件規模の不正データリカバリ対応
自分が体験したシステム障害を紹介してトラウマを抉り返す自虐コーナー
※特定避けるため一部脚色・変更しているが、大体ほぼ実体験。
障害No障害分類No
（自分用）発生分類
アプリ/データ/ミドル/ハード案件名個人的ヤバイ度
（５段階評価）
| 10 | A | データ | システムリリース直前に発覚した 1億件規模の不正データリカバリ対応 |
★★★★☆ |
| 発生日時 | 2011/09某日 | 解決日時 | 2011/09中 | 発見者 | お客さん | 対応者 | 俺＋もう一人 | 原因者 | 俺ではない つもりだが… |
||||
| 障害の詳細内容 | 新システムの初期移行データとして、 約1億件に及ぶデータを1週間くらいかけて移行し、業務処理で集計するという移行作業を実施した。 平たく言うとこの「集計結果」が無駄に多い（集計する必要のないものまで集計している）という指摘。 ”業務処理で集計する”ことから移行データ自体の誤りではなく（一部はそれもあったが）、 業務処理自体の障害が発覚した形になった。 別にそれ自体はまあ比較的よくある話である。（あってほしくないけど） 問題なのはこれが発覚したのがシステムオープンの２～３日前という超直前であること。 それまで２回の移行リハーサルと、 移行結果をもとにしたお客さんの受入テストも１～２か月のレベルで実施済、 その中で誰一人今まで一度も指摘してこなかったというのに、 直前になって「やっぱだめだわこれ、直してちょ！」っていうのは、 あんたそりゃどう考えても虫が良すぎませんか！ という気持ちがあったのは正直なところであり、 実際そういう理屈に基づいて 「このタイミングでの移行し直しは正直無理、延期させてくれ」 という交渉はしたのだが、 「この数値が間違ってるのはヤバイ。 エンドユーザの目に触れる部分だけでも稼働までにリカバれ！」 という、お客さん上層部からの半ば強制的な命令が、 営業も部長もスルーして直接俺たちにおりてきて、 仕方なく対応を検討することにしたのである。 「直前で発覚した」という点に関しては確かに感情的に拒否したくなる事情があったものの、 それでもなお強く断りを入れられなかったポイントになっているのは、 この件が「業務処理の障害」に起因して起きている問題であるという点だ。 つまり「障害」なのだ。 最初この件が起きたとき、 設計書とソースを見比べて、仕様通りに実装されていることも確認し、 「ほら、うちは仕様通りに作ってますよ（だから障害じゃないんですよ）」 と主張して、一瞬 「う～ん…じゃあシステムは問題ないのか…（仕様を伝えた我々のミスか…）」 とお客さん側も長考ムードに陥ったのだが、突然 「いや！！ほら！！！議事録に！！！！こう書いてあるじゃないですか！！！！」 と声を大にして反撃してきた。 よく見たら確かに現在実装されているのとは違う「仕様」に関する回答が お客さんからの発言として議事録に明記されていた。 要するに、設計書通りには作られているが、その設計書が間違っていたのである。 その点に関して、完全にこちらの落ち度になったのは間違いないだろう。 それさえ発見されなければ…と思うところは今でもある。 しかし一瞬お客さんですら考え込んだのに、 こっちの粗を探し出して、それを見つけると、 手のひらを返したように「なんとしてでも対応しろ！」と言ってきたのに対しては、 正直個人的にいい気がしなかったのは事実である。 「人間は自分の有利に進めるためなら簡単に人格を変えられる」 とまでいうと大袈裟かもしれないが 少なからず人間の本性を垣間見た気がして、 なにかドス黒い闇を感じたのである。 |
||||||||||||
| 対応内容・経緯等 | 今回の移行の考え方は以下のような流れになっていた。
上の図でいうところの左側がもとになる「移行データ」で、 それを業務処理でいくつかのタイプのデータに集計したのが右側の「集計データ」 画面機能では「集計データ」のほうを参照する。 で、指摘は、例えば上の図を例にとると「集計種別アだけが違う（不要に多い）」といったもの。 →集計種別アはα１＋α２じゃなくてα１だけでいい（α２が不要）んだよなぁ、という感じ。 以後、これを指摘の全容として話を進める。 冒頭で「約１億件」と言っていたのはこの「移行データ」のほうで、 指摘があったのも「集計データ」のうちαに関する部分だけ（βとγは問題なかった）。 そういう意味では「1億件の移行データが全て間違っている」という指摘ではなかったが、 最初に指摘内容を聞いた時は漠然とそう解釈してしまった。 →βとγは指摘がなかったものの疑う必要が出てくるし、 仮にもし何らかの問題を内在しているなら それらも含めて全部再集計が必要なのでは、 という危機感からのものもあった 救いだったのは↑の＜集計処理＞が割と汎用的になっていることで、 元の明細データだけ起こせばあとはそれなりに集計してくれるつくりになっていたので、 α１＋α２のうち「α２だけが不要」なのだとしたら、 「α２の赤伝（マイナスデータ）」を無理やり発生させてそれを＜集計処理＞に流せば、 α１＋α２－α２＝α１となって辻褄が合うはず！という作戦が取れた。 ＳＱＬのイメージだと↓みたいな感じかな。 insert into 移行データ
select rownum as 明細番号
,データ種別
,値Ａ * -1 as 値Ａ
,値Ｂ * -1 as 値Ｂ
,値Ｃ * -1 as 値Ｃ
from 移行データバックアップ
where データ種別 = 'α２'
処理済（集計済）の移行データは「バックアップ」に移しておいて（そうでないと再集計して±0になってしまう） そこから値を負数にしつつ（×-1をしつつ）集計処理のＩＮになるテーブルにINSERTしていく。 加えて、直前に見つかったとはいえ、システムオープン「前」だったので、 日次の処理がどんなに遅れてもエンドユーザへのサービス影響はなく対応が出来た、というのも、 このリカバリについては追い風になってくれた。 ↑の流れで大量に赤伝を作ると、 通常日次処理で処理する量とは比べ物にならない量のデータを処理することになり、 日次処理が通常よりロングランすることになるのだが、 どんなに遅れようが困る人がいないので、 割と気兼ねなく大量データの流し込みを決行できたのは強みである。 ※少し余談になるが、冒頭でも書いた通り、 ＜集計処理＞の集計仕様が誤っていた（障害があった）わけだが、 この＜集計処理＞は日次で動く通常業務バッチ処理なので、 移行データに限らず通常日次で発生するデータに対する集計も誤っていたことになるが、 その点についてもお客さんからは全く指摘がなかった… この点については後述するが、まあ、ただの愚痴である。。。 なお、正確に言うと、集計データの中にも、
→エンドユーザへのサービス影響がありそうな範囲だけはなんとか、という、 お客さん上層部の言葉もそれを指している ２．は極論言うと社内周知だけしてもらえば リカバリしなくてもいいんじゃね？くらいの意見すら出たほどだが、 結局後日同じ方法でリカバリすることになる。 このシステムは土日は対外クローズしていたので、 ２．のリカバリは稼働後の土日を使ってちょこちょこと行った。 結局２．を含めると全データのリカバリ完了まで１ヶ月くらいかかった… |
||||||||||||
| 反省点・あとがき | このプロジェクトにおけるお客さん側の窓口となる部署は、Ｅ部とＪ部の２部署だった。 設計のレビューや課題検討の打ち合わせはＥ部とＪ部とだけ行い、 またお客さんの受入テストもＥ部とＪ部だけが行っていた。 一方で、稼働直前に「数値がおかしい」と指摘してきたのは ＥでもＪでもない別の部署、Ｍ部の方である。 プロジェクト推進の中では一切関わっていないから、当然俺はどの人かわからない。 実際、Ｍ部→Ｅ部／Ｊ部と指摘が伝わり、 Ｅ部／Ｊ部から俺らに課題提起されたという流れだった。 このシステムではお客さん社内における様々な種類の「数値」を扱っていたが、 上に挙げた図を例にとれば、 「集計種別βとγはＥ部とＪ部でもなんとなくわかるが、αはＭ部でしかわからない」 というような社内事情があったようだ。 要は、各数値には業務専門性があり、それを日常的に取り扱う部署でないと、 その数値の妥当性が判断できなかったということである。 プロジェクトの主担当だったＥ部とＪ部はαの数値になんの疑問も覚えず作業を進めており、 いざ稼働直前というところでようやく全社展開したところ、 「αの数値っておかしくないか？」って声が社内から上がったと。 その声の主がＭ部だったと、まあ、事の背景はそういうことのようだ。 エンドユーザに公開する情報に誤りがあるとなると、 「Ｅ部とＪ部ではわからなかった」は当然エンドユーザ向けには言い訳にならないので、 全社を挙げた対応が必要になるのはわかる。 今回の件は「ベンダー（俺ら）の障害」だったので無償の瑕疵対応になったが、 仮に、これが完全仕様通りで、対応するにしても有償の仕様変更対応になたっとしても、 「稼働までに何とかなりませんか」という交渉があっただろうことは容易に想像が出来る。 （その場合、費用に関しては後回しで、落ち着いた後で個別の契約とかって話になったのであろう） 逆にいえば、 まがりなりにも稼働直前までプロジェクトを推進してきたＥ部とＪ部からすれば、 全く無関係だった部署のＭ部から考えもしていない指摘が入ったことに対しては、 少なからずＥ部とＪ部のメンツはつぶれただろう。 上でドス黒い闇を感じたと言っていたのの背景には、 もしかしたらそういう事情もあったのかもしれない。 （ちょっと組織構造が縦割りになっている印象の強い会社だったから） まあそこは俺らが知る由はないところだが… |
||||||||||||
