Airbnb、文化の問題ではなくツールとワークフローのギャップと判明しアラート開発を再構築
Airbnbは、監視アラートの開発と検証方法を再構築することで観測可能性を大幅に改善し、当初「文化の問題」と思われていた課題が実際にはツールとワークフローのギャップであったと結論付けた。
キーポイント
問題認識の転換
Airbnbは、監視アラートの問題が「文化の問題」ではなく、ツールとワークフローのギャップであることを発見した。
アラート開発の再構築
アラートの開発と検証方法を根本的に見直し、再構築することで、観測可能性の実践を大幅に改善した。
実践的改善の重要性
組織的な課題を解決するには、文化面だけでなく、具体的なツールとプロセスの改善が不可欠であることを示している。
影響分析・編集コメントを表示
影響分析
この記事は、大規模なテック企業が組織的な課題を解決する際に、表面的な「文化問題」に帰するのではなく、具体的なツールとワークフローの改善に焦点を当てる重要性を示している。特にDevOpsやサイト信頼性エンジニアリングの分野で、実践的な改善方法の参考事例として価値がある。
編集コメント
「文化の問題」という抽象的なレッテル貼りではなく、具体的なツールとプロセスに着目したAirbnbのアプローチは、多くのテック企業にとって参考になる実践的なケーススタディです。
Airbnb は、アラートの開発と検証のあり方を再考することで観測可能性（observability）の実践を大幅に改善したことを明らかにしました。その結果、「文化の問題」のように見えた課題は、実際にはツールやワークフローの欠落によるものだったことが判明しました。同社は「コードとしての観測可能性（Observability as Code: OaC）」のアプローチを再設計し、アラート開発サイクルを数週間から数分に短縮し、アラートのノイズを劇的に削減するとともに、数十万個のアラートを新しいプラットフォームへ移行可能にしました。
この問題の核心は、単純な洞察にあります。エンジニアが不適切なアラートを作成するのは規律不足のためではなく、デプロイ前にアラートがどのように動作するかを確認できなかったからです。数千ものサービスを支える約 30 万件のアラートを支えるため、Airbnb は OaC を活用して構造化と一貫性を実現していました。しかし、コードレビューでは文法やロジックの妥当性は検証されても、実際の運用環境での挙動までは捉えきれていませんでした。
そのため、エンジニアはアラートがノイズを発生させるか、インシデントを見逃すか、あるいはオンコールチームに不必要な通知を送るかを容易に判断できませんでした。その結果、本番環境がテストの場となり、チームは「アラートを改善して不安定化リスクを負う」か「信号品質の低さを我慢する」かの二者択一を迫られました。時間が経つにつれ、これによりアラート疲労が生じ、信頼性が低下し、イテレーション速度も鈍化しました。
根本的な原因は、迅速なフィードバックループの欠如でした。デプロイ前に実際のデータに対してアラートを検証する能力がなかったため、チームは遅く手動のプロセスに頼り、変更をデプロイして数日または数週間待ってから反復するという方法をとっていました。このアプローチはスケーラビリティにおいて非現実的であり、特に数千のサービスを管理する場合や、既存のツールがダウンサンプルされたデータへの依存や手動検証に頼っていたために限定的なサポートしか提供できない状況ではなおさらでした。
Airbnb はこれを解決するため、デプロイ前にアラートの挙動を可視化できるように観測性プラットフォームを再構築しました。新しいアプローチは迅速なフィードバックループを導入し、エンジニアが変更をマージする前に実際のデータを使用してアラートの挙動をプレビューできるようになりました。ローカル差分、デプロイ前の検証、大規模なバックテストといった機能により、チームは数週間ではなく数秒でアラートをテストすることが可能になりました。
ライフサイクルの初期段階に検証をシフトさせることで、Airbnb はアラートテストを生産環境から開発ワークフローへ移行し、観測性を現代的なソフトウェアエンジニアリングプラクティスと整合させました。その結果は顕著で、アラート開発サイクルが数分に短縮され、アラートのノイズは最大 90% 削減されました。これによりシステムへの信頼が回復しました。
これらの改善は、Airbnb が約 300,000 のアラートを Prometheus へ大規模に移行するプロジェクトを完了させるために不可欠でした。これは以前の手法では極めて困難であったはずです。
これらの変更は、Airbnb の「ゼロタッチ」観測可能性というより広範なビジョンも支えるものであり、チームが共有プラットフォームを採用する際に、高品質なアラート、ダッシュボード、サービスレベル目標（SLO: Service-Level Objectives）を自動的に継承できる仕組みです。このモデルでは、プラットフォームチームがベストプラクティスを再利用可能なテンプレートに組み込むことが可能になりますが、そのためにはこれらのテンプレートが大規模環境でも正しく動作するという確信が必要です。
Airbnb の経験は、エンジニアリング組織全体にとってより広範な教訓を示しています。一見すると文化の問題に見える課題の多くは、実際にはシステム全体の構造的問題である場合が多いのです。今回のケースでは、アラート疲労やモニタリングの一貫性の欠如は、不適切な慣行によるものではなく、開発ワークフローにおけるギャップに起因していました。
ツールとフィードバックループを改善したことで、Airbnb は技術的な成果を向上させるだけでなく、エンジニアの行動そのものも変えました。開発者はより積極的に反復作業を行うようになり、プラットフォームチームは標準を安全に進化させることが可能となり、結果として観測可能性全体の品質が向上しました。
究極的に、この物語は観測可能性を「開発者体験」の課題として再定義するものです。CI/CD パイプラインがコードに対して迅速なフィードバックを提供するように、観測可能性システムもモニタリングに対して同様の役割を果たさなければなりません。Airbnb のアプローチは、エンジニアが変更を早期に検証できる場合、より速く動き、より良い意思決定を行い、より信頼性の高いシステムを構築できることを示しています。これは、大規模な環境においては、人々を変えることよりもシステム自体を改善することが重要であることを証明するものです。
大規模なエンジニアリング組織の多くは、検証を左側へシフトし、自動化と標準化を通じて信号の質を改善することに注力することで、同様のアラート課題に取り組んできました。例えば Google では、Site Reliability Engineering (SRE) 慣行の採用により、Service Level Objectives (SLOs) とエラーバジェットがアラートの基盤として強く重視されるようになりました。あらゆる可能な障害条件に対してアラートを作成するのではなく、チームは SLO の違反に関連するユーザーに影響を与える信号に基づいてアラートを定義します。このアプローチは、アラートが意味があり実行可能であることを保証することでノイズを削減し、オンコールエンジニアに影響を与える前にアラートの有効性を検証するためのより明確な枠組みも提供します。
同様に、Netflix は自動化とリアルタイムの観測ツールリングを通じてこの問題に取り組んでおり、障害条件下でシステムの動作をシミュレーションおよびテストできるプラットフォームに多大な投資を行っています。チャオスエンジニアリング慣行と観測を組み合わせることで、チームは制御された障害中にアラートが適切にトリガーされるかどうかを検証でき、実際のインシデントが発生する前に効果的にアラートの挙動をテストできます。
Datadog や Prometheus のようなプラットフォームを利用する他の組織も、アラート設定への信頼性を高めるために、アラートのプレビュー機能や異常検知、歴史的なバックテストなどの機能を導入しています。これらのアプローチ全体に共通する明確なテーマは、アラートの品質向上がより厳格なプロセスの強制よりも、エンジニアにより良い可視性、迅速なフィードバック、そしてボリュームではなく意味のあるシグナルを優先するシステムを提供することに重点を置いている点です。
著者について
Craig Risi
Craig Risi は多才な人物ですが、その才能をどう活用すべきかという感覚に欠けています。世界を変える活動に出ることも可能ですが、彼はむしろソフトウェアを作ることを好みます。彼はソフトウェアデザインへの情熱を持っていますが、それ以上に、技術的に多様で絶えず進化し続けるテクノロジーの世界において、システム設計におけるソフトウェアの品質に情熱を注いでいます。
Craig はまた、『Quality By Design: Designing Quality Software Systems』という書籍の著者であり、自身のブログサイトや世界各地のさまざまなテックサイトで定期的に記事を執筆しています。
ソフトウェアに触れている時間以外では、文章を書くこと、ボードゲームをデザインすること、あるいは特に理由もなく長距離を走る姿をよく見かけます。
原文を表示
Airbnb has revealed how it significantly improved its observability practices by rethinking how alerts are developed and validated, concluding that what appeared to be a "culture problem" was actually a tooling and workflow gap. By redesigning its Observability as Code (OaC) approach, the company reduced alert development cycles from weeks to minutes, cut alert noise dramatically, and enabled the migration of hundreds of thousands of alerts to a new platform.
At the core of the issue was a simple insight: engineers were not creating poor alerts due to a lack of discipline, but because they could not see how alerts would behave before deploying them. With around 300,000 alerts supporting thousands of services, Airbnb relied on OaC to bring structure and consistency. However, while code reviews validated syntax and logic, they failed to capture real-world behavior.
This meant engineers could not easily determine whether alerts would generate noise, miss incidents, or unnecessarily wake on-call teams. As a result, production became the testing ground, forcing teams into a tradeoff between improving alerts and risking instability, or tolerating poor signal quality. Over time, this led to alert fatigue, reduced trust, and slower iteration.
The root cause was a lack of fast feedback loops. Without the ability to validate alerts against real data before deployment, teams relied on slow, manual processes, often deploying changes, waiting days or weeks, and then iterating. This approach was impractical at scale, especially when managing thousands of services, and existing tools provided limited support due to reliance on downsampled data or manual validation.
Airbnb addressed this by rebuilding its observability platform to make alert behavior visible before deployment. The new approach introduced fast feedback loops, allowing engineers to preview alert behavior using real-world data prior to merging changes. Capabilities such as local diffs, pre-deployment validation, and large-scale backtesting enabled teams to test alerts in seconds rather than weeks.
By shifting validation earlier in the lifecycle, Airbnb moved alert testing out of production and into development workflows, aligning observability with modern software engineering practices. The results were significant: alert development cycles dropped to minutes, and alert noise was reduced by up to 90 percent, restoring trust in the system.
These improvements were critical to enabling Airbnb to complete a large-scale migration of approximately 300,000 alerts to Prometheus, which would have been extremely difficult under the previous approach.
The changes also support Airbnb's broader vision of "zero-touch" observability, in which teams automatically inherit high-quality alerts, dashboards, and service-level objectives when adopting shared platforms. This model allows platform teams to encode best practices into reusable templates, though it depends on having confidence that those templates behave correctly at scale.
Airbnb's experience highlights a broader lesson for engineering organizations: problems that appear cultural are often systemic. In this case, alert fatigue and inconsistent monitoring were driven not by poor practices but by gaps in the development workflow.
By improving tooling and feedback loops, Airbnb not only enhanced technical outcomes but also changed engineering behavior. Developers became more willing to iterate, platform teams could safely evolve standards, and overall observability quality improved.
Ultimately, the story reframes observability as a developer experience challenge. Just as CI/CD pipelines provide rapid feedback for code, observability systems must do the same for monitoring. Airbnb's approach shows that when engineers can validate changes early, they move faster, make better decisions, and build more reliable systems, proving that at scale, fixing the system matters more than fixing the people.
Other large-scale engineering organizations have tackled similar alerting challenges by focusing on shifting validation left and improving signal quality through automation and standardization. At Google, for example, the adoption of Site Reliability Engineering (SRE) practices led to a strong emphasis on Service Level Objectives (SLOs) and error budgets as the foundation for alerting. Rather than creating alerts for every possible failure condition, teams define alerts based on user-impacting signals tied to SLO breaches. This approach reduces noise by ensuring alerts are meaningful and actionable, while also providing a clearer framework for validating alert effectiveness before they impact on-call engineers.
Similarly, Netflix has approached the problem through automation and real-time observability tooling, investing heavily in platforms that allow engineers to simulate and test system behavior under failure conditions. By combining chaos engineering practices with observability, teams can validate whether alerts trigger appropriately during controlled failures, effectively testing alert behavior before real incidents occur.
Other organizations using platforms like Datadog or Prometheus have also introduced features such as alert previews, anomaly detection, and historical backtesting to improve confidence in alert configurations. Across these approaches, the common theme is clear: improving alert quality is less about enforcing stricter processes and more about giving engineers better visibility, faster feedback, and systems that prioritize meaningful signals over volume.
About the Author
Craig Risi
Craig Risi is a man of many talents but has no sense of how to use them. He could be out changing the world but prefers to make software instead. He possesses a passion for software design, but more importantly software quality and designing systems in a technically diverse and constantly evolving tech world.
Craig is also the writer of the book, Quality By Design: Designing Quality Software Systems, and writes regular articles on his blog sites and various other tech sites around the world.
When not playing with software, he can often be found writing, designing board games, or running long distances for no apparent reason.
Show moreShow less
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み