ockie1729/manual.md Secret

## manual.md

      
    Raw
  

              manual.md
            
          
    ISUCON11 予選当日マニュアル

本マニュアルならびに、ISUCON11 予選レギュレーション をご確認ください。
本マニュアルとレギュレーションの内容に矛盾がある場合、本マニュアルの内容が優先されます。
スケジュール


10:00 競技開始
17:00 リーダーボードの更新停止
18:00 競技終了
翌 14:00 結果発表

課題アプリケーション ISUCONDITION について

課題アプリケーション ISUCONDITION の仕様については、ISUCONDITION アプリケーションマニュアルを参照してください。
ISUCON11 ポータルサイト（ポータル）

ISUCON11 の競技では下記のウェブサイトを利用します。事前に登録した情報を用いてログインしてください。
なお、このページは競技開始時刻までアクセスすることはできません。
ポータルでは、負荷走行（ベンチマーク）の実行/結果確認、質問/サポート依頼の送信、リーダーボードの確認ができます。
https://portal.isucon.net/contestant
リーダーボードの更新について

ポータル上のリーダーボードは、競技終了 1 時間前に他チームの情報が更新されなくなり、自チームの情報のみ更新されます。
Discord の利用について

ISUCON11 サポート Discord サーバーは競技中ならびにその前後の時間はすべてのチャンネルが発言不可となります。
競技時間中はポータルを通して質問/サポート依頼を送信することができますので、そちらを利用してください。
ただし、予選参加者（以下選手）は競技時間中も Discord の確認が可能な状態、通知が受け取れる状態を維持してください。
これは主催者が選手とリアルタイムでのチャットが必要だと判断した場合、主催者が Discord 上でプライベートチャンネルを作成しメンションの上、呼びかけを行う場合があるためです。呼びかけに応じない場合、競技に支障をきたす可能性があるため、必ず応答可能な状態を維持してください。
また、主催者からのアナウンス等も Discord で実施されます。
質問について

選手は主催者へ質問を送信することができます。質問は競技内容・マニュアル・レギュレーション等に対する疑問点の確認や、サーバー障害などのトラブル報告・サポート依頼に利用することができますが、これに限りません。
主催者は質問された内容が競技の一環である場合は、回答できない旨を返答することがあります。
競技時間中の質問について、主催者からの回答は全選手へ公開、あるいは個別に回答されます。全選手へ公開される場合、質問内容の原文、あるいは主催者による内容の要約が公開されます。未回答の質問・未公開の回答については質問した選手およびそのチームメンバー、主催者のみが確認できます。質問への回答・更新はポータル上にて選手およびそのチームへ通知されます。
主催者は競技時間中の質問への回答を、原則として全選手へ公開します。ただし、重複する質問や、選手およびチーム個別の問題に対する対応の場合、この限りではありません。
サポート対象外の事項

主催者が事前に Discord サーバー等で告知していた通り、下記はサポート対象外となります。

競技環境確認を事前に行っていないチームからの競技環境に関する質問/サポート依頼
AWS クーポンに関する質問/サポート依頼
スポンサー各社が提供しているサービスについての質問/サポート依頼

競技環境構築と接続

競技に参加するにあたり、各チームが用意した AWS アカウントで競技環境を下記の手順に従って構築してください。
1. テンプレートのダウンロード

まず、環境構築には AWS CloudFormation を利用するため、チームはポータル上から AWS CloudFormation のテンプレートをダウンロードします。
テンプレートはチームごとに固有のものとなっているため共有厳禁です。
https://portal.isucon.net/contestant/contestant_instances
このテンプレートでは以下のリソースを作成します。

EC2 インスタンス （c5.large）x 3
EBS（gp3 20GB）x 3
EIP x 3
VPC x 1
VPC サブネット x 1
VPC ルートテーブル x 1
インターネットゲートウェイ x 1
セキュリティグループ x 1
Availability Zone 情報取得に利用する Lambda 関数 x 1
IAM ロール x 2
EC2 インスタンスプロファイル x 1

テンプレートから作成される IAM ロールは、EC2 インスタンスおよび Lambda 関数で上記リソースの情報取得を行うために利用します。
許可されているアクションは AWS の仕様上、アカウントに存在する他のリソースの情報も閲覧できる設定になっていますが、主催者は不要な情報の取得は行いません。
2. スタックの作成


