新しいツール、プログラミング言語、または依存関係を環境に導入する場合、それを評価するためにどのような手順を実行しますか？この記事では、これらの決定を行うために使用する6つの質問のフレームワークについて説明します。
どのような問題を解決しようとしていますか？
私たちは皆、目前の問題の細部に巻き込まれています。正直で批判的な評価は、より広範な根本原因を明らかにし、マイクロ最適化を防ぐのに役立ちます。
[次のこともお勧めします：Linuxサービスとその関連ツールの6つの導入手順]
構成管理システムで問題が発生しているとしましょう。日常の運用タスクは必要以上に時間がかかり、言語での作業は困難です。新しい構成管理システムはこれらの懸念を軽減する可能性がありますが、このシステムのコンテキストをより広く検討するようにしてください。おそらく、仮想マシンから不変のコンテナーに切り替えると、同等の作業量でありながら、環境全体でこれらの問題やその他の問題が緩和されます。この時点で、より包括的なソリューションの実現可能性も検討する必要があります。コンテナに関する組織の知識が不足しているため、現時点ではこれは組織にとって実行可能なプロジェクトではないと判断するかもしれませんが、このトレードオフを誠実に受け入れることで、コンテナを次の四半期のロードマップに入れることができます。
この知的演習は、より大きな問題の症状ではなく、根本的な原因を掘り下げて主要な問題を解決するのに役立ちます。これは常に可能であるとは限りませんが、この決定を行うことについては意図的に行ってください。
このツールはその問題を解決しますか？
問題を特定したので、今度は自分自身と選択したツールの両方を批判的に評価します。
特定のテクノロジーは、それに関するクールなブログ投稿を読んだり、会議で講演したりするために新しいため、魅力的に見えるかもしれません。ベルやホイッスルはいいかもしれませんが、ツールは最初の質問で特定した主要な問題を解決する必要があります。
私は何を諦めていますか？
このツールは実際に問題を解決し、正しいを解決していることを私たちは知っています。 問題がありますが、トレードオフは何ですか？
これらの考慮事項は、純粋に技術的なものである可能性があります。可観測性ツールの欠如は、本番環境での効率的なデバッグを妨げますか？このツールのクローズドソースの性質により、微妙なバグを追跡することがより困難になりますか？このツールを使用することの運用上の利点に値するさらに別の依存関係を管理していますか？
さらに、あなたが運営しているより大きな組織、ビジネス、および法的文脈を含めてください。
重要なビジネスワークフローの制御をサードパーティベンダーに譲っていますか？そのベンダーがAPIコストを2倍にした場合、それはあなたの組織が余裕があり、喜んで受け入れるものですか？機密情報の機密情報を処理するクローズドソースツールに慣れていますか？ソフトウェアライセンスにより、これを商業的に使用することは困難ですか？
答えるのは簡単な質問ではありませんが、時間をかけてこのことを事前に評価することで、後で多くの苦痛を軽減できます。
プロジェクトまたはベンダーは健全ですか？
この質問には、「要件のバランスをとるための」補遺が付属しています。 Project X まで、チームが4か月から6か月のこぶを乗り越えるためのツールのみが必要な場合 が完了すると、この質問の重要性は低くなります。これが複数年にわたる取り組みであり、ツールが重要なビジネスワークフローを推進する場合、これは懸念事項です。
この手順を実行するときは、利用可能なすべてのリソースを利用してください。ソリューションがオープンソースの場合は、そのソフトウェアに関するコミット履歴、メーリングリスト、およびフォーラムディスカッションを確認してください。コミュニティは効果的にコミュニケーションを取り、一緒にうまく機能しているように見えますか、それともコミュニティのメンバー間に明らかな亀裂がありますか？購入するものの一部がサポート契約である場合は、概念実証フェーズでそのサポートを使用します。それはあなたの期待に応えますか？サポートの質はコストに見合うものですか？
オープンソースツールを評価するときも、GitHubのスターやフォークを超えた一歩を踏み出すようにしてください。ニュースアグリゲーターのトップページに何かが当たって数日間注目を集めるかもしれませんが、深く見ると、実際にプロジェクトに取り組んでいるコア開発者は2、3人だけであり、外部からの貢献を見つけるのに苦労していることがわかります。ツールはオープンソースかもしれませんが、企業が資金提供するチームがコア開発を推進しており、その組織がプロジェクトを放棄した場合、サポートは停止する可能性があります。おそらく、APIは6か月ごとに変更されており、以前のバージョンを採用している人々に多大な苦痛をもたらしています。
リスクは何ですか？
技術者として、あなたは何も計画通りに進まないことを理解しています。ネットワークがダウンしたり、ドライブに障害が発生したり、サーバーが再起動したり、データセンターの行の電源が切れたり、AWSリージョン全体にアクセスできなくなったり、BGPハイジャックによって数百テラバイトのインターネットトラフィックが再ルーティングされたりします。
このツールがどのように失敗する可能性があり、どのような影響があるかを自問してください。 CI / CDパイプラインにセキュリティベンダー製品を追加する場合、ベンダーがダウンするとどうなりますか？
これにより、技術的な考慮事項とビジネス上の考慮事項の両方が発生します。 CI / CDパイプラインは、ベンダーに到達できないために単にタイムアウトしますか、それとも「フェールオープン」してパイプラインが警告付きで完了することを許可しますか？これは技術的な問題ですが、最終的にはビジネス上の決定です。このシナリオでセキュリティスキャンをバイパスした変更を加えて本番環境に移行しますか？
明らかに、システムの複雑さが増すにつれて、このタスクはより困難になります。ありがたいことに、k8s.afのようなサイトは、停止シナリオの例を統合しています。これらの公開された事後分析は、ソフトウェアの一部がどのように失敗する可能性があるか、およびそのシナリオを計画する方法を理解するのに非常に役立ちます。
費用はいくらですか？
ここでの主な考慮事項は、従業員の時間と、該当する場合はベンダーのコストです。そのSaaSアプリは、より多くの人員よりも安いですか？その新しいCI/CDツールを使用してチームの各開発者を1日2時間節約した場合、次の会計年度にそれ自体で利益が得られますか？
確かに、すべてがコスト削減の提案である必要はありません。開発チームを1日数時間節約すれば、コストに中立ではないかもしれませんが、毎日のワークフローで巨大なブロッカーを削除することになり、彼らはそれをはるかに喜ぶでしょう。その幸福はおそらく経済的費用の価値があります。新しい開発者のオンボーディングにはコストがかかるため、これらの計算を行う際には、保持を増やすことの価値を過小評価しないでください。
[Red Hatの無料ガイド：ビジネスを自動化するための5つのステップ。 ]
まとめ
このフレームワークが洞察に満ちていることをご理解いただければ幸いです。また、このフレームワークを独自の意思決定プロセスに組み込むことをお勧めします。すべての決定に有効な万能のフレームワークはありません。時々、あなたはあなたの腸と一緒に行き、判断の電話をかける必要があるかもしれないことを忘れないでください。ただし、このような標準化されたプロセスがあると、決定を批判的に分析できるときと、その飛躍を遂げる必要があるときを区別するのに役立ちます。