【開発スキル】R＆Dオンライン事故のまとめ！

I.はじめに

你的代码出过事故吗？

老人は言った：私が川のそばをよく歩くとき、私は濡れた靴を持っていません。プログラミングと開発の仕事をしている限り、大小を問わず、間違いなく事故に遭遇するでしょう。

もちろん、研究開発の学生もいるかもしれませんが、比較的伝統的な業界やユーザーの少ない企業では、有名な事故に遭遇するのは難しく、そのほとんどは小さなオンラインバグであり、誰も修正されていません。

しかし、あなたがより大きなインターネット会社にいる場合、あなたが担当するシステム機能は数百万または数千万のユーザーに直面するかもしれません。小さなバグがあっても、すぐに大きくなり、顧客からの苦情が多くなり、資本損失のリスクが高まります。お気に入り：

拼多多多発の「羊毛」事件は、友人の輪によって狂ったように転送されました。
淘宝網は昨日、S1レベルの事故という重大なオンラインバグを報告しました。プログラマーが故意に地雷を植えた疑いがあります。 您使用的程序是内测版本，将于当地时间 2020-03-28 到期，到期后将无法使用，请尽快下载最新版本。
GitHubはSSL証明書の更新を忘れたため、Webサイトのレイアウトに混乱が生じ、一部のWebサイトを正常に開くことができませんでした。

このような事故は、技術プロセス、プログラムの実装、技術サービス、および運用構成が原因で発生する可能性があります。統合は次の点に要約できます。

関数型フロー設計カテゴリ：通常、製品ロジック関数実現プロセスのR＆D設計での呼び出し関係の誤った実行によって引き起こされるリスク事故を指します。
技術ソリューションの実装カテゴリ：R＆Dおよび設計プロセスの後、各機能ポイントの実装ソリューションは人によって異なり、偏差または不十分さを理解しているため、実装プロセスでは、実行中のプロセスにおけるコードの堅牢性の評価が不足しています。。
テクニカルサービスの使用カテゴリ：このカテゴリは、データベースサービス、キャッシングサービス、ビッグデータサービス、構成センターサービス、オンラインサービスの公開などを開発および使用する際の、さまざまなサービスの構成と使用に関する一定の理解の欠如を指します。
バックドアの違法操作：このカテゴリは、R＆D仕様の実装強度が異なること、およびそのようなリスクがあるかどうかによるものです。例：一部のR＆D学生は、いくつかのバックドアプログラムを開発します。たとえば、特定のERPページでデータベースステートメントを実行して、データを一時的に変更できます。これによって引き起こされるリスクは通常、バックドアの違法な操作であり、追放のリスクがあります。
運用上の誤り：研究開発では、社内のパートナーの中には、研究開発のクラスメートが開発したオペレーティングシステムを使用して、アクティビティの構成、ユーザーの変更、操作の実行を行うものがあると思いますが、一般に、このタイプのシステムには特定の強力なルール検証がありません。その結果、操作初心者は操作プロセスにリスクをもたらし、事故につながります。一般に、間違ったボリュームがオンラインで構成されたり、間違ったショートメッセージがユーザーに送信されたりするなど、すべてこのように発生します。

より愚かな事故のほとんどは、主に個人的な責任の問題であると言えます。しかし、技術的な内容の事故は一度犯す価値があります。会社はあなたが事故を起こすことを嫌っていますが、それは会社に損失をもたらすからです！しかし、そのような技術的な事故はあなたの個人的な成長にとって非常に良いケースです。しかし、禁止は良いですが、あなたは貪欲になることはできません！

次に、シャオフ兄弟は、さまざまな事故のスタイルを理解し、どのシーン、どのような問題に遭遇し、どのように解決するか、そして何を学ぶことができるかを説明します！

2.研究開発事故

1.機能フロー設計

