アプリケーション開発者にとって、大規模なインフラストラクチャ プラットフォーム チームと一緒に作業することは、ある日には幸運にも災いにもなり得ます。 そのチームが、管理されたセルフサービス モデルでインフラストラクチャ、ネットワーク、セキュリティ サービスを提供し、開発者がインフラストラクチャを管理する手間から解放されるのは、本当にありがたいことです。 それに比べて、インフラストラクチャ チームの主な成果物が 1 週間に及ぶバックログと引き継ぎの回転ドアである場合、アプリ開発者は呪われていると感じるかもしれません。
問題は、後者の場合何ができるかということです。 率直に言って、期待されるペースで生産する能力を制限している、遅くて扱いにくいインフラストラクチャ チームにはどのように対処しますか?
もちろん、その答えは紛争そのものと同じくらい古いものです。 まず全体像に対する理解を深め、適度な共感力を加え、相互尊重と共通の目標の雰囲気の中ですべてを仕上げましょう。 (平和賞の受け取り場所を教えてください。)
まあ、それほど単純ではないかもしれませんが、この計画は出発点としては最適です。
アプリ開発者は通常、いくつかの動かせない(または動かしにくい)制約に縛られています。 エンタープライズ インフラストラクチャ、ポリシー、セキュリティの必要性、監査要件はすべて重要なビジネス上の考慮事項であり、したがって重要なアプリケーション上の考慮事項でもあります。 しかし、多くの組織では、これらの重要な要素を担当する NetOps チームと SecOps チームの動きがDevOps チームよりも遅いことが多く、これが摩擦を生み出しています。
ある意味、NetOps が DevOps よりも遅いと言うのは、リンゴとミカンを比較するようなものです。 過去数年間で、DevOps 業界は劇的な変化を遂げ、よりアジャイルなワークフローを採用し、あらゆる場面で自動化を取り入れるようになりました。 一方、NetOps は現在、独自の自動化ツール セットにアクセスできるようになっています。 その結果、多くの組織は、速度と生産性のさらなる大幅な向上(今回はインフラストラクチャ サービス)に備えることができますが、そのためには、NetOps チームが新しいネットワーク自動化ツールを活用できるようにスキルを進化させる必要があります。
DevOps が NetOps よりもずっと長い間、自動化ツールにアクセスしてきたという事実は、2 つのグループ間の重要な違いです。 しかし、DevOps チームがインフラストラクチャ チームについて知っておくべき点は、この違いだけではありません。
ここでは、NetOps について知っておくべき (または場合によっては覚えておくべき) 5 つの推奨事項を示します。
ご存知のとおり、自動化はより迅速な展開の鍵となります。 NetOps の同僚が同じ認識を持つように作業します。 アプリ開発ライフサイクルにおける自動化の価値について必ず話し、自動化がワークフローにどのようなメリットをもたらすかを検討するよう促してください。 異なるチーム間の相互交流を促進するプログラムやイベントは、この共通の焦点を明らかにするのに役立ちます。 F5 では、従来は関連のなかった部門をまたいでランチ アンド ラーニング セッションを開催することで、大きな成果を上げています。
さらに、F5 は、さまざまな無料のオンライン Super-NetOps コースを通じて、ネットワーク プロフェッショナルが自動化に向けて一歩を踏み出し、スキルを向上できるよう支援します。 この Super-NetOps プログラムは、ネットワーク運用の専門家が重要なアプリケーション サービスを標準化するために必要なスキルを習得し、自動化されたツールチェーンを効果的に活用する能力を身に付けるのに役立ちます。 自動化ツールチェーン ところで、これによりサービスまでの時間が短縮される 数日から数分へ—同時に、 全て アプリケーションは必要なコンプライアンス、ポリシー、およびパフォーマンス基準を満たしています。
自動化の強化やセルフサービス インフラストラクチャなどのトピックについて同僚と話し合うときは、全員が同じ成果を目指して取り組んでいることを念頭に置いてください。 チーム間に摩擦があったり、あるチームのペースが他のチームよりも遅かったりすると、同僚が敵であり、最終的な成功の妨げになっていると考えてしまいがちです。 実際には、摩擦が排除され(または少なくとも大幅に軽減され)、すべての部門が他の部門をサポートしながら前進することで、持続可能な成功が達成されます。