Questions tagged «operating-model»

4
工程师部署和运行代码时,哪些流程或工具可实现职责分离?
在金融服务等高度管制的环境中,职责分工是避免具有发展责任和生产特权的个人之间发生冲突的重要机制。 传统上,这意味着开发人员先开发代码,然后将其移交给操作,但是在许多DevOps操作模型中,开发和操作之间的隔离至少是模糊的: 在Google的站点可靠性工程(SRE)中,实践是Google内有一个单独的SRE功能,但是,在高运营负荷时,开发人员被邀请来支持SRE。 在“构建,运行”模型中,没有单独的操作功能。 在花费数月时间深入研究职责隔离机制的根本原因之后,似乎似乎主要存在满足萨班斯·奥克斯利法案第404节:内部控制的管理评估: (a)所需规则。委员会应制定规则,要求1934年《证券交易法》第13(a)或15(d)条要求的每个年度报告均应包含内部控制报告,该报告应- (1)陈述管理层的责任,以建立和维持适当的财务报告内部控制结构和程序;和 (2)包含截至发行人最近一个会计年度结束时对发行人财务报告内部控制结构和程序有效性的评估。 (b)内部控制评价和报告。根据(a)款要求的内部控制评估,每个为发行人准备或发行审计报告的注册会计师事务所均应证明并报告发行人管理层的评估。根据本小节做出的证明应按照董事会发布或采用的证明业务的标准进行。任何此类证明均不应成为单独的约定的主题。 根据这些评论,重要的是要指出我所做的几个假设: 我主要考虑的是大众市场金融服务,即交易量很高,但价值相对较低。这与具有不同交易价值特征的商业金融服务相反。 金融机构的在线服务将由许多具有不同风险考虑因素的组件组成: 转移资金 -在帐户之间转移资金或在不同所有者的帐户之间转移资金。必须考虑反洗钱,欺诈保护和禁运国家的行动。 客户获取 -与“移动资金”相比,交易量较低,但“风险”较低,但仍需要考虑。 网上银行 -涵盖范围广泛且风险程度不同的服务,“移动资金”将被视为其中的一部分。 可以想象,对于每种风险,可以针对每种风险采取不同的方法,但是,为了保持简单性,我正在努力寻求一种适用于某些风险最高的运营的解决方案。 TL; DR:管理层的责任是确保建立适当的内部控制措施,以符合美国证券交易委员会的 规定。 通常,通过完成自上而下的风险评估可以使Sarbanes Oxley 404满意,其中一部分将评估共谋风险并提出缓解策略。 在采用DevOps实践和文化的公司中,开发人员通常可以同时访问源代码控制和生产,如何实现职责分离,或更普遍地讲,如何降低合谋风险。

1
传统的开发和运营模型与站点可靠性工程之间有什么区别?
“当您要求软件工程师设计运营团队时,就会发生SRE。” – 站点可靠性工程 自Google发布《网站可靠性工程手册》以来,我不止一次被告知SRE是现有运营或应用程序支持模型的扩展。 我们有几个问题定义了Sys之间的差异。管理员,DevOps工程师和站点可靠性工程师: Sysadmin和DevOps Engineer有什么区别? SRE和DevOps有什么区别? 将DevOps引入新手的有效定义是什么? 但是,这些问题或其答案均无法说明系统管理员与站点可靠性工程师之间的区别。 从广义上讲:Google的站点可靠性工程实践与企业中传统的分离开发与运营职能之间的主要区别是什么?

4
终止DevOps工作流程的利弊?
我正在尝试评估从devops风格的工作流程转到传统的dev-then-ops(不确定该怎么称呼)是否是一个好主意。 我们是一个由5人组成的小型部门,隶属于4000名员工的传统媒体(例如非软件)公司。两年前,我们开始构建软件,以使我们的部门能够显着扩大生产规模。我们已经取得了很大的成功,更大的公司开始注意到这一点。迄今为止,我们已全权负责已成为约10个服务的AWS微服务平台的设计,开发和部署。我们的团队并没有将其识别为DevOps,但是毫无疑问,我们过着DevOps的生活,每个开发人员都非常熟悉代码及其运行的系统。 我们不久将面临的问题之一是我们与母公司的IT部门之间共享什么“效率”。我们的项目所有者通常更喜欢外包而不是内部学习,因此,在我们的案例中,这些效率可能意味着尽可能多地利用IT工作。目前,我想说我们的团队在编码经验和基础架构经验之间占70/30%的比例。IT部门扎根于IT领域,没有明显的过渡到软件开发的过程。 我们的项目负责人(非技术人员)希望通过将尽可能多的工作交给IT团队,我们将在每个小时的工作中看到生产率提高1:1左右。我对此表示怀疑。我们的产品仍处于测试阶段(尽管已经是一项重要的业务资产),并且根据我们在IT部门的有限经验,通常会发生诸如文件系统权限更改之类的简单事情的严重延迟。 目前,我理想的解决方案是让IT部门“采用”我们并允许我们继续部署自己的工作,同时确保我们满足IT部门的标准和要求。我不确定那有多现实。另外,这几乎是我们项目所有者提倡的相反方法,因为它会在短期内增加其他操作工作。 在我们的情况下,坚持使用DevOps方法与交付IT相比可能有什么利弊?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.