AWS マネジメントコンソールの CloudFormation を開き、ページ右上に表示されているリージョン名がアジアパシフィック（東京）（ap-northeast-1）になっていることを確認します。
「スタックの作成」をクリックします。

既存のスタックがある場合は「スタックの作成」から「新しいリソースを使用（標準）」を選択します。


「スタックの作成」ページから「テンプレートの準備完了」、「テンプレートファイルのアップロード」を選択し、上記でダウンロードしたテンプレートのアップロードを行い「次へ」をクリックします。
「ステップ 2 スタックの詳細を指定」では任意のスタック名を設定し、「次へ」をクリックします。
「ステップ 3 スタックオプションの設定」では変更を行わず「次へ」をクリックします。
「ステップ 4 レビュー」において、ページ最下部「スタックの作成」ボタンの上に表示されている「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します」にチェックを入れた上で、「スタックの作成」をクリックします。
作成したスタックの状態が CREATE_COMPLETE（作成完了）になるまで待機します。

3. サーバーへの SSH 接続

スタックの作成完了後、1 分程度で SSH 接続できるようになります。サーバーには選手が GitHub に登録している SSH 鍵を利用して、ユーザ名 isucon で SSH 接続ができます。
サーバーの IP アドレスはポータルか、AWS マネジメントコンソールの EC2 インスタンスページから確認できます。
サーバーへ接続後、下記のコマンドを実行することで正しく起動しているか検証が行われます。この作業は全サーバーで実行する必要はありません（1 つの実行で全サーバーの検証が行われます）。
sudo /opt/isucon-env-checker/isucon-env-checker

アプリケーションの動作確認

ISUCONDITION には、サーバーの IP アドレスに Web ブラウザから HTTPS でアクセスできます。
なお、ブラウザからサーバーの IP アドレスを指定してアクセスすると、TLS 証明書の検証エラーが表示されますが不具合ではありません。このエラーを回避したい場合には以下の作業を行った後、https://isucondition.t.isucon.dev を指定してサーバーにアクセスしてください。
Mac や Linux であれば /etc/hosts に、 Windows であれば C:\Windows\System32\drivers\etc\hosts に以下の行を追記します。${サーバー IP アドレス} はサーバーの IP アドレスに読み替えてください。
${サーバー IP アドレス} isucondition.t.isucon.dev

上記変更の反映にはブラウザの再起動が必要な場合があります。
ISUCONDITION へのログイン

ISUCONDITION を利用するには Japan ISU Association（以下 JIA）のアカウントが必要です。JIA には下記の 4 ユーザが登録されています。
なお、isucon および isucon3 ユーザは初期状態で何もデータが登録されていません。


ログイン ID
パスワード


isucon
isucon


isucon1
isucon1


isucon2
isucon2


isucon3
isucon3


負荷走行 （ベンチマーク） の実行

負荷走行はポータル上からリクエストします。
ポータル にアクセスし、「Job Enqueue Form」から負荷走行対象のサーバーを選択、「Enqueue」をクリックすることで負荷走行のリクエストが行われ、順次開始されます。
なお、負荷走行が待機中（PENDING）もしくは実行中（RUNNING）の間は追加でリクエストを行うことはできません。
競技環境について

環境情報の確認と送信

サーバー起動（再起動を含む）時に競技環境が主催者の指定した環境で構築されているかを確認し、サーバー IP アドレスを含む環境情報をポータルに送信する処理が実行されます。
ポータルは送信された環境情報を元に、ポータル上に表示されるサーバー IP アドレス等のサーバー情報を更新します。なお、これはサーバー単位で更新されます。
この処理はサーバー起動時以外に、以下のコマンドで選手自らが行えます（競技環境構築で案内したコマンドと同一です）。
sudo /opt/isucon-env-checker/isucon-env-checker

競技環境の再構築方法

選手自らが設定変更等により競技環境を破壊するなどして、初期状態に戻す必要がある場合は上記「競技環境構築と接続」を参考に選手自らが AWS CloudFormation で新たに競技環境の構築を行うことになります。再構築以前の競技環境上で変更を加えたソースコードや設定ファイル等の移行が必要な場合は、各チームの責任で行ってください。
なお、サーバーの起動・停止・再起動は AWS マネジメントコンソールや API から選手が行っても構いません。
後述する「複数スタック」の問題を回避するため、再構築作業完了後は以前の AWS CloudFormation スタックを削除することをおすすめします。
複数スタックについて