インシデントレベル：P1
事故の判断：対応する研究開発、テストの概要とレビュー、警告として会議に参加しているパートナーのためにロリポップを購入するための50元の罰金。
インシデント名：宝くじの支払いプロセスが不合理です
インシデント現象：ユーザーはより多くのポイントを支払うため、顧客からの苦情、緊急のトラブルシューティング、修理が同じ日に行われ、ユーザーにポイントが追加されます。
インシデントの説明：この製品の研究開発の大部分は、背景の開発に関与している可能性があります。簡単に言えば、ポイント宝くじを使用するユーザーのニーズを満たすことです。上の図の左側は、研究開発の初期設計プロセスです。RPCインターフェースを介してユーザーポイントが差し引かれます。差し引きが成功すると、抽選が行われます。ただし、その日のRPCサービスが不安定なため、実際のRPC呼び出しは成功しましたが、タイムアウトエラーが返されました。RPCインターフェイスを呼び出すuuidは毎回自動的に生成され、呼び出しのべき等性はありません。そのため、ユーザーがより多くのポイントを支払うという現象が発生します。
インシデント処理：事故後の宝くじプロセスを変更し、最初に抽選する宝くじを生成し、宝くじIDからRPCインターフェイスを呼び出して、インターフェイスのべき等性を確認します。RPCインターフェースに障害が発生すると、タイミングタスク補正によって抽選が実行されます。プロセスの修正後、補正タスクが週に1〜3回発生することがわかり、RPCインターフェイスに可用性の問題があることが証明されました。また、かなり前にプロセスの問題があったことも示されましたが、それは少なかったためです。顧客からの苦情、フィードバックはありませんでした。
学習の概要：呼び出されたインターフェースと送信されたMQは、必ずしも毎回成功するとは限りません。次に、テクノロジーの実装プロセス全体をより完全にするために失敗した後、べき等と補償の良い仕事をしなければなりません。Xiao Fuが言ったように、お尻を拭く紙の面積の80％は実際には保護用の手です！

ネチズンは事故を共有します：

事故名称	事故の説明	事故の結果
ビジネスプロセスが間違っている+コードがスレッドプールを頻繁に開く	間違ったビジネスプロセスによって引き起こされる問題は、変更が特に大きいことです。これは、コードのリファクタリングに少し似ているため、サービスが長時間ダウンし、顧客はクレイジーなフィードバックを受け取ります。	ビジネスを変えるために残業しているクレイジー。私はナイーブで、書かれたコードがごみすぎて、上司に夢中になってしまったので、何泊追加したかわかりません。
オンラインでユーザーの配送先住所を変更できませんでした（同僚が必要とする問題については、次の^ v ^からも学ぶことができます）	シナリオ：顧客サービスは、ユーザーが河北省から浙江省に配送先住所を変更する必要があると応答し（流行のため）、会社はオンラインデータを変更するために作業指示書を提出する必要があります。したがって、次のような一連の手順レビュープラットフォームに申請書を提出する場合。問題：作業指示は、変更結果が成功したことを示していますが、データは変更されていません。多くの同僚がSQLをチェックし、SQLの書き込みに問題がないことを発見しました。解決プロセス：SQLが正しいかどうか、プラットフォームが正常に変更されたかどうか、データが正しいかどうかを確認し、変更時間が問題ないことを確認します。	まず、問題を見逃しました。この注文データは、淘宝網からの注文時に注文データと同期されます。データが変更された後、淘宝網もデータを同期し、変更されたデータは河北省の住所に変更されます。次に、SQL監査プラットフォームの問題を疑ってください。話はここにあります。結論：コードを信頼し、より不確実な状況をチェックし、行き止まりにならず、常に監査プラットフォームの問題を疑って、自分の問題をもっとチェックするように、すべての人に伝えたいと思います。
ビジネス関連の事件	新しいチームに参加し、他の人のコードを理解せずに再利用し、ビジネスシナリオを理解せずに条件を制限するだけです。同様の状況がたくさんあります。どこにいるのかわからないので、単純なコードでも畏敬の念を抱かなければならないと言えます。。うまくいかない	ユーザーの苦情、リーダーからの批判

2.テクニカルソリューション実現クラス

インシデントレベル：P0
事故判断：ユーザーを宣伝するためのマーケティング活動が多く、影響の範囲が広い。修正コードの研究開発とレビュー。
事件名：スパイクプログラムの独占競争状態の実現の問題
インシデント現象：ユーザーは見たときに購入できますが、注文する必要があるのは一度だけです 活动太火爆，换个小手试试。多数の顧客からの苦情が発生し、緊急のオフライン活動が調査されました。
インシデントの説明：製品アクティビティスパイクを実現するための初期設計は、ロックするアクティビティ番号IDに基づいており、このIDはスパイク中にロックされ、ユーザーは購入後に解放します。しかし、多数のユーザーが急いで購入した場合、スパイク分散ロック後のビジネスロジック処理で例外が発生し、ロックの解除に失敗しました。その結果、すべてのユーザーがロックを取得できなくなり、商品はあるが注文できないという問題も発生します。
インシデント処理：排他的競合状態をセグメント化された静的ステータスとして最適化し、アクティビティID +在庫番号を動的ロックIDとして使用します。現在のスパイクユーザーがロックに失敗した場合、後続のユーザーは影響を受けることなくスパイクを続行できます。そして、失敗したロックはワーカーによって補償および復元され、最終的には売られ過ぎと売れ残りが回避されます。
学習の概要：コアテクノロジーの実装では、多くのデータ検証とストレステストを行う必要があります。そうしないと、さまざまなシナリオでリスクがあるかどうかを評価することが困難になります。もちろん、これは唯一の実装スキームではなく、さまざまなシナリオに応じてさまざまに実装できます。

