価値実現までの時間の改善: プロセスと並列化

クリスマスの時期によくある嘆きがあります。 それは屋根の上から、そして松の木のとげのある枝の下から叫ばれます。

「一つの光が消えたら、全部消えるよ！」

これは、直列回路に配線されたライトに困っている人の叫びです。 なぜそうなるのかについては詳しく説明しません。ただ、切れた電球 1 つが障害要因になっていると言えば十分でしょう。

これは、並列回路に配線されたライトに恵まれた人には当てはまりません。 1 つの電球が切れても、他の電球は明るく点灯し続けることがあります。

これは価値実現までの時間とapplicationsにどのような影響を与えるのでしょうか? すべて。 実際のところ、従来の IT はシリアル回路で本番環境に向かっているのに対し、最新のアプリケーション開発は並列回路で常に稼働しているからです。

プロセス

最近のブログで、Pivotal Global Field CTO のJames Urquhart氏は、製品よりもプロセスに適切に重点を置いた継続的な IT の重要なイメージを提示しています。 彼はそれを「生産への道」と呼んでいます。

生産への道というアイデアは、実際にはプロセスに関するものであり、従来の IT の場合は並列化に関するものです。 この概念は、現代のapplication開発とアーキテクチャの中核となります。 アプリを個別の集中コンポーネント (マイクロサービスと呼ばれることもあります) に分解すると、当然のことながら並行開発につながります。 これは、小規模なチームが同時に異なるコンポーネントに取り組んでいるためです。 これが最終的に、アジャイルがapplicationsの価値実現までの時間を短縮し、速度を向上させるメカニズムとして機能する理由です。 小規模なチームではありません。 小さいアプリではありません。 applicationsの開発と配信においてこれらの概念を活用することで並列化が実現されます。

同じアプローチが生産への道にも適用されます。 つまり、スケールを実装し、applicationsのセキュリティを確保するために必要な実稼働コンポーネント (サービス) は、はるかに大規模なプロセスの一部であり、その一部は並行して開発および提供できます。

障害となっているのは従来の IT です。 シリアルIT。 ウォーターフォール開発手法が生産プールに波及しました。 データはネットワークをシリアルに流れるため、ネットワークをシリアル チャネルとして構築します。 ルーターからファイアウォール、負荷分散、アプリケーション サーバー、データベースまで。 データは予測可能なパスでネットワークの一端から他端まで流れます。 そのため、私たちはこれらのapplicationサービスを同じ方法、つまりデータ パスに自然に従う予測可能なシリアル化されたプロセスで実装し、提供します。

それはもううまくいきません。

まず、データパスが複数存在するようになったためです。 NS と EW を通過するデータ パスだけでなく、他の基本方向に逸れるデータ パスも含まれます。 NE からクラウドにアクセスしてスクリプトを取得します。 スプライトと Web フォントを取得するための SW。 WSE は地図を取得し、それをアプリに埋め込みます。

しかし、今日では、実稼働へのパスの並列化が必要なのは、データ パスの分散だけではありません。 それは効率性とスピード、つまり最適化の追求です。

並列化

今日の価値実現までの時間の期待に応えるために必要なスピードを実現するには、並行開発が必要です。 アプリ開発だけでなく、コア IT でも同様です。 現在組織で使用されているapplicationサービスの幅広さを見ると、並列化によって展開を高速化できる領域が複数あることがわかります。

従来の IT がサイロ化されているというわけではありません。 結局のところ、マイクロサービス アーキテクチャの結果は、それぞれが非常にターゲットを絞ったapplication機能セットに重点を置いた、数十または数百の小さなサイロ化されたチームになります。 従来の IT はすでにサイロの中にサイロが存在します。 問題は、アジャイル開発手法ではサイロ内での並行開発が推奨されるのに対し、従来の IT では依然として、生産プロセスを系統立ててシリアル化した方法で進めていることです。

問題となるのは、チーム間の引き継ぎと、本番環境へのパスでネットワーク トラフィックをミラーリングする方法です。 これは逐次的なプロセスではなく、サービスの開発と提供を並列化できる場合は、そうすべきです。

つまり、早期にコラボレーションを促進する部門横断的なチーム構造を意味します。

すべての懸念事項にわたってよりアジャイルなプラクティスを採用してプロセスを並列化することで、組織は生産までのスピードと効率を向上させることができます。

プロセスは製品である

ジェームズが言及しているように、生産への道は実際にはプロセスです。 プロセスはステップで構成されています。 シックスシグマのプロセスに精通した人なら誰でも言うように、プロセスを高速化するには、非効率性を見つけて排除することが重要です。 運用環境では、これらの非効率性は、デプロイメント プロセス内の厳格でシリアル化されたステップ間の待機時間 (ハンドオフ) として現れます。

ツールが役立ちます。 しかし、最終的に改善するには、プロセスを長期にわたって綿密に検討し、実稼働までのプロセスの一環としてapplicationサービスの配信を並列化する機会を探すことが必要になります。

文化、特にコラボレーションの文化はオプションではありません。 それは行動や実践に非常に現実的な影響を及ぼします。 チーム構造だけでもパイプラインの自動化は劇的に変化し、従来の単一機能のチームは、現代の DevOps 主導のチームに遅れをとることになります。 より協力的なチーム構造を推進します。 同様に、共同作業チームは主要な指標に基づいて調整する必要があります。 共有メトリックにより、NetOps とセキュリティはペナルティなしで継続的な展開に取り組むことができます。 現在、NetOps のほぼ 4 分の 3 がネットワーク稼働時間で測定されています。 展開の頻度はほとんど認識されません。 彼らはネットワークの維持に注力するつもりです。なぜなら、それが彼らが注力しなければならないことだからです。 共有メトリックにより、NetOps はビジネスのニーズ、つまりより高速で頻繁な展開に集中できるようになります。 

最後に、共感が必要です。 皆さんは同じチームに所属しており、驚くかもしれませんが、同じものを大切にしています。 NetOps は、DevOps と同様にパイプラインの自動化を非常に重視する可能性があります。 覚えておいてください。DevOps は、統合、ツール、スキルセットに関する障害の回避と克服において、NetOps よりも 10 年先行しています。 共同チームは、配信からデプロイメントまでをカバーするツール (Jenkins や GitHub/GitLab など) の標準化を推進することで役立ちます。

生産への道は製品ではありません。 それはプロセスです。 また、価値実現までの時間を短縮し、applicationの導入を成功させるには、このプロセスを共同で実施し、可能な限り並行して提供する必要があります。