Pinduoduo の技術的事故のレビュー、プログラマーは何を学ぶべきか?

あらゆる事故が発生すると、技術チームは成長する必要があります。バグが発生しない、間違いが発生しないという保証は誰にもありません。私たちがしなければならないのは、事故が発生した後に問題の原因を見つけて埋めることです。損失を阻止するための穴が間に合う。

2019 年 1 月 20 日の早朝、一部のネチズンは、Pinduoduo に重大なバグが発生し、ユーザーは 100 元のしきい値なしで受け取り、使用できると主張しました。クーポンはご自由に。皆が急いで情報を広め、真夜中に起きてクーポンを集めたユーザーもいました。賢明なユーザーは、チャイナモバイルにリチャージするなど、できるだけ早くクーポンを使い切ってしまいました。

おすすめ関連記事: Pinduoduo でプログラマーが重大なバグを引き起こし、数千万の罰金を課せられた

Pinduoduo は早朝に「黒と灰色の制作集団期限切れのクーポンの抜け穴がプラットフォームのクーポンを何千万枚も盗み、違法な利益を得ていたことを受けて、プラットフォームはできるだけ早く抜け穴を修復し、同時に関与した注文の出所を追跡しています。 「この事件を公安当局に報告しました。関係部門と積極的に協力して、関与した黒人および灰色のギャングを取り締まります。」

その後、拼多多の広報担当者は、実際の最終的な資産損失はこれより少ない可能性があると述べた。 1000万元以上。

この事件が起こった後、「バグにより会社に200億の損失が発生する可能性がある」という噂が広まったためか、テクノロジー界では爆発が起こりました。

プログラマとして私がもっと心配しているのは、このバグがどこから来たのかということです。市場の噂によると、おおよそ次のようなヒントが得られます。これらの手がかりの信憑性はまだ検証されていませんが、この事件の本当の状況ではないかもしれませんが、この事故が私たちにもたらした啓蒙を探るためにこれらの手がかりを使用することを妨げるものではありません。

● 多くの人が数十万ドルを稼いでいます。

● このクーポンはテスト クーポンです。

● システムは早朝にテスト クーポンを自動的に起動します。

● ● 運用と保守により、システムが爆発してしきい値を超えたことが判明しました。

● 関係者がテスト クーポンを手動でオフラインにしました。手動でオフラインにした人は、午前 8 時に再びオンラインになりました。

これらの手がかりは、重大なバグの展開と動作を合理的に説明しているようです。これらの手がかりから、クーポン自体の設計上の問題に加えて、運用と保守の混乱も見えてきます。テストクーポンをオンラインに掲載するにはどうすればよいですか?システムが制御不能になっているのに、なぜその後のリスク防止策が講じられていないのでしょうか?手動でオフラインにしたテスト クーポンを再度オンラインにするにはどうすればよいですか?なぜオンラインとオフラインのクーポン運用はこれほどずさんなのでしょうか？ソフトウェアシステムをこのレベルで運用、保守すると、遅かれ早かれ問題が発生します。何も問題がなければ、本当に運が良いとしか言​​えません。

クーポンのデザインの問題私たちを惹きつける最初の質問は、「多くの人が数十万ドルを稼いだ」というものです。これは、1 人が数千枚のクーポンを受け取ることができることを意味します。多くの人がこれを行っており、これは、閾値なしクーポンを受け取るための技術的な閾値が非常に低いことを示しています。

一般クーポンも割引クーポンと同様、100元購入すると20元割引などの利用基準があります。無期限クーポンとは、その名のとおり、100元のクーポンで100元の商品が購入できる、つまり現金とほぼ同等の利用限度額がないクーポンのことです。無期限クーポンは現金に近いため、通常のクーポンとは大きく異なります。

うぬぼれ政党を無視して、Pinduoduo は 3 億人のユーザーを抱えていると主張しています。各ユーザーが合法的かつ合理的に 100 元の閾値なしクーポンを受け取ることができた場合、これには 300 億元が必要になります。アカウント登録にはほとんど基準がありません。WeChat の 10 億人のユーザーが合法的かつ合理的に登録し、基準なしのクーポンを受け取り、携帯電話にチャージする場合、1,000 億元が必要になります。

