初心者向けの DevOps ガイド

DevOps の重要性、IT プロフェッショナルにとっての意味、手法、フレームワーク、ツールの説明。

DevOps という用語が IT の世界で定着して以来、多くのことが起こりました。 エコシステムの多くがオープンソースであるため、それがなぜ始まったのか、そしてそれが IT のキャリアにとって何を意味するのかを再考することが重要です。

DevOpsとは

単一の定義はありませんが、DevOps は、開発チームと運用チームのコラボレーションを可能にし、反復と自動化の機能を備えたコードをより迅速に実稼働環境にデプロイできるテクノロジー フレームワークであると私は考えています。 この記事の残りの部分では、この主張を解き明かしていきます。

「DevOps」という言葉は、「開発」と「運用」という言葉を組み合わせた言葉です。 DevOps は、アプリケーションとサービスの配信速度の向上に役立ちます。 これにより、組織は顧客に効果的にサービスを提供し、市場での競争力を高めることができます。 簡単に言うと、DevOps とは、より効果的なコミュニケーションとコラボレーションにより、開発と IT 運用を連携させるものです。

DevOps には、開発、運用、ビジネス チーム間のコラボレーションが重要であると考えられる文化が関係しています。 組織内の DevOps は顧客にも継続的に利益をもたらすため、これはツールだけの問題ではありません。 ツールは、人材やプロセスと並んでその柱の XNUMX つです。 DevOps は、組織が可能な限り最短の時間で高品質のソリューションを提供できる能力を高めます。 DevOps は、ビルドからデプロイメント、アプリケーション、製品に至るすべてのプロセスも自動化します。

DevOps の議論は、ソフトウェアを書くことを生業とする開発者と、そのソフトウェアの保守を担当するオペレーターとの関係に焦点を当てています。

開発チームの課題

開発者は、組織の問題を解決するために新しいアプローチやテクノロジーを導入することに熱心で熱心な傾向があります。 ただし、次のような問題にも直面しています。

• 競争の激しい市場では、製品を期限までに納品するという大きなプレッシャーがかかります。
• 彼らは、本番環境に対応したコードの管理と新機能の導入を担当する必要があります。
• リリース サイクルは長くなる場合があるため、開発チームはアプリケーションを実装する前にいくつかの仮定を立てる必要があります。 このシナリオでは、運用環境またはテスト環境への展開中に発生する問題を解決するために、より多くの時間が必要になります。

運用チームが直面する課題

運用チームはこれまで、IT サービスの安定性と信頼性に重​​点を置いてきました。 そのため、運用チームはリソース、テクノロジー、アプローチの変更を通じて安定性を追求します。 彼らの任務には次のようなものがあります。

• 需要の増加に応じてリソースの割り当てを管理します。
• 運用環境での使用に必要な設計またはカスタマイズの変更を処理します。
• アプリケーションの自己展開後の運用上の問題を診断して解決します。

DevOps が開発と運用の問題を解決する方法

企業は、アプリの多数の機能を一度に展開するのではなく、一連のリリース反復を通じて少数の機能を顧客に展開できるかどうかを確認しようとしています。 このアプローチには、ソフトウェアの品質の向上、顧客からのフィードバックの迅速化など、多くの利点があります。 これにより、高い顧客満足度が保証されます。 これらの目標を達成するには、企業は次のことを行う必要があります。

• 新しいリリースをリリースする際の失敗率を減らす
• 導入頻度を増やす
• 新しいアプリケーションがリリースされた場合の平均復旧時間を短縮します。
• 修正にかかる時間を短縮

DevOps はこれらすべてのタスクを実行し、中断のない配信を保証します。 組織は DevOps を使用して、ほんの数年前には想像もできなかったレベルの生産性を達成しています。 世界クラスの信頼性、安定性、セキュリティを提供しながら、XNUMX 日に数十、数百、さらには数千の展開を実行します。 (ロットサイズについて詳しくはこちら およびソフトウェア配信への影響)。

DevOps は、過去の方法論に起因する次のようなさまざまな問題を解決しようとします。

• 開発チームと運用チーム間の作業の分離
• テストと展開は、設計と構築の後に行われる個別のフェーズであり、構築サイクルよりも長い時間がかかります。
• コア ビジネス サービスの構築に集中する代わりに、テスト、導入、設計に過度の時間を費やす
• 手動でコードをデプロイすると実稼働環境でエラーが発生する
• 開発チームと運用チームのスケジュールの違いによりさらなる遅延が発生する

