IT運用はスクリプト作成を超えて自動化する必要がある

クイズ – どちらが重いでしょうか? 1 ポンドの羽根か、それとも 1 ポンドの石か?

もちろん、ひっかけ質問です。 1ポンドは1ポンドです。 1 ポンドの中には、石よりも羽の方がずっと多く含まれています。

さて、もっと関連した話題ですが、どちらが速いでしょうか? 手動コマンドで実行されるスクリプトですか、それとも API 呼び出しで呼び出されるスクリプトですか?

この時点で、答えは最初の質問と同じであると推測し、違いはない、と答えた可能性があります。 少なくとも、識別できるほどの違いはありません。

スクリプトはスクリプトであり、その実行時間は呼び出し方法に依存しません。 手動コマンドによって開始されるか、API 経由で呼び出されるかに関係なく、スクリプトは実行速度に応じて実行されます。 期間。

これは重要です。自動化による操作速度の向上は、実際にはスクリプトではなくプロセスに関するものだからです。 それはハンドオフについてです。 プロセス内の個々のステップのスクリプト作成だけに焦点を当てると、デプロイメントを最適化することはできません。 本当の改善が見られるようになるには、プロセス自体にまで到達して、さらに高いレベルに到達する必要があります。

どの業界においても、自動化の目標はほとんどの場合、最適化です。 2018 年のアプリケーション配信の現状に関する調査で、デジタル変革イニシアチブを実施している回答者の 72% が「IT の最適化」を最も期待されるメリットとして挙げていることがわかりました。 目標は最適化でした。

最適化とは、ボトルネックを見つけて排除することを意味します。 IT の世界では、それはほとんどの場合、運用プロセスのステップ間の引き継ぎになります。 実際の作業、つまりスクリプトこそが価値なのです。 これらのスクリプトが実行される間の時間は、出力を待っている人にとって、ほとんどの場合、遅延とフラストレーションの原因となります。 NetOps の大多数 (52%) は、依然としてこの方法でインフラストラクチャを管理しています。 

各運用ドメインがプロセス内の各部分をスクリプト化するだけでは不十分です。 ファイアウォールの変更のスクリプト作成、アプリケーション サービスのプロビジョニングと構成、アプリケーション インフラストラクチャの立ち上げは、すべて個別に行うのが適切です。 しかし、それはまだ始まりに過ぎません。 これらの個々の自動化されたステップが組み合わさって、単一の運用プロセスが構成されます。 それを自動化することをオーケストレーションと呼びます。 そして、オーケストレーションでは、遅延や誤った引き継ぎが発生し、ITOps を低下させる非効率性が生じます。 

ここで文化と組織構造が重要になります。 展開プロセスの最初のステップ、たとえばアプリ インフラストラクチャの立ち上げを担当している場合は、そのプロセスを次のステップに引き継ぐ必要があります。 これはおそらく、アプリケーション サービス (負荷分散など) のプロビジョニング手順です。

それを誰に渡すのですか？ キューに入りますか? チケットを生成しますか? それはどのように機能するのでしょうか?

これは、包括的なプレイブック (レシピ、クックブック、マニフェストなど) によって管理されるか、プロセスの実行を監視する外部システムによって管理される、シームレスな移行である必要があります。 プロセスの実行に手動操作を導入すると、自動化を実際に活用しているのではなく、単にスクリプトを作成しているだけになります。

スクリプトは自動化戦略の不可欠な要素であるかもしれませんが、スクリプトを駆動する管理プロセスと統合できないため、スクリプト自体は自動化ではありません。

自動化を使用して IT を最適化する場合は、プロセスを自動化する必要があります。 そうすることで、待機時間をなくし、硬直化した運用プロセス (3 層の承認を含む) を見つけ出し、実際にパフォーマンスを向上させ、有意義な方法で速度を上げることができるからです。   

単なるスクリプト作成ではなく自動化は、アジャイル ネットワークの目標に一歩近づく成熟した NetOps プラクティスの兆候です。