ネチズンは事故を共有します：

事故名称	事故の説明	事故の結果
gcクレイジーリサイクル	最近、サイドプロジェクトを調整しましたが、一定期間実行した後、メモリが急増したため、積極的に誘導できませんでした。	ダンプメモリ
二重控除	同時実行性が多すぎる、データベース接続がいっぱい、タイムアウトの待機、セッションの切断。トランザクションはコミットされておらず、引き続き作業を続けます。	500元、詳細な並行プログラミング、現在の並行性モデルが私の頭の中にあり、戦いへようこそ
データカバレッジ	データが周期的に更新されると、トランザクションが開かれますが、これは長すぎます。その後、継続的なトランザクションでユーザーが送信したデータが上書きされます。	それは問題ではありませんでした、あと数日だけ
データの浸透	3番目のポイントは、スクリプトを使用して同時実行を要求し、データの浸透を引き起こすことです。	切り捨てのピーク、キューを使用してリクエストを処理する
このシリアル番号が繰り返されるのはなぜですか？？	シリアル番号はグローバルに一意である必要があります。データの一部は収入の一部を表します。シリアル番号の生成ルールとコードのバグにより、シリアル番号が重複し、数万の単一収入チェックに影響します。	レベル1の事故、遡及的+通知
ビジネスプロセスのデータカバレッジ	プロセスはパブリッククラスであり、すべての種類のトランザクションがこれで実行されます。パブリッククラスは最初は設計されていません。このテンプレートタイプフィールドを返すメソッドがあります。同時に、このメソッドはチェッククラスです。その時点で、チェックが追加され、エラーとして返されました。コードにより、すべてのトランザクションがプロセスの開始に失敗しました。	長い記憶のために批判されます。。。
Simpledateformatのスレッドのセキュリティが低下すると、マルチスレッドタイミングタスクの日付の解析でエラーが発生します	特定の時間指定タスクが実行されている場合、日付解析アクションを実行する必要があるため、パブリック変数simpledateformatを使用してフォーマットします。その結果、タスクはエラーを断続的に報告し、数日に1回、または週に1、2回報告します。これは定期的ではありません。例外情報を見ると、日付を解析する文字列が非常に奇妙であり、奇妙な数字がたくさんあることがよくあります。	時限タスクはエラーを報告しますが、幸いなことに、時限タスクはキャッシュ専用であり、データベースの更新は含まれず、クエリのみが含まれます。
主キーを解析するフロントエンドが異常です	Long型は最大19桁で、JavaScriptの最大受信数は16桁であるため、本質的に精度が低下します。	IDを文字列に変換してからフロントエンドに戻るための統合処理
リストトラバーサル削除	カウンターのメモリを少し節約するために、リスト配列をトラバース削除して空にします。	エラーを報告しましたが、なぜカウンターを使用しないのですか？香りがしませんか？
売られ過ぎ商品	兄弟部門から電子クーポン製品を販売している場合、同期在庫コードに問題があり、売られ過ぎや顧客の損失を引き起こします	1,000元の罰金

3.技術サービスの利用

インシデントレベル：P2
事故の判断：ネチズンはしばらく平手打ちされたと言っていましたが、問題はそれほど大きくありません！
インシデント名：拡張中に接続プールのコーミングを無視すると、接続プールがいっぱいになります
インシデント現象：オンラインで突然アラームメッセージを受信し、コンピューターの電源を入れて確認します。シンプルなクエリインターフェイスは、戻る前に3分にタイムアウトしました。
インシデントの説明：幸い、監視アラームがすべて追加され、アラームメッセージが時間内に受信され、DBAに連絡して、接続プールがいっぱいであることを確認しました。オンラインアラームを迅速に解決するために、接続プールが一時的に拡張され、サービスが優先的に再起動されました。観察後、接続プールはいっぱいになり、消えます。
インシデント処理：アプリケーションデータベース接続プールの構成を確認し、頻繁にオンラインにならない追加のサービスのトラブルシューティングを行います。クエリを実行した後、すべてのアプリケーションを合わせた接続プールの最大構成が、データベースによって割り当てられた接続プールの数を超えていることがわかりました。特に、時限タスクはデータベースをスキャンして処理するのに長い時間がかかります。これは、接続プールが直接いっぱいになる重要な理由です。
学習の概要：R＆Dは、コード開発者であるだけでなく、サポートサービスの理解でもあります。合理的な使用と包括的な配慮により、不必要と思われる事故を回避できます。

ネチズンは事故を共有します：

