タグ付けされた質問 「sre」

SREとDevOpsの違いは何ですか？ サイトの信頼性のエンジニアリングと開発オペレーションは、かなり詳細に重複しているようです。どのグループが何に対して責任があるのか​​をどのように知ることができますか？ SREはサーバーとネットワークの保守に関するものであり、DevOpsはコードの保守に関するもののようですが、それは正しいですか？これら2つの間にはまだかなりの量の重複がありませんか？

57 terminology  sre  job-role  team-role 

金融サービス部門などの規制の厳しい環境では、職務分掌は開発責任と生産特権を持つ個人間の衝突を回避するための不可欠なメカニズムです。 従来、これは開発者がコードを開発してから運用に引き継ぐことを意味していましたが、多くのDevOpsオペレーティングモデルでは、開発と運用の分離は少なくともぼやけています。 Googleのサイト信頼性エンジニアリング（SRE）では、Google内に個別のSRE機能がありますが、開発者は、運用負荷が高いときにSREをバックストップするために持ち込まれます。 で「あなたはそれを構築し、あなたを実行それ」モデルは個別の操作機能はありません。 職務分離メカニズムの根本原因を数か月にわたって掘り下げた後、Sarbanes Oxleyセクション404：内部統制の管理評価を満たすために主に存在するようです。 （a）必要なルール。委員会は、1934年証券取引法第13条（a）または15条（d）で要求される各年次報告書に、内部統制報告書を含めることを要求する規則を規定します。 （1）財務報告のための適切な内部統制構造と手順を確立および維持するための経営者の責任を述べる。そして （2）発行者の直近の会計年度末の時点で、財務報告のための発行者の内部統制構造と手順の有効性の評価を含む。 （b）内部統制の評価と報告。サブセクション（a）で要求される内部統制評価では、発行者の監査報告書を作成または発行する各登録会計事務所は、発行者の経営者が行った評価を証明し、報告しなければなりません。このサブセクションに基づいて行われた認証は、理事会によって発行または採用された認証契約の基準に従って行われるものとします。そのような認証は、個別の契約の対象にはなりません。 コメントに基づいて、私が行っているいくつかの仮定を呼び出すことが重要です。 私は主に大規模市場の金融サービスを検討しています。つまり、取引量は多いが比較的低い価値です。これは、異なる取引価値プロファイルを持つ商業金融サービスとは対照的です。 金融機関のオンラインサービスは、さまざまなリスクを考慮した多くのコンポーネントで構成されます。 Move Money-アカウント間でお金を移動したり、異なる所有者のアカウント間で送金したりします。いくつかを挙げると、マネーロンダリング防止、詐欺防止、および禁輸国を考慮しなければならない作業。 顧客獲得 -Move Moneyに比べて取引量が少ないため「リスク」が少ないが、まだ検討が必要です。 インターネットバンキング -さまざまなレベルのリスクを伴う幅広いサービスをカバーしています。MoveMoneyはその一部と見なされます。 リスクに応じてそれぞれに異なるアプローチをとることが考えられますが、単純にするために、最もリスクの高いオペレーションの一部に適用されるソリューションに取り組んでいます。 TL; DR：証券取引委員会の 規制に準拠する適切な内部統制を確保することは、経営者の責任です。 Sarbanes Oxley 404は通常、トップダウンリスクアセスメントを完了することで満足します。その一部は共謀のリスクを評価し、緩和戦略を進めます。 開発者が日常的にソース管理と生産の両方にアクセスできるDevOpsのプラクティスと文化を採用している会社内で、職務分掌を達成する方法、またはより一般的には結託のリスクを軽減する方法。

18 sre  financial-services  operating-model 

