Yandex.Tellerのパートナーであるセンセーショナルな技術的エラー「Dodo Pizza」の話は、同社のシステムアーキテクトであるAndrei Morevskyから語られました。すぐにマイクを作者に転送しました。

サンクトペテルブルクで最初のドードーピッツェリアを開くためにサプサンに行きます。そのとき、支払い済みの注文の複数のキャンセルに関する通知を突然受け取ります。 そして、複数のものだけではありません-私たちのシステムは、1時間で800万ルーブルの支払い済みの注文をロールバックすることができました！

今、この話は笑顔を引き起こすだけですが、その朝はまったく面白くありませんでした。 したがって、インシデントの技術的な詳細と結論を共有し、同時にDodo Pizza注文処理システムについて少しお話したいと思います。

その朝、私たちはすぐにYandex.Kassaチームに連絡し、そのような状況は通常2〜3回のトランザクションで発生し、個別に解決されることを知りました。 そのような操作ごとに、支払いシステムチームは特定の銀行に連絡して要求を交換する必要があるため、問題は複雑に見えました。 受け取っていないお金を返済したことに気づいたのは特にがっかりでした。これらはテスト注文でした。

そしてすぐにネタバレ-それはすべてうまく終わりました

私たちは資金を返済するために最善を尽くしましたが、読者はこれが一般的にどのように起こるかについて戸惑い、「プログラマー」に対する報復の選択肢を無謀に整理しました。 はい、私は個人的に知り合いから約12の不快なメッセージを受け取りました。みんなはすべてが私と一緒にうまくいくかどうかに興味があり、「万が一に備えて」空席を提供しました。

週末に、Yandex.Kassaの経営陣まで、全員が問題につながりました。 支払いシステムチームは、誤った返品をキャンセルするための操作についてパートナー銀行と合意することができました。 それは本当に大きな仕事でした。1万件以上のトランザクションを手動でソートする必要がありました。

その結果、彼らは私たちにお金を返しましたが、銀行手数料の振込みで15万ルーブルを失いましたが、顧客のSMS通知にさらに4万ルーブルが費やされました..

原因と結果を求めて

Dodo ISをいくつかの環境でテストします。製品マネージャーへのデモンストレーション用のサンドボックス、統合ループがあります。 運用環境に投入する前に、アナリストとQAが安定した環境で最終バージョンをテストします。 検証には、実際のデータを使用します。これは、定期的に「戦闘」ベースからコピーします。 もちろん、実稼働環境の境界を越えるときのすべてのデータ-**環境**は非個人化されます。

安定した環境では、注文に関係のない支払いのキャンセルなど、戦闘条件を完全に再現しようとします。 実際の状況では、そのような支払いは、支払いプロセスのエラー、またはユーザーによる注文のキャンセル手順が誤って完了したことが原因で発生する場合があります。 テスト環境でキャンセルがどのように発生するかを確認するために、特別なタスクがスケジュールに従って起動され、テールがクリーンアップされます。

事件の前日、マーフィーの法則の最高の伝統の中で、2つの不幸な偶然の一致が起こりました。

• 構成エラーのため、バックグラウンドタスクは支払いサービスの模倣ではなく、Yandex.Cashへの実際の接続を見ていることが判明しました。

  
  
  
  
  
  
  
• 一方、バックグラウンドタスクはテストベースのバージョンを調べました。このバージョンでは、匿名の支払いトランザクションがありましたが、それに対応する注文はありませんでした。

したがって、クリーニングタスクは誠意を持って開始され、すべてのトランザクションを実行し、キャンセルする必要があるトランザクションを見つけました。 そして、キャンセルの1万件のリクエストがYandex.Cashに届きました。

犯人、責任、信頼について

会社の経営陣との会合では、しばらく経っても加害者を罰するという問題は発生しませんでした。

「もちろん、この重大なエラーから最も深刻な結論を導き出します。 「私たちは人々を罰しません。これが二度と起こらないように、私たちはすべてをします。」

事件直後のFedor OvchinnikovのFacebookとVKontakteページのメッセージ。

罰の恐怖は遅かれ早かれ、あらゆる会社の仕事を麻痺させます。 皆さんの多くは、「敗北の領域」から可能な限り離れるために、多くの文書や手紙を書いている企業に会ったことがあると確信しています。 大胆なものを受け入れる準備ができているマネージャーはいませんが、20の承認なしで些細な決定でさえも。 そのような企業は創造と開発が可能ではなく、大胆な先駆者が長年にわたって創造したリソースを「食い尽くす」だけでよいと思います。

間違いを犯す権利は、私たちの袖を通り抜けてハックする権利を意味するものではありません。何よりもまず、従業員が悪意を持って間違いを犯すことができないという信頼と自信です。

「何らかのトラブルが発生する可能性がある場合、間違いなく発生します。」

マーフィーの法則。

信頼は人々と魔法のようなことをします-私たちには、この事件を心に留めない、彼自身の痛みとしてそれを生きず、助けを提供しない単一の従業員がいませんでした。

