详解~前端人需要了解的DevOps_Javascript

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 服务；
自动化单元测试、冒烟测试；
数据库迁移自动化；
配置自动化。
应用自动化的自助式部署
- 开发人员专注于编写代码，点击部署按钮，通过监控指标看到代码在生产环境中正常运行，在代码出错时能获得错误信息快速修复。
通过代码审查、自动化测试、自动化部署，控制部署风险，必要时使开发人员也可进行部署操作，测试人员和项目经理可在某些环境中进行部署。
将部署和发布解耦
- 部署指在特定环境中安装制定版本的软件。
发布指将产品特性提供给所有客户或部分客户使用。
基于环境的发布模式
- 蓝绿部署
灰度（金丝雀）发布
基于应用的发布模式
- 实现特性开关，好处：轻松地回滚、缓解性能压力、可以屏蔽服务依赖。
实现黑启动：发布潜在风险的新特性时，隐式调用，仅记录测试结果。
持续交付的实践
- 持续交付是指，所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常的工作时段里按需进行一键式发布。开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），都能快速得到反馈。一旦发现这类问题，就立即加以解决，从而保持主干始终处于可部署状态。
持续部署的实践
- 持续部署是指，在持续交付的基础上，由开发人员或运维人员自助式地定期向生产环境部署优质的构建版本，这通常意味着每天每人至少做一次生产环境部署，甚至每当开发人员提交代码变更时，就触发一次自动化部署。
大多数团队采用持续交付实践。

降低发布风险的架构

松耦合架构
面向服务的架构
安全地演进企业架构
- 绞杀者应用模式：api封装已有功能、按新架构实现新功能、api版本化。
云原生架构

反馈的技术实践

这部分包含以下内容：

建立遥测系统
智能告警
应用反馈实现安全部署
应用a/b测试
建立评审和协作流程

建立遥测系统

什么是遥测（telemetry）？
- 遥测包含监控，实现对网络实时、高速和更精细的监控技术。
相比于传统的网络监控技术，遥测通过推模式，主动向采集器上推送数据信息，提供更实时更高速更精确的网络监控功能。
遥测的三大维度
- tracing（跟踪），metrics（指标） , logging（日志）。
可观察性
- 系统可以由其外部输出（遥测的数据）推断其内部状态的程度。
能发现、预测并解决问题。
集中式监控系统（可使用：prometheus、skywalking）
- 在业务逻辑、应用程序和环境层收集数据。
负责存储和转发事件和指标的事件路由器。
应用程序日志遥测（elk、审计日志、metrics）
重大应用事件清单：
- 认证/授权的结果（包括退出）；
系统和数据的访问；
系统和应用程序的变更（特别是特权变更）；
数据的变更，例如增加、修改或删除数据；
无效输入（可能的恶意注入、威胁等）；
资源（内存、磁盘、中央处理器、带宽或其他任何具有硬/软限制的资源）；
健康度和可用性；
启动和关闭；
故障和错误；
断路器跳闸；
延迟；

最后

javascript是前端必要掌握的真正算得上是编程语言的语言，学会灵活运用javascript，将对以后学习工作有非常大的帮助。掌握它最重要的首先是学习好基础知识，而后通过不断的实战来提升我们的编程技巧和逻辑思维。这一块学习是持续的，直到我们真正掌握它并且能够灵活运用它。如果最开始学习一两遍之后，发现暂时没有提升的空间，我们可以暂时放一放。继续下面的学习，javascript贯穿我们前端工作中，在之后的学习实现里也会遇到和锻炼到。真正学习起来并不难理解，关键是灵活运用。

css源码pdf