昨日の時点で、Pinduoduo の時価総額は 230 億米ドル近くで、これは 1,600 億人民元に相当します。 100元の敷金なしバウチャーは自由に集めることができ、これは会社を解体して全員にボーナスを与えるというジェスチャーのように見えます。これは確かに、閾値なしクーポンに期待されるものではありません。

気軽に手に入る敷居のないクーポンは、どう見ても商業デザインとして適格ではありません。少なくとも数量に上限を設けて、全員が手に入れたら数百万配ればなくなります。数百億ドルを寄付することは、通常のビジネス ロジックに準拠しません。

一般的に、通常のクーポンであっても、受け取るには多くの追加条件があります。たとえば、アカウントはそれを 1 回しか受信できない、または新しいアカウントのみがそれを受信できます。アカウント認証には、携帯電話番号のバインド、デバイスのバインド、安全な接続の使用など、多くのセキュリティ対策も必要です。アカウントの認証と管理は、サービス Web サイトの最も基本的な機能です。人が何千枚ものクーポンを受け取ることができたとしても、アカウント管理の基本的なスキルは合格したとは言えません。アカウント管理レベルが標準に達していない場合、この Web サイトのリスクは想像以上に深刻になります。

このような貧弱なアカウント管理とこのような貧弱なビジネス設計は非常に予想外であり、通常のロジックと矛盾しています。したがって、これは単なるテスト クーポンであり、通常のオペレーティング システムでは表示されるべきではないことに私は同意します。そして、それが本当にテストクーポンの問題であれば、ソフトウェア開発と運用保守の混乱が明らかになるだろう。

混沌とした研究開発と運用保守

テスト クーポンは手動でオフラインになった後、自動的にオンラインに戻りました。この製品発売のプロセスは信じられないほど素晴らしいです。機能のリリースは、正式なシステムに実装される前に、設計、実装、レビュー、テスト、承認を経る必要があります。これらのリンクのいずれかが機能している限り、テスト クーポンは自動的にオンラインになることはもちろん、オンラインにもなりません。

オンライン化後は、継続的にリスクを監視する必要があります。システムが閾値を超えて爆発した場合、運用保守側は、深夜にアカウントが異常に活発になっている、クーポンビジネスが流行しているなど、爆発に関する情報を即座に得ることができ、タイムリーにリスクを遮断することができます。

運用および保守要員に対する合理的な拘束メカニズムは、営利企業が慎重に扱わなければならない問題であることがわかります。ランダム テスト クーポンを公式システムで直接使用するにはどうすればよいですか?ソフトウェアの運用と保守は、特にソフトウェアの品質が維持されていない場合、リスク管理と制御に特別な注意を払う必要があるリンクです。ソフトウェアの運用と保守の事故は、場合によっては業界を破壊することさえあります。

2011 年、デジタル証明書発行機関が Google に複数のデジタル証明書を発行しました。 Google はこの組織にデジタル証明書を申請したことはありません。つまり、デジタル証明書の所有者は Google ではありません。この所有者は、Google の Web サイトになりすまして、ユーザー名やパスワードなどのユーザーのログイン情報を盗むことができます。これは、企業の技術レベルに問題がある（ハッカー攻撃）か、企業の運用保守能力に問題がある（証明書のランダム発行）かのどちらかを意味します。このセキュリティ問題は 2011 年 8 月に明らかになり、ほぼすべてのソフトウェア大手が直ちにこの組織のデジタル証明書をブロックすると発表しました。 9月、市場に大きな影響力を持つこの金融機関が破産を宣告した。

しかし、これで終わりではなく、デジタル証明書発行業界の破滅は始まったばかりです。時価総額 4,000 億ドルの企業のセキュリティは、時価総額 40 億ドルの企業の運用能力に依存できないことに、人々は突然気づいたようです。その結果、その後数年間にさまざまな新しい技術が登場しました。これらの新しいテクノロジーが広く使用されると、デジタル証明書発行業界全体が完全に消滅することになります。そのような日は遠くありません。現在、デジタル証明書発行機関の状況は比較的厳しいものとなっており、一部は売却され、一部は散在しています。

ヒッチハイクは安全事故を頻繁に引き起こしますが、長期的には同様の性質があります。対照的に、事故で失うものがお金だけであれば、その衝撃は耐えられるかもしれません。失われるのはお金だけだといいのですが、私はこの期待について楽観的ではありません。

