我要评论
devops 的起源可以追溯到 2008 年，在一次敏捷大会的敏捷基础设施话题组被提及，从起源我们可以了解到 devops 的发展跟敏捷软件开发是密不可分的。
devops 定义
devops 经过这些年的发展，其定义也在不断变化，先来看三段 devops 的 wiki 定义。
- devops 2017 - 2020 年英文 wiki 定义（直译）
- devops 2021 年英文 wiki 定义（直译）
另：
- devops 中文 wiki 定义
提取这三段的共同点，可以看到不论定义如何变化，devops 所要实现的目标都是一致的——缩短软件开发生命周期并使用 「持续交付」 提供高质量的软件。由于持续交付活动中包含了构建、测试和发布等活动，我更倾向于用这个定义，可以更好地缩减定义长度。
另外可以看到英文直接翻译过来的定义中都包含「「实践」」 一词，而中文 wiki 经过一定的翻译或本地化后变成了「「文化、运动或惯例」」，其还更强调开发运维之间 「沟通合作」 这一点，因此将最新的英文 wiki 定义与中文 wiki 定义相结合，可以帮助我们更好地理解 devops，那么它的最终定义是什么就交由读者朋友自己去领会吧。
devops 发展背景
为什么 devops 会如此热门，时常被人所提及，这与其发展背景是分不开的，主要原因可以概括为以下几点：
- 敏态需求的增加，即探索性工作的增加；
-
软件开发从传统的瀑布流方式到敏捷开发，再到现在对敏捷开发提出了更高的要求，近些年创新型的应用不断涌现，在这些应用的研发过程中多采用小步快跑、快速试错的方式，这些探索性工作要求运维能够具备一天发布多次的能力，需要企业完成由稳态到敏态的转变。
-
软件开发活动在企业经营活动中占比的不断增加；
-
- 业务发展对软件的依赖由轻度依赖、中度依赖发展到目前的重度依赖。
-
企业存在对消除浪费的需求。
-
- 软件开发活动在企业中的位置越来越重要，而像企业经营活动一样，软件开发活动中也存在着许多的浪费，企业管理上必然存在着 「识别并消除浪费」 的需求。
-
软件开发中的浪费包括不必要和必要的浪费，不必要的浪费有：无人使用的功能、软件bug、等待测试、等待审批等；必要的浪费包括：工作项移交、测试、项目管理等。
以上主要从企业的角度说明了 devops 的发展，这是较为深层次的原因，表层的推动因素包括：容器化技术的发展、微服务架构的发展等等，这些技术上的创新为 devops 提供了良好的发展条件，以解决企业面临的这些问题。
devops 原则与实践
了解了什么是 devops 及其发展原因后，又该如何具体的进行 devops 实践，我们采用黄金圈法则来思考这一问题。
黄金圈法则
devops 原则是总体指导思想，实践是具体的执行方法，devops 是一个动态的过程，在进行相关实践的时候可以看看其应用了哪些原则，当违背原则的时候需要思考实践的合理性。
devops 原则
devops 包含以下三大原则：
-
流动原则：「加速」 从开发、运维到交付给客户的流程；
-
反馈原则：建设 「安全可靠」 的工作体系；
-
持续学习与实验原则：采用科学的工作方式，将对组织的 「改进和创新」 作为工作的一部分。
流动原则
- 坚持少做
-
产品开始开发时采用 mvp 原则。
-
产品迭代时要适时做减法。
-
持续分解问题
-
- 大的变更或需求拆解为一系列小的变更，快速解决。
-
工作可视化
-
- 采用 sprint 看板将工作可视化。
-
控制任务数量
-
- 减少前置时间，降低测试人员的等待时间。
-
任务越多，预估越不准确。
-
减少交接次数
-
- 减少不必要的沟通和等待。
-
持续识别和改善约束点
-
- 识别出影响流动的主要前置因素，比如搭建环境、需求文档。
-
qa、开发、运维、产品持续提升生产力。
-
为非功能性需求预留20%的开发时间，减少技术债务。
-
消除价值流中的困境和浪费（导致交付延迟的主要因素）
-
- 半成品——未完全完成的工作。
-
额外工序——从不使用的文档、重复编写接口文档等。
-
额外功能——用户实际不需要的功能。
-
任务切换——将人员分配到多个项目或截然不同的工作任务中。
-
等待、移动、缺陷、非标准化的手动操作。
反馈原则
- 在复杂系统中安全地工作
-
管理复杂的工作，识别出设计和操作的问题；
-
群策群力解决问题，从而快速构建新知识；
-
在整个组织中，将区域性的知识应用到全局范围；
-
领导者要持续培养有以上才能的人。
-
及时发现问题
-
- 快速、频繁和高质量的信息流——每个工序的操作都会被度量和监控。
-
技术价值流的每个阶段（产品管理、开发、qa、安全、运维），建立快速的反馈和前馈回路（包括自动化构建、集成和测试过程）。
-
全方位的遥测系统。
-
在源头保障质量
-
- 过多的检查和审批流程，使得做决策的地方远离执行工作的地方，这导致流程有效性降低，减弱了因果关系之间反馈的强度。
-
让开发人员也对系统质量负责，快速反馈，加速开发人员的学习。
-
为内部客户优化工作
-
- 运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。
持续学习与实验原则
-
建立学习型组织和安全文化
-
将日常工作的改进制度化
-
把局部发现转化为全局优化
-
在日常工作中注入弹性模式
-
缩短部署的前置时间、提高测试覆盖率、缩短测试执行时间，甚至在必要时解耦架构，都属于在系统中引入类似张力的做法。
-
领导层强化学习文化
-
- 领导者帮助一线工作者在日常工作中发现并解决问题。
devops 实践
基于 devops 的相关原则，有与其对应的实践，包括：流动的技术实践、反馈的技术实践和持续学习与实验的技术实践。在应用这些实践之前还需认真设计组织结构，使其有利于实践的开展。
设计组织结构
-
利用康威定律设计团队结构。
-
- 康威定律：软件的架构和软件团队的结构是一致的。
-
软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。
-
过度职能导向（成本优化）的危害。
-
- 执行工作的人通常不理解自己的工作与价值流目标的关系（“我之所以要配置这台服务器，是因为别人要我这么做”）。
-
如果运维部门的每个职能团队都要同时服务于多个价值流（即多个开发团队），那么问题更是雪上加霜，因为所有团队的时间都很宝贵。
-
组建以市场为导向的团队。
-
- 将工程师及其专业技能（例如运维、qa和信息安全）嵌入每个服务团队，或者向团队提供自助服务平台，其功能包括配置类生产环境、执行自动化测试或进行部署。
-
这使每个服务团队能够独立地向客户交付价值，而不必提交工单给it运维、qa或信息安全等其他部门。
-
使职能导向有效。
-
- 快速响应。
-
高度信任的文化。
-
将测试、运维和信息安全融入日常工作。
-
- 保证质量、可用性和安全性不是某个部门的职责，而是所有人日常工作的一部分。
-
使团队成员成为通才。
-
- 培养全栈工程师。
-
给工程师提供学习必要技能的机会，让他们有能力构建和运行所负责的系统。
-
松耦合架构，提高生产力和安全性。
-
保持小规模（“两个披萨原则”）。
要使职能导向有效，需要由传统的集中式运维向提供运维服务的方向转变。
传统的集中式运维向提供运维服务的方向转变
运维融入项目开发工作
-
创建共享服务（类生产环境、部署流水线、自动化测试工具、生产环境监控台、运维服务平台等），提高开发生产力。
-
运维工程师融入开发团队。
-
- 使产品团队自给自足，可以完全负责服务的交付和支持。
-
派遣工程师到项目开发团队（运维工程师的面试和聘用仍由集中式运维团队完成）。
-
为每个项目团队分派运维联络人（派遣的运维工程师）。
-
- 集中式运维团队管理所有环境，派遣的运维工程师需要理解：新产品的功能、开发原因、程序如何工作、可运维性、可扩展性、监控能力、架构模式、对基础设施的要求、产品特性的发布计划等。
-
邀请运维联络人参加开发团队会议、每日站会、回顾会议。
-
使用看板图展示运维工作。
流动的技术实践
该部分包含以下内容：
-
运行部署流水线的基础。
-
实现快速可靠的自动化测试。
-
代码持续集成。
-
自动化和低风险发布。
-
降低发布风险的架构。
运行部署流水线的基础
-
自动化环境（开发、测试、正式）搭建。
-
- 使用 shell、iac（puppet、ansible、terraform）、docker、k8s、openshift 等技术。
-
所有内容做版本控制。
-
- 应用程序代码版本控制；
-
数据库代码版本控制；
-
运维配置代码版本控制；
-
自动化和手动测试的脚本；
-
支持代码打包、部署、数据库迁移、应用配置的脚本；
-
项目相关文件（需求文档、部署过程、发布说明等）；
-
防火墙配置、服务器配置等脚本。
-
扩展完成的定义。
-
- 在类生产环境中按照预期进行，开发工作才认为是完成的。
实现快速可靠的自动化测试
-
持续构建、测试和集成。
-
- 代码分支持续集成到主干中，并确保通过单元测试、集成测试和验收测试。
-
常用工具：jenkins、tfs、teamcity、gitlab ci。
-
对持续集成的配合：自动化测试工具；一旦失败必须立即解决的文化；代码持续合入到主干，而不是持续在特性分支上工作。
-
构建快速可靠的自动化测试套件。
-
- 单元测试：junit、mockito、powermock
-
单元测试度量：测试覆盖率。
-
验收测试：自动化api测试、自动化gui测试。
-
并行测试：安全测试、性能测试、单元测试、自动化测试。
-
测试驱动开发：tdd、atdd。
-
让部署流水线始终保持绿色状态。
-
- 部署流水线失败时，所有人立即解决问题或者立即回滚代码，后续的代码提交应该拒绝。
代码持续集成
-
持续集成代码。
-
- 开发人员在自己的分支上独立工作的时间越长，就越难将变更合入主干。
-
小批量开发。
-
基于主干开发。
-
- 频繁向主干提交（通过合并请求）代码。
自动化和低风险发布
-
自动化部署步骤：构建、测试、部署；相关流程包括：
-
- 代码打包、构建；
-
上传 docker 镜像；
-
创建预配置的 k8s 服务；
-
自动化单元测试、冒烟测试；
-
数据库迁移自动化；
-
配置自动化。
-
应用自动化的自助式部署
-
- 开发人员专注于编写代码，点击部署按钮，通过监控指标看到代码在生产环境中正常运行，在代码出错时能获得错误信息快速修复。
-
通过代码审查、自动化测试、自动化部署，控制部署风险，必要时使开发人员也可进行部署操作，测试人员和项目经理可在某些环境中进行部署。
-
将部署和发布解耦
-
- 部署指在特定环境中安装制定版本的软件。
-
发布指将产品特性提供给所有客户或部分客户使用。
-
基于环境的发布模式
-
- 蓝绿部署
-
灰度（金丝雀）发布
-
基于应用的发布模式
-
- 实现特性开关，好处：轻松地回滚、缓解性能压力、可以屏蔽服务依赖。
-
实现黑启动：发布潜在风险的新特性时，隐式调用，仅记录测试结果。
-
持续交付的实践
-
- 持续交付是指，所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常的工作时段里按需进行一键式发布。开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），都能快速得到反馈。一旦发现这类问题，就立即加以解决，从而保持主干始终处于可部署状态。
小编13年上海交大毕业，曾经在小公司待过，也去过华为、oppo等大厂，18年进入阿里一直到现在。
深知大多数初中级前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面v无偿领取！（备注：前端）
最后
其实前端开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。
这里再分享一个复习的路线：（以下体系的复习资料是我从各路大佬收集整理好的）
《前端开发四大模块核心知识笔记》
最后，说个题外话，我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
碰到天花板技术停滞不前！**
因此收集整理了一份《2024年web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-koemaum9-1711192897465)]
[外链图片转存中…(img-q3dcgzqm-1711192897466)]
[外链图片转存中…(img-dznkkmyh-1711192897467)]
[外链图片转存中…(img-lroujgyg-1711192897467)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面v无偿领取！（备注：前端）
[外链图片转存中…(img-ypqrxwmt-1711192897468)]
最后
其实前端开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。
这里再分享一个复习的路线：（以下体系的复习资料是我从各路大佬收集整理好的）
《前端开发四大模块核心知识笔记》
最后，说个题外话，我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在it学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。
发表评论