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

• 运维配置代码版本控制；

• 自动化和手动测试的脚本；

• 支持代码打包、部署、数据库迁移、应用配置的脚本；

• 项目相关文件（需求文档、部署过程、发布说明等）；

• 防火墙配置、服务器配置等脚本。

• 扩展完成的定义。

• • 在类生产环境中按照预期进行，开发工作才认为是完成的。

实现快速可靠的自动化测试

• 持续构建、测试和集成。

• • 代码分支持续集成到主干中，并确保通过单元测试、集成测试和验收测试。

• 常用工具：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）

• 重大应用事件清单：

• • 认证/授权的结果（包括退出）；

• 系统和数据的访问；

• 系统和应用程序的变更（特别是特权变更）；

• 数据的变更，例如增加、修改或删除数据；

• 无效输入（可能的恶意注入、威胁等）；

• 资源（内存、磁盘、中央处理器、带宽或其他任何具有硬/软限制的资源）；

• 健康度和可用性；

• 启动和关闭；

• 故障和错误；

• 断路器跳闸；

• 延迟；

• 备份成功/失败。

• 将建立生产遥测融入日常开发工作。

• 使用遥测指导问题的解决。

• 建立自助访问的可视化遥测信息系统（信息辐射器）

• • Grafana

• SkyWalking

• Kibana

• 发现和填补遥测的盲区（建立充分而完整的遥测）

• • 业务级别：订单量、用户数、流失率、广告展示和点击等。

• 应用程序级别：事务处理事件、应用程序故障等。

• 基础架构级别：服务器吞吐量、CPU负载、磁盘使用率等。

• 客户端软件级别：应用出错和崩溃、客户端的事务处理事件等。

• 部署流水线级别：流水线状态、部署频率等。

智能告警

• 解决告警疲劳

• • 充分而完整的遥测会引入告警疲劳问题，需要更智能的报警。

• 使用统计分析方法，而非静态阈值设置告警

• • 使用均值和标准差（适用于正态分布的数据）：度量数据与均值存在较大标准差时告警。

• 使用预防故障的告警，而不只是故障发生后的告警

• • 试着问有什么指标可以预测故障。

• 异常检测技术

• • 平滑统计技术：使用移动平均数，利用每个点与滑动窗口中所有其他数据的平均值，来转换数据。

• 支持高级异常检测的工具：Prometheus、Grafana。

应用反馈实现安全部署

• 通过遥测使部署更安全——部署后能立即发现问题。

• 价值流中的所有人（开发人员、开发经理、架构师、运维团队等）共同承担运维事故的下游责任。

• • 共同承担值班工作、共同解决生产环境问题。

• 让开发人员跟踪工作对运维人员的影响。

• • 使开发的应用易于部署，提升运维人员幸福感。

• 让开发团队自行管理生产服务。

• • 首先由开发团队管理，然后才交由集中的运维团队管理。

• 运维工程师由生产支持转变为顾问或加入团队，帮助做好部署准备，建立服务发布指南（包括：支持有效的监控、部署可靠、架构能支持快速频繁的部署等）。

• 为团队分配SRE人员。SRE定位：SRE就是软件开发工程师负责了运维工作，SRE非常稀少，只能分配给最重要的团队。

应用A/B测试

• 在功能中集成A/B测试

• • 向用户随机展示一个页面的两个版本之一。

• 在发布中集成A/B测试

• • 使用特性开关。

• 在功能规划中集成A/B测试

• • 不仅要快速部署和发布软件，还要在实验方面不断提升，通过实验主动实现业务目标和客户满意度。

建立评审和协作流程

• 防止「过度控制变更」

• • 反事实思维容易认为事故是由于缺乏审批流程导致。

• 建立同行评审，缩短审批流程

• • DevOps 中高绩效的组织更多地依赖同行评审，更少地依赖外部变更批准（层层审批）。

• 代码评审

• • 每个人的代码提交到主干时，必须由同行进行评审；

• 每个人应该持续关注其他成员的提交活动；

• 定义高风险变更，从而决定是否需要请领域专家进行审查；

• 将大的提交变更拆分成小批量变更。

• 利用结对编程改进代码变更

• • 研究表明：结对的程序员比两个独立工作的程序员慢了15%，而‘无错误’代码量却从70%增加到了85%。

• 测试和调试程序的成本通常比写初始代码的成本高出多倍。

• 评估合并请求的有效性

• • 与在生产环境产生的结果无关。

• 有效合并请求的基本要素：必须足够详细地说明变更的原因、如何做的变更，以及任何已识别的风险和应对措施。

持续学习与实验的技术实践

这部分包含以下内容：

• 将学习融入日常工作

• 将局部经验转化为全局改进

• 预留组织学习和改进的时间

将学习融入日常工作

• 公正文化和学习文化

• • 人为错误往往不是问题的根本原因，可能是复杂系统中存在不可避免的设计问题而导致。

• 不应该对造成故障的人进行「点名、责备和羞辱」，我们的目标是最大限度地抓住组织学习的机会。