ソースを振り返ると、運用と保守は非常に混沌としており、一般にソフトウェアの品質と切り離すことはできません。本格的なソフトウェア システムの場合、その作成方法、展開方法、運用方法、認可方法、危機への対処方法など、これらすべての問題を設計、実装、計画する必要があります。関係者は、オペレーティング システムで実行でき、無制限に受信できるしきい値なしのテスト クーポンを設計しました。これにより、その背後にあるソフトウェアの低品質と、緩慢で無秩序なソフトウェア開発プロセスが明らかになりました。優れたソフトウェアは優れたプロセスから生まれるとよく​​言われます。研究開発プロセスが無秩序であると、高品質の製品を生産することが困難になります。 ＃＃＃＃＃＃＃＃＃＃＃＃私たちは何をすべきか？

無知は恐れを知らぬということは、セキュリティ問題が特別である理由は、それが起こらなければ、私たちは問題の存在を決して知ることができないし、もちろん、どれほど深刻であるかも分からないからです。問題は。あらゆる安全保障危機を無駄にしてはなりません。私たちが当事者である場合、同様の事故を避けるためにどのような方法が考えられますか？ 最も緊急なことは、アカウント保証債務をできるだけ早く返済することです。そうしないと、これが広まった後、多くの目がこの脂肪の部分に引き寄せられるでしょう。ハッカー攻撃の次の波はすでに始まっている可能性があります。

次に、できるだけ早く次のことを検討してください。

最初にやるべきことは、研究開発プロセスを標準化することです。

一流のソフトウェア開発プロセスで作られた製品は、どんなに粗悪なものであっても、それ以上に劣るものではありません。この研究開発プロセスでは、プログラマーが単独で行動することはできません。要件を議論し、設計をプレビューし、機能をレビューし、コードをレビューし、ソフトウェアをテストし、システムを試運転する必要があります。誰でも間違いを犯すものです。すべてのステップをもう少し監視することで、間違いを犯す可能性が大幅に減ります。プログラマーは研究開発プロセスを通じて急速に成長し、エラーの可能性をさらに減らすこともできます。良いシステムは人々を成功させることができますが、悪いシステムは人々を破滅させる可能性があります。

2 番目に行うべきことは、コードのセキュリティに注意を払うことです。 コードのセキュリティは、必ずしもハッカーの侵入を指すわけではありません。この閾値なしクーポンの使用は、重大な安全上のインシデントです。コードレベルで反映すると、アカウント管理が安全でなかったり、ビジネスロジックが検証されていなかったり、運用保守の権限管理が甘かったり、異常なリスクの警告が間に合わなかったりする可能性があります。

3 番目に行うべきことは、事前にビジネス設計を推測することです。 たとえハッカーが存在しなかったとしても、しきい値なしクーポンで 1,000 億人民元という金額は、営利組織が喜んで支払えるコストではありません。これは幼稚園レベルの間違いです。ビジネス ロジックが当てはまらない場合、それはソフトウェア要件に欠陥があることを意味します。バグのある要件に基づいて構築されたソフトウェアもバグだらけになります。

4つ目は、製品発売の仕組みを改善することです。 製品起動用のチェックポイントとパイプラインを設定します。チェックポイントが失敗すると、パイプラインが中断され、製品はオンラインで起動されません。これらのチェックポイントには、製品の試用、機能の承認、監視措置のサポートなどが含まれます。

5つ目は、運用保守のリスク予防力の向上です。 ユーザー数 3 億、市場価値 230 億米ドルの電子商取引企業がハッカーの標的になっています。特にユーザーのプライバシー情報とキャッシュフローは企業の死活に関わります。この規模の企業にとって、優れたリスク防止能力を備えていることは、おまけではなく最も基本的な要件です。積極的なリスクの検出、タイムリーな警告、迅速な対応はすべて、継続する必要があります。

しきい値フリークーポンのビジネス設計が導き出され、ソフトウェアの機能が議論され、実装コードがレビューされ、発売のリハーサルが完了していれば、事故は間に合うように警告できます。いずれかのリンクが機能している限り、このような悲劇的な事故は起こらないでしょう。

私は、あらゆることに関係なく全速力で前進し、スピードのために品質を犠牲にするという企業の競争圧力と動機を理解しています。しかし、現在のスピードを追求する場合、3フィート先の未来も考慮する必要があります。そうしないと、尻に積もった借金が本当に振り切れない大きな尻尾になってしまいます。