移行時に避けるべきよくある間違い

企業にとって、何千ものアプリケーションを移行できることは、競争力を維持するために避けられない部分です。移行を成功させる方法を理解するのは怖いので、避けるべき落とし穴に飛び込みましょう。

COVID-19 は、技術的な人材不足と、技術的なタイムラインの加速に対する需要の増加の両方を生み出しました。多くの企業が「 赤の女王」効果に直面し始めており、企業は競争力を維持するために、市場で競争する方法と場所を再定義する必要があります。今日、現状に満足している企業は、深刻な不利益と絶え間ないキャッチアップ サイクルという報いを受けています。既存のテクノロジーから、より応答性が高く費用対効果の高いソリューションへの移行は、企業の変革の重要な部分です。ただし、準備ができていない人にとっては落とし穴に満ちている可能性があります。

ボストン コンサルティング グループが 2020 年に行った調査によると、895 件のデジタル トランスフォーメーションに関与する 70 社の 825 人の上級管理職が参加し、トランスフォーメーションの目標を達成したのはわずか 30% でした。

これらは、自信を持たせるための数字ではありません。幸いなことに、Stark & Wayne のような企業は、他の企業が移行を回避できるように、複数の企業移行を可能にするために取り組んできました。 Stark & Wayne は、エンタープライズ規模のインフラストラクチャの移行の専門家です。過去のプロジェクトには、45,000 のアプリ インスタンスを管理するCloud Foundry Foundationの展開が含まれていました。

パフォーマンス ベースラインを文書化する

委任状です！すべての企業がパフォーマンスの向上を求めていますが、パフォーマンスの基準となる指標や、パフォーマンスの向上が何を意味するかを測定する方法が不足している企業が多くあります。パフォーマンスはエンド ユーザー エクスペリエンスに関連していますか?パフォーマンスは、ワークロードをスケールアップおよびスケールダウンして消費を削減することに基づいていますか?導入またはアップグレードにかかる時間を短縮してパフォーマンスを測定していますか?パフォーマンスの測定方法を確立したら、それをアプリケーション、顧客、およびビジネスに関連付けることができます。

これにより、移行中および移行後にアプリのパフォーマンスが低下しているかどうかを評価できます。また、重要な変化の際の認識を管理し、成功を定量化するのにも役立ちます。移行前と移行後のプラットフォームを同様のワークロードと比較する必要があります。何を測定するかはビジネス要件によって異なりますが、いくつかの一般的な測定値は次のとおりです。

• コンポーネントの実行時間
• アプリケーションの応答時間
• アプリケーション全体の実行時間
• アプリケーションをテストして、コンポーネントの接続性とサービスのアクセシビリティを検証します
• API メトリクス (ページ読み込み、メモリ使用率、CPU、サーバー パフォーマンス)
• ログ出力負荷
• 時間の経過に伴うインシデント レポートの負荷
• 自動化 (そして、全体的なパフォーマンスが向上するため、自動化を第一級市民として扱います)
• 移行とタスクの自動化による運用コストの変化
• 環境をモデル化するアプリケーション タイプでテストします。

優れたダッシュボード: 見つからないものは移行できません

ほとんどの組織は、現在何をサポートしているかを把握していますが、移行後に何をサポートしたいかを特定する必要があります。ベンダーはこのメトリックに基づいて請求する可能性が高いため、アプリケーション インスタンスの数を知るのは簡単です。それでも、アプリケーションの数、アプリケーションをサポートするチーム、相互依存関係のあるアプリケーション、および各アプリケーションが使用するサービスの種類を知る必要もあります。これらの変数を特定すると、新しい環境への移行とサポートの両方を行う方法を決定するのに役立ちます。

各アプリケーションの所有者をマッピングする際に、アプリケーションが機能していることを検証するためのテスト スクリプトを自動化した所有者を特定することが不可欠です。すべてのアプリケーションに自動化されたテスト スクリプトがあることが理想的ですが、少なくとも、アプリケーション所有者のマッピングが必要です。また、未使用で保守されていないアプリケーションを探す必要があります。移行前にアプリを削除または修正する必要がある場合に、機能しないアプリケーションを移行することは最も避けたいことです (これは実際に発生しています)。驚くほど多くの場合、アプリケーション所有者のマスター マッピングが存在せず、移行中および移行後に問題が発生します。

そのため、焦点は「在庫、在庫、在庫」です。多くの企業は、各アプリケーションの所有者、各アプリケーションが何を持っているか、何を実行しているか、およびアプリケーションのビジネスへの影響をカタログ化する中心的な場所を持っていません。関連情報をすばやく照会して検索する機能は、運用、効率、およびビジネス上の意思決定にとって不可欠です。

どこから始めれば？まず、より広範な質問に答えます。

• 実行している地域とその理由は?
• 各リージョンで実行されているアプリケーションは?
• 各アプリケーションが各リージョンで使用しているサービスは?
• どのバージョンの Linux が使用されていますか?
• リージョン内の他のアプリケーションと通信するアプリケーションは?
• クライアント向けと内部向けのアプリケーションは?

これらの開始データ ポイントを収集しても、すべての不明点が解決されるわけではありませんが、必要な洞察が得られるようになります。

できることを監査する: 知らないことを受け入れる

