3つのお気に入りのバグ

バグがあり、BAGがあります。 また、バグが通常修正され忘れられた場合、BAGは永久に残ります。 これら3つのBAZHishchiを共有したいと思います。



最初のこのような事件は、2005年に私がFriendScout24で働いていたときに発生しました。 監視用のツールがあり、サーバー上の各行にプレートがありました。 サーバーが正常に応答した場合、緑色で描画され、そうでない場合は赤色で描画されました。 通常、すべてが静かに緑でした。 そして、ある晴れた8月の1日、サーバーははしごで落ち始めました。 Pam-Pam-Pam-3分で4台のサーバー。 5分後、何も起こらなかったように、すべてが再び緑色になりました。







これは翌日、1日おきに繰り返され、1週間も続きました。 通常の容疑者（ロードバランサー、javascript）が除外された後、Oliver（フロントエンドの乙女の1人）は、これが何らかのユーザーであると仮定しました。 約200万人のユーザーと約25,000人のユーザーが同時にログインしているため、見つけるのが難しいことがわかりました。 しかし、FriendScout24の歴史では、1人のユーザーがシステム全体を投入する状況がすでにあったため、あきらめないことにしました。



そして、全体として、すべての悪の理由は写真でした。 しかし、それほど単純ではありません。 1人の少女は、写真で自分のプロフィールを豊かにすることを決めました。 ただし、彼女の写真はPDF形式のみでした。 当時のすべての通常のポータルと同様に、PDFは受け入れませんでしたが、さまざまな種類のJPEGとGIFは受け入れました。 少女-愚か者ではなく-foto.pdfをphoto.jpgに改名しました。 そのため、彼女はMIMEタイプのチェックをバイパスし、写真がシステムの荒野を泳ぎ回りました。 これらの荒野では、 imagemagick 、そして写真を処理するための最先端のライブラリーがありました。 だから、これもばかではないimagemagickは 、jpgではないと言って写真を送り返すのではなく、コンテンツ内のpdfを認識し、そのpdfを処理するためにsidekick ghostscriptを呼び出しました。 そして、これらのマシンでPDFを処理する人は誰もいなかったため、ゴーストスクリプトは存在しなかったため、ネイティブライブラリで簡単なセグフォールトが発生し、JVMを安全に近くに置きました。 おっと



暗がりのない少女は、次のサーバーでもう一度やり直し、サーバーを1つずつ殺しました。 彼女が12回試してみる忍耐を持っていなかったことに感謝します。



2番目のバグは、 このサイトの最初のバージョンの1つを作成した先史時代に発生しました。 このサイトには、あらゆる種類のドライクリーニングマシンとランドリーに関する情報があり、これらすべてのマシンは、サイトが作成されたコンテンツ管理システム（cms）に設定されています。 最初はすべて満足でしたし、顧客も満足していました。 1週間後、顧客は電話をかけ、新しいマシンの追加が疑わしく長い時間続いたと訴えました。 チェックしました、ログが空、サーバーがアイドル状態、何も見つかりませんでした。 顧客は再度電話をかけ、100台の車が追加され、新しい車が1分ごとに追加されるようになったと言います。 彼は見て、チェックした-彼は真実を語っていた。 一般に、作業は長い間行われますが、すぐにおとぎ話が影響し、ほぼすべての行に時間の測定値を入れて、悪党を見つけました。 彼は長い間目を信じていませんでした： log.debug（cache） 。



同時に、デバッグ自体がオフになったため、ログには何も表示されませんでしたが、このキャッシュのtoStringメソッドはすべての詳細の内容を単純にペイントしました。 そしてますます続きました。 1回の操作に3分。 一般的に、それ以降は常にlog.isDebugEnabled（）を使用します。 彼は時間を無駄にしましたが。



そして最後に、私のお気に入り。 すべての時間の主なバグ。 2003年には同じFriendScout-eのコマーシャルでした。 彼らが私を雇う前に（多分それが彼らが私を雇った理由です）。 当時のプラットフォームは非常に不安定で、しばしば落ちて、彼らが何をしているかをほとんど理解していない人々によってサポートされていました。 そして、人々がシステムの悪い振る舞いの原因を望んでいない、または理解できないとき、彼らは1つの修復方法を持っています-ctrl-alt-del。 結局のところ、Windowsで良いことはどこでも良いはずです。



この場合、管理者の1人がシステムログを読み取るスーパースマートスクリプトを作成し、そこでキーワードFATALが見つかった場合、アプリケーション全体を再起動しました。 25台すべてのサーバー、係留、蒸気船があります。 再起動が頻繁になると、ポリシーを再検討する必要がありました。 そして、それはこのように起こりました：

女性がカスタマーサポートに電話し、次のように言います。



女性：「そして、なぜ私があなたのシステムにログインするとすぐにオフになるのですか？」

サポートエージェント：「ユーザー名は？」

女性：「 femme-fatale 」（致命的な女性）。



カーテン。