ポータルからダウンロードしたテンプレートを利用して AWS CloudFormation スタックを複数作成しても構いません。ただし、以下の点に留意してください。
まず、「環境情報の確認と送信」で言及した通り、サーバー情報の更新はサーバー単位、かつサーバーが起動（再起動を含む）するたびに実施されます。
そのため、複数のスタックで作成されたサーバーが同時に存在している時、選手の操作によっては、ポータル上のサーバー情報が複数のスタックに跨ってしまう場合（混在）があります。
競技時間中は混在した状態になってしまっても問題ありませんが、競技終了時点でポータル上のサーバー情報が混在していた場合は失格となります。
主催者はポータルに登録された環境以外のサポートや、混在した状態でのサポートは行いません。
なお、混在しているかの判断はポータルとスタックのリソースに表示されている IP アドレスを元に行ってください。
重要事項


競技終了後は主催者からアナウンスがあるまで競技環境のシャットダウンや停止などは行わず、3 台とも起動した状態を維持してください。

競技時間中の再起動や一時的な停止に関しては問題ありません。


競技に利用できる計算機資源は主催者が公開した CloudFormation テンプレートの内容に沿って起動された EC2 インスタンスのみです。

例えば、テンプレートで作成されたリソースを、その内容に沿わなくなる変更（例： インスタンスタイプの変更）を行った状態で、競技に利用すると失格となります。
競技終了時点で 環境情報の確認 に失敗する状態の場合、失格となります。
競技終了時点でポータル上のサーバー情報に複数環境（スタック）が混在した状態の場合、失格となります。
レギュレーションに記載した通り、モニタリングやテスト、開発において外部の資源を用いても構いませんが（例： メトリクス計測サービス）、スコアを向上させるいかなる効果を持つものであってはいけません。これは前述している複数環境の利用も含みます。


競技終了後は、主催者が追試を行います。Discord サーバー および https://isucon.net にて主催者がアナウンスをするまで、競技環境の操作はしないでください。

競技終了後、別途アナウンスがあるまでの作業や操作（削除を含む）は失格となります。なお、アナウンスは結果発表後の予定です。
競技環境の削除は、各チームで行う必要があります。削除を行わなかったために発生した不利益について、主催者は一切の責任を負いません。削除を行ってよいタイミングについても、結果発表後にアナウンスの予定です。


変更してはいけない点

下記は追試や環境確認に利用するため、変更した場合は失格となります。

isucon-env-checker.serviceに関わるファイル

/etc/systemd/system/isucon-env-checker.service
/etc/systemd/system/multi-user.target.wants/isucon-env-checker.service
/opt/isucon-env-checker 内のファイル


その他、主催者による追試を妨げる変更（例： サーバー上の isucon 以外のユーザに関する、ユーザ削除や既存の公開鍵の削除）

参考実装

下記の言語での実装が提供されています。

Go
Node.js
Perl
PHP
Python
Ruby
Rust

参考実装の切り替え方法

初期状態では Go による実装が起動しています。
各言語実装は systemd で管理されています。
例えば、参考実装を Go から Ruby に切り替えるには以下のコマンドを実行します。
sudo systemctl disable --now isucondition.go.service

sudo systemctl enable --now isucondition.ruby.service
PHP への切り替え

ただし、PHP を使う場合のみ、systemd の設定変更の他に、次のように nginx の設定ファイルの変更が必要です。
sudo unlink /etc/nginx/sites-enabled/isucondition.conf
sudo ln -s /etc/nginx/sites-available/isucondition-php.conf /etc/nginx/sites-enabled/isucondition-php.conf
sudo systemctl restart nginx.service
データベースのリカバリ方法

参考実装では、初期化処理（POST /initialize）においてデータベースを初期状態に戻します。
以下のコマンドでもデータベースを初期状態に戻すことができます。
~isucon/webapp/sql/init.sh

初期化処理は用意された環境内で、ベンチマーカーが要求する範囲の整合性を担保します。
サーバーサイドで処理の変更・データ構造の変更などを行う場合、この処理が行っている内容を漏れなく提供してください。
/etc/hosts ならびに isucondition-[1-3].t.isucon.dev ドメインについて

