どうも、いからしです。気づけばもう年末ですね。

年末最大の楽しみといえばもちろん、Qiitaの本番環境でやらかしちゃった人アドベントカレンダーを見て一人ほくそ笑むことですね。

とはいえ毎年ほくそ笑んでいるだけだと性格の悪い陰湿根暗クソ野郎だと思われかねないので、私がいかにハートフルで人間味のある熱い人間であるかを伝えるためにも、このブログで過去の失態を2つほど書いてみることにします。

いずれも若かりし頃の愛嬌ある失態なので、そろそろ笑って許されるかな(テヘペロ って感じでお願いします。本当に。

(ちなみに今回、技術的な話題は全然ありません)

(あと案件の内容とかは多少ぼやかしてます)

 

性能試験で連携先システムをパンクさせる

よくある話ではあるんですけど、初期開発時にちゃんとした性能試験を実施していなかったシステムがありまして。

そいつが運用開始から2年ほど経って色々と性能的な問題を出し始めたんですね。

そんで「ここいらで性能目標設けてソレを満たすように改修入れようや!」ってなったわけです。

 

性能目標を立てたりボトルネックの調査やら改修をしたりってのはそこそこ順調に進んでました。

まあ全くインデックスが貼られていなかったテーブルが20個近く見つかったり処理完了に5時間もかかるクセにほとんど空回りで何もしていないバッチがみつかったり、それはそれでナゼナゼミーティングが組まれて面倒な思いはしましたが。

 

で、改修がほぼほぼ完了してあとは最終的な性能試験!って段階でやらかしました。

結論はタイトルにもある通りなんですけど、JMeterで大量のリクエストを検証環境に飛ばし始めてから10分くらいで、我々が改修していたシステムの連携先システムがパンクしてアクセス不可能になりました。もちろん連携先はガチガチの本番環境。

あの…今ってなんかやってます?想定してないプライベートIPからテストデータっぽいのが大量に飛んできてWebサーバーが応答しなくなっちゃってるんですけど」って暗い顔の先方担当者がやってきたときは3秒くらい世界が止まりましたね。

 

原因はお察しかと思いますが、我々の検証環境から接続していた連携先が本番環境になってたんですね、はい。

なぜそんなことになったかと言うと、「検証環境DBに本番環境と同等量のデータを持たせたい = 本番DBからダンプ取ればいいじゃん♪」ってことで本番と同じ内容のデータを検証環境で使ったからです。

そしたらマスタ系テーブルの中に連携先システムのURLを持ってたんで、本番環境の連携先を叩きに行ってしまったわけです。

 

ただこれ、若かりし五十嵐くん(私)にも情状酌量の余地はあると思うんです。

  • そもそも連携先システム側は事前検証時に「元々性能目標を満たしている」と報告していた。なので本来であれば今回のケースでサーバーがハングアップするはずがない。
  • 本番環境からのダンプは自分自身で取ることはできず、事前に目的を書いた申請書に承認をもらった上で、運用担当チームがダンプを取得している。なので実施内容がおかしいことに気付けるタイミングはあった。
  • 検証環境と本番環境のネットワークが分離されていれば、連携先システムへアクセスできないのでこのようなことは起きなかった。仕組みの問題もある。
  • ってか連携先のURLなんて頻繁に変更されないんだから設定ファイルで持っとけや!

とかね。とはいえ自分のミスでもあるのでモチロンちゃんと反省はしました。あと本番のダンプとか安易に使わないようになりました。

 

1万件の本番障害ログを放置

これは私が初めて設計〜実装をメインで担当した案件。

既に動作実績のあるアプリケーション横展開して、必要な箇所だけ改修を加えてリリースする的な案件で、まあそれを大人しくやれば良かったんですが。やらなかったんですよ。

 

それまでずっと比較的レガシーな案件にアサインされていた反動か、独学で勉強していたRailsやらWebフロント界隈の空気感に惹かれていた頃でして。

「プレゼンテーション層にJDBCベタ書きとかありえん!ラップしてActiveRecordみたいなの作ったろ!」とか「モダンなフロントはJavaScriptもカプセル化!JS全部書き直そ!」とかね。

熱意はまあ良いんですけど、スキルがそれに見合ってない若造なもんだから。

元々実装されてた機能を削っちゃってテストのタイミングで死ぬとか、スケジュールがズルズル遅延し始めて当時の会社の先輩にヘルプに入ってもらうとか、もう本当にいろいろありました。

 

つーことで開発時だけで恥ずかしいエピソードがたくさんある案件なんすけど、当然のように本番環境でもやらかす。

中でも一番インパクトが強いのはタイトルの通り、1万件の本番障害ログを放置していたこと。

しかもそれが5日間の有給を取って海外旅行にいく前日の夜に上司にバレるというね。

 

そのシステムのログはapplication.log的なところにどんどん吐かれていくものと、どこでもCatchされずにフレームワークまで行き着いたException1件につき、ソレのスタックトレースがlogs/errors配下に個別のファイルとして吐かれるっていう仕組みになってました。

そんでね、たまに調査でログを確認するときに、なんかlogs/errors配下にたくさんファイルがあるなぁとは思ってたんです。思ってたんですけどね。

上記の通りいろんな問題が多発してたこともありまして、雰囲気でスルーしてたんですね。

 

そんで有給消化開始の前日。

なんかあったときに保守できるようにってことで当時の上司にログの場所とかDBの接続情報とか諸々引き継いで帰宅。

さあ明日からベトナムだぞー♪ってタイミングで、夜中にその上司から電話がきまして。

 

 

logs/errorsの下になんかめっちゃファイルあるけどコレ何…?

 

 

 

 

 

 

 

このあと結構な時間まで電話とチャットでやりとりしたんですが(翌日早朝に羽田だったんで早く寝たかったんですけど)、ファイル数が1万ちょいという膨大な数だったこともありすぐに解決できるものでもなく。

私の旅行中にその上司と他の先輩が障害対応にあたってくれました。その節は本当にありがとうございました。

 

ちなみにこの件、100%自分が悪いやらかしが露呈したことによる精神的ショックが強過ぎたせいかなんか知りませんが、その辺りの記憶があんまりないんですよね。人の脳って不思議。

 

エラー自体は連携先のAPIをコールする際になぜか名前解決エラーで落ちるみたいなやつだった気がするんですが。

それの一部(流石に1万件のうちで言うとごくわずか)が問い合わせフォームで結構な数の質問に答えたあとの確定タイミングでも発生していて。

まあ顧客影響アリよりのアリでした。ごめんなさい。

 

そしてこれは1つ目のやらかしと違って、情状酌量の余地もないんですよね。

これ以降、エラーであれワーニングであれ、見かけてしまったものは発生原因をめっちゃ気にするようになりました。

 

 

…はい。なんか最後に「こういうやらかしが起きたときの振り返りとして〜」とかそれっぽいまとめを書こうかとも思いましたが、そういうのは本家のアドベントカレンダーやらなんやらにたくさんあるので省略します。

みんなも本番環境は慎重に丁寧に扱おうね、お兄さんとの約束だぞ!!