DevOps は配信で終わらない
デプロイメントによってリリースが遅れる場合、どれだけ速く提供できるかは関係ありません。 NetOps は自動化とオーケストレーションに積極的に取り組んでいますが、展開をスピードアップするための取り組みには大きな課題が伴います。 DevOps は、それを実現するのに最適な立場にあります。
デジタルトランスフォーメーションとはDevOpsを意味する
デジタルトランスフォーメーションと DevOps の間には議論の余地なく関連があります。 DX により、48% の組織がアプリをより頻繁に本番環境に配信するようになっています。 62% が IT システムとプロセスの自動化とオーケストレーションを行っています。 52% がアプリの開発方法を変更しています (アジャイルを検討)。 また、42% がコンテナとマイクロサービスを検討しています。 アプリケーションの構成要素そのものから、それを市場に投入するための方法に至るまで、デジタル変革とは、DevOps が「継続的デリバリー」を「継続的デプロイメント」に拡張する方法を持っていることを意味します。 覚えておいてください、「配信」は市場への提供を意味するのではなく、デプロイメント プロセスが開始され、アプリケーションが使用に適した状態になる本番環境への提供を意味します。
「消費に適している」というのは、単に「アプリが正常に動作している」という意味ではないからです。 これには、アプリケーション サービスの形式で実装および展開する必要がある一連の要件が含まれます。 アプリケーションが「使用に適している」と判断されるには、スケール、セキュリティ、パフォーマンス、監視など、すべてが整備されている必要があります。 それが今日の「展開パイプライン」を構成するものです。
自動化とオーケストレーションの約束を実現するには、デプロイメントに DevOps が必要です。
残念ながら、配信と展開の自動化の状態をあまりにも正確に描写したものは、ジョージ・ジェットソンとフレッド・フリントストーンとのスキー旅行です。 前者は未来から来たのでジェットエンジン付きのスキーに乗っていますが、フレッドは過去に生きており、手動のスキーに乗っています。 ロケットエンジンのスキーに乗ったジョージ・ジェットソンが、継続的な配信を行う DevOps だと推測したなら、その通りです。 また、NetOps が主に手動の方法で継続的な展開を行おうとしていると推測した場合も、その通りです。
NetOps は、今日の組織で使用されている平均 14 個のアプリケーション サービスのプロビジョニング、展開、および運用を担当する人々です。 これには、スケーラビリティ (負荷分散とイングレス制御) からセキュリティ (Web アプリケーション ファイアウォールとボット防御)、アプリケーションをサポートするスタック全体のパフォーマンスを向上させるあまり知られていないサービスまで、あらゆるものが含まれます。
現在、彼らはより速く動くのに役立つスキーを手に入れましたが、DevOps の同僚のようなロケット支援スキーはまだ備えていません。
パイプライン自動化の不均衡はイライラさせる遅延につながる可能性がある
「継続的な展開」を実現するために必要なさまざまなアプリケーション サービス コンポーネントの自動化率の不一致は、大多数の組織で依然として使用されている手動の方法につながる「不均衡な力」を排除する必要があることを示しています。 これは、自動化されたゼロ展開コンポーネントを持つ組織に特に当てはまります。 これがロケットアシストスキーと従来のスキーの違いです。 パイプラインの一部を自動化できた組織でも、一貫して自動化できているわけではありません。4 つの主要コンポーネントすべてを自動化できた組織はわずか 21% です。 11% は 1 つの領域のみを自動化し、25% は 2 つの領域を自動化しました。
飛行中に突然スキーのロケットが消えたと想像してください。
展開をスピードアップするために、従来の「問題解決に人員を増やす」という解決策に頼ることはもうできません。 これにより、生産拠点への配送と消費者への配送の間にさらに多くの通信レイヤーとプロセスの落とし穴が追加され、遅延がさらに悪化することになります。
こうした遅延により、企業は待たされるだけでなく、時間を補うためにセキュリティなどの手順を省略しなければならないため、不満を募らせます。 これを修正するには、継続的なデプロイメントを遅らせる「不均衡な力」を見つけて対処する必要があります。
これらの「不均衡な力」とは何でしょうか。また、それらのバランスを取り戻すために DevOps は何ができるでしょうか。
展開における不均衡な力は、NetOps が挙げた課題の中に見ることができます。 スキル、ポリシー、予算、統合は、継続的なデプロイメントを実現する上で大きな障害となります。 誤解しないでください。NetOps はスクリプトを作成できますし、常にスクリプトを作成しています。 しかし、スクリプトは自動化ではないため、潜在的に 14 種類の異なるデバイス、システム、サービスにわたる統合の必要性には対応していません。 NetOps では、これらの異なるシステム間の統合を可能にするだけでなく、一貫性があり、予測可能で、繰り返し可能な方法で展開プロセスを推進するツールと方法論を特定し、実践するための支援が必要です。
ここで、DevOps は NetOps が継続的なデプロイメント プラクティスを成功させるのに役立ちます。
コラボレーションはITと開発の境界を越えなければならない
文化は選択できるものではありません。 それは行動や実践に非常に現実的な影響を及ぼします。 チーム構造だけでもパイプラインの自動化は劇的に変化し、従来の単一機能のチームは、現代の DevOps 主導のチームに遅れをとることになります。 より協力的なチーム構造を推進します。 同様に、共同作業チームは主要な指標に基づいて調整する必要があります。 共有メトリックにより、NetOps とセキュリティはペナルティなしで継続的な展開に取り組むことができます。 現在、NetOps のほぼ 4 分の 3 がネットワーク稼働時間で測定されています。 展開の頻度はほとんど認識されません。 彼らはネットワークの維持に注力するつもりです。なぜなら、それが彼らが注力しなければならないことだからです。 共有メトリックにより、NetOps はビジネスのニーズ、つまりより高速で頻繁な展開に集中できるようになります。
最後に、共感が必要です。 皆さんは同じチームに所属しており、驚くかもしれませんが、同じものを大切にしています。 NetOps は、DevOps と同様にパイプラインの自動化を非常に重視する可能性があります。 覚えておいてください。DevOps は、統合、ツール、スキルセットに関する障害の回避と克服において、NetOps よりも 10 年先行しています。 共同チームは、配信からデプロイメントまでをカバーするツール (Jenkins や GitHub/GitLab など) の標準化を推進することで役立ちます。
ランチ＆ラーニングを主催します。 NetOps 担当者の指導を申し出て、NetOps 担当者が業界のコツを学ぶ機会を提供できるような洞察やチュートリアルやコミュニティへのリンクを共有します。 「オートメーション センター オブ エクセレンス」またはコミュニティを立ち上げて、ベスト プラクティスを確立し、ソリューションを共有し、それらの「不均衡な力」に対処する知識の共有を促進します。
DevOps は配信で終了すべきではありませんし、終了することもできません。 アプリケーションは、対象とする消費者の手に渡るまでは、実際には「完成」したとは言えません。 つまり、導入、そしてデバイスとアプリケーション サービスの複雑なパイプラインを自動化して、導入にかかる時間を短縮する必要があります。 DevOps には、NetOps のスキー板にロケットを取り付けるためのスキル、ツール、経験があり、NetOps もビジネスのニーズに応じて迅速に動くことができます。