事故名称	事故の説明	事故の結果
fastjsonを使用する	全身はリスクの高い脆弱性に満ちており、バージョンは一年中継続的にアップグレードされ、パッチが適用されます	人生を大切にし、fastjsonから離れてください
WeChatの名前ストレージのバグ	WeChat名のemjファーストクラスはmysqlに保存され、エンコーディングはutf8ライブラリエラーレポートです。	びっくりしました！utf8mb4エンコーディングに変更
ディスクが不足しています	データベースクラスタのディスク容量が不足しており、2週間前に拡張申請を提出しました。パーティAは運用・保守を提出しませんでした。最後に、特定のマシンの容量が不足し、クラスタ全体が完全に機能しなくなりました。水平方向の拡張に便利であると主張されている特定のidbの優位性を体験してください。	罰金、責任はシステムビルダーにあります

4.バックドア違反操作

インシデントレベル：P0
事故の判断：ネチズンからのフィードバック、バックドアの私的開発、SQLエラーの実行、より大きな影響。追放！
インシデント名：バックドアプログラムを介してオンラインデータを変更する
インシデント現象：変更の範囲が予想よりも小さいデータの一部のみがキャッシュされ、データベースのアクティビティ情報が読み取られます。少数のお客様から、アクティビティが名前と一致しないとの苦情が寄せられました。
インシデントの説明：R＆D担当者は、運用要件に応じて、誤ったオンライン構成でアクティビティの名前を変更する必要がありますが、電子メールの記録と担当者による承認が必要です。そのため、R＆Dはバックドアプログラムを介してSQLステートメントの変更を非公開で送信しましたが、where条件を記述するのを忘れたため、何千ものアクティビティ名が同時に変更されました。
インシデント処理：後でDBAに連絡して、binlogログを介してデータを緊急に修復します。
学习总结：研发人员应避免操作线上数据，尤其是变更数据类。也不要开发各类改数据、上线、传配置文件等后门。而应该严格遵守研发流程，紧急事情需要请求批准处理。

网友事故分享：

事故名称	事故描述	事故结果
删除整个项目目录文件	测试区，测试删除文件时目录写错，导致整个weblogic子项目目录被删	请项目中负责集成部署的公司帮忙重新部署，测试区瘫痪了两天
误更新生产订单数据3万多条	下班前，未带核心过滤条件，导致误更新3万多条订单数据，偷偷利用binlog恢复了，耗时3个小时	完美恢复数据
线上库整库误删除	应业务方要求要在线上环境创建线上联调库，使用了导出数据库DDL语句后，直接执行，导致执行了exists drop语句，删除了线上库所有数据，数据量大表均在千万级，APP、网站全线瘫痪。	使用前一天的备份副本数据恢复，下载binlog日志按操作避开事发时间点分割后编译，导入数据，然后再修复事故之后的数据，共计耗时48小时。

5. 运营操作失误类

事故级别：P2
事故判责：网友说，金额太大没发出去！被喷了一会！
事故名称：运营把券配置成红包
事故现象：线上用户客诉，看到几百亿大的红包，领不到！
事故描述：运营人员配置优惠券，但是类型选成了红包，导致页面展示出超大额的红包金额待领取，都超出屏幕长度了！
事故处理：紧急下线活动，重新配置上线。同时产品设计需求，由研发人员实现对于此类配置提供明确、醒目的配置和完整的审核流程。如果配置红包、优惠券，会有校验此券的是否存在以及红包最大金额限制。
学习总结：看上去是运营配置错误，但从某个角度看其实也可以说是研发在做功能实现时，太过于单一完成产品功能，而没有加深考虑以及产品的易用性。 有时候多问一句就少一个风险！

网友事故分享：

事故名称	事故描述	事故结果
业务漏洞	业务乱配优惠券，可以叠加，超级优惠，然后被薅羊毛	部门帮着查羊毛记录，处理订单，挽回损失。然后对外发公告宣称是被部门的风控系统误杀的。
贷款费率	运营配置T+1日结算贷款费率错误，导致用户贷款金额发生错误。	上线新费率替换旧费率，已经产生的费率错误联系贷款用户修复。
多活动互斥	三个部门的都做活动，但最后导致重复发奖。一个用户邀请别人奖励，变成了三份奖励。	产品提供渠道和互斥功能，让运营自己选择是否可以并行发放奖励。

三、总结

讲道理，开发没事故，不是没用户体量，就是没用户规模。否则只要是人就一定会出现事故，要不是小bug被你销声匿迹隐藏了，或者是大事故被喷了或者送飞机了。
而尽可能减少事故的方式是需要尽可能按照一定的研发流程来实现功能逻辑。就像： 设计评审，把控的是实现流程、代码评审，把控的是实现方案，在配合上完善的监控和报警。只有这样才能更少的减少不必要的事故。