DevOps、アジャイル、従来型 IT 間の対立

DevOps は、他の IT 実践、特にアジャイル IT やウォーターフォール IT と関連して議論されることがよくあります。

アジャイルは、ソフトウェア制作のための一連の原則、価値観、実践です。 したがって、たとえば、ソフトウェアに変換したいアイデアがある場合は、アジャイルの原則と価値観を使用できます。 ただし、このソフトウェアは開発環境またはテスト環境でのみ実行できます。 ソフトウェアを迅速かつ反復的に運用環境に移行するには、シンプルで安全な方法が必要です。その方法は、DevOps ツールとテクニックを使用することによって実現されます。 アジャイル ソフトウェア開発は開発プロセスに重点を置き、DevOps は最も安全で信頼性の高い方法での開発と展開を担当します。

従来のウォーターフォール モデルと DevOps を比較することは、DevOps がもたらす利点を理解する良い方法です。 次の例では、アプリケーションが 85 週間以内に稼働し、開発が XNUMX% 完了し、アプリケーションが稼働し、コードを出荷するためのサーバーを購入するプロセスが始まったばかりであると想定しています。

伝統的なプロセス
DevOps のプロセス

新しいサーバーを注文した後、開発チームはテストに取り組みます。 タスクフォースは、企業がインフラストラクチャを展開するために必要な広範な文書化に取り組んでいます。
新しいサーバーが注文されると、開発チームと運用チームが協力して、新しいサーバーを設置するためのプロセスと書類作成に取り組みます。 これにより、インフラストラクチャ要件をより深く理解できるようになります。

ドメインの深い知識を持つ開発チームからの情報が存在しないため、フェイルオーバー、冗長性、データセンターの場所、ストレージ要件に関する情報が誤って伝えられています。
フェイルオーバー、冗長性、災害復旧、データセンターの場所、およびストレージ要件の詳細は、開発チームの入力により既知であり、正確です。

運用チームは開発チームの進捗状況についてまったく知りません。 彼女はまた、彼女自身のアイデアに基づいてモニタリング計画を策定します。

運用チームは、開発チームの進捗状況を十分に認識しています。 彼女は開発チームとも交流し、IT とビジネスのニーズを満たす監視計画を共同で開発します。 また、アプリケーション パフォーマンス監視 (APM) ツールも使用します。

アプリケーションの起動前に負荷テストを実行すると、アプリケーションがクラッシュし、起動が遅れます。
アプリケーションを実行する前に負荷テストを実行すると、パフォーマンスが低下します。 開発チームはボトルネックを迅速に解決し、アプリケーションは予定どおりに起動します。

DevOps ライフサイクル

DevOps には、一般に受け入れられている特定のプラクティスの導入が含まれます。

継続的な計画

継続的な計画は、ビジネスやビジョンの価値をテストし、継続的に適応し、進捗状況を測定し、顧客のニーズから学び、機敏性に対応するために必要に応じて方向を変更し、ビジネス計画を再構築するために必要なリソースと成果物を特定することにより、小規模から開始する無駄のない原則に依存しています。

共同開発

共同開発プロセスにより、異なるタイムゾーンにまたがる企業、開発チーム、テスト チームが高品質のソフトウェアを継続的に提供できるようになります。 これには、マルチプラットフォーム開発、クロス言語プログラミングのサポート、ユーザー ストーリーの作成、アイデア開発、ライフサイクル管理が含まれます。 共同開発には、頻繁なコード統合と自動ビルドを促進する継続的統合のプロセスと実践が含まれます。 コードをアプリケーションに頻繁にデプロイすることで、統合の問題がライフサイクルの早い段階 (修正が容易なとき) で特定され、プロジェクトが継続的かつ目に見える進捗を示すため、継続的なフィードバックを通じて全体的な統合作業が軽減されます。

継続的なテスト

継続的なテストは、開発チームがスピードと品質のバランスを取るのに役立ち、テストのコストを削減します。 また、サービスの仮想化によってテストのボトルネックが排除され、システムの変更に応じて簡単に共有、展開、更新できる仮想化テスト環境の作成が容易になります。 これらの機能により、テスト環境のプロビジョニングと保守のコストが削減され、テスト サイクル時間が短縮され、ライフサイクルの早い段階で統合テストを実行できるようになります。

