怒涛の夜勤
2004年7月1日6/21〜6/25。7月1日のリリースに向けて、懸命の調整作業。
6/29に本番データベース変更作業に向けて、各グループとの調整が
行われていた。
1．開発チーム（当日、データ更新作業）
2．データベース変更チーム（当日、データベース変更作業）
3．インフラチーム（当日、サーバーの再起動作業）
俺は2の「データベース変更チーム」に所属。
当日、サーバーをダウンさせている間に、データベースの定義を
変更するのが主な作業だ。今回は、
「2時間30分のサーバーダウン中に作業を完了する」
ということで、時間内に終るよう、綿密に計画を立てた。
開発チームから、作業の見積もり時間をもらい、インフラチームと
サーバーダウン時間、各種作業のトリガーについて打ち合わせを実施。
当日の作業フローとチェック用紙を各チームに配布。
本番環境で流す、データ定義変更のスクリプトも開発環境で
5回流して、ミスのないことを確認。さらに、時間を過去の資料と
サーバーのスペックから計算して、秒単位で見積もった。完璧だった。
開発チームにも、当日の失敗がないように口酸っぱく、
「更新するSQL文の見直し依頼」、「所用時間の確認」を行った。
--- 作業スタート！
当日、俺とY先輩はお客様先で作業。
残りは、自社作業という体制で進めることとなっていた。
俺とY先輩は、作業開始の1時間前にお客さん先に到着。
事前準備作業を追え、お客さまにサーバー停止の確認を取り、
1時ちょうど、Y先輩のサーバー停止作業で一斉に作業開始っ！
--- すべては計画どおりに
俺の作業が始まった。事前にチェックを繰り返してきたので、
自信を持って作業に臨めた。ミスもなく、いたって快適に作業は進む。
各チームに配布したチェックシートには順調に「済マーク」が入り、
残るは、「開発チーム」のデータ更新処理と軽い残作業だけなった。
計画よりも30分前倒し。もはや、予定終了時刻を待たずして
45分の前倒し終了は確定的に思われた。
--- いつまで経っても終らない！
3時。まさかの事態が発生。予定では、15分で完了するはずの
データ更新処理が、1時間経っても終らない。しかも、1時間経過して、
まだ50％だと言う。もはや、序盤の30分のマージンも使い果たし、
時間内に作業を終了するのも絶望的となった。しかも、連絡が遅すぎる！
何事かと、更新を行うSQL文を見ると、そこには驚くべき記載が！
最悪だ。INDEX（索引）を使わないようなSQLとなっていたのだ。
INDEX（索引）と言われてピンと来ない人は、本の目次を
思い出して見るといいだろう。
たとえば、1冊の「料理の本」があったとして、
「中華」「洋食」「和食」に大きく章が分かれているとする。
今、「麻婆豆腐」の作り方を調べたいと思ったとする。
読者は、まず「中華」のページを目次から探すだろう。
なぜなら、1ページ目から「麻婆豆腐」を探すのは効率が悪いからだ。
「中華」のページを目次から見つけた時点で、今は関係のない
「洋食」「和食」のページを飛ばすことができる。
欲しいデータを検索する際、目次（INDEX）を利用することで、
圧倒的に探す時間を短縮できるはずだ。
データベースにもこれと同様の考え方があり、これをINDEXという。
話を元に戻そう。
INDEXを使用しないSQL文を組んだがために、更新対象データを
見つけるまでにかなりの時間を要してしまってたのだ。
当たり前だ。1400万件を1件目から判断しているのだから。
見積もり時間15分とお客さんに言っておいて、実質の時間は2時間以上。
これは、世が世なら「切腹」ものである。
今さら「ムンクの叫び」顔をしても、ボケたフリをしても始まらない。
お客様に作業遅延の報告を入れる。どうにか、30分の延長が許された。
SQL文を修正し、再度実施すると、なんと今度は5分で終了♪
残作業も完了して、予定時間を30分オーバーしたが、なんかと完了！
お客さんに終了報告をして、帰る準備を始めた矢先だった。
--- すみません、納品するプログラムを3本ほど漏らしてました…
耳を疑うような情報が飛び込んできた。
またもや開発チームのチョンボである。この日、お客さんに納品する
プログラムは全部で40本だった。しかし、本当は43本だったのだ。
リリース（納品）メールに書き漏らしてしまったのだと言う。
今さら「北斗百列拳」を叩きこんでもしょうがない。
1．自社からお客さんへプログラム配信
2．お客さんが全国の支店へプログラム追加配信
とりあえず、2が終るまでは動くに動けない雰囲気に…。
こっちはミスしてないのに、お客さん側であり、針のムシロである。
まじで勘弁してくださいよ(つД⊂)
--- あれ？！おかしなデータベースエラーが出ているぞ！？
7時。もう朝である。随分と明るくなったものだ。陽も差して来た。
ふー、それにしても眠い！眠い戦隊、ネムインジャー降臨である。
お客さんの配信終了を待つだけの時間。何かする作業もないので、
ほんまにツラい。早く終ってくれー。
とその時、Y先輩が思わぬ一言を。
「あれ？おかしなデータベースエラーが出てるぞ？！」
見せてもらうと、確かにデータを格納する一時作業領域が溢れている。
これは、短時間に大量のデータに更新がかかったことを意味する。
「おかしい。開発チームのデータ更新処理はとっくに終わったはず」
--- すみません、データ更新処理が失敗していました！今やってます！
不振に思ったY先輩が、うちの開発チームに電話を入れた。
Y先輩
「お疲れさま。何かそっちでやってる？」
開発担当
「はい、やってます！さっきの更新処理が失敗してたんです！
さっき気づいて、今更新処理をスタートさせたところです！」
工工エエェェ（´д｀）ェェエエ工工
そんなことってあるのか〜？！更新処理の失敗って、どういうこと？？
もうデータベースは起動してるわけだから、
1．更新処理失敗のため、現行のプログラムでエラーが発生する
2．データベース停止せずに更新処理をやると、
別のサブシステムが強制停止する可能性が高い
3．データ更新処理を今さらやっても、恐ろしく時間がかかる
と、明らかにヤバいことだらけ…。ナニを考えてるんだー（泣）。
--- 10時30分から約10分、サーバーが緊急停止します。
全国の支店に対して緊急のFAX配布。お客さん、もうカンカンである。
結局、うちの幹部クラスとお客さまの会話により、
10時30分から約10分程度、サーバーを停止することとなった。
朝9時くらいから、お客さんの社員も続々と出社するし、
伸びたヒゲ、やつれた顔。恥ずかしいったらありゃしないよ。
いろいろとトラブルが重なったわけだが、根本的な原因は、
開発チームは事前準備が甘すぎた
これに尽きる。SEとして恥ずかしいことです。
たぶん、この失敗を契機に大きく変わるはず。いや、変わらなければ
ダメだろうな。会社的に…。
今日の失敗を体験して、ナニが一番大切か分かった気がした。
プライドは高いが、ビジネススキルの欠如したSEが多い。
俺は絶対にそんなダメダメSEにはならないぞ、と心に誓って、
お客さん先を後にする。
もう13時か。9時間の遅延だナ(つД⊂)
6/29に本番データベース変更作業に向けて、各グループとの調整が
行われていた。
1．開発チーム（当日、データ更新作業）
2．データベース変更チーム（当日、データベース変更作業）
3．インフラチーム（当日、サーバーの再起動作業）
俺は2の「データベース変更チーム」に所属。
当日、サーバーをダウンさせている間に、データベースの定義を
変更するのが主な作業だ。今回は、
「2時間30分のサーバーダウン中に作業を完了する」
ということで、時間内に終るよう、綿密に計画を立てた。
開発チームから、作業の見積もり時間をもらい、インフラチームと
サーバーダウン時間、各種作業のトリガーについて打ち合わせを実施。
当日の作業フローとチェック用紙を各チームに配布。
本番環境で流す、データ定義変更のスクリプトも開発環境で
5回流して、ミスのないことを確認。さらに、時間を過去の資料と
サーバーのスペックから計算して、秒単位で見積もった。完璧だった。
開発チームにも、当日の失敗がないように口酸っぱく、
「更新するSQL文の見直し依頼」、「所用時間の確認」を行った。
--- 作業スタート！
当日、俺とY先輩はお客様先で作業。
残りは、自社作業という体制で進めることとなっていた。
俺とY先輩は、作業開始の1時間前にお客さん先に到着。
事前準備作業を追え、お客さまにサーバー停止の確認を取り、
1時ちょうど、Y先輩のサーバー停止作業で一斉に作業開始っ！
--- すべては計画どおりに
俺の作業が始まった。事前にチェックを繰り返してきたので、
自信を持って作業に臨めた。ミスもなく、いたって快適に作業は進む。
各チームに配布したチェックシートには順調に「済マーク」が入り、
残るは、「開発チーム」のデータ更新処理と軽い残作業だけなった。
計画よりも30分前倒し。もはや、予定終了時刻を待たずして
45分の前倒し終了は確定的に思われた。
--- いつまで経っても終らない！
3時。まさかの事態が発生。予定では、15分で完了するはずの
データ更新処理が、1時間経っても終らない。しかも、1時間経過して、
まだ50％だと言う。もはや、序盤の30分のマージンも使い果たし、
時間内に作業を終了するのも絶望的となった。しかも、連絡が遅すぎる！
何事かと、更新を行うSQL文を見ると、そこには驚くべき記載が！
最悪だ。INDEX（索引）を使わないようなSQLとなっていたのだ。
INDEX（索引）と言われてピンと来ない人は、本の目次を
思い出して見るといいだろう。
たとえば、1冊の「料理の本」があったとして、
「中華」「洋食」「和食」に大きく章が分かれているとする。
今、「麻婆豆腐」の作り方を調べたいと思ったとする。
読者は、まず「中華」のページを目次から探すだろう。
なぜなら、1ページ目から「麻婆豆腐」を探すのは効率が悪いからだ。
「中華」のページを目次から見つけた時点で、今は関係のない
「洋食」「和食」のページを飛ばすことができる。
欲しいデータを検索する際、目次（INDEX）を利用することで、
圧倒的に探す時間を短縮できるはずだ。
データベースにもこれと同様の考え方があり、これをINDEXという。
話を元に戻そう。
INDEXを使用しないSQL文を組んだがために、更新対象データを
見つけるまでにかなりの時間を要してしまってたのだ。
当たり前だ。1400万件を1件目から判断しているのだから。
見積もり時間15分とお客さんに言っておいて、実質の時間は2時間以上。
これは、世が世なら「切腹」ものである。
今さら「ムンクの叫び」顔をしても、ボケたフリをしても始まらない。
お客様に作業遅延の報告を入れる。どうにか、30分の延長が許された。
SQL文を修正し、再度実施すると、なんと今度は5分で終了♪
残作業も完了して、予定時間を30分オーバーしたが、なんかと完了！
お客さんに終了報告をして、帰る準備を始めた矢先だった。
--- すみません、納品するプログラムを3本ほど漏らしてました…
耳を疑うような情報が飛び込んできた。
またもや開発チームのチョンボである。この日、お客さんに納品する
プログラムは全部で40本だった。しかし、本当は43本だったのだ。
リリース（納品）メールに書き漏らしてしまったのだと言う。
今さら「北斗百列拳」を叩きこんでもしょうがない。
1．自社からお客さんへプログラム配信
2．お客さんが全国の支店へプログラム追加配信
とりあえず、2が終るまでは動くに動けない雰囲気に…。
こっちはミスしてないのに、お客さん側であり、針のムシロである。
まじで勘弁してくださいよ(つД⊂)
--- あれ？！おかしなデータベースエラーが出ているぞ！？
7時。もう朝である。随分と明るくなったものだ。陽も差して来た。
ふー、それにしても眠い！眠い戦隊、ネムインジャー降臨である。
お客さんの配信終了を待つだけの時間。何かする作業もないので、
ほんまにツラい。早く終ってくれー。
とその時、Y先輩が思わぬ一言を。
「あれ？おかしなデータベースエラーが出てるぞ？！」
見せてもらうと、確かにデータを格納する一時作業領域が溢れている。
これは、短時間に大量のデータに更新がかかったことを意味する。
「おかしい。開発チームのデータ更新処理はとっくに終わったはず」
--- すみません、データ更新処理が失敗していました！今やってます！
不振に思ったY先輩が、うちの開発チームに電話を入れた。
Y先輩
「お疲れさま。何かそっちでやってる？」
開発担当
「はい、やってます！さっきの更新処理が失敗してたんです！
さっき気づいて、今更新処理をスタートさせたところです！」
工工エエェェ（´д｀）ェェエエ工工
そんなことってあるのか〜？！更新処理の失敗って、どういうこと？？
もうデータベースは起動してるわけだから、
1．更新処理失敗のため、現行のプログラムでエラーが発生する
2．データベース停止せずに更新処理をやると、
別のサブシステムが強制停止する可能性が高い
3．データ更新処理を今さらやっても、恐ろしく時間がかかる
と、明らかにヤバいことだらけ…。ナニを考えてるんだー（泣）。
--- 10時30分から約10分、サーバーが緊急停止します。
全国の支店に対して緊急のFAX配布。お客さん、もうカンカンである。
結局、うちの幹部クラスとお客さまの会話により、
10時30分から約10分程度、サーバーを停止することとなった。
朝9時くらいから、お客さんの社員も続々と出社するし、
伸びたヒゲ、やつれた顔。恥ずかしいったらありゃしないよ。
いろいろとトラブルが重なったわけだが、根本的な原因は、
開発チームは事前準備が甘すぎた
これに尽きる。SEとして恥ずかしいことです。
たぶん、この失敗を契機に大きく変わるはず。いや、変わらなければ
ダメだろうな。会社的に…。
今日の失敗を体験して、ナニが一番大切か分かった気がした。
プライドは高いが、ビジネススキルの欠如したSEが多い。
俺は絶対にそんなダメダメSEにはならないぞ、と心に誓って、
お客さん先を後にする。
もう13時か。9時間の遅延だナ(つД⊂)
コメント