今、楽しい部分は何をすべきかです。

Dodo ISの急速な成長に伴い、他のすべてよりも開発の速度を優先することがよくありました。 これは、システムロジック、アーキテクチャ、およびインフラストラクチャを損なうことがありました。

その結果、システムはモノリシックで強力に接続されました。 支払いを処理し、取得者とやり取りするためのコードは、UIおよびコントローラーと共にクライアントサイトに直接配置されていました。 そのため、コントローラーの変更は、直接または間接的に支払いロジックに影響を与える可能性があります。 さらに、一般的なリポジトリ内の支払いロジックの場所は、すでに知っているインシデントにつながりました。 お金を失うことは、システムの他の部分での作業の副作用であり、本質的には支払い処理に関係していませんでした。

過去6か月にわたって、システムのリエンジニアリングに取り組んでおり、モノリスをSOA（サービス指向アーキテクチャ）のレールに移行しています。 今日、社内のプログラマーからマネージャーまで、誰もが技術的負債を返済しなければならないことを理解しています。

システムのSOAへの移行の一環として、個別の支払い処理サービスである支払いゲートウェイを強調します。 このサービスは、取得者とのやり取りを含むすべての支払いロジックをカプセル化します。 実際、私たちは自分のニーズに合わせて独自の支払いアグリゲーターを開発しています。 支払いゲートウェイは、クライアントサイト（dodopizza.ru）およびその他のオンライン販売チャネルのオンライン支払いの単一ポイントになります。

PCI DSS自己評価を使用して支払いゲートウェイを認証することにしました。 考え方は議論の余地があるように見えるかもしれませんが（PANカード番号は保存していません）、PCI DSS規格は官僚的な形式ではなく、機密データを扱うための優れた実践とヒントで構成されるチェックリストです。

内部からの支払いゲートウェイ

各支払いゲートウェイには、UMLダイアグラムで記述されたアーキテクチャが必要です。 これは、ゲートウェイのコンポーネントモデルです。

そして、IBackService、IPlugin、およびその他のインターフェイスの内部は次のとおりです。

しかし、何個の図を描画しませんが、それでも言葉で説明する必要があります:)ゲートウェイは何で構成され、そのコンポーネントはどのような役割を果たしますか？

クライアントサイト

そのようなサイトdodopizza.ruがあり、ほとんどの注文が発行されています。 これで、選択した方法（Yandex.Cashなど）に応じて、サイトはユーザーを支払いページにリダイレクトし、支払いシステムからの応答を処理します。 必要に応じて、サイトのバックエンドはアクワイアラのバックエンドを呼び出します。 しかし、新しいアーキテクチャでは、サイトは支払いページまたは取得について何も知りません。 ユーザーを支払いゲートウェイにリダイレクトするだけです。支払いゲートウェイは、さらにどこに送信するか、取得者とやり取りする方法を決定します。

支払いゲートウェイ

ゲートウェイは、返品と注文の支払いのリクエストを受け入れるRESTfulサービスであり、2つのAPIを提供します。

1. Back APIはDodo ISからの呼び出し専用であり、DMZでのみ使用可能です。

   
   
   
   
   
   
   
2. パブリックAPIはインターネット全体に公開されています。リクエストの取得とクライアントサイトからのユーザーのリダイレクトを処理します。

支払いゲートウェイのソースコードは、すべての開発者から閉鎖された特別なリポジトリにあります。 ソースコードの変更については、開発者は別のアプリケーションを発行する必要があります。 サービス自体は、セキュリティ要件が強化された分離環境に展開されます。

プラグイン

支払いゲートウェイには、支払い処理の基本ロジックが含まれており、特定の取得者との統合の特定のロジックはプラグインに含まれています。 したがって、新しいアクワイアラーを接続したり、利用可能なアクワイアラーのリストを変更したりする作業は、キャッチしすぎるリスクを最小限に抑えながら、個別に実行されます。

データサービスとデータベース

支払いゲートウェイは、支払いに関する情報を独自のデータベースに保存します。このデータベースは、外部およびDodo ISの他の部分から閉じられています。 それらへのアクセスは、ゲートウェイ自体でも不可能です。 データベースには、エンティティを管理するための独自のAPIがあり、支払い回線内でのみ開きます。

各コンポーネントの役割をより明確に確認し、データがどこでどのように流れるかを想像するために、データフロー図を確認することをお勧めします。

図を見ても、新しいアーキテクチャで支払いがどのように進行するか理解できない場合は、ネタバレの下の詳細な例を見てください。

この時点で、内部ドキュメントのHabrへのコピーを停止するように求められたため、終了しました。 この記事があなた自身のアーキテクチャについての考えをあなたに促したり、新しい解決策を提案してくれたら嬉しいです。 そして、あなたが私たちに気づかれていない何かを見つけて、私たちが間違っていることを教えてくれたら本当にクールです。 しかし、あまり厳しすぎないでください-おそらくニュアンスの多くは忘れられず、単に記事の範囲外にとどまったので、コメントで説明します。