タグ付けされた質問 「operating-model」

4
エンジニアがコードを展開および実行するときに、職務分掌を可能にするプロセスまたはツールは何ですか?
金融サービス部門などの規制の厳しい環境では、職務分掌は開発責任と生産特権を持つ個人間の衝突を回避するための不可欠なメカニズムです。 従来、これは開発者がコードを開発してから運用に引き継ぐことを意味していましたが、多くの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のプラクティスと文化を採用している会社内で、職務分掌を達成する方法、またはより一般的には結託のリスクを軽減する方法。

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

4
DevOpsワークフローを中止することの長所/短所?
私は、devospスタイルのワークフローから従来のdev-then-ops(何と呼ぶか​​わからない)に移行することが良いアイデアかどうかを評価しようとしています。 私たちは、従業員が4000人いる従来のメディア(ソフトウェア以外)などの企業に隠れている5人の小さな部門です。2年前に、部門での生産を大幅に拡大できるソフトウェアの構築を開始しました。私たちはかなり成功しており、より大きな会社が注目を集め始めています。これまでのところ、私たちは、最大10のサービスのAWSマイクロサービスプラットフォームとなったものの設計、開発、デプロイを単独で担当してきました。私たちのチームはDevOpsとして識別しませんが、間違いなく私たちはDevOpsの生活を送っています。各開発者は、コードとそれが実行されるシステムの両方に精通しています。 私たちがまもなく直面する問題の1つは、親会社のIT部門と私たちの間でどのような「効率」が共有されるかです。私たちのプロジェクトオーナーは通常、社内での学習よりもアウトソーシングを好むため、私たちの場合、これらの効率は、可能な限り多くのIT作業を「オフプレート」で行うことを意味します。現在、私たちのチームは、コーディングとインフラストラクチャの経験が70/30%分かれていると思います。IT部門は、IT開発の領域にしっかりと属しており、ソフトウェア開発に目に見えるクロスオーバーはありません。 私たちのプロジェクトオーナー(技術者ではない個人)は、できる限り多くの作業をITチームに引き渡すことで、削減した運用作業の1時間あたりの生産性が最大1:1向上することを期待しています。私はこれについては懐疑的です。私たちの製品はまだプレベータ版です(すでに重要なビジネス資産であるにもかかわらず)。IT部門との限られた経験の中で、ファイルシステムのアクセス許可の変更などの単純なことには通常、大幅な遅延があります。 現在、私の理想的なソリューションは、IT部門が私たちを "採用"し、ITオフィスの標準と要件を確実に満たしながら、私たち自身の仕事を展開し続けることです。それがどれほど現実的かはわかりません。さらに、短期的には追加の運用作業が追加されるため、プロジェクトオーナーが推奨するアプローチとはほぼ逆です。 私たちの状況では、DevOpsアプローチを維持することとITを引き継ぐことの賛成/反対の可能性は何ですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.