継続的なリリースと展開

これらの手法は、継続的なリリースとデプロイメントという核となる実践をもたらします。 これは、主要なプロセスを自動化する継続的なパイプラインによって保証されます。 ボタンを押すだけでデプロイメントが可能になるため、手動の手順、リソースの待ち時間、再作業が削減され、その結果、より多くのリリース、より少ないエラー、そして完全な透明性が実現します。

自動化は、安定した信頼性の高いソフトウェア リリースを保証する上で重要な役割を果たします。 最大の課題の XNUMX つは、ビルド、リグレッション、デプロイメント、インフラストラクチャの作成などの手動プロセスを自動化することです。 これにはソースコードのバージョン管理が必要です。 テストと展開のシナリオ。 インフラストラクチャおよびアプリケーション構成データ。 アプリケーションが依存するライブラリとパッケージ。 もう XNUMX つの重要な要素は、すべての環境の状態をクエリできることです。

継続的な監視

継続的な監視により、開発チームがアプリケーションを運用環境に展開する前に、運用環境での可用性とパフォーマンスを理解できるようにするエンタープライズ グレードのレポートが提供されます。 継続的なモニタリングによって提供される早期のフィードバックは、エラーのコストを削減し、プロジェクトを正しい方向に導くために重要です。 この実践には、通常、アプリケーションのパフォーマンスに関連するメトリクスを明らかにする監視ツールが含まれることがよくあります。

継続的なフィードバックと最適化

継続的なフィードバックと最適化により、顧客の流れを視覚的に表現し、問題領域を正確に特定します。 価値を最大化し、より多くの取引を確実に完了させるために、販売前と販売後の両方の段階でフィードバックを含めることができます。 これらすべてにより、顧客の行動やビジネスへの影響に影響を与える顧客の問題の根本原因を即座に視覚化できます。

DevOpsのメリット

DevOps は、開発者と運用担当者がチームとして協力して共通の目標を達成する環境の構築に役立ちます。 このプロセスにおける重要なマイルストーンは、継続的インテグレーションと継続的デリバリー (CI/CD) の実装です。 これらの手法により、チームはバグを減らしてより迅速にソフトウェアを市場に投入できるようになります。

DevOps の重要な利点は次のとおりです。

• 予測可能性: DevOps では、新しいリリースの失敗率が大幅に低くなります。
• 保守性: DevOps を使用すると、新しいリリースが失敗した場合やアプリケーションがダウンした場合でも簡単に回復できます。
• 再現性: ビルドまたはコードのバージョン管理により、必要に応じて以前のバージョンを復元できます。
• 品質の向上: インフラストラクチャの問題に対処すると、アプリケーション開発の品質が向上します。
• 市場投入までの時間: ソフトウェア配信の最適化により、市場投入までの時間が 50% 短縮されます。
• リスクの軽減: ソフトウェアのライフサイクルにセキュリティを実装すると、ライフサイクル全体を通じて欠陥の数が減少します。
• コスト効率: ソフトウェア開発におけるコスト効率の追求は、上級管理職にとって魅力的です。
• 安定性: ソフトウェア システムはより安定しており、安全であり、変更を監査できます。
• より大きなコードベースを管理可能な部分に分割する: DevOps はアジャイル開発手法に基づいており、これにより、大規模なコードベースをより小さな管理可能な部分に分割できます。

DevOpsの原則

DevOps の採用により、進化した (そして進化し続ける) いくつかの原則が生まれました。 ほとんどのソリューション プロバイダーは、さまざまな技術を独自に修正して開発しています。 これらの原則はすべて、DevOps への総合的なアプローチに基づいており、あらゆる規模の組織で使用できます。

本番環境に似た環境で開発とテストを行う

その目的は、開発チームと品質保証 (QA) チームが実稼働システムと同様に動作するシステムを開発およびテストできるようにして、アプリケーションが展開の準備が整うずっと前にアプリケーションがどのように動作し、実行されるかを確認できるようにすることです。

