エンジニア リーダーが避けるべき 6 つの DevOps の落とし穴

1. 部分的な組織変革

ソフトウェア組織内で DevOps を稼働させても、提供速度が全体的に改善されないこともあります。多くの場合、DevOps の基本原則をエンジニアリング部門にのみ導入し、組織図の他の部門では何も変えないことが原因です。DevOps はよりアジャイルなソフトウェアの提供モデルであるため、IT チーム、UX チーム、製品チーム、マーケティング チームなど、ソフトウェア以外のチームも合わせる必要があります。

2. 不完全なテストの自動化

継続的な提供は継続的テストを意味します。テストの自動化を設定するには時間と労力がかかるため、一部のチームは特定の複雑なテストのみ手動で実行しています。この方法では、コミットごとにテスト スイート全体を実行できません。ただし、コミット時に中核となるテスト セットのみを実行し、完全なテスト スイートを定期的に実行するように設定できますが、これではワークフローの後半になるまでバグが検出されず、バグを修正するのが難しくなります。

3. ツール インテグレーションの問題

DevOps ツールキットには、ソース管理、CI、デプロイ、テスト、インフラストラクチャのプロビジョニング、通知などのアプリケーションが含まれています。チーム間で話し合う機会はあるのでしょうか。多くのソフトウェア組織は DevOps ツールチェインを手動で管理したりカスタム スクリプトを使って全てを関連付けたりしますが、このアプローチはツールやケースが増えるにつれ持続可能性が低くなります。この問題を解決するために、GitHub は最近、ワークフロー ステップをコードとして扱うことができ、必要に応じてインテグレーションに結び付けることができる GitHub Actions という新機能をリリースしました。

4. 多くが速すぎる

多くの企業が DevOps モデルに移行する理由の 1 つは、開発チームの仕事量が過度である点です。ただし、過度なワークロードにより DevOps の導入に失敗する場合があります。既にワークロードの管理に苦労しているチームに新しいツールやプロセスを導入すると、混乱、従業員の燃え尽き症候群、離職率の上昇を招きます。DevOps への移行を試みる前に、可能な限り、作業の優先順位の見直し、延期、請負業者への委任を検討します。

5. 失敗を恐れる

DevOps は失敗しにくい環境を作りますが、失敗しないという意味ではありません。DevOps を初めて使用する多くの組織は、失敗した後、ワークフローのいずれかの時点に原因があると決めつける過ちを犯します。代わりに、失敗を学習の機会として捉えましょう。問題解決のアプローチを取る方が、余計なストレスを抱えずに済みます。Netflix などの一部の企業では、チームが失敗の対応に慣れるように、あえて失敗をシミュレーションしています。

6. 製品の完全な無秩序状態

DevOps が柔軟であることは、良い点も悪い点もあります。設計上、DevOps チームにより広範な権限と自律性が与えられますが、すべきでないことも行ってしまう可能性があります。より混沌とした環境では、十分に吟味されていない機能や再設計がデプロイ、修正、ロールバックされ、顧客のフラストレーションを引き起こす可能性があります。DevOps を導入する前に、プロセスにいくつかの承認とコントロールを慎重に設計することが必要です。