## 定義 オペラビリティ（Operability）は、システムが本番環境で安全かつ効率的に運用可能であるという性質である。可用性・信頼性と密接に関連するが、より広く「運用チームがシステムの状態を理解し、障害に対処し、変更を安全に適用できること」を指す。 [[Adrian Colyer]] は 400 本以上の研究論文の横断レビューに基づき、オペラビリティが 4 段階の連鎖で構成されることを示した（[[@2016__blog.acolyer__The Morning Paper on Operability]]）: 1. **運用性のための設計**: 設計段階で運用性を組み込む。Hamilton の知見「運用上の問題の 80% は設計と開発に起因する」が核心 2. **システム挙動の理解**: トレーシング・プロファイリングによる可視化（Dapper、Mystery Machine、Gorilla） 3. **根本原因の分離**: デバッギング技法による障害の絞り込み（Failure Sketching、Delta Debugging、HDD、DEMi） 4. **開発へのフィードバック統合**: 運用データの開発ワークフローへの組み込み（FDD） ## 横断的知見 - Hamilton (LISA '07) の「運用上の問題の 80% は設計と開発に起因する」という知見は、Google SRE Book (2016) の「開発と運用の責任共有」や DevOps の文化的原則と整合する。設計段階への運用性組み込みという主張は、Cook の「How Complex Systems Fail」（[[@1998__CtL__How Complex Systems Fail]]）が示す「複雑なシステムは必然的に劣化モードで運用される」という観察の実践的対策でもある（Source: [[@2016__blog.acolyer__The Morning Paper on Operability]]） - Colyer の 4 段階モデル（設計→可視化→デバッギング→フィードバック）は、[[SRE]] の実践体系（設計レビュー → モニタリング → インシデント対応 → ポストモーテム）と構造的に対応する。特に第 4 段階（FDD）はポストモーテムの知見を開発プロセスに還元するフィードバックループの自動化に相当する（Source: [[@2016__blog.acolyer__The Morning Paper on Operability]], [[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]]） - 根本原因分離の段階では、テスト可能な障害（[[デルタデバッギング]]、[[階層的デルタデバッギング]]、[[分散実行最小化]]）と本番でしか再現できない障害（[[障害スケッチング]]）が相補的に位置づけられる。前者は入力空間の探索、後者は実行時状態の協調観測という異なる戦略をとる（Source: [[@2016__blog.acolyer__The Morning Paper on Operability]]） ## 未解決の問い - Colyer の 4 段階モデルは 2016 年時点の知見に基づく。コンテナ/Kubernetes、マイクロサービス、LLM ベースのシステムにおけるオペラビリティの新たな課題（構成爆発、非決定論的挙動、エージェントベースの運用）はこのモデルにどう統合されるか - 設計段階への運用性組み込みを形式化する方法論は依然として確立されていない。Hamilton の原則は経験則であり、定量的な設計指標やチェックリストへの体系化は未完 - 「フィードバックの閉ループ」が実際にどの程度のラグで開発に還元されるか。FDD のビジョン（IDE 統合）は 2015 年時点で概念実証にとどまり、大規模本番での実装事例は限定的 ## 関連 - [[SRE]] — オペラビリティの実践体系としての Site Reliability Engineering - [[オブザーバビリティ]] — 4 段階モデルの第 2 段階に対応 - [[デルタデバッギング]] / [[障害スケッチング]] — 第 3 段階の根本原因分離手法 - [[フィードバック駆動開発]] — 第 4 段階のフィードバック統合 ## 出典 - [[@2016__blog.acolyer__The Morning Paper on Operability]]