Airbnbは、内部のExperiment Guardrailsシステムを展開して、さまざまなチーム間での変更による潜在的な悪影響を特定した。提案された変更がガードレールを通過しない場合は常に、影響を受けるチームと利害関係者によるさらなる分析のためにエスカレーションされる。このように、AirbnbのデータサイエンティストのTatiana Xifara氏は説明する。
Airbnb Guardrailsシステムは、チームが本番環境に対してある変更を行うことを防ぐことを目的としている。その変更とは、チーム自体のメトリックを改善する一方で、Airbnbの他のチームに関連するさまざまなメトリックに悪影響を与える可能性があるものである。これは、各チームが特定の目標セット（不正の検出、顧客満足度、全体的な収益など）に焦点を合わせ、変更によるチーム間のトレードオフが明確であるとは限らない大規模な組織に典型的なシナリオである。
現在のところ、Xifaraは次の通り説明している。Airbnb Guardrailsシステムには、提案された変更の影響についてのさまざまな統計的側面を説明する3つのガードレールが含まれている。影響、パワー、統計的に有意な負の値（略してstat sig negative）の3つである。
簡単に言うと、影響ガードレールは、メトリックがパーセントで特定のエスカレーションしきい値tを下回らないようにするものである。パワーガードレールは、実験の結果が統計的に有意になるように、実験を十分に長く実行することを目的としている。これは、標準誤差に対してtに対するFの割合が指定未満であることが要求される（例えば、StdErr < 0.8 * t）。最後に、stat sig negativeガードレールを使用して、特定のメトリックに対する統計的に有意な負の影響を、たとえ、その影響が小さくても、エスカレーションされる。このガードレールは、収益などの特に機密性の高いメトリックに対してより高い保証を提供する。このメトリックでは、わずかな減少でも大きな影響が生じる可能性がある。
Airbnb Guardrailsシステムでは、いくつかの任意の定数に基づいてそのパフォーマンスが決まる。それらのうちの2つは、エスカレーションしきい値tとパワーガードレールによって使用されるtに対するFの割合である。
tは、適用されるメトリック、たとえばページの読み込み時間に直接関係するため、理解しやすい。一方で、Fにはさらなる考慮が必要である。Fに低い値を選択した場合は、より多くのユーザに公開されるように、実験をより長く実行する必要がある。これにより、実験を実行するのが現実的でなくなったり、開発速度に悪影響を及ぼしたりする可能性がある。
調査すべきもう1つの側面は、すべての実験が同じグローバルカバレッジを持つわけではないという事実である。これは、実験に割り当てられたユーザの割合である。したがって、同じパワーガードレールを通過する必要がある場合、カバレッジの低い実験は、カバレッジの高い実験よりも長く実行する必要がある。すべての実験を同じ時間で完了するには、エスカレーションしきい値tをグローバルカバレッジの関数として定義し、カバレッジが小さいほどtを高くすることができる。
Xifaraによると、Airbnb Guardrailsシステムは月に約25回の実験にフラグを立てる。エスカレーションとレビューの結果、それらの約20％、つまり5つが最終的が中止になる。重要なのは、すべての定数を選択して、メトリックの保護と開発の速度のバランスをとることである。
言うまでもなく、Guardrailsシステムは特定のメトリックの集合に制限されるものではない。各組織には常に監視するための独自のメトリックのセットがある。Xifara氏とAndersen氏の記事には、ここで説明できる情報よりもはるかに多くの情報が書かれているため、詳細に興味がある場合はお見逃しなく。