各詳細をどれだけうまく監査または文書化しても、ダウンタイム、顧客、同僚、費用、およびタイムラインに影響を与える未知の変数が存在します。これらの不明点は、技術チームが移行プロセスに手を染めたときにのみ発見できます。彼らをサポートする方法は次のとおりです。

• 未知のタイムラインを追加
• 不明なアイテムが問題を引き起こした場合に役立つリソースをより多く利用できるようにする
• 会社のポリシー、社内会議、新機能のロールアウトに柔軟に対応する
• テストが失敗した場合のロールバックなどのバックアップ計画を用意する
• 大きなものを計画しながら勢いを増すために、最初に小さな勝利に焦点を当てます。運用上のオーバーヘッドが増えない限り、具体的な迅速な勝利は士気を高めることができることを忘れないでください。

推奨される方法は、完全な監査を実施し、組織構造と関係を文書化し、これを作業全体の参照に使用することです。プロジェクトが開始されると、このドキュメントが地図になり、優先順位を下げたりアイテムを保留にしたりするのを避けるのに役立ちます。実行する必要のあるアクションに優先順位を付けるために、上層部へのエスカレーションが必要になる場合があります。それでも、個々のチームがどのように機能するかを理解し、彼らとの良好なコミュニケーションを確立することを優先する必要があります。

セキュリティ: SecOps チームを昼食に連れて行きましょう

これは、トニー・ソプラノの「乗ってみよう」という意味ではありません。セキュリティ チームを昼食に連れて行き、顔を合わせて信頼関係を築くことを意味します。セキュリティ チームは、発生したブロッカーを制限、緩和、または回避策を提供する移行プロセスに不可欠です。また、移行を成功させるために必要な新しいソフトウェアの迅速なレビューも必要です。無視されたセキュリティ チームはブロッカーになります。別の恐ろしい映画のアナロジーでそれに直面しましょう。セキュリティは、モンティ・パイソンの黒騎士になりたいとは決して思っていません。しかし、彼らは本当にすべてを安全に保つという重要な役割を果たしたいと思っています.最終的に、セキュリティは、適切なガイドラインがある限り、組織内のすべての人を有効にしたいと考えています。早い段階で彼らを関与させれば、最後の最後に警備員が引き込まれたときの頭痛を避けることができます。

スコープ クリープに抵抗する: これは本当に素晴らしいアイデアです… 来年に向けて

スコープ クリープは慎重に管理する必要があります。すべての組織は問題を同時に解決したいと考えていますが、非常に具体的な 1 つの問題を解決することに集中する必要があります。 Pivotal Cloud からオープン ソースの Cloud Foundry への移行を例にとると、Cloud Foundry の主な強みは、追加できる多くの機能とカスタマイズの可能性です。たとえば、ディザスター リカバリー体制とバックアップを改善することは魅力的ですが、追加のスコープを作成すると、追加の問題点が生じます。

スコープ クリープは、何かが破損する可能性があるという問題も引き起こします。破損の原因が包括的なプロジェクトの目標によるものなのか、追加のスコープによるものなのかを確認することはできません。

ミラーリング：残したい世界に合わせる

プロジェクトのパラメーターと目的の結果を確立したら、移行するすべての環境をミラーリングしたことを確認する必要があります。これには、運用環境または「プレイグラウンド」が含まれます。ここでは、すべてを実証し、非運用環境に移行し、最終的に運用環境に移行します。

Playground 環境を構築するときは、既存のテクノロジ (この例では Pivotal) が非運用環境と同等であることを確認する必要があります。これにより、問題が少なくなるという自信が持てるようになります。

管理上の問題: 高い場所で友達を作る

経営陣からのサポートが必要になるため、完全にバラ色の絵を描いてはいけません。移行には長い道のりがあります。プラットフォームを移動することは 1 つのことですが、すべてのサービスにも対処する必要があります。経営陣は、移行へのアプローチと、ビジネス リスクを軽減するための計画を知る必要があります。移行は収益に影響を与える可能性があるため、経営陣は神経質になるため、それを回避するためのすべての対策について話し合う必要があります。

うまく失敗する：それを成功させる

失敗は良いことであり、失敗は素晴らしいことであり、次に学んだ教訓を実行する限り、失敗は当然のことです。すべてを説明することはできず、未知の要素がブロッカーになると、認識された失敗が発生します。経営陣に失敗があることを知らせることで、否定的な意味合いを回避し、全体的な士気を向上させることができれば幸いです.実際、進歩しているので、失敗から学んだことを祝う必要があります。失敗を許容できると売り込むには、明確なフォールバック計画が必要です。これを、ロールバックの実施/中止の決定ポイントを含む移行日の計画の一部として実施してください。

ライセンス料金とリスクは、オープン ソースの Cloud Foundry または Kubernetes に移行する主な要因です。数千のアプリを実行している大規模な組織にとって、利害関係はミッション クリティカルです。スケーリングに対する需要の高まりと開発者の不足により、移行は危険に思えます。主な関心事は、アプリケーション チームへの影響を回避し、ダウンタイムを回避することです。幸いなことに、Stark & Wayne は、開発者への影響を最小限に抑え、変更管理ウィンドウに限定されたダウンタイムを順守するエンタープライズ規模の移行を数多く成功させてきました。

私たちが遭遇したこれらのよくある間違いを考慮に入れることで、次のプロジェクトが、Boston Consulting Group が示唆する 70% の一部になる可能性が低くなります。

ここにも掲載されています。