APM時代の品質保証への道：Tencent InteractiveEntertainmentの品質管理部門のパフォーマンスリーダーへのインタビュー
ガイド：11月23〜24日、GIACグローバルインターネットアーキテクチャカンファレンスが上海で開催されます。GIACは、アーキテクト、テクニカルリーダー、およびハイエンドのテクニカルプラクティショナー向けに、可用性の高いアーキテクチャテクノロジーコミュニティによって開始されたテクニカルアーキテクチャカンファレンスです。今年のGIACには、Microsoft、Tencent、Alibaba、Ant Financial、Huawei、iFlytek、Sina Weibo、JD、Qiniu、Meituan Dianping、Are you hungry、Caiyun、Geling Shentong、Databricksなどがあります。会社の専門家が出席した。今週購入すると、チケットが12％割引になり、高可用性構造のメンバーは最低40％割引になります。
会議の前夜に、High Availability Architectureは、2017 GIAC Quality AssuranceSub-forumのプロデューサーであるHeChunにインタビューし、すべての人が広く懸念している品質保証の問題についてインタビューを実施しました。
Tencent InteractiveEntertainmentの品質管理部門のパフォーマンスリーダーでありTencentTDRの専門家である彼は、パフォーマンスの問題に関するモバイルゲームの位置付けと調整に焦点を当てたTencentモバイルゲームリリース標準の策定に参加しました。パフォーマンス分析ツール（UPA）およびAPMモバイルゲームクライアントのパフォーマンス管理ツールの開発をリードしています。「Gloryofthe King」、「Crossing the Line of Fire：Gunfight King」、「Contra：Return」、「Naruto Mobile Games」、戦術的な競争力のあるモバイルゲームなど、多くの戦略的製品のパフォーマンス最適化に参加し、豊富なクライアントパフォーマンスを蓄積しました。の経験。
高可用性アーキテクチャ：パフォーマンスはユーザーエクスペリエンスに直接影響するため、パフォーマンスの問題は現在非常にホットな問題です。多くの関連する実務家は、さまざまな会議で実際のユーザーエクスペリエンスの問題を解決していることを強調しているため、ゲーム業界からでは、実際のユーザーエクスペリエンスをどのように定義しますか？あなたの経験によると、現在のモバイルゲームのパフォーマンスの問題はどこにありますか？
He Chun：私が働いているゲーム業界を例にとると、パフォーマンスの問題は主に画面のジッターとフリーズ、およびユーザー操作の応答時間に反映されます。これは実際には、私たちが通常呼ぶ広い意味でのパフォーマンスの問題です。技術的なレベルからは上記のデータが気になりますが、それはユーザーの知覚に変換されます。ゲーム中のユーザーの手の操作やユーザーの眼球の知覚は実際には数値を反映していません。たとえば、通常、メモリが非常に高い、CPUが非常に高い、またはネットワーク遅延が非常に高いと言われますが、ユーザーにとっては、CPUの高さがわからないため、ユーザーに次のように表示される場合があります。画面のジッター、ネットワーク遅延による応答タイムアウト、APP全体の直接フラッシュバックは、ユーザーが直接目で見ることができる効果であり、これが実際のユーザーエクスペリエンスだと思います。
パフォーマンスモニタリングの観点から、ゲームは主に画面のフレームレートを確認します。プレーヤーが操作している画面は、標準のオペレーティングシステム画面ではありません。AndroidインターフェイスでもAppleインターフェイスでもありませんが、ゲームエンジンを介して描画されます。画像のジッターと画像のフレームレートの変化は、プレーヤーのエクスペリエンスに大きな影響を与えます。ゲームのモニタリングでは、ユーザーに選択肢を与える、つまりユーザーにコアシーンを選択させる必要があるという特別な点もいくつかあります。多くのゲームでは、ログインフェーズまたはゲームロビーにいる場合、画面のジッターとネットワーク遅延もユーザーエクスペリエンスに影響しますが、ユーザーにはあまり影響しません。つまり、読み込み時間は少し長くなりますが、1回です。マップに入った後、プレイするときにパフォーマンスの問題はないはずです。
高可用性アーキテクチャ：以前はパフォーマンステストツールに取り組んでいましたが、現在はAPMツールに取り組んでいます。これら2つの異なるツールの開発についてどう思いますか？
He Chun：パフォーマンステストツールはテスターと開発者を対象としています。テストツールは実際には、より深く、より包括的なパフォーマンスデータを取得でき、テストツールはAPP自体に一定のパフォーマンスの影響を与えます。問題はありません。これは開発段階でのみ使用されます。APMと言えば、パフォーマンスの監視、収集、分析はC側に向けられており、製品に直接統合されて外部にリリースされます。したがって、監視するときは、APP自体のパフォーマンスへの影響を最小限に抑える必要があります。また、国によってはユーザーの機密データに制限がある場合があるため、海外に進出する企業がある場合は、EU GDPR契約の制限にも直面し、データ収集のレベルでいくつかのトレードオフを行います。大まかに言えば、現在の監視はユーザーエクスペリエンスをより良く改善することです。
高可用性アーキテクチャ：データの収集に関しては、APMのデータソースと製品マネージャーが一般的に使用するデータバックエンドは非常に均一です。では、2つのデータソースを1つに結合することを検討できますか？もしそうなら、どのような側面に注意を払う必要がありますか？そうでない場合、その理由は何ですか？
He Chun：はい、データタイプとデータ定義標準を調整する必要があります。もちろん、2つの間でデータプライバシー要件に違いがあるかもしれません。この記事に記載されているすべてのパフォーマンスデータの「監視」と「収集」について、Tencent Interactive Entertainmentは厳格な監督プロセスを実施しています。ユーザーのプライバシーを含まないことを前提として、これらのパフォーマンスデータは、R＆Dの品質を向上させ、より良い結果をもたらすのに役立ちます。製品の品質とユーザーエクスペリエンス。
高可用性アーキテクチャ：スピーチで、パフォーマンステストの閉ループについて言及されました。検証と比較、リアルタイムモニタリング、パフォーマンスの早期警告、問題の特定など、4つのリンクがあります。テンセントは「大きな工場」として体系的な建設を重視していますが、なぜこれらの4つの次元が選ばれたのかを個別に教えてください。
He Chun：まず、最初の次元は検証と比較であると言いました。パフォーマンスの収集、分析、および監視の最終的な目標は、ユーザーエクスペリエンスを向上させることです。つまり、バージョンの反復プロセス中に問題をできるだけ早く発見して修正できます。問題が修正されたら、新しいバージョンのリリース後に前後の比較を行う必要があります。
2番目のリンクはリアルタイムモニタリングです。いわゆる「リアルタイム」とは、バックグラウンドでビッグデータ計算を行うときに、計算頻度を1分や5分などの特定の範囲に下げようとすることを意味します。現在、計算頻度の遅延は最大5分です。ユーザーが任意の時点でAPM製品ページを開くと、表示されるすべてのデータは最新のものであり、現在計算されています。
3番目のリンクはパフォーマンスの早期警告です。現在取り組んでいるのは、ツールベースのプラットフォーム製品です。ツールの観点からは、「使いこなす」という原則があり、開発生にとってツールがあまり時間をかけないことを願っています。私たちのようなプラットフォームタイプのR＆Dツールであるため、その本質は作業効率を向上させることです。毎日このページを見てデータを確認するのに多くの時間を費やしても、実際には効率が向上しません。したがって、プロジェクトチームが製品の機能を認識した後は、毎日私たちのページにアクセスすることはありません。警告方法を使用して、問題を自動的にフィルタリングして検出できるようにしたいと考えています。実際には、それらを保存することです。時間。
最後のリンクは問題の配置です。限られた状況や条件の下で、問題を可能な限り特定の範囲に減らす必要があります。たとえば、通常、ゲームのフレームレート（25または23フレーム/秒）について説明します。ある時点で突然問題が発生し、フレームレートが非常に低いレベルに低下しました。このとき、問題の範囲を狭めるために最適化できるいくつかのポイントをさらに見つける必要があります。現時点では、特定の小さなシーン、携帯電話のモデル、さらにはAndroidやAppleのバージョン番号などをターゲットにする必要があります。そのため、問題の位置付けに関しては、非常に詳細なデータ分析を行い、多くの次元に分割し、複数の次元間で相互比較を行いました。このようにして、分析したデータはゲームのバージョンとゲームに対して正確になります。シーンはプレーヤーのモデルに正確であり、パフォーマンスの問題が発生する期間も正確です。期間の概念については、ゲームのパフォーマンスの問題を引き起こすサードパーティの理由がたくさんあることもスピーチで述べましたが、ゲームプロジェクトチームには明らかではないかもしれません。たとえば、サードパーティのコンポーネントが突然オンラインで更新されたり、携帯電話の製造元がオペレーティングシステムのバージョンを更新したりします。現時点では、プロジェクト開発チームが事前に知らない場合があります。これには、期間を監視する必要があります。これは私たちの仕事にも当てはまります。これらの問題の配置方法を通じて、プロジェクトチームは多くの問題を発見しました。
高可用性アーキテクチャ：現在、多くの企業がマイクロサービスアーキテクチャを採用しています。マイクロサービスの規模とダイナミクスによってデータ収集のコストも増加し、サービスの分割はエンドツーエンドの監視にある程度の影響を与えると思いますか。これらの質問？
He Chun：私の理解では、マイクロサービスの本質は、多くの大きなバックエンドサービスを多くの小さなリンクに分割し、各リンク間の結合を減らし、サービス間の独立性を高めることです。このようにして、各小さな機能のチームはより小さくなり、小さな機能の開発はより速く、より効率的に、より独立し、より自律的になります。次の問題は、ユーザーエクスペリエンスの観点から、サービスリクエストを開始すると、リンク全体に多数のリンクが存在することです。現在、WeTest APMサービスの焦点はクライアント側の監視であり、サーバー側の監視は次の焦点です。サーバー側の監視業界には実際に成熟したソリューションがあります。Googleのエンジニアリングチームは、大規模な分散システム監視システムDapperについて論文で説明しました。これは、リンク全体の分析に時間がかかります。このソリューションは比較的成熟しています。一部のWebサイド製品で使用されます。たとえば、ユーザーがWebページで製品の購入リクエストを送信すると、ボタンをクリックしてからバックグラウンドレスポンスまで、このリクエストに費やされた合計時間が多くのノードに分割されるため、このリクエストに費やされた時間が次のようになっていることがすぐにわかります。どのサービスに最も時間がかかりますか。したがって、私の意見では、マイクロサービスアーキテクチャは、パフォーマンスの分析と配置を行うのに便利です。マイクロサービスアーキテクチャを実装する前に、バックグラウンド応答のタイムアウトであろうとサーバーの問題であろうと、バックグラウンドチームがより多くの費用を費やす必要があると仮定します問題のトラブルシューティング。しかし、ノードごとに時間のかかる分析を計算するようなツールがあれば、どのノードに問題があるのかすぐにわかります。現時点では、小さなチームに通知するだけで済みます。チームは必要ありません。関係のない人々は、この分析を行うために仕事をやめます。
高可用性アーキテクチャ：WeTestアプリケーションのパフォーマンス監視の研究開発の段階はどのようなもので、将来どのような計画がありますか？
He Chun：最初の段階の焦点は、SDKを作成することです。SDK自体は、クライアントのパフォーマンスにほとんど影響を与えません。ゲームとSDKで一般的に使用されるアプリにはまだ大きな違いがあります。一般的に使用されるアプリにもAPMSDKがありますが、一般的に使用されるAPP操作は低頻度の操作であるため、パフォーマンスへの影響の要件は必ずしも高くありません。一部のIMソフトウェアでは、ほとんどの場合、入力とチャットのみを行い、複雑な操作を実行しないため、SDKがある程度のパフォーマンスを消費しても、ユーザーはそれを感じません。しかし、ゲームをしていると、プレイヤーの目と心が非常に集中し、手の操作の頻度も非常に高くなります。現時点では、SDK自体がゲームのパフォーマンスに与える影響をほぼゼロにする必要があります。これは、最初の段階の難しさです。
第2段階の難しさは、バックグラウンドでの高い同時実行性です。特に中国では、人気のあるゲームの中には、同時実行性が高く、ユーザー数が非常に多いものがあります。アクティブユーザーの数は簡単に数千万人に達する可能性があります。逆に、海外では簡単になります。ほとんどの海外ゲームはグローバルです。製品の1日の有効量は、国産品の1日の有効量ほど良くありません。
第3段階の難しさは、バックグラウンドデータ分析です。データ分析には、データ分析の専門知識とゲーム自体の理解の両方が必要です。現時点では、データ分析だけでは不十分だと思います。プロジェクトチームが多くの問題を見つけるのを手伝うことはできましたが、データ分析の深さは十分ではありません。実際、多くのデータをクロスすることができ、より深いクロス分析を行うことができます。 。
今後の計画としては、フルリンクモニタリングにも戻っており、上記のダッパーの発想に基づいてフルリンク分析をゲームに適用していきます。これには、ゲームのバックエンドサーバーアーキテクチャの調整が含まれます。現在、ゲームのバックエンドシステムのマイクロサービスを行っているTencentの自己調査チームで実験を行っています。フルリンクの構築が完了すると、各ノードの消費時間をカウントできます。1日に100万件のリクエストが同時に発生した場合、これらの100万件のリクエストのうち10,000件のリクエストがあることがわかります。消費時間が標準値を超えているため、これらの1万件のリクエストを確認します。問題のほとんどはどのノードにあるので、バックグラウンド応答時間を実際にすばやく修正して最適化できます。作業。
高可用性アーキテクチャ：あなたは今、あなたの答えの中で高い同時実行性について言及しましたが、APMは高い同時実行性のためにどのような最適化を行いましたか？1億2000万DAUの製品ラインの場合、データクリーニングはどのように達成されますか？
He Chun：APMの高い同時実行性は、実際には従来のAPPバックエンドサーバーと同じです。同時に収集されるデータの量は非常に多く、データを失うことはありません。ゲームビジネスの特性に基づいて、すべてを収集します。APM側での高同時処理の特徴は、クライアントの1つがゲームを完了した後、それを1つのファイルの形式で収集することです。ファイルがアップロードされた後、バックグラウンドでの高同時処理はファイルを受信する必要があります。従来のAPPの高い同時実行性は単なる要求であり、要求のデータ量は非常に少なく、おそらく数バイトにすぎません。バックグラウンドでの平均ファイルサイズは約100kです。大きい場合は300kになる可能性があるため、ファイルを受け取って保存し、ファイル内のデータを解析して別のデータテーブルに保存してから、ファイルを削除します。落とす。これが私たちの高い同時実行性の特徴です。
高可用性アーキテクチャ：あなたが言及した完全なコレクションはすべての指標を収集しますか？データ収集のパフォーマンスは通常、サンプリングレートと密接に関連していることがわかっています。サンプリングレートが高いと、パフォーマンスに影響が出ることがよくあります。サンプリングレートが低いと、極端な状況を見逃しやすくなります。高性能を達成し、可能な限り多くのデータを収集するために、WeTest APMのサンプリングレートはどのように決定されますか？
He Chun：はい、すべてのインジケーターが収集され、バックグラウンドの選択が行われます。これはより柔軟です。APMは、各フレームのレンダリング時間を収集し、データを固定キャッシュメモリに書き込み、キャッシュがいっぱいになったときにファイルに転送します。ディスクバッファテクノロジは、パフォーマンスへの影響を最小限に抑えるための書き込み操作に使用されます。
高可用性アーキテクチャ：あなたのスピーチでは、製品への機械学習と深層学習の適用についても言及されていましたが、機械学習と深層学習はどのように適用され、どのシナリオで適用されますか？
He Chun：APM側では、機械学習は主に2つの側面で使用されます。
1つ目は警告システムの学習です。私たちの深い学習はこのプロジェクトでいくらかの進歩を遂げました。スピーチを共有するとき、私はアラートメールのオープン率が現在75％であり、早くても30％に過ぎないかもしれないと述べました。最初は1日に数回警告が表示されることがありますが、見すぎると見た目が悪くなり、開けたくない場合があります。その後、コンバージェンス、つまり同じタイプまたは同じレベル、または過去2、3週間連続で見つかった問題を実行しましたが、発生した問題については警告を出しません。さらに、一部の監視付き学習は手動で行われます。たとえば、アラームシステムには確認と否定の2つのボタンがあります。ボタンをクリックすることで、その時点の警報システムのデータ値に基づいて、いくつかの深い学習が試みられます。現在、アラートメールの開封率は75％に引き上げられており、目標は90％に引き上げることです。アラーム正解率は90％になりました。アラーム正解率を深く学習または改善する過程で、私たちのチームは単一のプロジェクトでそれを検証します。たとえば、戦術的な競争力のあるモバイルゲームがあります。深い学習の道を進むには手動で確認する必要があるため、毎日生成されるアラームの内容を手動で確認します。アラームシステムは完全に監視されていない学習です。パフォーマンスの問題のほとんどは主観的なものであり、クラッシュやクラッシュとは異なりますが、画像が少し動かなくなっていると思う人もいれば、動かなくなっていないと思う人もいます。一人一人の寛容さは主観的な要因と関係があるので、私たちはまだここで監督された学習を行っています。
もう1つは、現在取り組んでいるプロジェクトですが、あまり良い結果が得られていません。簡単に言えば、さまざまな監視データを組み合わせてスコアを付ける必要があります。このスコアは、ゲームの「パフォーマンスの健全性」として理解でき、スコアは正確です。このスコアの背後には実際には計算式があり、一連のアルゴリズムがあるため、パフォーマンスと有効性は深層学習を通じて行う必要があります。深層学習を使用してこの計算式を強化し、式の精度と有効性を向上させる必要があります。その合理性さえも改善しなければなりません。このプロジェクトでは、すでに試みを開始しており、今後進展が見られる場合は、ぜひお知らせください。
要約すると、APM側の深層学習は、主に警告システムを強化し、将来の総合スコアを強化するために使用されます。
高可用性アーキテクチャ：APMは90％を超える精度でAIアラームを使用している、つまり、まだいくつかの誤判断があるとおっしゃいましたが、一般的に、誤判断に対処するにはどうすればよいですか？誤判断を減らすために技術的手段を通じて継続的に最適化する方法は？
He Chun：重要なアイテムのアラームを1つずつ手動で確認し、AIに手動介入による監視学習を行わせます。Googleの最近のWeChat Moments of Friendsは、実際には監視学習に属する「DrawingIGuess」アップルトをリリースしました。種類。
高可用性アーキテクチャ：Tencentが開発し、自己開発した80を超える人気のあるゲームをサポートするため、APMのプレッシャーは小さくありません。完全なコレクションの場合、このAPMのセットをサポートするために使用するストレージクラスターとアプリケーションクラスターの現在の規模はどのくらいですか。バックエンドアーキテクチャはプレッシャーと不安定さにさらされていますか？どのように対処しますか？
He Chun：リアルタイムのパフォーマンスが高い一部のデータについては、引き続きmysqlを使用して保存します。リアルタイムの要件が低いデータは、Hadoopに保存され、オフラインで計算されます。ビジネス量の増加と製品自体のニーズに伴い、バックエンドアーキテクチャ3つの調整と最適化が連続して実行されました。「シングルゲーム」ユニットでデータを収集したため、QQスピードなどの「シングルゲーム」が多数あるプロジェクトはより大きなプレッシャーを生み出しますが、大規模なマッププロジェクトはそれほどストレスを受けません。この計画には、受信側の動的拡張、大規模プロジェクトの独立したストレージ、およびリアルタイム要件の低いデータのオフライン計算が含まれます。
高可用性アーキテクチャ：インタビューで言及されたデータ分析の分野では、私たちが収集したデータは最終的にどのように分析、比較、表示されますか？リアルタイム？またはオフライン？一般的に、データのどの次元に焦点を当てていますか？
He Chun：データは、リアルタイムとオフラインの2つのタイプに分けられます。それらのほとんどは、Hadoopによってオフラインで計算され、ごく一部はリアルタイムで計算されます。ユーザーエクスペリエンスからは、フレームレート、フリーズ、および遅延に焦点が当てられています。
高可用性アーキテクチャ：完全なエンジン互換性のために、C2DX、U3D、およびUNREALの3つのエンジンを完全にカバーするにはどうすればよいですか？適応プロセス中にどのような興味深い問題が発生しましたか？
He Chun：実際、SDKパッケージには、c ++バージョン、ユニティバージョン、非現実バージョンの3つのバージョンがあります。適応テストも最も基本的なプロセスの1つであり、バージョンが更新されるたびに、最上位のtop300モデルで実行され、メインストリームマシンが確実に実行されるようにします。タイプは結構です。
高可用性アーキテクチャ：ツール製品として、社内で宣伝するのは簡単ではありません。さまざまなビジネスラインやスタジオが独自のツールと独自の「ホイール」を持っている場合があります。この部分で共有する経験はありますか？ツールを作っている学生は学ぶことができますか？
He Chun：まず第一に、大企業では確かに「車輪を作り直す」という状況があります。これは、ツールであるクラスメートにとっては確かに少し難しい状況です。ここで最も重要なことは、考え方を変えて自分自身を置くことです。作成されたツールは、toB製品として宣伝および運用されています。Tencentの自己開発プロジェクトでは、各プロジェクトチームが問題の監視と問題の修復をどれだけ重視しているかに応じて、APM作業とデータ収集を行うチームが実際に存在します。しかし、プロジェクトチームはバックエンドにデータを収集しただけで、相互分析も行わず、非常に詳細な多次元の組み合わせ分析も行いませんでした。このツールには非常に使いやすい製品ページがありませんでした。開発チームは開発ニーズに基づいている可能性があります。データベースからいくつかのデータを取得して確認します。開発チームの2つの問題点を分析すると、これは実際にはツールチームが懸命に取り組むことができる方向です。また、APMを行う機会がありました。さらに興味深いのは、後で実際にAPMという用語について学んだことです。このシステムで作業していたとき、実際には、すべてのTencentプロジェクトで使用できる完全な監視システムを構築したかったのです。その後、この国際的な名前がAPMと呼ばれることを徐々に知りました。
APM製品と言えば、それ自体がTo Bアプリケーションであり、最初は非常に困難ですが、一度実行すると、構築する障壁が高くなります。たとえば、前述のパフォーマンステストツールの場合、会社に同様のシステムがいくつかある場合があります。プロジェクトチームは、私のもの、あなたのもの、または彼のものを使用できます。テストツール自体は製品の運用段階に影響を与えませんが、APM SDKは接続されていて安定したパフォーマンスを備えている限り、プロジェクトチームは簡単に交換できません。
さらに、[To B]フィールドでは、さまざまなチームとやり取りしてコラボレーションする方法を学ぶ必要があります。別のチームもAPMSDKを作成したいと思っている場合、彼の目的は何ですか？彼の最終的な目標は、SDKのためにSDKを構築することではなく、プロジェクトチームが問題を見つけて特定するためのデータを取得することです。それらの真の目的を知っているので、SaaSサービスと同等のデータインターフェイスを開くことができます。これは、オープンでウィンウィンのエコロジカルな協力またはチーム間の協力に相当します。これは、多くのチームで「車輪を作る」という考えを払拭する可能性があります。
高可用性アーキテクチャ：個人の成長について少し話しましょう。昨年はパフォーマンステストを行い、今年はAPMに切り替えましたが、実際には、パフォーマンス管理にはより大きな全体像が必要になる可能性があるため、技術ルートの観点からはテストよりも少し高いと思われます。将来のモバイルインターネット時代においても、パフォーマンスは非常に重要なトピックです。一部のテストエンジニア、またはパフォーマンスを行っているエンジニアや将来パフォーマンス管理に進む可能性のあるエンジニアにとって、個人の成長にもっと注意を払う必要があると思いますか。問題は何ですか？それとも、個人の成長においてどのような良い経験がありますか？
He Chun：最初に背景について話しましょう。Tencentのモバイルゲームは2013年に始まりました。2013年に「DailyCool Run」を始め、次にカードゲーム、次にRPG、そして今はMOBAをやっています。この傾向から、重いゲームは徐々に携帯電話に移行します。現在の観点から、多くのゲームの運営戦略は長期運営であり、単一の製品が安定した長期の運営収入を持つことが期待されています。これには、製品のすべての側面、特に経験要件に対してますます高い要件が必要になるため、一般的な背景から、パフォーマンスの監視と最適化、および継続的な反復は厳格なニーズです。
個人開発に関しては、元のテストツールは開発期間中の一部のチームのみを対象としています。オンラインのリアルタイムAPMシステムを構築する場合は、ユーザーグループを開発チームまたは計画チームにまで拡大できます。 、プロジェクトプロデューサーやディレクターなどのより高いレベルの人々でさえ、チーム内であなた自身の影響力を拡大します。個人的な技術の向上に加えて、技術者であるという全体的な見方も大幅に向上します。元のテストツールでは、単一のプロジェクトの単一のテストの結果を見ただけでしたが、今ではプロジェクトの大きなデータを見ることができ、すべてのプロジェクトのデータを見ることができます。すべてのプロジェクトデータがなくなったら、次のことができます。カテゴリセグメンテーションは、ゲームの種類に応じてMOBAカテゴリ、レーシングカテゴリなどに分類できます。セグメンテーションカテゴリのパフォーマンスデータが公開されると、将来の新しいプロジェクトの意味を示す指標になります。
これらのデータが出た後、これらの指標が満たされている限り、ゲームが成功したとは言えませんが、経験が悪くなることは決してないことをゲーム開発チームに直感的に伝えることができます。新しいプロジェクトの場合、これは非常に参考になります。
今年は、APMプラットフォームは実際には橋だと感じています。橋の左側にはR＆Dチームがあり、右側にはさまざまなメーカーがあります。APMプラットフォームは、プロジェクトチームの最適化を支援するだけでなく、ハードウェアメーカー全体に共通のハードウェアの製造を促進することもできます。製品の最適化。ゲームは携帯電話のソフトウェアとハードウェアリソースの中で最も消費量の多いアプリであるため、多くのメーカーは依然として重いゲームでの携帯電話のパフォーマンスを高く評価しています。以前に新モデルがリリースされたことを思い出しました。リリース時、「Honor of Kings」はデフォルトで最高の画質でしたが、実際にはモニタリング後のパフォーマンスデータが良くなかったため、デフォルトのオプションを中程度の画質に調整しました。長期的なデータ分析により、さまざまなハードウェアの組み合わせの作業効率が相加的ではないことがわかりました。CPU、メモリ、GPU、さらには一部の低レベルのマザーボードやチップセットでさえ、1 + 1 + 1 = 3ではありません。関係は1+ 1 + 1 = 2.5または2.8の場合があります。
高可用性アーキテクチャ：当時、このことをやりたいと言ったとき、これが国際的にAPMと呼ばれていることを知りませんでしたが、当時、このことを行うのはリーダーシップの仕事でしたか、それともそれをやりたいと思ったのはボトムアップチームでしたか？
He Chun：ボトムアップでローンチされました。Tencentの創造性と多くのタスクの多くはボトムアップです。リーダーシップのアイデアは30％〜40％を占め、残りはチームによって上から下へと開始されます。誰もが技術の成長と革新を必要としています。Tencentはまた、すべての人が社内で革新することを奨励し、すべての人が独自のアイデアを持ち、積極的に考える習慣と能力を持っていることを奨励しています。以前はテストツールに取り組んでいましたが、一部の開発クラスメートから、現在のテストツールはテストフェーズのデータのみを確認するように求められました。実際にオンラインでリリースされた後、パフォーマンスの監視に役立つツールを入手できますか。だから私はその時にこれをすることにしました。
今年の6月、私はシアトルで開催されたMicrosoft Buildカンファレンスに参加しました。Microsoftは、APMがDevOpsの非常に重要な部分であり、テスト、運用、保守、そしてもちろん開発の両方に役立つことを提案しました。APMで生成されたビッグデータは、データ分析を通じて得られた結論と指標の後に、会社の意思決定者が見たいものです。これらの結論と指標を通じて、スタジオの責任者は、どのプロジェクトのユーザーエクスペリエンスまたは外部を知ることができます。ネットフィードバックはより良くなります。これは、エンジニアリングチームがツールを使用して、社内でボトムアップでビジネスの改善を促進する方法の良い例です。
高可用性アーキテクチャ：GIACへのメッセージは何ですか？
He Chun：昨年のクオリティスペシャルのプロデューサーとして、GIACの現場の魅力と観客の積極的な熱意を深く感じました。これは純粋なトピック共有であるだけでなく、業界の考え方の深い衝突交換でもあります。GIACがどんどん良くなってくれることを願っています。
WeTestについて：
Tencent WeTestは、Tencentによって正式にリリースされたワンストップ品質のオープンプラットフォームです。品質管理における10年以上の経験、品質標準の構築と製品の品質向上に取り組んでいます。Tencent WeTestは、互換性、クラウド実機、パフォーマンス、セキュリティ、ペンギンニュースなどの優れたR＆Dツールをモバイル開発者に提供し、R＆Dと運用のさまざまな段階での製品のテストニーズをカバーする100以上の業界向けのソリューションを提供し、数千の製品を経験しています。 。金メダルの専門家チームは、5つの次元と41の指標を通じて、製品の品質を360度保証します。
このGIAC会議では、品質保証/ DevOpsセクションのすばらしいトピックは次のとおりです
。GIACに参加し、2018年に最新のテクノロジーを確認します。会議の詳細については、「オリジナルを読む」をクリックしてください。