上司(営業さん)に報告。言っても、1人1人が独立してやっている会社なので、営業も他の開発も助けてくれるわけでもなく。お客様(結構大企業)に事情を説明。激怒するというよりは、冷静に、復旧手段を考えてくれとのことで必死に考えました。(この時点で夜10時)ひとまずサイトはこの時点で停止されました。昨日時点の、バックアップDBがあることをお客様に確認。よし!と一休さん並に思いつきました!!!復旧手順1:バックアップDBがある分はユーザーIDをメールアドレスの一致で普及し復旧手順2:バックアップDB後に登録されたユーザーは、登録時の履歴メールから普及することでなんとか普及できる!(履歴メールがDBで残っていてよかった)まずは電話でお伝えする。⇨社内で検討するので資料を作ってくれとのこと。相手は、偉い人も含め数名が残っています。(こちらは私1人)復旧手順の資料を作る。30分後くらいにOKが出ました。次は復旧後に、復旧が正しく行われたことをどう確認するかの資料を作ってとのこと。復旧後にその数が一致することを確認できる手順を記載した資料を提出。お客様から資料の確認が取れ、OKが出ました(この時点で深夜2時)社内には私一人しかいません。皆大丈夫?とは気遣ってくれるものの、手伝えるような社内の組織体系ではないので、残念ながら、一人で対応するしかない。復旧手順1と復旧手順2の復旧プログラムを作成そして復旧後の確認プログラムも作成。プログラムをお客様に提出。(この時点で深夜4時)よくわからないだろうけど、一応確認してくれたみたいで、OK実行してくれとの許可がおりました。(この時点で深夜5時)ここからスムーズにいきました。復旧プログラムを実行し、確認プログラムを実行。奇跡的にしかるべき数値になっていました。そのまま報告し、OKをもらい、その後お客様の方でサイトの停止から再稼働。(午前7時、もうギリギリっすわ)その後、お客様からは、深夜稼働分の請求はきました。本日の教訓ひとーつ:UPDATE文(DELETE文も)には、WHERE句は絶対必要!!!はぁ?と思うかもしれませんが、非常に大切なことです。WHEREによるUPDATEや、DELETEを許していないフレームワークもあります。UPDATE、DELETEはデータを取得し、プライマリーキーを指定することでしか実行できないようになっていたりします。次ひとーつ:障害復旧には復旧したことの証明が必要!!実はこれ結構重要で、これがあると、お客様は納得してくれます。中身はシステムよりになるので、意味はわからないのでしょが、ここの数値が合えば、うまくいった証拠になります。いうのが伝われば、納得してくれます。この技はその後も社内での復旧作業時も含め、何度か使用しました。いかがでしたでしょうか。皆様もこのような大トラブルの1つや2つは経験していると思います。それを今後にどう活かすかですよね!!(超ポジティブシンキング)ということで、今後もアップしていきますので、ご愛読の方よろしくお願いします。コメントをキャンセルメールアドレスが公開されることはありません。FameThemes。