アプリケーションは、ライフサイクルのできるだけ早い段階で運用システムに接続し、潜在的な XNUMX つの主要な問題に対処する必要があります。 まず、実際の環境に近い環境でアプリケーションをテストできるようになります。 XNUMX 番目に、アプリケーション配信プロセスを事前にテストおよび検証できるようになります。 XNUMX 番目に、運用チームはライフサイクルの早い段階でアプリケーションの展開時に環境がどのように動作するかをテストできるため、高度にカスタマイズされたアプリケーション中心の環境を作成できます。

再現可能で信頼性の高いプロセスで導入する

この原則により、開発チームと運用チームはソフトウェア ライフサイクル全体を通じてアジャイル ソフトウェア開発プロセスをサポートできます。 自動化は、反復的で信頼性の高い反復可能なプロセスを作成するために不可欠です。 したがって、組織は、継続的かつ自動化された展開とテストを可能にする配信パイプラインを作成する必要があります。 また、頻繁なデプロイメントにより、チームはデプロイメントプロセスをテストできるため、ライブリリース中のデプロイメント失敗のリスクが軽減されます。

作業品質の監視とチェック

組織は、メトリクスと主要業績評価指標 (KPI) をリアルタイムで取得するツールを備えているため、実稼働環境でのアプリケーションの監視に優れています。 この原則により、ライフサイクルの早い段階で監視が進められ、自動テストによってプロセスの早い段階でアプリケーションの機能的属性と非機能的属性が確実に監視されます。 アプリケーションをテストしてデプロイするときは常に、品質指標を検査して分析する必要があります。 監視ツールは、生産中に発生する可能性のある運用上および品質上の問題を早期に警告します。 これらの指標は、すべての関係者がアクセスでき、理解できる形式で収集される必要があります。

フィードバックループの改善

DevOps プロセスの目標の XNUMX つは、組織がより迅速に対応し、変更を加えられるようにすることです。 ソフトウェア配信において、この目標を達成するには、組織が早期にフィードバックを受け取り、実行された各アクションから迅速に学習することが必要です。 この原則では、組織は、利害関係者がフィードバック方式でアクセスして対話できるコミュニケーション チャネルを作成する必要があります。 開発は、プロジェクトの計画や優先順位を調整することで行うことができます。 製造業は生産環境を改善することで行動できます。

デベロッパー

• 企画: Kanboard、Wekan、その他の Trello の代替手段。 GitLab、Tuleap、Redmine、およびその他の JIRA 代替手段。 Mattermost、Roit.im、IRC、その他の Slack の代替手段。
• コードを書く: Git、Gerrit、Bugzilla。 Jenkins およびその他の CI/CD 用オープンソース ツール
• アセンブリ： Apache Maven、Gradle、Apache Ant、Packer
• テスト: JUnit、Cucumber、Selenium、Apache JMeter

オプス

• リリース、展開、運用: Kubernetes、Nomad、Jenkins、Zuul、Spinnaker、Ansible、Apache ZooKeeper、etcd、Netflix Archaius、Terraform
• 監視： このガイドで説明されている Grafana、Prometheus、Nagios、InfluxDB、Fluentd など

(*運用ツールには運用チームが使用する順序で番号が付けられていますが、そのツールはリリース ツールや展開ツールのライフサイクル ステージと重複しています。読みやすくするために、番号は削除されています。)

結論

DevOps は、開発者と運用を XNUMX つのユニットとして統合することを目的とした方法論として人気が高まっています。 これは従来の IT 運用とは異なり、ユニークであり、アジャイルを補完します (ただし、それほど柔軟性はありません)。

ゼロから人気の職業に就く方法、または SkillFactory の有料オンライン コースを受講してスキルと給与の面でレベルアップする方法の詳細をご覧ください。

• DevOpsコース (12ヶ月)

さらに多くのコース

• 機械学習コース （12週間）
• データサイエンスの専門職をゼロから教える (12ヶ月)
• あらゆる開始レベルのアナリストの職業 (9ヶ月)
• Web開発のためのPythonコース (9ヶ月)

便利

• 450 の無料アイビー リーグ コース
• 2020 年のデータ サイエンスのトレンド
• データサイエンスは死んだ。 ビジネスサイエンス万歳
• ステロイドに関するデータ サイエンス: 意思決定インテリジェンスへの入門
• 最も成功し、最もスキャンダラスなデータ サイエンス プロジェクト: Cambridge Analytica

出所： habr.com