什么是devops:如何构建一个高效的devops团队
多年来,我一直在帮助团队采用和实现DevOps原则。DevOps这个词最近经常被人提起。我对过度使用myself这个词感到有点内疚——看看我的码头工人和Kubernetes课程 - 但我是Devops运动的巨大粉丝(创造)帕特里克Debois),我看到它改变了很多组织,让生活变得更好。
2021年9月
使用DevOps |在Docker, Kubernetes, Compose, Swarm和Registry上使用最好的超大课程构建,测试,部署容器By Bret Fisher,Docker Captain计划
探索课程我不是从理论的角度来定义DevOps,而是根据我所知道的和我所共事的团队所发生的事情来写。在本文中,我将重点关注那些能够帮助您立即提高DevOps知识的领域。首先,我将列出并详细说明DevOps是什么和不是.然后,我会通过我的DevOps评估来帮助您评估你和你的团队有多“开发”。
devops是什么
DevOps的核心是一种跨团队协作和软件交付过程中可衡量的改进的文化。它开始时是一个开发者和运营商的共享责任模式。但现在,它通常包括安全(DevSecOps)和业务团队(BizDevOps)。在DevOps中,一个团队一起工作,消除竖井,改进协作,并在他们构建和支持的软件的持续改进上创建共享所有权。
1.DevOps是软件创建的中心
DevOps要求创建软件的过程与软件本身一样重要。与其只专注于“面向客户的新特性”,员工还应该优先改进系统。devops特定的指标突出了这些系统中的问题,所以领导可以看到他们什么时候需要优先考虑“非特性工作”。
2.DevOps是由速度驱动的。
这种速度允许您向客户交付更好的产品,并通过反馈和自动化不断改进产品。从产品构思到产品发布,然后重复。这就是DevOps的♾无限标志的来源——它是一个不断改进和提高发布速度的无休止的循环。
3.DevOps实现是活动的组合
这包括新的流程和以新的方式组织人员。DevOps希望您创建一种新的文化并实现新技术,以帮助实现自动化并突出应用程序生命周期的重要方面。它涵盖了很多领域,影响的不仅仅是工程师。
4.DevOps是由数据和指标驱动的
DevOps文化通过这些指标来衡量它的成功,从而做出明智的决定,知道什么是有效的,下一步该做什么。四个常见的指标是部署频率、变更前置时间、变更失败率和恢复服务的时间。下面将对此进行解释。
DevOps不是什么
它不是“实施工具”的一系列复选框。实施Docker不会让您多个jenkins删除。当然,技术可以帮助实现更高水平的Devops成熟,但我也看到这些Devops工具误用,使系统难以使用和脆弱变化。必须以一种方式实现工具,以便它们改进DevOps度量标准。
1.你永远不会“完成”DevOps
它不是一个目的地 - 它是一种提高心态,组织的流程和技术自动化的旅程,同时更频繁地寻求反馈。
Devops不仅仅是一个更好的项目计划
如果我们在50年的软件开发过程中学到了什么的话,那就是在开始之前,你越是试图详细地描述计划,就越难在不断变化的需求中保持敏捷。DevOps应该帮助您找到一个中间地带,在这里您可以灵活地进行更改,同时规划所需的工作。DevOps的一个重要组成部分是创建较小的更新(更频繁)以减少风险,并尽早(更频繁)获得反馈以限制重复工作。
3.DevOps不怕失败。拥抱它
我们是人,自然倾向于避免失败。这种倾向导致了从失败中恢复的技能和过程的缺乏。DevOps并没有优先考虑避免故障,而是将改进的检测和恢复自动化结合起来,优先考虑快速恢复。DevOps还优先考虑度量发现问题(MTTD)和修复问题(MTTR)的时间。
4.这不是“虚荣心指标”
说到指标,DevOps是它的忠实粉丝。我们应该用指标来衡量我们的成功。然而,DevOps并不喜欢全部指标。避免那些鼓励坏习惯或让我们感觉良好而没有显示出我们的DevOps能力是否成熟的虚荣指标。虚荣心指标包括“关闭的门票数量”或“构建的功能数量”。这些指标跟踪人们的工作,当然,但它是正确的工作吗?像“部署频率”(DF)和“变更的平均提前时间”(MLT)这样的可操作指标突出了组织改进其流程和自动化的速度。
5.DevOps不是一个头衔
这是一个棘手的问题,因为我一般的咨询标题通常是DevOps
Devops的优点
我已经帮助许多团队在DevOps成熟度方面取得了进步。我教我所有的课程码头工人掌握和Kubernetes掌握带着这种心态。以下是我认为团队投入几个月的努力后会产生的巨大好处:
- 它自然避免了工艺刚性。成熟的DevOps允许您的团队在发布生命周期的任何时刻走弯路和掉头。
- 它可以防止任何一个人成为单一的失败点。鼓励自助服务系统,人们更具授权才能向前移动,因为自动化工具和测试集成到许多过程中。
- 它会让所有想知道的人都知道你的工作。自动化将更改记录下来,让每个人都能看到。版本控制系统跟踪几乎所有的事情。Pull Request工作流成为一种文化,让你设计一个变更,然后寻求审查和批准,从代码到基础设施等等。
- 它促进了共同的知识和交叉训练。信息孤岛是不鼓励的,分享你的知识是队友和管理层高度重视的。人们的价值取决于他们分享和教导了多少,而不仅仅是他们知道什么。
- 它经常迭代小的更改。一个具有高devops级别的组织将能够更频繁地发布产品和变更,并取得更高程度的成功。自动化和测试的持续改进使变化的速度呈上升趋势,同时也减少了风险和停机时间。
- 它可以更快地恢复。DevOps将快速故障恢复设计为工作流的一部分。回滚和修复是短暂而无痛的。当检测到失败的更改时,自动化可以提供自动回滚。
- 它包含不断的反馈和改进。反馈成为每个过程的一部分,无论是自动化的(测试)还是人工的。信心增长,创造更好的团队凝聚力和改进的灵活性,以适应不断变化的条件。
- 它减少了辛劳,增加了团队(和客户)幸福。“辛劳”是可以耗尽,耗时的手动任务,并且通常重复。它可能与测试,调试,管理员命令和手动活动有关,我们现在可以为他人提供自动化和提供自动化工具的方法。例如,具有开发人员测试而不是自动化过程。阅读更多关于辛劳和如何消除它的信息在谷歌SRE书上.
Bret的DevOps成熟度评估
我喜欢评估组织的DevOps实践。评估可以帮助你确定自己的位置以及哪些领域最需要关注。除非你知道你从哪里开始,否则你很难知道你需要去哪里。
Devops在组织的各个部分上施放了这样一个大网,很难从外面看,并且知道组织在其成熟时所处的位置。您需要某种评估来帮助。
当您搜索“DevOps成熟度模型”时,会有很多结果,并且有两种基本类型的评估可用。它要么太笼统,对采取行动没有真正的价值,要么太详细,仅完成评估就需要数小时或数天。
我给你做了一个小型评估现在.我称之为Bret的DevOps成熟度评估。简称B-DOME,哈!对于三个主题领域中的每一个,有五个问题,在整个评估中最高75分。对于每个问题,我给你三个基本选择:
- 我们还没有devops特性:0点
- 我们正在做一些正确的事情:3分
- 我们把所有的东西都DevOps了,5分
DevOps评估第一部分:文化
- 生产故障处理:这是发展文化的一个关键指标,这是DevOps成熟的核心。
- 很少停电后期,责备是常见的:0点
- 定期进行故障事后分析,从不追究责任:3分
- 包括其他团队反馈的事后分析。没有分配责任。通常导致更好的自动化和提高团队绩效:5分
- 减少工作:与健康系统自动化和消除日常人类互动。
- 作为正常开发和IT操作的一部分,人类执行许多重复性任务。betwayapp下载安装人类不需要对自动化手工操作任务负责:0点
- 鼓励自动化,但辛劳无法测量。用户功能通常优先于操作改进:3分
- 辛劳是衡量的,低于50%的工作为操作。管理层尊重并鼓励自动化工作,就像用户特性一样:5分
- 让他人分享知识:共享多少知识和交叉培训鼓励?是“部落知识”积极抵制?
- 只存在基本的文档(wiki, readme’s等)。不持续更新。新团队成员很难靠自己跟上进度:0点
- 培训是多模态和例程(录制的教程,午餐和学习,代码配对)。新团队成员从以下学习很多:3分
- 培训是多模式,例程,预期,并从顶部作为优先活动支持。评估反映了您对分享的承诺,人们竭尽全力降低部落知识。新团队成员存在一个正式的过程,以了解现有记录并提供有关缺乏的反馈:5分
- 自助服务工具创建:其他员工能在多大程度上帮助员工自助?是否鼓励团队为其他团队创建工具,以消除他们参与正常工作流程的需要?员工“保护自己的地盘”的现象普遍吗?这通常与上一个问题的答案联系在一起。
- 信息和控制是竖井式的,我们通常需要其他人来配置、部署或在正常操作期间提供东西:0点
- 我们有一些自助服务工具,但它们缺乏严格和自上而下的支持,无法成为高质量的产品:3分
- 自助服务工具很常见,并且与面向外部客户的产品具有类似的优先级。减少辛劳的结果通常会产生新的自助工具,它们会根据反馈定期改进:5分
- 随叫随到是谁?
- 待命人员通常不是开发人员,应用程序维护人员通常不是应用程序生产系统的待命人员:0点
- 应用程序维护者是呼叫过程的一部分。他们回应了他们自己的产品的中断:3分
- SRE文化是活的。应用程序维护人员随时待命。运营工程师是开发人员,通常会提交代码来提高应用的稳定性和性能:5分
软件开发工具特色课程betwayapp下载安装
DevOps评估第2部分:过程
- 释放节奏:您交付给客户的变更率也称为“部署频率”。我猜它还在积极发展中。betwayapp下载安装一个健康的DevOps实践是更频繁地发布较小的更新。
- 一个月或更长时间:0点
- 天到几周:3分
- 每天多次:5分
- 故障率变化:生产变更需要多久需要修复?它也称为“缺陷逃生率”。Devops工作可以降低变化的失败率,同时也增加了变化率。这也与MTTD和MTTR有关。
- 超过15%的时间,或未知:0点
- 失败的几率不到15%:3分
- 失败率低于15%,提高MTTR与提高失败率同等重要:5分
- 交货期:从提交更改(代码或配置)到使其在产品中对客户可用所花费的时间。这将与其他问题相关,但它是部署工作流自动化程度和建立程度的可靠指标。
- 几周或更长时间:0点
- 天到一周:3分
- 几个小时到几天:5分
- 恢复时间:当客户收到报告后,他们需要花时间去解决主要问题。它被测量为平均恢复时间(MTTR),并受到两个标准DevOps指标——平均检测时间的密切影响。
- 数天到数周甚至更长时间,许多人参与其中,手工工作超出了典型的发行版开发过程:betwayapp下载安装0点
- 几小时到几天,具有与标准版本类似的工作流程,即CI测试并主要是自动化:3分
- 几分钟到几小时,在许多情况下使用回滚和自修复声明性选项。对MTTD和MTTR进行跟踪,并给予改进时间:5分
- 安全的供应链:增加您设计的代码和基础设施是实际交付的东西的信心。有这里有很多旋钮要转动,所以我将重点讨论工程控制中最常见的部分。
- 许多人可以直接在生产环境中更改某些内容,而无需更改管理、版本控制或审核:0点
- 提交签署。拉出请求样式测试和批准。声明式系统很常见。工件是标准的部署对象(Docker/OCI映像):3分
- 提交签署。拉出请求样式测试和批准。声明式系统无处不在。工件是标准的部署对象(Docker/OCI映像)和要求促销活动.人们通过2FA/MFA认证。机器之间相互验证。变更工作流的每一步都是可审计的,并经过加密验证:5分
DevOps评估第3部分:技术
- 解耦本地开发环境。为了更好地培训开发人员和增加自助服务,最好使您的本地环境需求尽可能地自动化、精简和通用。对于已经设定的标准(检测、测试、代码质量),开发人员有多种流行的选择来满足需求。
- 我们不支持所有主要的操作系统(Win/Mac/Linux)或平台(x86_64/arm64),有一个复杂的安装过程,并需要一个支持开发环境工具和数据中心的专家:0点
- 我们支持所有主要的操作系统和平台。整个开发团队可以快速设置和维护开发环境及其工具:3分
- 在所有主要的操作系统,平台和编辑器,包括web IDE的(例如,GitHub Codespaces)。为本地基础设施使用容器。日常工作流程不需要复杂的命令或自定义脚本:5分
- 丰富的“左移”本地开发工具。”左转“对于安全扫描、测试和检测来说,让开发人员(和操作人员)为任何提交版本控制更改的人提供自助服务是很重要的。在将变更推入代码存储库之前,评估变更的机会越多,延迟和返工就越少。
- 本地测试非常有限。CI管道、检测和安全扫描仅由选定的少数人创建和/或控制,并在提交后执行:0点
- 在提交之前,可以进行本地单元和功能测试,并鼓励进行测试。开发人员编辑CI管道的权限有限。一些有限的本地检测或安全扫描:3分
- 每个开发人员都可以在提交推送之前在本地运行完整的CI、检查程序和安全扫描。CI管道与代码一起存储,所有人都可以编辑它。管道工作流在需要时作为源代码更改的一部分进行更新:5分
- 基础设施改变跟踪。通常,基础设施变更管理的成熟度滞后于开发人员源代码工作流程。DEVS将通过CI迅速发布更新,并准备持续部署,但系统管理员没有调整,并且无法以不断变化的速度保持稳定。如果使用DevOPS指标来跟踪变化率,稳定性和恢复速度,则基础设施工具和操作更改管理流程必须保持速度。其中大部分意味着采用基础设施团队内的开发人员的工作流程模式。
- 基础架构更改不会自动跟踪或实时跟踪,并且在更改之前未通过CI测试:0点
- 大多数基础架构作为代码(yaml,toml,json等),git修订和ci测试:3分
- 几乎所有的基础设施更改都是代码化的、版本化的、CI测试的、同行评审的(拉请求)的,并且通常是用最少的努力就可以逆转的:5分
- 部署工件,而不是源代码。容器映像是事实上的Cloud Native部署对象。一旦采用映像作为常见的部署工件(包括无服务器),开发到操作的几个主要问题就会显著减少。环境变化不再是一个问题,部署时间缩短了,并且可以投资于临时系统以获得更高级别的稳定性和敏捷性。
- 几乎没有软件被部署为容器映像:0点
- 大多数软件部署为容器映像:3分
- 容器图像是您团队所做的一切的标准。图像标签永远不会重用用于生产工作负载确保旧映像不被重用:5分
- 基础设施变化控制。了解命令式基础架构与声明式基础架构.同时,也要接受教育GitOps.
- 在实际的系统中,主要是由人手动(命令式)完成的:0点
- 通过对系统的人类(一些必不可少的陈述)进行配置管理工具,主要是:3分
- 主要是GitOps。由人类在代码库中更改。由CI测试,人类认可。基础架构(声明式)更新自身:5分
把你的分数加起来,我为不同的成就等级分配了一些头衔,以此来追踪你的进步。在Twitter上与我分享你的结果@bretfisher.:
10 - 27分:DevOps新生儿!你开了个好头。预计走向成熟的过程需要几个月或几年。 27 - 45分:DevOps毕业生!您已经有了坚实的基础,许多DevOps改进产生了可衡量的结果。现在不要停止! 46+分:Devops Masters!你们是一个全面发展的DevOps组织。继续推动增长将带来持续的利益和DevOps的成熟。 |
我希望你意识到,根据我与团队的经验,这并不是全面的,而且是非常武断的。我的目标是,这可以让您了解自己做得好的地方,以及在没有正式而详细的评估的情况下需要做些什么。这15个话题触及了我在团队发展DevOps能力时看到的大问题。
祝您在DevOps之旅中好运,并祝您所有的部署都成功!