15
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

本番環境でやらかしちゃった人Advent Calendar 2022

Day 23

お客様のデータを先祖返りさせた話

Last updated at Posted at 2022-12-26

この記事は「本番環境でやらかしちゃった人 Advent Calendar 2022」の23日目の記事です。

私が新卒入社1年目にやらかしたことで、未熟さが大いに表れたミスであり、なんでこんな当たり前のことをやってないの?と思われるかもしれませんが、これから新卒として働き始めるエンジニアたちへの反面教師になればいいなと思い、投稿させていただきます。

どんな惨劇が起こったのか

当時私はいわゆるSIer企業に勤める1年目プログラマーでした。
業務内容は主にお客様が業務中に使用するデータ分析アプリの開発でした。
このツールには週次、月次、年次で行う必要のあるデータ更新作業があり、今回の惨劇はその週次作業で発生したものとなります。
データ更新作業はそれ専用のGUIツールが存在し、基本的にはそれのUI上から今回更新する必要のある週を選択し、実行するだけのツールとなっています。週選択は「yyyy/ww」形式のプルダウンから選択するものとなっており、今回も毎週のように対象の週を選択したことを確認し、実行ボタンを押しました。
バッチが流れ始めたことを確認し、私は先輩と共にランチへと向かいました。
楽しいランチの後、仕事場へ戻ると、電話対応をしている社員がおり、何やら深刻そうな話をしていました。
なんだか嫌な予感がしつつも、パソコンのスリープを解除し、ツールを確認した私は驚きました。
「ぜんぜん違う週のデータ更新してるやん」
このツールのデータ更新作業は簡単に言えば一度全てのデータを削除し、最新週までのデータを作り直すというものなのですが、ツール上で誤って数週間前の週が選択されており、結果、分析ツールで表示できる情報が数週間前に先祖返りしていたのでした。
電話はお客様からのクレームだったのです。

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

実はこの日、月次の更新作業も午後に行う必要があったのですが、何を勘違いしたのか私は週次の更新ツール上で月次の更新作業で選ぶべき年月を年週として選択して実行していたのでした。
UI上は年月も年週もスラッシュ区切りの数字6桁であり、また週次、月次のツールの見た目が酷似していたため、自分がやっていることのおかしさに気づけなかったのです。
また、この更新バッチがおよそ30~40分ほどかかるため、毎回流した後にランチに出ていたのですが、この日はお客様がこちらの完了後検証が終わる前にアプリを触ってしまい、クレームにつながりました。

どのように復旧したのか

お客様に現在の状況を説明の上、ツール上で本来選ぶべきだった年週を選択し、再度更新処理を走らせ、アプリ上の表示が問題ないことを確認しました。
先祖返りしていた状態でアプリを触ったのはクレームを入れたお客様一人だけだったので、そこまで大事にならなかったのが幸いでした。

惨劇を起こさないためにできること

実行前にダブルチェックを徹底する

まずはこれに尽きると思います。実行ボタンを押す前に他のメンバーと一緒に問題ないことを確認するべきでした。特にお客様の分析業務に大きな影響を与える作業であったため、これを怠ったのは非常にマズイです。

バッチの完了・更新後検証を行わずに長時間離席しない

更新バッチを流した後、すぐにランチのため離席していましたが、これもあまりよろしくないです。データ更新に異常があった場合に発見が遅れ、影響範囲が拡大する恐れがあります。

プルダウン選択値が想定外のものになっていないかツール側でチェックする

今回のケースですと、現在のデータの最新日付を確認し、それ以前の年週が選択された場合はそもそも実行させないというような実装をツール側にしておけば、防げた問題ではありました。人の手が介在する作業にはどうしてもヒューマンエラーが付き物なので、プログラムで防げる部分はできるだけ機械に任せたいところです。
そもそもプルダウンで週選択をさせる必要もなかったのではないかと今では思います。

週次のツールなのか月次のツールなのか見た目ですぐにわかるようにする

週次のツールと月次のツールの見た目が酷似していたことも一因なので、見た目ですぐに判別できるようにしたいです。実際このやらかし後、ツール上に「これは週次のツールです」のようなクソデカ赤文字が表示されるように改修されました。

お客様へのメンテナンス時間の周知を徹底する&メンテナンス中にアプリを触られても問題ないようにする

今回検証作業前にお客様がアプリを触り、クレームに繋がったわけですが、明示的にこの時間に更新作業を行いますよという合意が取れていませんでした(もしくは御偉方の間では取っていたのかもしれませんが、お客様側に十分に周知されていませんでした)。
またお客様がメンテナンス時間内に触ってもいいように、メンテナンス中である旨をアプリ上に表示する、もしくは可能なら更新検証が終わったのちにデータを本番反映できるような仕組みを導入するようなことができればベターだなと思います。

おわりに

正直、見直した方がいいことがまだまだたくさんあると思いますが、キリがないのでここまでとします。
新人の頃にはとんでもないミスを犯してしまうこともあるかもしれませんが、人は何かしら必ずミスをする生き物です。
結局はそこからどう学んで今後に活かすかが大事だと思います。
いつの日かそんなミスも笑い話の一つとして語れるようになったら、ある意味成長できた証なのかな?と思います。

15
4
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
15
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?