DevOps: ボトムアップで信頼性を構築する方法

DevOps が失敗する理由は数多くあります。 すべての革命的なアイデアにとって、
開発と運用を協調させる文化的なシフトが必要です。多くの企業、特に大企業は、トップダウンのアプローチをとっています。C レベルの役員は、斬新的な DevOps のイニシアティブをもてはやしますが、
他の人々は抵抗するか、骨抜きにするか、無視します。
SaaS 企業の開発者である私の成功は運用にかかっています。開発と運用が不信によって分離され、
リリースの際に、両者の間に話し合いがないケースが多すぎます。こうしたギャップを埋めるには、ステータスや互いに異なるインセンティブの違いから発生する、緊張の下でも会話できる方法を見つけることが必要です。
ここに、あまりに多く見てきた例があります。プロジェクトが遅れ始め、開発は運用機能をないがしろにし、
最初の展開は壮大な失敗に終わります。開発は運用を非難し、運用は開発を非難し、CEO が仲裁に呼ばれます。通常、開発は CEO と緊密ですが、
運用だけが責任を負わされても、将来の関係には役立ちません。
根の深い相互不信があるため、開発と運用が協力できるためのキーが信頼であることは、明らかなようです。たとえ反対が真実でないとしても、個々の貢献者の間での信頼によって、

より上位の不信を克服することができます。CIO とエンジニアリング責任者の間での偉大な関係は、
必ずしも DevOps の成功を保証しません。それが、私が DevOps をボトムアップで始めるべきと考える理由です。理想的な開始ポイントは、大きなビジネス価値を生む短期のプロジェクトであり、
これが成功しない限り低収益となるプロジェクトです。
私が試みたあるアプローチは、開発のリーダーに運用からの大使を私のチームに指名させることでした。(まだ、SFPD に駐車違反切符を
見逃させようとしているようなものです。) 運用からの大使は、毎週の計画ミーティングに出席し、毎日発言します。これが、全体論的な思考を吹き込みます。
影響を受ける人々が部屋にいれば、開発側は運用においてバグを確認することの難しさを考慮するようになり、
運用側は特定の妥協がなぜなされたかについて、よりよく理解できるようになります。最近では、運用の大使が、スパムの少ないログシステムの設計を手伝うようになっています。
顧客の危機が発生したとき、ログを詳細に調べて、問題をより迅速に見つけることができるようになったのです。
たしかに、多くの人が、人の問題より、技術の問題で、DevOps が失敗していると言っています。私は、より良いテストの自動化や、継続的な統合なしでは、
DevOps は不可能であると頻繁に聞きます。たしかに、こうしたテクノロジーはより高い品質の機能をより迅速に構築するのに役立ちますが、
必然的にバグが発生したときに問題を解決することはできないのです。運用を開発における信頼できるパートナーとして迎えることで、機能フラグやログなどの一見刺激的ではないアイテムを、
単なる後知恵から、設計の不可欠の要素に高めることができるのです。
もちろん、信頼の価値は、単なる開発と運用の問題を超えます。たとえば開発対営業や、開発対サポートなどの、
不信のペアが多くのソフトウェア企業を苦しめています。AppDynamics の強みの一つは、こうした境界を超えるコラボレーションの深さです。我々は、DevOps を超えて、
顧客の DevOpsDocSupportSales に焦点を当てるように奨励しています。より後の段階で DevOps を適用することに同じ考えを持つ同僚は多くはありませんが、
ここで BizDevOps に関するアイデアをぜひ読んでみてください。