DevOps Days Amsterdamの2日目、YelpのSam Eaton氏が、予測可能性を高めてコミュニティの意識と共同作業を助けるには、組織内における信頼が重要であると語った。DevOpsが組織で成功するためには、アクティビティに直接関わる個人やチームを超えて、信頼をスケールする必要がある。だが信頼をスケールするのは難しい。なぜなら、MonkeySphere（ダンバー数とも言われる）現象のため、関係を保てる仲間の人数には限界があるためだ。
開発と運用との間に信頼を築くには、よくある衝突誘因（アプリケーションの安定性 vs. デリバリの機能性）をうまく調整する必要があるだろう。これに対し、マネジメントレベルの信頼は、DevOpsがビジネスにもたらす価値を示すことで高まるはずだ。
信頼を築くためには、常にコミットメントを果たし、双方のオープンで誠実なコミュニケーションを確立する必要があるとSam氏は指摘する。信頼が構築できていれば、これまでの信頼に基づいて、例外的要求（たとえば、機能デリバリーを一時的に遅らせて技術的負債の支払いに取り組むという技術要求や、強い顧客要求に対して緊急で変更をデリバリーするというビジネス要求）を受け入れやすくなる。
他のチームからの尊敬を得るためには、常にビジネス視点で変化を評価し、人と付き合うときには冪等性を示し（相手によってばらばらな対応をする人は信頼するのが難しい）、不変性（変化は制御され自動化されたもののみとする）のために努力する必要があると、Sam氏は提案する。
継続的インテグレーションやデリバリーパイプラインといったテクニックは、プロセス上の失敗を早期に明らかにし、なされた変化を可視化することで、チーム間の信頼を促すだろう。これは失敗を予測し、協調作業環境を改善するのに役立つ。デリバリーフローの後になって、機能不全を非難するようなカルチャーをもたらすことはない。
規約というのも信頼の欠如に対処するもう1つのテクニックだ。組織内部で規約を作ることは、お互いに信頼しなくてはならないことを教えるのに役立つ。Sam氏は例として、開発者がコードをプロダクション環境に自動デプロイするために従うアプリケーションインフラストラクチャ規約をあげた。
Sam氏が提案している信頼をスケールするためのレシピには、以下が含まれる。
- 開発とテストのためのプロダクションライクな環境（プロダクションデータおよびトラフィックのレプリカを含む）を用意する
- MTBFの代わりにMTTRにフォーカスする
- ほかのチームを含む頻繁なふりかえりをする
- チーム間のフローの評価と重複したアクティビティ（不信のサイン）を取り除く
- 事前に定義した期待に対するパフォーマンスを監視する
- Wiki、チャット、デリバリープロセスの全アクティビティ（コミット、デプロイ、テスト結果など）のメッセージキューなどを利用し、透明性を高め、知識を共有する
カンファレンスのライブストリーミングと彼のスライドを見てみよう。