- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
DevOps、SRE和平台工程的概念在不同时期出现,并由不同的个人和组织开发.
值得注意的是,虽然这些概念出现在不同的时期。它们都与软件开发和操作中改进协作、自动化和效率的更广泛趋势有关.
在过去的十年中,工程和技术组织已经将构建和部署云原生应用程序的最佳实践集合在一起。这些最佳实践包括持续交付、容器化和构建可观察系统。 与此同时,云原生组织已经从根本上改变了他们的组织方式,从大型部门(开发、QA、运营、发布)转移到较小的独立开发团队。这些应用程序开发团队得 到两个新功能的支持:站点可靠性工程和平台工程。SRE和平台工程是传统运维团队的精神继承者,将软件工程的学科带入运维的不同方面.
这两个团队经常混淆,这两个术语有时可以互换使用。事实上,一些组织将SRE和平台工程合并到相同的功能中。之所以会出现这种情况,是因为这两个角色都适用一套共同的原则.
平台工程师不断地检查从源代码到生产的整个软件开发生命周期。通过这个内省的过程,他们构建了一个工作流,使应用程序开发人员能够快速编写和发布软件。基本的工作流通常包括与持续集成系统相连接的源代码控制系统,以及将工件部署到生产环境中的方法.
随着使用工作流的应用程序开发人员数量的增长,平台的需求也在变化。不同的应用程序开发团队需要类似但不同的工作流,因此自助服务基础设施变得很重要。自助服务的常见平台工程目标包括CI/CD、警报和部署工作流.
除了自助服务,教育和协作也成为挑战。平台工程师发现,他们花越来越多的时间培训应用程序开发人员,让他们了解最佳实践和如何最好地使用平台。 应用程序开发人员还发现他们依赖于其他应用程序开发人员团队,并期望平台工程团队为他们提供与不同团队高效协作的工具.
站点可靠性工程师创建和改进系统,以自动可靠地运行应用程序。站点可靠性工程的概念起源于谷歌,详细记录在 谷歌SRE手册 中。谷歌公司负责技术运维的高级副总裁Ben Treynor Sloss将SRE描述为“当你要求软件工程师设计运维团队时发生的事情”.
SRE定义服务水平目标,并构建系统来帮助服务实现这些目标。这些系统发展成为一个平台和工作流程,包括监控、事件管理、消除单点故障、故障缓解等.
SRE文化的一个关键部分是将每一个故障视为可靠性系统中的一个故障。严格的事后分析对于识别故障的根本原因至关重要,并将纠正措施引入自动化系统以继续提高可靠性.
我们中的一个人(Bjorn Freeman-Benson)一直管理着 New Relic 的工程组织,直到2015年,它从少数客户发展到成千上万的客户,所有客户每秒都向云端发送数百万个请求。New Relic有独立的SRE和平台工程团队,他们遵循上述一般原则.
这些团队被分开建立的原因之一是,在这些角色中取得成功的人是不同的。虽然sre和平台工程师除了需要经典的编程技能外,还需要强大的系统工程技能,但这些角色决定了非常不同的性格类型。 sre倾向于享受危机管理,并在排除故障时获得肾上腺素飙升 。SRE经理能在巨大的压力下茁壮成长,擅长招募和管理想法相似的人。另一方面, 平台工程师是更典型的软件工程师,他们更喜欢不间断地工作在大而复杂的问题上。 平台工程经理更喜欢按照一致的节奏进行操作.
在过去的十年中,DevOps已经成为描述这些实践的一个流行术语。最近,GitOps也成为了一个流行术语。DevOps和GitOps与平台和SRE团队有什么关系? DevOps和GitOps都是一套关于如何管理基础设施不同方面的松散编码原则。这两种哲学的核心原则——自动化、基础设施作为代码、软件工程的应用——非常相似。 DevOps是一场广泛的运动,它专注于消除开发和运维之间的传统竖井。随着时间的推移,基础设施自动化和考虑运维的工程应用等策略已经被广泛接受,成为更好地构建高可靠性应用程序的方法。 GitOps是一种应用程序交付方法。在GitOps中,声明性配置用于在任何时刻编码应用程序的所需状态。这个配置在版本化的源代码控制系统中作为唯一的真实数据源进行管理。这确保了可审计性、可再现性和配置的一致性。 简而言之:DevOps是SRE的一套指导原则,而GitOps是平台工程的一套指导原则.
站点可靠性工程和平台工程是优化构建云原生应用的工程组织的两个关键功能。SRE团队致力于为高可靠的应用程序交付基础架构,而平台工程团队致力于为快速的应用程序开发交付基础架构。这两个团队共同提高了应用程序开发团队的生产力.
参考:
最后此篇关于DevOps、SRE、平台工程的区别的文章就讲到这里了,如果你想了解更多关于DevOps、SRE、平台工程的区别的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
市场是否支持 Azure Devops Server 2020?我最近构建了一个扩展并添加了对 ADO Server 2019 的支持,但是当我更新安装目标以包含新的服务器版本时,我在市场中没有看到任
在公司,我们将 Azure Devops 工作区的 URL 从 https://oldname.visualstudio.com 更改为至 https://dev.azure.com/newname
我想将 SSH 公钥添加到运行我的 yaml 管道的 Azure DevOps 帐户。根据这篇文章:Azure DevOps API Add public key在使用 PAT token 进行身份验
Azure CLI与 Azure DevOps extension已更换 VSTS CLI .但我找不到有关如何使用 Azure CLI 和 Azure DevOps 扩展连接到 Team Found
我正在尝试使用 API 在 Azure devops 中创建/更新工作项。如果项目没有任何关系,我可以创建/更新它。但是,如果我指定关系,例如亲子然后我得到以下错误: TF401349:发生意外错误,
我们有一个每晚安排的管道运行测试并将结果发布到测试运行。我们可以看到测试运行的 url,因为它是由 PublishTestResults@2 任务生成的。我想通过向一组用户发送测试运行的 devops
我在 azure devops 中有 2 个变量 Var1= A,B,C Var2= 1,2 我需要在以下条件下运行一个任务 Var1=A,B,C & Var2=1,2 Var1=A & Var2=1
我正在尝试运行 container job在本地构建和缓存的 Docker 镜像(来自 Dockerfile)中运行,而不是从注册表中拉取镜像。根据我目前的测试,代理只尝试从注册表中提取图像,而不是在
我有以下配置:Azure DevOps 服务器版本 Dev18.M170.8 trigger: none # No CI build pr: none # Not for pull requests
Azure DevOps 是否禁止人们在创建合并请求时添加/删除所需的审阅者? 我已经设置了“自动包含审稿人”的政策,其中包含一组必需的审稿人。 但创建 PR 的任何人仍然可以轻松地将其他人添加到所需
在 Azure DevOps 中,我有一个项目管理员组。它的权限设置为除了 删除共享的 Analytics View &编辑共享的 Analytics View 是允许的。 有一个团队和区域设置,项目
我在 azure devops 中找到了以下任务定义: - task: DotNetCoreCLI@2 name: 'CleanProjectsBeforeBuild' displayName
TL;DR - 是否有 Azure DevOps 管道任务用于在构建过程中格式化代码?我一直没能找到一个,但真的会发现它很有用。 我的团队使用免费的 CodeMaid “美化”(格式化)C# 代码的
我正在尝试从我在 Azure DevOps 中的项目的根目录中获取 dist 文件。但无论我做什么,我都会继续收到此错误: ##[error]Error: ENOENT: no such file o
我想在发布时设置通知。我以前可以这样做,但现在我无法为不同的项目设置它。我不知道 Azure DevOps 中是否发生了某些变化,或者我搞砸了自己。 Azure 告诉我指定一个有效的筛选器,但我没有要
我正在尝试设置构建管道以在特定代理池上运行。目前它坚持在“Azure Pipelines”池上工作: 但是我无法更改构建管道的代理池(至少我不确定如何)。 我的 YAML 如下所示: trigger:
我正在尝试使用一些使用条件编译符号的项目在 Azure DevOps 中设置构建。构建不断失败,因为它似乎没有看到我的符号。任何想法在哪里应用设置? 我有两个共享一些代码的项目,符号基本上用于控制项目
我正在寻找一种在 Azure DevOps .yaml 文件中设置动态需求名称的方法。 现在我们有一些由 Azure DevOps 服务随机选择的自托管构建代理,但有时我们需要选择一个代理来调查它为什
当我们在 Azure DevOps 中创建一个新的 Pull Request 时,我们最近注意到 Reviewer 在默认情况下是 Optional 的。 这引起了一些困惑,据我所知,过去总是默认要求
使用继承的进程 - 我们不能修改 Reason 或 Root Cause 选项列表值?如果我们不能对其进行定制以适应我们的流程,那么专业组织如何实际使用它? https://docs.microsof
我是一名优秀的程序员,十分优秀!