私見では、DevOps変換によるチームの利益を直接、すぐに適用してチームをスケールダウンすることはお勧めできません。せいぜい、将来そのような改善を行うというチームのモチベーションだけが失われるでしょう。しかし、ほとんどの場合、そのチームの才能のほとんどまたはすべてが失われます。
代わりに：
- チームが経験した難しい変革のメリットを理解できるようにして、変革を経験しなければならない（またはすでに変革に取り組んでいる）他のチームに言葉を広める
- より良い品質の製品/サービスをより迅速に-同じチームで-変革によりこれが可能になりました。
- 多くの場合、変革のためにあなたのビジネスはスピードを取り戻します-すぐに人を雇う必要があるでしょう-私見新規雇用者を教育するよりもあなたがすでに持っている人の経験を使うほうが良いです
- 自発的な消耗があなたのために働き、効果的なダウンスケーリングを道に譲ることを許可します。
しかし、通常、DevOps変換は、上記の選択を可能にするほど速く発生しない傾向があります:)
次に、スケールアップ/スケールアウトについて説明します。
理想的には、DevOpsトランスフォーメーションにより、ソフトウェア開発およびデリバリープロセスの予測可能性が大幅に向上するはずです。既存のチームの能力をかなり正確に伝えることができるはずです。特定の品質のSW /サービスが、現在のチームが特定の時間内にどれだけ達成できるかを示します。
より多くのことを行う必要がある場合、または現在のチームの能力よりも優れている/速い速度で行う場合は、チームをスケールアップ/スケールアウトする必要があります。正確な詳細は、日常のアクティビティに使用するプロセス/方法論、おそらくアジャイルバリアントから得られます（私の組織は、Agile Softを採用する必要がありますか？DevOpsを採用する前にDev。も参照してください）。
方法 - どうやら簡単：あふれる活動を処理するためにより多くの人々を雇う。どれだけ速くそれらをオンボードにして、実際にそのオーバーフロー作業を予想される速度で処理できるかが心配な場合は、予測に基づいて、早期に採用を開始してください。
ただし、現実はそれよりも少し難しい場合があります。ソフトウェア製品/サービスまたはそれをサポートする開発プロセスとツールのスケーリングは、DevOpsを活用した組織であっても、必ずしも単純ではありません。
私のお気に入りの例の1つは、スケーラビリティに関して最も弱いDevOpsリンク、継続的統合です。CIビルドが失敗した場合は、配信/展開が行われない可能性があります（CDのコンテキストで「継続的」という用語を損なう）。
特定のチームがきちんと結果を出してCIを喜んで使用しているからといって、チームのサイズが2倍になっても同じことが起こるとは限りません。いいえ、結果は壊滅的なものになる可能性があります-配信プロセスが停止して（極端な場合）停止する可能性があります。これを従来のCIシステムの輻輳で説明しようとしています（免責事項：私は参照ページを所有し、この問題の解決策を提供している会社の創設者です）。
別の例としては、たとえば、使用されているバージョン管理システム（VCS）が考えられます。リポジトリに格納されているソフトウェアが進化すると、その変更履歴も変化し、VCSシステムの限界を超え、場合によっては許容可能なパフォーマンスレベルを超えます。よりスケーラブルなVCSシステムに切り替えるか、コードベースを複数のリポジトリに分割することで、この問題に対処できる可能性があります。
しかし、開発プロセスの進化とそれらをサポートするツールは、提供されるソフトウェア製品/サービスの進化と並んで、基本的に成熟したDevOpsチームが行うことです。それらは、チームのスケールアップ/アウト戦略で考慮される必要があるだけです。
それを念頭に置いて、実際には、チームのサイズを増やすだけで、上記の戦略の実行に必要な追加の作業量をカバーする方法を減らすことができます。