サーバーには初期状態で、3 台のサーバーの IP アドレスが事前に /etc/hosts へ登録されています。これらのホスト名は自由に利用して構いません。ベンチマーカーは下記のホスト名に対して接続します。
192.168.0.11 isucondition-1.t.isucon.dev
192.168.0.12 isucondition-2.t.isucon.dev
192.168.0.13 isucondition-3.t.isucon.dev

また、サーバーに設定されている TLS 証明書は subject name が *.t.isucon.dev であるため、このホスト名で HTTPS 接続を行うと TLS 証明書の検証エラーは発生しません。ベンチマーカーはこれを期待します。
なお、*.t.isucon.dev の FQDN に関しては 127.0.0.1（IPv6 は ::1）の DNS レコードが登録されています。必要に応じて、検証や開発などで活用してください。
負荷走行について

ベンチマーカーによる負荷走行は以下のように実施されます。

初期化処理の実行 POST /initialize（20 秒でタイムアウト）
アプリケーション互換性チェック（数秒～数十秒）
負荷走行（60 秒）

初期化処理もしくはアプリケーション互換性チェックに失敗すると、負荷走行は即時失敗（fail）になります。
負荷走行終了時点で HTTP レスポンスの処理を打ち切ります。未完了のリクエストなどは強制的に切断されます。
リダイレクトについて

ベンチマーカーは HTTP リダイレクトを処理しません。
キャッシュについて

ベンチマーカーは下記を除き、データの更新が即時反映されていることを期待して検証を行います。ただし、アプリケーションはベンチマーカーが検知しない限りは古い情報を返しても構いません。
コンディションの反映について

POST /api/condition/:jia_isu_uuid で受け取ったコンディションの反映が遅れることをベンチマーカーは許容しています。以下のエンドポイントが該当します。

GET /api/isu
GET /api/isu/:jia_isu_uuid/graph
GET /api/condition/:jia_isu_uuid
GET /api/trend

ただし、 GET /api/condition/:jia_isu_uuid と GET /api/isu/:jia_isu_uuid/graph の間で取得できる情報は 1 秒以内に整合性を保つ必要があります。
たとえば、GET /api/condition/:jia_isu_uuid で取得できたコンディションは、 1 秒以内にGET /api/isu/:jia_isu_uuid/graph でも取得できなければいけません。
なお、反映を遅らせた場合、加点の機会が減る可能性に留意してください（「スコア計算」を参照）。
Conditional GET のサポートについて

ベンチマーカーは一般的なブラウザの挙動を模した Conditional GET に対応しています。
アプリケーションは、 Cache-Control やその他必要なレスポンスヘッダを返すことで、ベンチマーカーから Conditional GET リクエストを受けることができます。
データが更新されていないことが期待されるリクエストにおいては、304 Not Modified を返したり、あるいはブラウザのキャッシュ有効期限の制御によってリクエストが発生していない場合も、ベンチマーカーはそれらのキャッシュを利用してレスポンスがあったものとみなします。
なお、ベンチマーカー内のユーザは独立しているため、 Cache-Control: public 等が指定されていたとしても、ユーザ同士でキャッシュを共有することはありません。
タイムアウトについて

ベンチマーカーにおいて設定されているタイムアウト値は下記の通りです。

POST /initialize

20 秒以内にレスポンスを返す必要があります。これを超えた場合、負荷走行は即時失敗（fail）します。


POST /api/condition/:jia_isu_uuid

100 ミリ秒を超えるとタイムアウトしますが、後述のスコア計算にあるように減点の対象とはなりません。


上記以外の HTTP リクエスト

1 秒以内にレスポンスを返す必要があります。これを超えた場合、後述のスコア計算に従い減点の対象となります。


ISU の仮想時間について

ベンチマーカー上では現実の 3 万倍の速度で時間が流れており（現実の 1 秒がベンチマーカー上では 30,000 秒）、ISU はこの仮想時間を使ってデータを送信し、ユーザも仮想時間に基づいたリクエストを送信します。
ベンチマーカーが利用する JIAアカウント

ベンチマーカーは JIA アカウントの 1 つとして isucon を利用します。
isucon ユーザを用いることで、負荷走行後のアプリケーションの状態確認が可能です。
スコア計算

アプリケーション互換性チェックを通過し負荷走行が開始されると、初期スコアとして 1,000 点が加点されます。
それ以降は下記の通り加点・減点が行われます。
負荷走行時における加点について