• 从学习的角度看待错误、报错、失误、过失等。

• 相关实践1：在事后分析中，不指责，公正地进行评判，使工程师自己愿意对事情负责，并且热情地帮助其他人避免同样的错误发生；广泛地公开事后分析会议结果。

• 相关实践2：在生产环境中引入受控的人为故障（捣乱猴），针对不可避免的问题进行演练。

• 降低事故容忍度，寻找更弱的故障信号

• • 随着组织能力的提升，事故数量大幅降低，故障越不应该出现。

• 在复杂的系统中，放大微弱的故障信号对于防范灾难性故障事关重要。

• 重新定义失败

• • 高效能DevOps组织的变更频率是平均水平的30倍，即使失败率只有平均水平的一半，也显然意味着故障总数更多。

• 鼓励创新并接受因此带来的风险。

• 创建故障演练日

• • 帮助团队模拟和演练事故，使其具备实战能力。

• 暴露系统的潜在缺陷。

将局部经验转化为全局改进

• [ChatOps] 使用聊天机器人、积累组织知识

• • 自动化工具集成到聊天中，比如（@bot depoy owl to production）；

• 操作结果由机器人发送回聊天室，每个人都能看到发生的一切；

• 新来的工程师也可以看到团队的日常工作及执行方式；

• 看到他人互相帮助时，人们也会倾向于寻求帮助；

• 使用话题组，建立起组织学习，知识得到快速积累。

• 加强了透明、协作的文化。

• 将标准、流程和规范转化为便于执行的形式

• • [ArchOps] 使工程师成为构建者，而不是砌砖工；

• 将手动操作流程转换为可自动化执行的代码；

• 将合规性使用代码表达出来。

• 运用自动化测试记录和传播知识

• • 自动化界面测试，令使用者知道系统如何使用；

• 单元测试，令调用者知道方法API如何使用。

• 项目开发中包含非功能性的运维需求

• • 对各种应用和环境进行充分的遥测；

• 准确跟踪依赖关系的能力；

• 具有弹性并能正常降级的服务；

• 各版本之间具有向前和向后的兼容性；

• 归档数据来管理生产数据集的能力；

• 轻松搜索和理解各种服务日志信息的能力；

• 通过多个服务跟踪用户请求的能力；

• 使用功能开关或其他方法实现简便、集中式的运行时配置。

• 把可重用的运维用户故事纳入开发

• • 将重复的运维工作通过编码进行实现。

• 技术选型需要考虑运维因素

• • 不能减慢工作流；

• 思考举例：TIDB VS MySQL 该如何选择。

预留组织学习和改进的时间

• 偿还技术债务制度化

• • 定时「大扫除」

• 开发和运维针对非功能性需求进行优化，横跨整个价值流。

• 价值：赋予一线工作人员不断识别和解决问题的能力。

• 让所有人教学相长

• • 所有的工程师都越来越需要某些技能，而不只是开发人员如此。

• 越来越多的技术价值流采用了DevOps的原则和模式。

• [每周学习文化] 每周一次的学习时间，每个同伴既要自己学习，又要教别人。

• 内部顾问和教练

• • 成立内部的教练和咨询组织，促进专业知识在组织内的传播。

实践重点

---

DevOps 的实践包含许多内容，提炼了以下重点方便查阅：

• 流动原则的实践

• • 部署流水线的基础（所有内容做版本控制、在类生产环境按预期工作才算完成）

• 实现快速可靠的自动化测试（自动化运行、始终保持流水线处于绿色状态）

• 代码持续集成（小批量开发）

• 自动化和低风险发布（自助式部署、部署和发布解耦、采用持续交付）

• 降低发布风险的架构（云原生架构）

• 反馈原则的实践

• • 建立遥测系统（Tracing、Metrics、Logging）

• 智能告警（使用统计分析方法和预防故障的告警）

• 应用反馈实现安全部署（部署后立即发现问题、共同承担责任）

• 应用A/B测试（功能规划中集成A/B测试、使用特性开关）

• 建立评审和协作流程（同行评审、减少审批流程、结对编程）

• 持续学习与实验原则的实践

• • 将学习融入日常工作（从学习的角度看待事故、寻找更弱的故障信号）

• 将局部经验转化为全局改进（ChatOps、让规范便于执行、非功能性的运维需求）

• 预留组织学习和改进的时间（定时偿还技术债务、教学相长、内部教练）

结语

–

总结

秋招即将开始，校招的朋友普遍是缺少项目经历的，所以底层逻辑，基础知识要掌握好！

而一般的社招，更是神仙打架。特别强调，项目经历不可忽视；几乎简历上提到的项目都会被刨根问底，所以项目应用的技术要熟练，底层原理必须清楚。

这里给大家提供一份汇集各大厂面试高频核心考点前端学习资料。涵盖 HTML，CSS，JavaScript，HTTP，TCP协议，浏览器，Vue框架，算法等高频考点238道（含答案）！

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

资料截图 ：

高级前端工程师必备资料包