「SREは、ソフトウェアエンジニアに運用チームの設計を依頼すると発生します。」– サイト信頼性エンジニアリング Googleのサイト信頼性エンジニアリングブックがリリースされて以来、複数回、SREは既存の運用モデルまたはアプリケーションサポートモデルの拡張であると言われました。 Sysの違いを定義する質問がいくつかありました。管理者、DevOpsエンジニア、およびサイト信頼性エンジニア： SysadminとDevOpsエンジニアの違いは何ですか？ SREとDevOpsの違いは何ですか？ DevOpsを初心者に紹介するための有効な定義は何でしょうか？ ただし、これらの質問や回答のいずれも、システム管理者とサイト信頼性エンジニアの違いを説明していません。 広義には、Googleのサイト信頼性エンジニアリングの実践と、ビジネス内の従来の分離された開発および運用機能との主な違いは何ですか。

14 sre  operating-model  sysadmin 

スクラムやかんばんなどのアジャイルプラクティスは、主にソフトウェア開発用に設計されました。 中断および予定外の作業は、ほとんどのSRE（サイト信頼性エンジニアリング）またはDevOpsチームが行うことの重要なコンポーネントです。Jiraのような追跡システムを使用して作業を管理することは常に役立ちますが、スプリントまたはかんばんはSREチームにとって本当に機能しますか？ 私が見る制約は： 仕事は本質的に非常に動的であり、優先順位は日々変化します。このため、2週間のスプリント期間は非常に積極的で、不要なオーバーヘッドが追加されます。 待機中の人々は問題に別の側面を追加します。時々、複数のチームメンバーがオンコール/事後のタスクに関与する場合があります。 チームには単一の「製品」がないため、一般的な計画プロセスに身を任せません。 タスク間の重複がないため、毎日のスタンドアップ会議はあまり意味がないかもしれません チームは複数のパートナーチームに関連するタスクに取り組んでいるため、複数のJiraプロジェクトにまたがっている可能性があります。スプリントまたはカンバンボードでは1つのJiraプロジェクトしか許可されないため、すべての作業に対応できない場合があります。 私が話し合った多くのSREから聞いたところによると、スプリント計画はそれらに対してまったく機能していません。コミュニティから、スプリントとかんばんの経験について聞いてみたいと思います。 私もこの質問をscrum.orgで行いました： SREチームはスクラムを効果的に使用できますか？

10 process  sre  agile 

サイト信頼性エンジニアリング専用のstackexchangeがないため、これは1つに近いことがわかりました。 SREの原則についてのスライドデッキのインスピレーションとして使用する優れたリソースがいくつかあります[SREスライド]。 まだ見つかりません： ショート 簡潔な 例 組織にSREを実装するための支出リソースの動機付け。 私の職業生活で経験したことのほとんどは、機密性の高い事件と数でした。私は、SREが知っているほとんどの数値が、企業内で提示されるために「内部」のままであることを懸念しています。 ただし、いくつかの調査（できれば一連の）死後のすばらしい例（1つずつでも良い）を知っている可能性があるため、「nから成長した変更の組織速度にSREモデルを導入した後」などの強力な議論を行うことができます。 xあたりのmのリリースプッシュに、yによる可用性の向上とz "（ブレーンストーミング）または他のハードデータポイントによるコストの削減を伴いますか？ [SREスライド]-いくつかの例： サイトの信頼性エンジニアリング：ITSM Academy、Inc.によるエンタープライズ導入ストーリー（ITSM Academyウェビナー） Squareのプラットフォームエンジニア、Grier JohnsonによるSRE From Scratch GOTO 2017•Googleでのサイト信頼性エンジニアリング•Christof Leng PSこの質問を、このサイトのガイドラインによりよく適合するように言い換えることができる場合は、コメントで提案を提供し、改善のための変更を提供してください。それ以外の場合は、他の優れたプラットフォームに感謝します（ただし、reddit.com / r / sreは私に大きな印象を与えませんでした）

8 sre 

DevOpsは主に配信速度に焦点を当て、SREは本番環境の信頼性に焦点を当てていますが、本番環境のモニタリング、アラート、パフォーマンス、ユーザーエクスペリエンス、インシデント管理、RCAに焦点を当て、コードの欠陥に取り組み、ビジネス機能を理解するプロダクションサポートエンジニアはどこに適していますか？ SREの世界では、プロダクションサポートエンジニアはSREとより連携するのでしょうか、それともSREと統合するのでしょうか。

7 culture  sre  organization