「SREは、ソフトウェアエンジニアに運用チームの設計を依頼すると発生します。」– サイト信頼性エンジニアリング
Googleのサイト信頼性エンジニアリングブックがリリースされて以来、複数回、SREは既存の運用モデルまたはアプリケーションサポートモデルの拡張であると言われました。
Sysの違いを定義する質問がいくつかありました。管理者、DevOpsエンジニア、およびサイト信頼性エンジニア：
ただし、これらの質問や回答のいずれも、システム管理者とサイト信頼性エンジニアの違いを説明していません。
広義には、Googleのサイト信頼性エンジニアリングの実践と、ビジネス内の従来の分離された開発および運用機能との主な違いは何ですか。
回答:
ありがたいことに、サイト信頼性エンジニアリングはGoogle内で開発され、ごく最近になってより広範なコミュニティに進出し始めたため、かなり明確に定義されています。何ではない、ウェブ・オペレーション（ -明快さの欠如の一例として、あなたはあなたの質問の両方を使用するか、「システム管理」）ですが、。どちらかが完全にわからない場合、2つのことの違いを議論することは困難です。
しかし、私は冒険好きなので、試してみます。
非常に伝統的な店では、開発者とシステム管理者はお互いから非常に隔離されています。開発者はアプリをビルドし、コードがコミットされるとすぐに仕事が完了したと見なします。システム管理者はビルドアーティファクト（インタープリター言語の場合は単なるコードかもしれません）を取得し、運用サーバーに展開します。アプリケーションをスムーズに実行し、一般に運用環境を管理するのは、システム管理者の仕事です。ただし、多くの場合、パフォーマンスの問題はアプリのアーキテクチャの問題に起因します。システム管理者はアプリが何をしているのかを知るためのプログラミング知識がなく、開発者は本番トラフィックを使用した本番トポロジーでアプリがどのように動作するかを知らないため、誰も問題を解決できません。
さらに、開発者は通常、新機能をどれだけ迅速に作成できるかについて判断されますが、システム管理者は本番環境でアプリが壊れる頻度が低いかどうかについて判断されます。変化は破損の主な原因の1つであるため、2つの部門が互いに対立します。これは、ビジネスと関係者を傷つける古い競争です。
ある時点で、一部の開発者中心の企業はこれに非常に悩まされ、「NoOps」の実践を開始しました。運用部門とそれに伴う障害を排除しました。実際には、これは開発者がオペレーションの役割を引き受けたが、古いタイトルを維持したことを意味していました。
でNoOpsを取り巻く議論、ジョンAllspaw、その後、EtsyのでテクニカルオペレーションのVPとのエディタ尊敬のWebオペレーション本は、Etsyのでは、このように役割を定義しました。
Etsyオペレーションは以下を担当します：
- 停電への対応、オンコール
- 警告システムのしきい値設定、設計
- アーキテクチャの設計とレビュー
- メトリックコレクションの構築
- アプリケーション構成
- インフラストラクチャの構築/管理
Etsy開発の責任は次のとおりです。
- 停電への対応、オンコール
- 警告システムのしきい値設定、設計
- アーキテクチャの設計とレビュー
- メトリックコレクションの構築
- アプリケーション構成
- 一般向けコードの配送
これらのリストはどちらも包括的なものではなく、何かが欠けていると確信しています。Etsy Opsは実稼働向けのアプリケーションの変更を行いましたが、それらはごくわずかですが、実際の（そして時には非常に深い）ものです。Etsy DevはChefの変更を行いますが、それらはごくわずかです。責任に非常に多くの重複がある場合、なぜ違いがあるのか、尋ねることがありますか？ドメインの専門知識と背景。多くの開発者は、TCPスロースタートがどのように機能するかについて深い知識を持っていませんが、Opsは知っています。ソートまたは関連性アルゴリズムの包括的な知識を持っているOpsは多くありませんが、Devにはあります。Opsは、許容できる精度でリソース使用量を迅速に予測する長年の経験がありますが、Devにはありません。開発者は、すべてのレイヤー1〜7にワークロードオプションを分散することの長所と短所を認識していない場合があります。エンティティ関係のモデリングは開発者にとって自然なことかもしれませんが、そうではないかもしれません。最終的に、彼らは両方の層と層で、さまざまな形式のビザンチン障害シナリオと回復パターンのソリューションを発見します。
彼の世界では、開発者と運用エンジニアは非常によく似た高レベルのスキルセットと責任を持っていました。彼らが異なっていたのは専門知識でした。彼らの異なる専門分野は、彼らが問題を解決するために協力することを奨励し、彼らの共通の基本レベルのスキルは彼らにそれを行うための言語を与えました。
これは一般に、ほとんどの場合に私が上陸するWeb操作の定義です。それが私たちが一緒に続けるつもりです。
それでは、サイト信頼性エンジニアリングとは何ですか？
Google SREブックは、SRE ...の定義で開き、次に別の1 ...で、役割を定義し続ける章と詳細をカバーする本全体を費やします。1つの組織で開発された場合でも、仕事を1つの合意された定義に凝縮することは難しいようです。
まず、ベントレイナーがGoogleに入社し、最初のサイト信頼性エンジニアリングチームを設立した2003年にさかのぼる必要があります。数段落前、2010年代初頭であったことを思い出してください。しかし、2003年の時点でも、業界はシステム管理者と開発者の格差を自然な方法として設定していました。したがって、ソフトウェアエンジニアが運用チームを作成した場合にSREが起こるとBenが言ったとき、これは現在のように2つの世界がより過激に融合したものでした。
序文で与えられた定義は、3つの単語のそれぞれを個別に強調しています。
導入の章では、サイト信頼性エンジニアリングの教義を次のようにリストしています。
私は、サイト信頼性エンジニアリングを最新のWebオペレーションの特殊なサブセットとして分類します。SREの組織は、すべてを自動化することに重点を置いており、かなり大規模な企業でのみ費用対効果が高い程度です。エラーバジェットなどのアイデアは、サービスに多数のリクエストがある場合にのみ機能します。そうしないと、粒度が失われます（サービスが小さい場合、特定のエラーがリクエストの0〜20％に影響する場合があります）。セキュリティなどの関連分野は、SREの定義には含まれていません。これは、真のSREチームを持つのに十分な規模の企業がセキュリティ専用のチームを持っているためです。
Googleが定義するSREプログラムは、Googleの特定のニーズに合わせて開発されたWeb運用であり、必ずしも他の場所に適用できるとは限りません。
ただし、サイト信頼性エンジニアリングは最近、より広範な業界での使用に拡大しています。私がはるかに小さな会社で働いていて、私の仕事の説明がJohn Allspawの2012 Etsy web opsの定義にかなり合っていたとしても、私の現在の役職はSREです。私の理論では、単一の分野の進化を支持するための略記として、タイトルを通じて進歩してきました。
それでは、sysadminとSREの違いは何ですか？彼らがタイトルを受け取った年。従来の運用とサイトの信頼性エンジニアリングの違いは何ですか？SREは、新しいツール（hello、containers！）を使用した現在のopsの単なる化身であり、ネットワーク化されたプログラムがますます大きく重要になっているため、1人のエンジニアがより多くのことを行えるようになっています。