146
31

More than 3 years have passed since last update.

あの夏の抽出件数を僕はまだ忘れていない

Last updated at Posted at 2019-12-19

これから読む君へ、さきにひとつ謝っておこう。
華々しい本番やらかしの告発が連なるこのカレンダーにおいて
今夜語る事件はあまりにも些細で地味なものだ。

そうさ、些細だが
1円を笑うものが1円に泣くように
1行を笑うものは1行に泣く。

データってやつに裏切られたくなかったら
しっかり両目を開いて見つめるんだ。
むろん、ブルーカット眼鏡も忘れずにな!

※年数がたっていて記憶がおぼろげなのをいいことに
 だいぶフィクション感てんこ盛りでお送りしたいと思います。そして小説風に便乗する輩。

あの夏

当時ぼくは零細SESの中でも、体育会系の空気を馬鹿にしきっていたので
逆に年かさのオジサンたちからは、素行の悪い輩だと目をつけられていた。

僻地での開発案件でけだるく過ごした後、あたらしく配属された常駐現場は
やる気のないやつはこれでもやってろと言わんばかりに
初めて運用の現場での契約となった。

斜にフーンと構えるぼくの胸算用とは別に
出迎えたチームメンバーとリーダーは少なからず期待をしてくれたようで
いかにもサーフィンが好きそうな日焼けしたパリピ主任と
いかにもいい人で眼鏡七三のサラリーマンパイセンと
スクエアな雰囲気でキレを感じさせるギークなリーダと
これまたいかにもいい人で気の弱そうないぢられメンバーくんetc.に
「開発経験者なんだってね!?」と温かな眼差しで迎えられた。

リーダ「ここはちょっと特殊な現場でね。ふつうはこんなにアクロバティックなことはしないんだけど」

   

業務内容は顧客データの保守運用なのだが
運用は初なので、ぼくには本来のオペレーションがどうあるべきかわからない。
ただただ本番データに触るのは、嫌な汗をかくなぁ…と
その時のぼくは呑気に遠い目をしていた。

普段の作業はこうだ。
既存の検証済みクエリを使ってデータの抽出または更新を行う。
実行したクエリごとに必ず抽出結果は残し、
連続したクエリは都度結果を確認しながら作業を完了させていた。
担当部署から作業依頼が来れば対応するし、
定常で月次週次で行う作業もする。
IR用の集計データなんかも、その一つだ。

データの更新に関していえば、絶対にダブルチェック・2者でのオペレーションが必須だった。
問題は抽出だったが、こちらも基本的にはダブルチェック…だったんじゃないかな。

時々、既存のクエリでは補いきれないからと
新規のクエリの建付けをしなければならない時があった。
そういう時は数日かけて、設計⇒製造⇒検証を行って初めて本番で使用…と言いたいんだが
組んでいたのは結局本番DB上だったような気がする。
テストデータは既存に触れないから、上流のチームに調整してテストデータを挿入してもらう。

この時点でけっこう怖いな?

建付けたクエリは当然レビューを受ける。
ぼくの場合はパリピ主任がお目つけ役だ。
よく深夜作業をしながらモテ自慢を挟んでくる以外は気のいい主任だし、
若いから、締め付けもゆるくて仕事がしやすい。
主任は主任で抱えている作業も多く、
ぼくが早々に自走できるようになったのでずいぶん信頼したのか
うるさく言われないのは大変に快適な環境だった。
まぁそんな期待に応えられなかったのは大変申し訳ないんだが。

ある日、お客様データの中から月次の通知かなにかの送信先を抽出したが
3件間違って送られていたという障害報告が入った。

本番DBで流したクエリの誤りを見つけて
本来抽出されるべきだった3名を改めて抽出しなくてはならない。

当然ながら緊急対応で、クエリを建付け、クエリのレビューも受け…たよな?
あれ?記憶ないぞ?

まぁカチャカチャとSQLを組み立て、ぼくは当該顧客の特定に急いだ。
終電まで小一時間というところで、
想定件数通りの3名を抽出したぼくは
パリピ主任に元気よく報告したんだ。

ぼく「クエリOKです!抽出できましたよ!」
主任「よっしゃ、3件?」
ぼく「3件!」

たしかそのとき、主任は主任で作業を抱えていたんだ。
緊急対応が無事済み、重い仕事をそれぞれ仕上げてスッキリしたぼくたちは
現場近くのBarでわずかな時間ながら祝杯をあげた。
忘れもしない。
主任は、よく対応してくれたと言って、ぼくのビールも気前よく払ってくれたんだ。

翌日、抽出作業には続きがあった。
昨晩抽出した3件の顧客はその時点で担当部署に送信され、
速やかに、つつがなく、フォローの対応がされていたはずだ。

報告作業用だったろうか、
改めて抽出結果の3件のレコードを、まじまじと見ていたんだ。

・・・

・・・?

?!

1行…値の違うレコードが混ざってる!!!!!!!!!?

惨劇はなぜおこってしまったのか

あれ?
昨日、ぼくってば確認したよね
主任と一緒に

「3件?」
「3件!」

そう、件数だけな。

まともに情報系の勉強してきた人なら当たり前の話さ。
クエリの検証に件数のみの一致では足りないなんてさ。

でも、でもだよ。

何十万何百万レコードを登録されてるわけじゃないか。
そんなさ、ぴったりさ、たった3件だけ
それも3件のうち1件だけが別物にすり替わって抽出されるもんだろうか?

抽出されるもんなんだよな!現実に

全身から血の気が引くという言葉の意味を、校長先生の話以外で感じたのはこの時ばかりだったよ。

障害発生からのお詫び対応での抽出失敗……!
最悪のタイミングでSQLの奥深さを思い知ったぼくなのだった。

二度と惨劇を起こさないためにどうしたのか

お気づきの方も多いと思うが、
日常的にオペレーションが効率重視で危うい運用ではあったんだとは思う。
まぁ、日本の金融・保険業界あたりでは打ち首獄門レベルで許されない間違いも
他業種では案外ゆるかったりもするし、
リスクも挽回のコストが払えるんならむしろ許容っていう外資のスタンスと思えば
起ったことは、自分が思うほど組織のダメージには、なってなかったのかもしれない。

それでも開発だけやってきて、本番コワイと思ってドナドナされてきた青少年には
ちょっと刺激の強いトラウマだったんだ。とらうま。

現場はどうあれ、
技術者的には検証は念入りに。
というかデータを保証できるだけの勘所を無駄なく効率的に検証するに越したことはない。

まぁパリピ主任のような口頭確認のみでダブルチェックとは呼べないあれも、
自分がその立場の時には気を付けような。
という雑な反省ですまない。

データというのは実に奥深いし、舐めてると痛い目を見るのだ。
そんな気持ちが文章量には反比例するだろうけども、
少しでも伝わったら僕はうれしい。

146
31
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
146
31