スコアはユーザが下記のように ISU のコンディションやグラフを確認することで加点されます。

ISU のコンディション確認（GET /api/condition/:jia_isu_uuid）で、ユーザが前回確認したコンディションより新しいコンディションを確認した際に加点

Info（50 件ごとに 20 点）
Warning（50 件ごとに 8 点）
Critical（50 件ごとに 4 点）


ISU のグラフ確認（GET /api/isu/:jia_isu_uuid/graph）で、ユーザがグラフの確認に成功した際に、そのデータに応じて加点（後述）

ユーザはある 1 つの ISU のグラフを複数確認したいことがあります。その場合、確認したいグラフ全てを確認できた時に加点が発生します。


仮想時間における当日のグラフの確認による加点

ベンチマーカーはグラフを日毎で取得します。具体的には日本時間（JST）で時刻が 00:00:00 となる値を datetime パラメータとして付与し、得られたグラフは日毎となります。このようなグラフを以後 日毎グラフ とします。なお、グラフのデータポイントは 1 時間単位です。
当日のグラフ とは、仮想時間における現在時刻 （仮想現在時刻） が例えば 2021-08-19 01:13:30 であるとき、 2021-08-19 00:00:00 を datetime に指定して得られる、2021-08-19 の 日毎グラフ です。
当日のグラフ で得られる得点は、確認したグラフ中で各データポイントが持つコンディションの数を数え、その最小（n）を元に計算されます。疑似コードで示すと下記の通りです。
dataPointConditions = dataPoints.map((dataPoint) => {
  return dataPoint.conditions.length
})
n = min(dataPointConditions)

なお、仮想現在時刻 より後の時刻 （未来） のデータポイントは無視されます（例えば 仮想現在時刻 が 14:15 であるとき、 14 時以降のデータポイントは無視されます）。


得点
条件


Good
60
20 < n


Normal
40
10 < n <= 20


Bad
24
5  < n <= 10


Worst
4
0  <= n <= 5


仮想時間における当日以外のグラフの確認による加点

当日以外のグラフ（当日のグラフ ではない 日毎グラフ）は、 完成したグラフ（後述）のみ加点の対象になります。
完成したグラフ で得られる得点はグラフ中で各データポイントが持つコンディションの数の最小（n）を元に計算されます。
同日の 完成したグラフ からは複数回得点を得ることはありません。同日の 完成したグラフ で得られる得点の計算は、そのグラフが最後にユーザに送信されたデータで行われます。


得点
条件


Good
150
20 < n


Normal
100
10 < n <= 20


Bad
60
5  < n <= 10


Worst
10
0  <= n <= 5


完成したグラフとは

ベンチマーカーが任意の 日毎グラフ を確認する際に 完成したグラフ の判定が行われます。これは前項で言及されている 当日のグラフ の確認でも発生します。
まず、任意の 日毎グラフ（G）、G の前日の 日毎グラフ（G-1）、G の前々日の 日毎グラフ（G-2）を考えます。次の 2 つの条件をチェックします。

G の 12 時以降のデータポイントいずれかにデータがある時、 G-1 以前の 日毎グラフ は全て 完成したグラフ とみなされる。
G の 0～11 時のデータポイントいずれかにデータがある時、 G-2 以前の 日毎グラフ は全て 完成したグラフ とみなされる。

また、このチェックの際は G のうち 未来 のデータポイントは無視されます。
具体例


2021-08-16 13:00:00 が 仮想現在時刻 であるとき、 当日のグラフ で 12 時のデータポイントにデータが確認されると、2021-08-15 以前の 日毎グラフ が全て 完成したグラフ とみなされます。
2021-08-10 04:00:00 が 仮想現在時刻 であるとき、 当日のグラフ で 2 時のデータポイントにデータが確認されると、2021-08-08 以前の 日毎グラフ が全て 完成したグラフ とみなされます。

言い換えると、 当日のグラフ である 2021-08-10 の 2 時のデータポイントは 2021-08-09 の 日毎グラフ に属さないデータポイントですが、これは「2021-08-09 の 12 時以降のデータポイント」であると考えることができます。そのため、2021-08-08 以前が 完成したグラフ とみなされます。


2021-08-05 09:00:00 が 仮想現在時刻 であるとき、2021-08-04 の 日毎グラフ で 14 時のデータポイントにデータが確認されると、2021-08-03 以前の 日毎グラフ が全て 完成したグラフ とみなされます。

