自動課金トラブルの再発防止についてのご報告
いつもFeedeenのご利用ありがとうございます。運営者の伊藤です。
4月26日に発生した自動課金トラブルの再発防止として、以下2点を実施したことをご報告させていただきます。
- 動作確認環境からの本番用外部API（課金用API含む）アクセス情報の削除
- 動作確認環境のデータベースからの一部ユーザー固有情報の削除
これらの対策により、「動作確認環境での操作ミスによって課金が発生してしまう」というトラブルの再発は完全に排除できたと考えております。もちろんこれで終わりではなく、操作ミスを防ぐための自動化や粒度の高い権限分離など、より広範なトラブル防止策を引き続き実施してまいります。
以下、対策の詳細をご説明させていただきます。
1. 本番用外部APIアクセス情報の削除
従来から動作確認環境では動作確認用のモードで各種プログラムを実行することにより、本番環境に影響が出ることを防いでいました。しかし、このモード切り替えが比較的容易であったため、操作ミスにより本番モードで自動課金の処理を起動してしまい、今回のトラブルを引き起こしてしまいました。これには、大別して以下の2つの問題があったと考えております。
- モード切り替えが容易で、操作ミスにより本番環境で処理を起動してしまうことを排除できていなかった
- 本番モードへの切り替えが必要とはいえ、動作確認環境から本番環境用APIへのアクセスが可能だった
この対策により、たとえどのモードでプログラムを起動したとしても、動作確認環境から本番用の外部APIにアクセスすることは不可能になりました。
前者の問題につきましても、今後より信頼性の高いモードの制御方法を検討し、現在の方法から段階的に移行していく所存です。
2. 動作確認環境のデータベースからの情報の削除
動作確認環境は本番環境とは独立したネットワークに構築しており、動作確認環境から本番のデータベースを「更新」することは不可能です。しかし、（場合によるのですが）動作確認環境のデータベースは本番用のバックアップから構築しており、バックアップ時点のデータベースの内容を「読み取る」ことは可能となっております。
本番用のデータを使っている主な理由は、購読されているすべてのフィードについて正しくクロールできることを確認するためです。RSS / Atomフィードは一応標準化されているとはいえ、サイトごとの形式の差が大きく、明らかに標準から逸脱したものも多く存在します。それらも含めて広範なフィードを購読できることはフィードリーダーの根本的な価値に直結するため、本番と同じデータを使用して最終的な動作確認を実施しております。
しかし、動作確認時のデータベースに本番用のデータが含まれることで、トラブル発生のリスクが増していることも事実です。今回のトラブルでも、もしデータベースに自動課金用の情報がなければ、操作ミスをしても実際の課金が行われることはなかったはずです。
そこで、まずは暫定的な対処として動作確認用データベースからセンシティブなユーザー情報（メールアドレス、課金周りの情報、外部サービスへのアクセス情報など）を削除する処理を追加しました。これは動作確認環境を構築するスクリプトに組み込まれており、必ず実行されます。
動作確認用データベースにはユーザー固有の情報を一切含まないのが理想ではありますが、そのためには必要な情報・不要な情報を完全に切り分け、クローラ等が正しく動作するようにデータを再構築する必要があります。これには相当な工数が必要となりますので、今後の課題として取り組んでいきたいと考えております。
一時的とはいえ二重課金の状態を発生させてしまったことは、課金を伴うサービスとしてあってはならないことで、非常に重大な事態と受け止めております。以上はまったく同じトラブルを繰り返さないための緊急対策として実施させていただきましたが、これで終わりということではなく、継続して取り組んでいくべき対策の最初のステップと認識しております。
安心してご利用いただけるサービスを目指して改善を続けてまいりますので、今後ともFeedeenをよろしくお願い申し上げます。
コメント
コメントを投稿