「すでにDevOpsをお持ちですか？ MegaTeleKoでは、すべてが本格的です。 最近35人のDevOpsチームを募集しました！」
では、DevOpsチームを雇うのはなぜ悪い考えなのでしょうか？
その瞬間、私はキャプテン・ピカードのスタイルでfacespalmに抵抗しました。 残念ながら、DevOpsという言葉を含む職に従業員を雇い、これに関するこの会話の参加者の喜びは偶然の妄想ではありません。 インターネット上のソースの簡単なレビューによると、多くの企業は、特に以下に従事するDevOpsエンジニアを探しています。
- インフラストラクチャの変更の自動化
- JIRAセットアップ
- MySQL管理
- 大規模なLinuxプロジェクトのサポート
- パペットに関連するすべてを管理する
- ruby、python、bashでスクリプトを書く
- あちこちで「クランチ」で運用をサポート
このリストは実際のジョブの一部で構成されており、特定の人を暗示しないようにわずかに変更されています。
一般的に、DevOpsの概念が一般的になりつつあるという事実に肯定的です。 ただし、アジャイルの場合と同様に、DevOpsは別の流行語のステータスを取得し、その後すべての意味を失う危険にさらされています。 DevOpsを探しているほとんどの企業は、単にシステム管理者を雇いたいだけでなく、同時にモダンに見えます。 標準DevOpsジョブの要件の大部分は、サポートエンジニアまたはシステム管理者の能力によって完全にカバーされています。 同時に、これらの要件では、「シンプルで実用的なソリューションを作成する能力」という項目がしばしば欠落していることが特に面白いです。 開発とサポートの相互作用の方向で品質を改善する代わりに、IT業界は単に管理者に新しいタイトルであるDevOpsを与えることで「削減」しようとしているようです。
それでは、DevOpsを開発するために本当に必要なものは何でしょうか？
新しいDevOpsチームを作成する代わりに、開発部門とサポート部門の間の壁を取り除いてみてください。 開発者とシステム管理者は、ソフトウェアとその問題のインストール、構成を含む、すべての作業の瞬間を話すために定期的に会う必要があります。 フィードバックとアイデアの議論は両方の方法で機能するはずです。 プロジェクトマネージャーは、システム管理者を同じソフトウェアユーザーと見なす必要があります。したがって、外部ユーザーの場合と同様に、作業シナリオを検討し、希望を考慮に入れる必要があります。 開発者は、要件をサポートし、実装に責任を持ってアプローチすることに共感する必要があります。 もちろん、2つのチームはそれぞれ独自の特性、強み、能力を持っているため、独立したままである必要がありますが、共通の目標を持つ「スーパーチーム」の一部として一緒に働くことは、複雑なビジネス問題を解決するためのエレガントで高品質の製品を作成し、維持することです
ユビキタスインフラストラクチャスクリプトの代わりに、ソフトウェアを全体的かつ論理的にする必要があります。 Linuxの世界のように、このエコシステムには効率的な自動化ツールがないため、WindowsにはDevOpsという用語は存在しないと考えられています（ここではシェフとパペットをほのめかしています）。 異議を唱えるのは難しいですが、そのようなツールは非常に便利ですが、自動化がDevOpsの基礎であるという見解を支持しません。 実際、ソフトウェアはインストールや設定に重要なスクリプトに依存すべきではありません（perl、puppetは関係ありません）。 実装は、理想的には、ターゲットマシン上の通常のxcopyのようにシンプルである必要があります（ソフトウェアが最初の実行時にインストールされると便利です）。 設定は構成サービスから取得する必要があり、XMLファイルのカーニバルを手配する必要はありません。 別のGoldbergマシンを構築する代わりに、ソフトウェアのセットアップのすべての機能と困難をスクリプト化するために、最終的に開発（および管理）と対話して、そのような問題と不要な複雑さを取り除きます。
DevOpsを別の流行語と考えないでください。この哲学を受け入れて広めてください。 実際には、履歴書にこの言葉を使ってスペシャリストを雇ったり、巨大な自動化ソフトウェアを実装したりして、DevOpsを手配することはできません。 DevOpsはZenを文化的な飛躍へと導きます。 エンドユーザーに固執している開発者は、サポートとそのニーズを確認する必要があります。 管理者は、無言のうなり声ではなく、製品に不便を報告し、作業プロセスの改善に貢献する必要があります。 したがって、企業内で関係を確立することが最初の重要なステップです。 次に、時間とリソースをかけて製品を「シンプルで便利な」状態に改善する必要があります。 中央サービスを介した構成、単純なコピーによる実装、外部依存関係の欠如、ログ内のゴミではなく十分に考慮されたメトリックは、途中の重要なタスクです。
DevOpsをショーに使用しないでください。 この哲学は、コミュニケーションと相互作用を意味し、最も重要なことは、喜んで開発、維持、使用される高品質のソフトウェアを作成したいという願望です。