自動課金トラブルの再発防止についてのご報告
いつもFeedeenのご利用ありがとうございます。運営者の伊藤です。 4月26日に発生した 自動課金トラブル の再発防止として、以下2点を実施したことをご報告させていただきます。 動作確認環境からの本番用外部API(課金用API含む)アクセス情報の削除 動作確認環境のデータベースからの一部ユーザー固有情報の削除 これらの対策により、「動作確認環境での操作ミスによって課金が発生してしまう」というトラブルの再発は完全に排除できたと考えております。もちろんこれで終わりではなく、操作ミスを防ぐための自動化や粒度の高い権限分離など、より広範なトラブル防止策を引き続き実施してまいります。 以下、対策の詳細をご説明させていただきます。 1. 本番用外部APIアクセス情報の削除 従来から動作確認環境では動作確認用のモードで各種プログラムを実行することにより、本番環境に影響が出ることを防いでいました。しかし、このモード切り替えが比較的容易であったため、操作ミスにより本番モードで自動課金の処理を起動してしまい、今回のトラブルを引き起こしてしまいました。これには、大別して以下の2つの問題があったと考えております。 モード切り替えが容易で、操作ミスにより本番環境で処理を起動してしまうことを排除できていなかった 本番モードへの切り替えが必要とはいえ、動作確認環境から本番環境用APIへのアクセスが可能だった このうち前者の改善にはプログラムの大幅な書き換えが必要で、残念ながら一朝一夕に実施することができません。そこで、今回の対策では後者の解消に注力しました。具体的には、動作確認環境の構築時に外部APIへのアクセス情報を書き換え、すべてのモードのアクセス情報を動作確認用のものに置き換える処理を追加しました。 この対策により、たとえどのモードでプログラムを起動したとしても、動作確認環境から本番用の外部APIにアクセスすることは不可能になりました。 前者の問題につきましても、今後より信頼性の高いモードの制御方法を検討し、現在の方法から段階的に移行していく所存です。 2. 動作確認環境のデータベースからの情報の削除 動作確認環境は本番環境とは独立したネットワークに構築しており、動作確認環境から本番のデータベースを「更新」することは不可能です。しかし、(場合によるのですが)動作確認環境のデータベースは本