知っておくべきDevOpsとSREの5つの基本的な違い
公開: 2021-02-22情報技術とソフトウェア開発の世界では、DevOpsをSREと混同して、同じことを意味することがよくあります。 ただし、この2つには大きな違いがあります。 サイト信頼性エンジニアリング（SRE）は近年注目を集めていますが、DevOpsはずっと長く存在しています（DevOpsという用語が存在する前でも）。
簡単に言うと、DevOpsとSREはどちらも、ソフトウェアをより迅速に提供するために導入された手法です。 2つの違いは、アプローチにあります。 DevOpsはソフトウェア開発ライフサイクルの短縮に重点を置いており、SREは同じ目的を達成するためにシステムの弱点を排除することに重点を置いています。
この記事では、DevOpsとSREが互いに異なる基本的な方法を見ていきます。 その前に、DevOpsとSREとは何かを理解することから始めましょう。
目次
DevOpsとは何ですか？
The DevOpsHandbookとThePhoenixProjectの著者であるGeneKimの言葉を借りれば、
「DevOpsは、世界クラスの信頼性、運用、セキュリティを維持しながら、開発から運用へのテストまで、計画された作業の迅速な流れを[可能にする]一連の文化的規範と技術慣行です。 DevOpsは、あなたが何をするかではなく、あなたの結果が何であるかについてです。」
そのため、DevOpsは主に、ソフトウェア開発ライフサイクル（SDLC）を高速化するために、組織内の文化的慣習を変革することに重点を置いています。 個人、グループ、または役職を対象としていません。 DevOpsは、情報技術運用チームとソフトウェア開発チームの両方の間のコラボレーションを強化することを目的としています。
それが何をし、どのように行うかは重要ではありません。 プロセスの結果のみが承認されます。
DevOpsは一連の原則を使用して、ソフトウェアエンジニアリングチームの本番システムへの露出を強化し、IT運用チームが不一致を開発チームにさらに効率的にエスカレートできるようにします。 実際、SREは、プロアクティブなテスト、速度、可観測性の実現、サービスの信頼性の向上を促進することにより、DevOps組織で重要な役割を果たします。 DevOpsは、すべてのDevOps中心の組織が、モデルCALMSで概説されている文化的原則に従って運用することを推奨しています。
SREとは何ですか？
SREは、サイト信頼性エンジニアリングの略で、技術運用の監督を担当するGoogleの上級副社長BenTreynorによって造られた用語です。
Drew Farnsworth（Green Lane Designの）は次のように説明しています。「私は一般的に、SREを開発が運用を制御するシステムと考えています。 これは、環境がITスタックの最も基本的なコンポーネントに分解され、ハードウェアに組み込まれたベストプラクティスとともに展開されるシステムです。」
基本的に、ソフトウェア開発の専門知識を持つSREチームは、配信速度とシステムの信頼性のバランスを維持しながら、システム生産の問題を解決する責任を負っています。 このように、SREアプローチでは、運用の役割を担うソフトウェア開発担当者を集めて、組織のポリシーを維持するために構造化されたエンジニアリング手法を適用します。
これらは、ソフトウェアチームがシステムの信頼性を高めるための技術サービスを開発するために、システムが常に利用可能で効率的に実行されていることを保証します。 大きな問題が発生する前に、潜在的な弱点を特定するのはSREの責任です。
DevOpsとSRE：DevOpsとSREの主な違い
実際には、DevOpsとSREは、DevOps中心の構造の一部としてのSREが、技術サービスの信頼性の向上に重点を置いている補完的な分野と見なす必要があります。 したがって、基本的に、DevOpsとSREのようなものはありません。
したがって、このセクションで行っているのは、DevOpsとSREの根本的な違いを評価することです。
変更の実装
更新が頻繁に行われ、ユーザーがより新しく、より関連性の高いテクノロジーにアクセスできるようにするために、DevOpsとSREの両方が迅速にペースを調整する予定です。 ただし、DevOpsは慎重に徐々に前進しますが、SREはより速く移動できない場合のコストを考慮に入れます。
自動化を実装し、ツールを使用してこの目的を達成します。
失敗を正常と見なす
DevOpsは、失敗を受け入れ、それを抑圧を学ぶことと見なすのに非常に大きな役割を果たします。 そのため、障害はプロセスの一部であり、システムを100％フォールトトレラントにすることに重点を置いていないことを受け入れることで、非難のない文化を促進します。 この例は、SimianArmyを備えたNetflixです。
一方、SREは、非難のない事後分析をサポートします。 この背後にある目的は、失敗の原因を特定し、説明責任を割り当て、将来同様の失敗を回避するように取り組むことです。 システムで発生する可能性のある障害の数は、エラーバジェットに含まれます。 SLI、SLO、およびSLAメトリックは、これを決定して生産コストを削減します。 基本的に、SREは、潜在的な障害を回避するために、予防的な監視と警告の手法を採用しています。
世界のトップ大学からオンラインでソフトウェア開発コースを学びましょう。 エグゼクティブPGプログラム、高度な証明書プログラム、または修士プログラムを取得して、キャリアを早急に進めましょう。
自動化とイノベーション
DevOpsは、自動化を最重要視しています。 DevOpsに重点を置いた環境では、これはシステムが可能な限り自動化されることを意味し、退屈なリリースになります。 開発者がコードをコミットした後、以下のアクティビティのほとんどは、すべてではないにしても、自動化する必要があります。
したがって、CI / CDを追求するDevOpsの理由は、より高速で高品質のシステムを開発することです。
CI / CDを追求するSREの理由は異なり、障害のコストを削減することを目的としています。 展開やバックアップなどの操作における一般的、一般的、または反復的なタスクは、注目に値しないと見なされます。 したがって、SREは、運用上の労力を回避するために特定の時間を確保します。 これは、新しいテクノロジーやアーキテクチャ関連のアクティビティの実行や革新など、より魅力的なタスクを追求できるようにするために行われます。
チェックアウト：初心者向けのDevOpsプロジェクト
組織のサイロを分解する
展開プロセスに関しては、開発者とオペレーターが対立します。 開発者は、機能がコーディングされるとすぐに展開されることでメリットが得られますが、運用担当者は、展開プロセスを妨げるシステムを利用可能にすることに重点を置いています。
DevOpsとSREはどちらも、組織内のサイロを削除する方法が異なります。
DevOpsハンドブックで説明されているように、DevOpsは、より小さなバッチでの運用や構成のより適切な管理などのプラクティスを含めることで、この問題に取り組みます。
SREは、チーム間のフローを最適化することだけでなく、システムの運用を支援することも目的としています。 彼らはコンサルタントとしてチームに統合し、システムを実行する責任を共有することによって開発者をサポートすることによってそうします。 これは、SREが組織内のサイロを破壊する方法です。
成功した実装の測定
DevOpsメトリックは、すべて操作の速度に関するものです。 これには、展開が行われる頻度、展開にかかる時間、および問題が発生する頻度が含まれます。
PuppetとDORAからの2017年のレポートによると、DevOpsでの実装の成功の測定は以下に依存します。
- 展開が発生する頻度
- コードのコミットとそのデプロイの間の期間
- 展開が失敗する頻度
- 展開の失敗からの回復に時間がかかる
これらのフィードバックループは、実験での変更を容易にしながら、DevOpsがシステム品質を向上させるのに役立つように配置されています。
一方、SREは、システムの信頼性を念頭に置きながら、システムの改善に取り組んでいます。 実装が成功したかどうかを判断するために、次の主要なメトリックが考慮されます。
- サービスレベル目標（SLO）
- サービスレベルインジケーター（SLI）
- サービスレベルアグリーメント（SLA）
上記のメトリックは、システムの信頼性の指標です。 これらのメトリックは、変更のリリースが本番環境に到達するかどうかを事前に決定します。
SREでは、速度と品質のこれらのメトリックは、新しい機能に取り組むのではなく、エラーバジェットを作成してシステムの信頼性を向上させるときに役立ちます。
読む：インドのDevOpsエンジニア給与
結論
Googleは、TreynorがSREを次のように説明している本番システムにサイト信頼性エンジニアリングを実装する方法に関する電子書籍を公開しました。
「SREは、ソフトウェアエンジニアに運用チームの設計を依頼したときに起こることです。」
DevOpsとSREの違いについては、SREは運用チームではなく開発者によって推進されていることを覚えておく必要があります。 メンテナンスとモニタリングはどちらも、主に開発者の管理下にあります。 それが主に2つの分野を区別するものです。
ビッグDevOps、フルスタック開発について詳しく知りたい場合は、upGrad＆IIIT-Bのソフトウェア開発のエグゼクティブPGプログラム-フルスタック開発の専門分野をチェックしてください。これは、働く専門家向けに設計されており、500時間以上の厳格なトレーニングを提供します。 9以上のプロジェクトと割り当て、IIIT-B卒業生のステータス、実践的な実践的なキャップストーンプロジェクト、トップ企業との雇用支援。
