真面目で優しいシステムエンジニアは損をする18~リカバリ~
どうも！ヒグッティ(ヒグッティ＠システムエンジニア)です！
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は当事者意識についての話について書きました。
今回も引き続きデータ移行の話です。では、お楽しみください！
今回の記事で言いたいこと
単体テストはロジックの網羅とデータパターンの網羅が必要。
バグをお客さんに報告する時は胃が痛い。
バグや障害が発生し徹夜で対応してもお金や休みをくれるわけではない。
リカバリ
6月中旬に実施した模擬移行テストは見事に失敗しました。原因は夜バッチ処理が異常終了したためでした。異常になった原因はプログラムのバグでした。単体テストの時点で見つかるべきバグでしたが…plsqlからJavaに変換した時、十分に単体テストができていませんでした。元々、無茶なスケジュールで変換していたので多少はバグがあるとは思っていましたが…
バグのあった機能を調べると、そもそも単体テストが2件くらいしかありませんでした。ロジック上はテストが網羅できていてもデータパターン的に網羅ができていなかったのです。レビューも十分にできていなかったですし…
バグ自体は修正すればすぐに直ることがわかりました。問題はお客さんへの報告でした。もちろん、起こったことをそのまま報告するのですが、業務知識や技術的な知識がない人に問題を報告するのは一苦労でした。しかし、最も重要なことはリカバリでした。どうやって復旧させるのか、データをリカバリするのかも考えなければなりませんでした。
ヒグ：皆さん朝からお集まり頂きありがとうございます。今回、夜のバッチ処理が異常終了した原因についてご報告します。
仲間：ヒグさん、ちょっと確認だけど、今、新システムは処理が全部止まってるの？
ヒグ：はい…夜バッチが1つでもエラーになると次の日のバッチ処理は動かないので、今日の朝バッチは全て停止しています。
仲間：わかりました。バッチ処理のリカバリも考えておいてくださいね。
ヒグ：了解てす。では説明します。
バグの内容や修正方法を一通り説明しました。
仲間：バグについては了解です。今回は移行のテストなのでバグについては一旦置いておきましょう。問題は今からどうやってリカバリするかです。そこは考えてますか？
ヒグ：まだ資料などは用意できていませんが、考えはあります。
仲間：では資料ができたら見せてください。いつくらいになりますか？
ヒグ：16時くらいまでには…
仲間：了解です。では16時から会議をしましょう。
午前中の会議が終わりなんとか終わりました。バグについて詰められるかと思いましたが、仲間さん的には移行のリハーサルの観点を重視していました。バグよりもリカバリ方法を優先したいということでした。
そして16時からの会議のためリカバリ方法を考えました。
リカバリ方法は2案ありました。
1.とまったバッチから今まで流れるはずだったバッチを全て流す
2.現行本番DBサーバからデータを取得し直し、データの断面を一致させてから、バッチを流す。
1は時間的に無理でした。バッチを流すのにデータの断面を合わせたり、前日のファイルを用意したりとやることが多すぎました。もちろんお客さんにはそんなこと言えないので、別の言い方で説得しました。それは、流すバッチの本数と時間です。1バッチあたりにかかる時間が準備含め平均10分、それが約100バッチあると計算しました。なのでリカバリ時間が単純に16〜17時間かかることを説明しました。お客さん的にはその方法でやってほしかったようですが、今から16時間リカバリしたら、明日の朝9時になるんですよね、、、寝ずに徹夜でリカバリしろよ！って話でした。正直、それでは体も心も持たないし、そんな状態で仕事してもミスが多くなるだけ…私はゆとり世代なのか率直に思いました。IT業界の40代以降の人って割と徹夜してでも終わらせろ的な圧力かけてくるんだよなぁ。なので16時からの会議は案2でいくしかない状況でした。
余談ですが、緊急事態の時は寝れないってのが当たり前になっていますが、対応したところでお金や休みはもらえません。だってミスはこっちの責任だからね…自分達の責任は自分で拭く！当たり前ですが、正直やってられないですね！言われた通り動作しない時だけ怒られて、正常に動いているときは、お客さんにとって当たり前だと思われています。当然のことだけどね。下請けSierはお客さんの言われた通りにシステムを作って、バグを出さずにリリーズ、運用することで、初めてお客さんから信頼を獲得できます。リリース後、バグを１件でも出したら支払った金額に見合わないと裏で言われますね。1次受け、2次受けの会社は責任が重いので、厳しいことを言うのはわかりますが、、、その分、下請け会社に支払うお金は安くなっています。私の感覚は20%はお客さんに抜かれていると思います。そりゃー、俺の給料上がらないわけだ(笑)。
16時の会議で何とか時間がかかり過ぎるという説明でお客さんに納得してもらいました。
この時、沖縄さんが色々とアイディアを出して、お客さんにも説明してくれたので助かりました。お客さんを説得するのに２時間は会議していました。なんでバッチを流すのに時間がそんなにかかるのか？そもそも他に方法はないのか？など、色々言われました、、、この時からお客さんの信用を既に失っていたような気がします。プロジェクトを進めるうえで一番きつい状況でした。信用を失うと何も進められなくなるからです。
そんなこんなで現行本番DBからデータを取得し直すことになりました。もちろんエラーとなった処理は修正しました。
その後は何とかリカバリを完了させ、再度、バッチを流すことができました。模擬移行テスト自体はその後も順調に進み何とか終わりました。
この模擬移行テストで各作業の手順やかかる時間が大体わかりました。処理が止まってしまった時どうするか決めていなかったので、ドタバタしましたが、今回を教訓にとりあえず処理は動かし続けようということになりました。
ちなみにこれと同じことをあと2回やります…模擬移行テストは最低でも2回実施することがリリース条件だそうです。ちなみにこの情報はこのテストが終わった時、初めて聞きました。
次の模擬移行テストは7月上旬です。それまでにさらに準備が必要です。この時私は、今回のテストで大体は資料ややり方も確立されたので次はそんなにやる事がないかなぁと思っていました。しかし、以前として、タスクや時間に余裕ができたわけではありません。相変わらず人は足りない、タスクは多い、慢性的な高負荷状態でした。
しかし、この時、プロジェクトが爆弾を抱えていることをまだ私は知りませんでした。それは遡ること1月のこと。
システムテストをどうやって実施するかを決めている時でした。
ヒグ：PMさん、システムテストのweb画面系のテストはどうしましょ？今、画面は使えますが、認証機能が使えないので、本番とは動きがちょっと違うんですよ。今のままでもテストはできますけど、このままテストしていいですか？
PM：そうだねー。認証機能を使うには、会社内で申請出さなきゃいけないんだけど間に合わないなぁ。どこに申請出していいかもわからないし(笑)。今回は認証機能は無しでテストしようか！
ヒグ：了解です。認証機能を使えるようにする申請っていつくらいに通りますか？
PM：わからない！まずはどうやって申請するか調べてみるわ！
ヒグ：了解です。（相変わらずだけど、大丈夫か…）
この認証機能の申請が後の爆弾になってきます。4月に入ったあたりから毎週、この申請について提出したかをPMさんに確認していましたが、まだ余裕あるから大丈夫っと言われていました。今は6月の下旬。確かにまだ余裕はあるのかもしれませんが…
この時はまだこの認証の申請が重要であることを全く気付いていませんでした。そんなことなど忘れ１回目の模擬移行テストが終了し少し安心していました。
この時期、休みの日でも気力がわかず無駄に過ごしていました。１日中何も考えずにただyoutubeをダラダラと見ていたりと。たまにランニングして気分転換していましたが全く効果が無いように思えていました。