この時、2021-08-04 の 日毎グラフ は 完成したグラフ とはみなされません。
2021-08-04 の 日毎グラフ は、 2021-08-05 の 12 時以降のデータポイントにデータが確認された際のチェックでなければ、 完成したグラフ とみなされません。


最新の 完成したグラフ が 2021-08-10 で、2021-08-16 13:00:00 が 仮想現在時刻 だとします。この時、2021-08-14 の 日毎グラフ で 12 時のデータポイントにデータが確認されると、2021-08-11, 2021-08-12, 2021-08-13 の 日毎グラフ が全て 完成したグラフ とみなされます。

チェックが実施された 日毎グラフ が 2021-08-14 であるため、2021-08-14, 2021-08-15, 2021-08-16 の 日毎グラフ は、 完成したグラフ とはみなされません。
2021-08-11 から 2021-08-13 までの 日毎グラフ で更新が遅延している状況だとしても、2021-08-14 のチェックで 完成したグラフ とみなされます。また、仮想時間は 日毎グラフ が更新されているかどうかにかかわらず経過します。


負荷走行時における減点、即時失敗（fail）について

下記のエラーは減点や即時失敗（fail）となります。fail となった場合スコアは 0 点となります。


初期化処理、アプリケーション互換性チェックに失敗した

1 回以上で fail


HTTP ステータスコードやレスポンス内容などに誤りがある

1 回あたり減点 1 点
100 回の失敗時点で fail


リクエストがタイムアウトした場合（タイムアウトについて）

10 回あたり減点 1 点
fail は発生しない


ただし、POST /api/condition/:jia_isu_uuid は上記の場合でも一切の減点や fail は発生しません。
また、負荷走行終了時点で処理が打ち切られたリクエストやレスポンスでは減点は発生しません。
最終スコア

競技終了後、主催者は 全サーバーの再起動後に負荷走行を実施 します。その際のスコアを最終スコアとします。
追試

最終スコアが確定後、主催者による確認作業（追試）を行います。下記の点が確認できなかった場合は fail となります。

負荷走行実行時にアプリケーションに書き込まれたデータはサーバー再起動後にも取得できること
アプリケーションはブラウザ上での挙動を初期状態と同様に保っていること

その他

POST /initialize での実装言語の出力

POST /initialize レスポンスにて、本競技で利用した言語を出力してください。参考実装はそのようになっています。この情報は集計し ISUCON 公式Blog での公表や、参考情報として利用させていただきます。
POST /initialize のレスポンスは以下のような JSON となります。
{
    "language": "実装言語"
}
language の値が実装に利用した言語となります。 language が空の場合は初期化処理が失敗と見なされます。
禁止事項

以下の行為を特に禁止する。

競技終了時間までに、競技の内容に関するあらゆる事項（問題内容・計測ツールの計測方法など）を公開・共有すること（内容を推察できる発言も含む）

不特定多数への公開はもちろん、他チームの選手と連絡を取り、問題内容等を共有する事（結託行為）も禁止とする。
ただし主催者が Twitter, Web サイトにおいて公開している情報は除く。ポータルでログインを要するページ（選手が参加する Discord を含む）において記載されている内容は公開情報でない旨留意すること


競技時間中、チーム外の人物と ISUCON11 問題にまつわる事項のやりとり（ISUCON11 選手であるかどうかを問わない、SNS での発言も含む）
主催者の指示以外で利用が認められたサーバー以外の外部リソースを使用する行為（他のインスタンスに処理を委譲するなど) は禁止する。

ただしモニタリングやテスト、開発などにおいては、PC や外部のサーバーを利用しても構わない。


選手が主催者からその選手が属するチームへ提供されていないサーバーについて直接のアクセスを試みる行為や、外部への不正アクセスを試みる行為。具体的にはベンチマーカーへのログイン試行等。（なお、例示のため、これに限らない）
他チームと結託する行為（程度を問わず）
主催者が他チームへの妨害、競技への支障となるとみなす全ての行為

本マニュアルやレギュレーション、ポータルにおいて禁止とされた行為（禁止事項）への違反は、失格となる。
	得点	条件
Good	60	20 < n
Normal	40	10 < n <= 20
Bad	24	5 < n <= 10
Worst	4	0 <= n <= 5