HNに聞く: 今日うるう年バグを経験しましたか？

決済システムのバグ修正完了

• 今朝緊急で行われた作業の末、月額購読者に対して誤って追加日数分の料金を請求するバグを決済チームが修正した。
• 現在、すべてのテストスイートが通過しており、QAが2028年に修正内容を確認した後、SREが事後分析を行う予定。

GN⁺の見解

• 今回のバグ修正事例は、ソフトウェア開発におけるQA（Quality Assurance）の重要性を強調している。QAプロセスで発見されなかったバグは、実運用環境で問題を引き起こす可能性があり、これは顧客満足度に直接影響する。
• 事後分析（postmortem）の手順は、システム障害やバグ発生後に原因を分析し、再発を防止するための重要なプロセスである。これによりチームは問題解決能力を向上させ、類似の問題が再び発生しないよう予防策を整えることができる。
• 類似の機能を提供する他の決済システムとしては、StripeやPayPalなどがあり、これらはそれぞれ独自のセキュリティおよび安定性機能を備えている。利用前に各サービスの特徴とコストを比較してみるとよい。
• 技術導入時に考慮すべき事項としては、システムの安定性、ユーザー体験、費用対効果などがある。また、障害発生時の迅速な対応と透明性のあるコミュニケーションも重要である。
• この技術を選択することで得られる利点は、顧客の信頼回復とシステムの安定性向上だが、その一方で、緊急のバグ修正による作業中断のような短期的コストが発生する可能性がある。

[GN⁺]

Hacker Newsの意見

• 中国で友人が聞いた話: 結婚証明書予約アプリの年齢計算部分にバグがあり、法定最低年齢の22歳を年から引く計算をした結果、存在しない2002年2月29日になった。アプリはこの日付をユーザーの生年月日と比較しようとしたが、すべてのエラーを比較時に発生したものとみなすエラーハンドリングコードのせいで、ユーザーは結婚するには若すぎるとして、すべての結婚証明書予約を拒否した。
• ChatGPT APIを使う製品があり、3.5 Turbo版を使用している。クエリに一部日付が含まれているのだが、通常のテキストを返す代わりに、今日は2024年2月29日が無効な日付だと判断してエラーを返す。Webインターフェース経由でも時々簡単に再現でき、最初は無効な日付だと言った後、説明する過程で間違いに気づいて、ときどき自分で訂正する。
• Cloudflareが今日請求書を送ってきたが、添付PDFのファイル名が cloudflare-invoice-1970-01-01.pdf になっていた。
• スウェーデンのICAストアでは木曜の朝、カード決済を受け付けられなかった。代わりに現金、Swish、またはアプリで支払う必要があった。問題の原因は、2月の追加日、つまりうるう日によるICA決済システムの内部問題だった。ICAはスウェーデン最大の食料品チェーンである。
• 一部のソフトウェアは日付ごとにデータをローテーションディレクトリへ書き込むのだが、テストシステムで手動デバッグをしている最中、UTCで2月29日に初めてディレクトリを作成する際に失敗した。原因はディスク容量不足だと判明したが、1時間以上うるう年バグだと確信していた。
• サンフランシスコの日次気象記録をMastodonに投稿するボットがある。今日は予定どおり投稿しなかった。1875年から現在までのその日の最高気温、最低気温、降水量を参照しているが、1875年2月29日という日付が存在しないためエラーになった。
• 逆に! うるう年でない年には誕生日を祝ってくれないいくつかのサービスが、今日は祝ってくれた。2月29日生まれ。
• 具体例として、Theatrhythm Final Bar Line というリズムベースのファイナルファンタジーのゲームは、うるう日への対処を処理していなかったため、今日は人々がゲームをプレイできなくなった。ゲーム自体は起動できるが、実際には遊べない。
• Rails 6アプリがあり、time_ago_in_words(1.year.from_now) が「約1年」を返すことを期待するテストがある。テストは失敗し、最初はフレークテストだと思ったが、ローカルでも再現できた。うるう日にそのコードを実行すると「ほぼ1年」を返すためである。Railsコンソールで確認できる。
• ニュージーランドのいくつかのガソリンスタンドでは、決済ソフトウェアの「うるう年グリッチ」により木曜に給油ポンプが動かなかった。ガソリンスタンドと決済サービス提供会社がこれを認めた。