HCIP-Cloud Service DevOps Engineer V2.0 华为认证（考点纪要）

题库

模拟考试链接一【点击进入】

练习题【练习题】

考点

部分英文/缩写名词解释

• MVP：最小可行产品
• Cloud Native：云原生
• DevOps：Development and Operations，开发运营一体化的管理策略
• PM：Product Manager
• SL：
• WIP：在制品。正在制作的产品。
• PO：Product Owner，产品负责人。
• Sprint：指Scrum团队完成一定数量工作所需的短暂、固定的周期，可称为迭代。
• Feature: 特性
• backlog: 订单
• Block：阻碍
• MTTF：Mean Time To Failure。衡量可靠性的参数:平均失效时间
• MTBF：Mean Time Between Failure。衡量可靠性的参数:平均无故障工作时间
• Chaos: 馄饨测试
• TRO：数据恢复用时
• RPO：数据恢复点
• Selenium: UI自动化测试工具
• Chaos Monkey：混乱猴子
• DevSecOps：华为云devOps的安全实践，安全测试云服务
• DevCloud: 华为云
• CodeCheck: 华为云静态代码检查工具
• CodeHub：华为云代码托管工具
• TDD：test driven development,测试驱动开发
• ATDD：acceptance test driven development,验收测试驱动开发
• BDD: Behavior driven developmen，行为驱动开发
• AW：action Word 关键字，可复用的执行逻辑单元
• APITest: 华为云接口测试工具
• CPTS：华为云运性能测试服务，专注于性能测试的云测试工具
• CCE：Cloud Container Engine，华为云容器引擎
• CCI：Cloud container Instance,云容器实例
• Microservice：微服务
• IAM：Identity and Access Management，统一身份认证
• CTS:Cloud Trace Service,云审计服务
• XSS:Cross Site Scripting，简称XSS，跨站脚本
• Docker:容器引擎技术
• kubernetes:简称k8s，容器编排技术
• CGS：容器安全服务
• CD：Continuous Delivery，持续交付
• CI: Continuous Integration 持续集成
• CD：Continuous Deployment 持续部署
• npm:构建工具，JavaScript
• Gulp:构建工具，JavaScript
• Grunt:构建工具，JavaScript
• Maven: 编译构建工具 java
• Ant:编译构建工具 java
• Gradle:编译构建工具java
• lvy: 构建工具java
• make: 编译构建工具c/c++
• CMake: 编译构建工具c/c++
• MSBuild: 编译构建工具 c#
• Build Tool：编译构建工具
• setuptool：编译构建工具 python
• pylnstaller：编译构建工具 python
• docker:编译构建工具
• Ansible: 部署工具，配置管理工具，轻量级
• SaltStack: 配置管理系统
• puppet: 部署工具，自动化配置工具
• chef:自动化配置工具
• cce: 部署工具,华为云产品
• springboot: 部署工具
• kubernetes: 部署工具
• serviceStage:: 部署工具,华为云产品，微服务解决方案平台
• jenkins:流水线工具
• spring cloud:微服务框架。
• zuul:是Netflix的负载均衡器
• Eureka:是Netflix的服务注册和发现组件
• Zipkin：分布式实时数据追踪系统
• Feign:声明式的Web Service客户端
• ServiceComb：微服务框架
• ETCD:k8s,负责保存cluster的配置信息。
• node: k8s，节点
• kubelet:k8s,node上的agent
• kubectl：k8s命令行工具
• kube-proxy：k8s实现负载均衡
• POD：k8s,最小部署单元
• ReplicaSet:k8s，副本控制器
• Statefulset:k8s，中部署的有状态的应用
• DaemonSet：k8s中的应用对象
• Terraform：多云资源管理
• CloudArtifact：华为云私有依赖库
• CloudRelease：华为云发布库
• SWR: software repository for container，华为云容器镜像管理
• CloudDeploy：华为云自动部署服务
• ITIL：Information Technology Infrastructure Library）：即信息技术基础构架库
• AIOps:Artificial Intelligence for IT Operations，智能运维，云上运维。

一、前言概览（10%）

• 用VUCA归纳企业面临的挑战
  • Volatility 易变性(拥抱变化)
  • Uncertainty 不确定性(快速响应)
  • Complexity 复杂性(精细管理)
  • Ambiguity 模糊性(小步快跑)

云原生

• 云原生背后典型的技术产品有？
  • 容器、docker、编排k8s、微服务、服务网格、敏捷、持续集成-交付-部署、DevOps等

• 云原生应用？
  • 云原生应用是独立的小规模松散耦合服务的集合，提供业务价值，融合用户反馈实现持续改进
  • 云原生应用开发可以加速构建新应用、优化现有应用
  • 云原生应用的目标是以企业需要的速度满足应用用户的需求

• 云原生计算基金会CNCF给出云原生应用三大特征？
  • 容器化封装：以容器为基础，提高整体开发水平，形成代码组件重用，简化应用程序的维护，
  • 动态管理：通过集中式的编排调度系统来动态地管理和调度
  • 面向微服务：明确服务的依赖，相互解耦

• 云原生应用12要素？（前五个是重点）
  • 基准代码，一份代码库对应多份部署
  • 依赖，显示声明依赖关系，通过依赖清单确切声明所有依赖项，这一做法会统一应用到生产和开发环境
  • 配置，在环境中存储配置、推荐。可以非常方便的在不同的部署间修改，不动一行代码。
  • 后端服务，把后端服务当做附加资源，每个不同的后端是一份资 源，例如一个mysql数据库是一个资源，两个被当做两个不同的资源
  • 构建、发布、运行云原生应用，需要严格区分构建发布运行这三个步骤。
  • 日志
  • 处理
  • 开发环境与线上环境等价
  • 管理进程
  • 端口绑定
  • 并发

微服务

微服务是一种用于构建应用的架构方案。

• 传统单体架构的缺陷？
  • 复杂性高，单体架构项目包含模块多，模块边界模糊，依赖关系不清
  • 技术债务逐渐上升，已使用的系统或代码难以修改
  • 部署速度逐渐变慢，构建和部署时间增加，单体应用中每次功能的修复，都需要重新部署整个应用
  • 扩展能力受限，单体应用只能作为一个整体进行扩展，无法结合业务模块的特点伸缩
  • 阻碍技术创新，单体应用必须使用相同的开发语言和架构，引入新技术非常困难

• 微服务架构？
  • 微服务架构样式是一种将单个应用程序开发为一组小型服务的方法
  • 每个小型服务都在自己的进程中运行并通过轻量级机制进行通信服务
  • 这些服务围绕业务功能构建，且由全自动部署机制来独立部署
  • 这些服务通过最低限度的集中管理，可用不同的编程语言和不同的数据存储技术

• 微服务架构的优势？
  • 可通过分布式部署，提升日常工作来效率，并发多个微服务，意味着开发人员可以同时开发同一个应用，进而缩短开发（TTM）所需的时间*
  • 加速做好面试准备，因开发周期缩短，微服务架构有助于实现更加敏捷的部署和更新
  • 高度可扩展，可跨多个服务器和基础架构进行部署
  • 出色的弹性，只要正确构建，独立的服务不会彼此影响，意味着一个服务出现故障，不会导致整个应用下线

敏捷简介

• 敏捷开发宣言的四项价值观？
  • 个体和互动高于流程和工具
  • 工作的软件高于详尽的文档
  • 客户合作高于合同谈判
  • 响应变化高于遵循计划

• 敏捷开发宣言的十二条原则？(第一条和第七条值得注意)
  • 最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
  • 欣然面对需求变化，即使在开发后期也一样
  • 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期
  • 业务人员和开发人员必须相互合作，项目中的每一天都不列外
  • 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任从而达成目标
  • 不论团队内外，传递信息效果最好效率最高的方式是面对面的交谈
  • 可工作的软件是进度的首要度量标准
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户能够要共同维持其步调稳定延续
  • 坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强
  • 以简洁为本，他是极力减少不必要工作量的艺术
  • 最好的架构、需求和设计出自自组织团队
  • 团队定期的反思如何能提高成效，并依次调整自身的举止表现

• 敏捷与传统瀑布型模式的区别？
  • 价值驱动是敏捷与传统瀑布型模式的最大区别
  • 敏捷追求价值驱动，强调固定资源和固定时间，通过调节特性，追求最大化的价值产出 (固定时间，弹性范围)
  • 传统瀑布是计划驱动，利用估算的资源在估算时间内，按照计划达成固定需求(固定范围，弹性时间)

• 敏捷价值主张的好处呈现？
  • 带来全程持续的高可视性，了解现场情况
  • 通过短迭代模式，在每个短迭代均可进行需求调整，带来高适应性
  • 通过聚焦价值来排序特性，从一开始就产出高业务价值，在边际效益递减时决策减少投入
  • 能够更早的发现和解决风险，避免风险恶化

DevOps简介

Development and Operations，开发运营一体化的管理策略，是一组过程、方法与系统的统称、用于促进软件开发、运维和质量保障部门之间的沟通、协作与整合。DevOps在流程上打通了软件开发的整个生命周期。

• DevOps五个要素（CALMS）？
  • 文化，DevOps团队的前提建立一体化的全功能团队，打破开发和技术运营隔阂，形成DevOps的协同合作的文化氛围
  • 自动化，自动化一切可以自动化的，通过自动化工具或脚本实现软件工程从构建到运维过程的自动化流水线作业
  • 精益，以精益的方式小步快跑，持续改善
  • 度量，建立有效的监控与度量手段快速获得反馈，推动产品和团队持续改进
  • 分享，不同职能、不同产品之间的经验分析促进DevOps的文化沉淀、促进产品迭代和更新

• DevOps是敏捷理念从开发领域向运维领域的延伸，几个阶段
  • 计划阶段：运维人员为开发提供需求，制定发布计划
  • 编码 /构建/验证阶段：Scrum、极限编程、精益生产、持续集成、自动化测试
  • 部署阶段：开发团队负责部署、监控部署过程，以及部署后的运行

• DevOps与敏捷的关系？
  • DevOps不是对敏捷的否定，而是融合了敏捷和精益的思想和方法，并在其基础上进一步发展
  • 敏捷打通客户和开发团队，DevOps打通软件交付全流程

• DevOps持续交付实施框架七大领域？
  • 团队模型
  • 分支模型
  • 测试模型
  • 技术架构
  • 部署模型
  • 基础设施
  • 数据库

• EXIN 的 DevOps Master白皮书推出DevOps知识体系？
  • 敏捷管理：包含计划、需求、设计、开发
  • 持续交付：包含开发、部署、运营
  • IT服务管理：包括运营、周期终止
  • 精益管理：从计划到周期终止全称

• 交付流程的覆盖范围经历了四个阶段？
  • 敏捷开发
  • 持续集成（continues integration/CI）
    • 强调开发提交新代码后，立即自动进行构建、单元测试，验证提交代码的正确性
    • 重视自动化测试验证的结果，对可能出项的问题进行预警，保证合并的代码没有问题
  • 持续交付（continues delivery/CD）
    • 在持续集成基础上，将集成后的代码部署到更贴近真实环境验证，不断发布可用版本
    • 持续交付并不是指每一个改动都要尽快部署，是指任何代码修改都可以在任何时候实施部署
    • 持续部署是自动的，是持续交付的最高阶段
  • DevOps
    • 端到端交付周期，覆盖以上全流程，加入运维环境，促进部门沟通、协作、整合，实现工程效率最大化

二、持续规划与设计（13%）

敏捷项目管理理念与方法实践

• 敏捷开发与瀑布开发的外在区别？
  • 瀑布： 做完所有的需求分析之后进行设计、开发、测试。一次性交付。
  • 敏捷： 分迭代进行，将需求拆分成小颗粒，每个迭代只交付一个。

• 敏捷开发与瀑布开发的内在区别？
  • 瀑布： 固定范围，弹性时间
  • 敏捷： 固定时间，弹性范围

• 敏捷开发常用的工程方法论？
  • Scurm、Scrum/XP混合使用率最高
  • 其他：Scrumban、看板方法、精益创业、极限编程(XP)
  • 其他小众方法：DSDM、FDD、RAD

增量式交付

增量式交付：指为及时反馈和接纳，频繁向客户交付连续改善的工作产品。

敏捷开发的基石是增量式交付。

• 增量式交付的特点？
  • 起步于粗糙的产品原型/框架
    • （(MVP)最小可用产品）
  • 细节功能不完善，但可以验证用户的整体使用场景
    • 行走的骨骼，没有人形，但具备所有基础框架
  • 每增加一点功能，用户都能体会到价值的提升
    • 持续改进，一次交付和迭代的区别
  • 与用户一同找寻最终的产品
    • 用户能从早期的增量，更加理解后面的需求

• 增量式交付和瀑布式交付对比？
  • 瀑布交付是用于目标不变的场景。一个产品经过了所有流程后与客户贱民。
  • 增量式交付用于目标不确定复杂变化的场景。每个阶段给出一个可交付的成果，根据用户反馈不断调整，最终交付客户真正想要的真实可用产品。
  • 结论：
    • 如果交付的目标确定，两者交付的周期和资源投入是一致的。
    • 如果软件目标总是变化，会经常出现增量式需要更长的周期和更多的投入，最终交付了不同的目标。
    • 因此，我们需要措施，确保我们按照用户可用的场景去交付。 由此引入影响地图和故事地图两个工具做规划。

影响地图

影响地图是实现从业务目标到功能规划，将极度抽象的概念，通过场景和用户故事，抽现为产品规划的过程。

影响地图是一个以价值为导向的实践方法，通过可视化的方式，建立商业目标和产品功能的关联， 并将联系背后的假设可视化出来，实现将概念进行可视化。

• 如何实践影响地图?
  • 通过四个问题达成统一
    • 为什么why
    • 谁who
    • 怎样how
    • 什么 what
  • 对复杂任务关系进行分析拆解
    • 可以做什么
    • 目标是什么
  • 建立产品目标和功能之间的关系

• 影响地图解决的问题？
  • 解决业务和技术无法对话的问题
    • 业务部门和开发部门之间的理解、沟通、协调及隔阂
    • 目标到功能间联系的模糊和不一致

用户故事地图

故事地图是实现从功能规划到功能实现，让抽象的功能规划变成明确和极度明确的开发任务。

• 什么是用户故事地图？
  • 用户故事地图：透过可视化的方式，建立用户场景与技术规格之间的联系，并辅助团队有效沟通。
  • 让用户在产品还没有做出来之前就可以体验到产品所提供的功能，并以二维结构呈现产品的主线功能和辅助功能，帮助设计者决策。

• 用户故事地图必须的三类功能？
  • 主干
  • 行走的骨骼
  • 额外的特性

• 用户故事地图使用的三个步骤？
  • 广度优先：从左到右，讲述用户经历的重要步骤，要体现交互最好。
  • 深度优先：针对每个主流程进行细化。
  • 版本规划确认MVP。

看板

• 看板的含义？
  • 看板源于精益制造
    • 精益制造，又称为丰田生产方式。
  • 指可视化卡片
    • 看板工具的实质：后道工序在需要时通过看板向前道工序发出信号--请给我需要数量的输入，前道工序只有得到看板后，才按需生产。看板信号又下游上上游床底，拉动上游的生产活动，是产品向下游流动。拉动的源头是下游的客户价值，也就是客户订单或需求。
    • 使项目管理最大可视化，管理研发过程、记录过程中的细节和历程。

• 拉动式生产的收益和好处？
  • 精益制造体系通过看板形成拉动系统，带来控制库存、加速流通、灵活响应、促进改善等好处，最终让用户价值顺畅高质量得流动。

• 看板建立和运作的五大实践？
  • 建立看板
    • 可视化价值流动：是看板方法中最基础的实践，它涉及可视化用户价值、价值的流动过程、以及价值流动过程中的问题和瓶颈。
    • 显示化流程规则：是指明确价值流转和团队协作的规则并达成共识。显示化流程规则是团队协作的依据，是团队改进的基线。
      • 流转规则、分类规则、工作节奏
    • 控制在制品数量：控制在制品数量让环节内冰星工作减少，单个工作项的完成加等待时间缩短。
      • 在制品是指特定环节内所有的工作项，包括进行中和等待的。
      • 控制在制品数量加速了用户价值的流动，对产品开发的敏捷性至关重要
      • 如果某工作长时间受阻成为瓶颈，影响上游环节，团队应聚焦于完成已经快开始的工作，及时处理出现的问题。
  • 运作看板
    • 管理工作项流动：管理工作项流动是为了让用户价值顺畅和高质量得流动。它包含三个分项实践。
      • 就绪队列填充活动(对应用户价值的输入)：是输入环境和价值流动的源头，对价值的顺畅流动和质量非常重要。
      • 看板站会(对应中间过程)：是管理价值流动过程的活动，典型看板站会发生在每个工作日，同一时间同一地点，重点关注流动过程中的问题和阻碍。
      • 发布评审(对应输出)：是需求发布前的计划活动，决定上线或发布哪些需求以及相关发布策略。是一个可选的活动，持续交付模式下，可被例行机制替代。
    • 建立反馈、持续改进
      • 流动是否顺畅的反馈，如：阻碍问题分类、影响和原因分析。
      • 质量问题的反馈，如开发和测试环境遗留缺陷的分析等。

• 不同角色关注看板的重点？
  • PM及以上人员
    • 每天需求交付计划和交付数量
    • 总体产能和吞吐量
    • 交付是否平滑
    • 控制需求导入节奏
  • SL关注点
    • WIP限制
    • 关注流动
    • 关注阻塞和瓶颈
    • 聚焦解决
  • 团队人员关注点
    • 制定计划
    • 及时拖动
    • 标识阻塞和风险

• 看板展示的核心元素？
  • 分层
  • 泳道
  • 列
  • 价值流
  • 在制品(WIP)
  • 风险&瓶颈
  • 拉动式开发

• 看板分层架构：基于产品研发等不同视角的价值流，看板可以划分为多层试图，更好的管理产品的价值的流动。
  • 产品级看板：基于产品视觉看到的研发价值流，这是每个项目开展精益看板，首要分析和建立的看板系统。管理产品特性的流动。
  • 团队看板：基于设计团队、开发团队、SIT测试团队的价值流视图，这是团队开展和改进的视图。精细化管理需求在设计阶段、Story开发、需求测试的流动。

• 看板度量指标和方法？
  • 主要指标
    • 前置时间(Lead Time)：又称为交付时间（Deliver time）
    • 吞吐量(Throughput)
    • FE流动效率
    • 准时交付率
    • 流动性&波动性
  • 主要方法
    • 价值流图
    • 累积流图
    • 控制图
    • 直方图（weibull分布图）

• 累积流图（Cumulative Flow Diagram/CFD）？
  • 累积流图是可以快速概述项目或产品工作中发生的情况的图表之一。
  • CFD中有关工作状态的典型信息有:
    • 已完成的工作量
    • 正在进行的工作
    • 未完成的工作
    • 进度如何
  • 结论
    • 为了快速交付，最有效的方法是降低在制品数量
    • 提交质量的管理杠杆点在于减少在制品数量

Scrum

Scrum是一个包括了一系列实践和预定义角色的过程框架。

Scrum类似于橄榄球赛的团队合作方式： 团队作为一个整体，在团队的内部传球并保持前进， 更好的满足当前激烈的市场竞争。

• Scrum三大特点？
  • 可能性的艺术(关注当下)
  • 团队自组织、自管理(放权)
  • 面对面沟通(提高沟通效率)

• Scrum框架？
  • 是一个轻量级的项目管理的框架，它的核心在于迭代，通过迭代去实现最终的产品。

• Srum大体框架流程
  • 将需求形成一个产品待办列表。
  • 在迭代的计划中，从产品待办列表选取适当的需求条目，进入到 sprint 待办列表。
  • 进入到 2 一 4 周的迭代开发过程，每天会进行每日站会，在站会上团队成员会共享进度资源和风险。
  • 迭代完成，提交一个潜在的可交付的产品增量给客户进行评审。
  • 最后共同展开一次回顾会议，针对本次迭代内容回顾。

• Scrum框架基本三要素和主要内容
  • 三种角色
    • 产品负责人(Product Owner/PO)
      • 是一个人并只能由一个人担任，客户代表
      • 定义所有产品功能，决定产品发布内容和日期
      • 负责管理产品待办列表
      • 对产品待办事项进行优先排序，按价值排序，与工作量无关
      • 与团队一起来进行工作量估算
      • 对于项目的成功负责并保证投资回报率
      • 认同或拒绝迭代的交付
      • 特征：被授予产品决策权，驱动产品走向成功，提供产品领导力、理想情况是真正的用户来担任。
      • 职责：产品经理、需求分析、需求管理、项目管理、质量保障、客户代表、对外职责。
    • Scrum主管(Scrum Master)
      • 保证Scrum团队遵守Scrum的价值
      • 帮助团队和组织采用scrum模式进行流程组织
      • 指导团队变得更高效，高质量。
      • 保证各个不同角色之间的良好协作
      • 不要管理团队
      • 核心能力：敏捷精益实践者、专业辅导、引导、变革、业务、技术、培训。
    • 开发团队（Dev Team）
      • 最佳团队大小：5-9人。
      • 多功能跨职能团队：程序员、测试、设计、数据库管理、架构师
      • 保证团队成员全职参与开发且长期存在
      • 自我管理，没有头衔之分，不组建子团队
      • 特性团队，全栈工程师
      • 迭代交付质量负责
      • 管理sprint backlog并跟踪进度
      • 成员更替只能在迭代之间进行，最佳方式是发布之间进行
      • 团队关系在一个迭代中应该是固定的，个人职能可以在新迭代开始时发生调整
  • 活动
    • 冲刺规划会议 Sprint Paln Meeeting
    • 每日站立会议 Scrum Daily Meeeting
    • 冲刺复审会议 Sprint Review Meeeting
    • 冲刺回顾回忆 Sprint Retrospective Meeeting
  • 三种工件
    • 产品订单（product Backlog）
      • 产品需求变动的唯一来源
      • 动态，用不完整，持续更新
      • 有序，排序越高越清晰
      • 每个产品都有一个，与团队数量无关
      • 产品负责人管理其内容，可用性和排序
    • 冲刺订单（Sprint Backlog）
      • 包含产品待办事项列表中当前Sprint的子集
      • 包含完成Sprint目标所需要的任务细节
      • 开发团队可视情况增加或移除任务
    • 新的功能增量（产品增量）
      • 当前 Sprint 完成的产品待办事项列表，以及之前所产生的增量总和
      • 必须达到完成的标准
      • 无论是否发布，必须是可用的。
    • 燃尽图（Burndown Chart）

• Scrum过程模型(5个活动事件+1个合约)
  • Sprint(迭代)
    • Scrum项目周期以一组迭代周期“sprints”组成。
    • 团队用来实现迭代目标的时间区间
    • 迭代目标：可发布的软件产品
    • 典型迭代周期为2-4周，最多一个自然月
    • 时间长度决定何时结束迭代，不由工作量来完成决定
    • 一个迭代周期的长短取决于能够保障多长时间需求变化不影响到产品开发
  • Sprint计划会议(Sprint Planning)
    • 解释：每轮迭代启动前，讨论详细开发计划的过程，输入是产品backlog，输出是团队迭代backlog。
    • 要做什么？
      • 进行迭代规则
      • PO向团队介绍产品待办事项
      • 团队在PO的协助下充分理解产品待办事项
      • 确定迭代目标和迭代合约
      • 对产品待办事项进行细分并创建迭代待办事项
    • 两个阶段
      • 选取用户故事，确定迭代目标
      • 拆分任务，创建迭代backlog
    • 关键要点：充分参与、相互承诺、确定内部任务
  • 每日Scrum站会(Daily Scrum)
    • 站立进行，固定时间（15分钟）、固定地点
    • 3个问题：昨天做了什么，今天计划，遇到的障碍
    • 信息沟通，不解决任何问题不向任何人汇报，避免无关讨论
    • 更新sprint backlog。包括增减任务项，更新任务进度和状态
    • 关键要点：准时开始、高效会议、问题跟踪、沟通协同，暴露问题。
  • Sprint评审回忆(Sprint Review)
    • 验收成果：由Scrum Master组织，PO和用户代表验收，Team提前准备负责演示。
    • 团队展示完成的功能并收集反馈
    • 对未完成的功能进行描述并说明情况
    • PO接受/不接受当前迭代
    • 邀请所有人包括客户参与
    • 好处：确定项目进度，获取用户反馈。
  • Sprint回顾回忆(Sprint Retrospective)
    • 对当前迭代周期做一个阶段性的总结
      • 哪些做的好？
      • 哪些做的不好？
      • 哪些改进？
    • 从以下方面回顾：
      • 团队效率、团队合作、项目进展、成员分工、任务分配、缺陷报告率、是否有严重的Block因素等。
    • 仅团队成员参与（Scrum master/PO/Dev Team/或客户）
    • 迭代结束进行，一般15-30分钟。
  • 迭代合约
    • 团队组成
    • 完成规范
    • 团队对迭代目标的承诺
    • 迭代长度
    • 迭代待办事项的估算
    • 迭代评审和下一次计划会议的时间和地点

• Scrum的5个价值观？
  • 承诺：愿意对目标作出承诺
  • 勇气：有勇气做出承诺，履行承诺，接受别人的尊重
  • 专注：把心思和能力都用到承诺的工作上
  • 开放：把项目中的一切放开给每个人看
  • 尊重：每个人都有独特的背景和经验，要给予尊重

• Scrum的三大支柱？
  • 透明：通过任务板，把任务和资源等进行可视化
  • 检视
  • 适应：在检视过程中发现偏差，就要进行调整，以适应当前情况

用户故事

用户故事描述了对用户、系统或软件购买者有价值的功能。

用户故事是敏捷开发方法中用来定义系统需要提供的功能和做为需求管理条目化的基础。

• 用户故事由以下三方面组成
  • 一份书面的故事描述卡片，用来做计划和作为提示。
  • 有关故事的交流，用于具体化故事细节。
  • 测试，用于记录和确认故事细节且可用于确定故事何时完成。

• 描述用户故事
  • 有什么用户角色
  • 系统提供什么功能
  • 达到什么目的或实现什么价值

• 角色类型的创建过程：当我们编写用户故事的时候，会有很多不同类型的用户。
  • 头脑风暴：只创造角色，不讨论角色。
  • 整理角色类型
  • 提炼角色类型

• 搜集用户故事的方式
  • 用户访谈
  • 问卷调查
  • 观察
  • 故事编写工作坊

• 用户故事的INVEST原则？
  • I - Independent 独立的
  • N - Negotiable 可讨论的
  • V - Valuable 有价值的
  • E - Estimable 可估计的
  • S - Small 合适的小粒度
  • T - Testable 可测试的

• 用户故事的层级关系
  • 史诗级Epic：大于一个或多个版本
  • 特性Feature:大于一个迭代Sprint
  • 故事story：迭代sprint内
  • 任务task：小时。

• 用户故事的优先级？
  • 考虑因素：价值、风险、成本、新知识。最重要要的就是根据业务价值来确定优先级， 既用户故事能给客户带来多少经济上的收益，这是最重要的。
  • 渴望度Kano模型：除了最基本的功能之外，还有一些预期功能。
  • MoSCoW原则
    • Must have：基础功能要有。
    • Should have：短期内有替代方案，功能应该有。
    • Could have：没有时间，可以不考虑。
    • won't have this time：客户希望有，但我们要同时承认它，需要在后续发布中实现，这次发布不会有。

• 案例模拟-项目流程？
  • 项目开始
  • 创角色
  • 编写第一个用户故事
  • 估算用户故事
  • 确定优先级
  • 整理用户故事
  • 合并和拆分用户故事
  • 估算速度
  • 确定迭代计划

三、持续开发与集成（10%）

持续集成

Martin Fowler对持续集成的定义是：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都是通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快发现集成错误。

• 持续集成的基本原则？
  • 只维护一个代码仓库
  • 自动化build
  • 让你的build自行测试
  • 每人每天都要向mainline提交代码
  • 每次提交都应在集成计算机上重新构建mainline
  • 保持快速build
  • 在类生产环境中进行测试
  • 让每个人都能轻易获得最新的可执行文件
  • 每个人都能看到进度
  • 自动化部署

• 持续集成更全面的原则和实践？
  • 构建失败后不要提交新代码
  • 提交前在本地，或持续集成服务器，运行所有测试
  • 提交测试通过后再继续工作
  • 回家之前，构建必须处于成功状态
  • 时刻准备着回滚到前一个版本
  • 在回滚之前要规定一个修复时间
  • 不要将失败的测试注释掉
  • 为自己导致的问题负责
  • 测试驱动的开发

• 持续集成的价值？
  • 减少项目风险
  • 减少重复过程，减少合并的复杂性
  • 减少变更到生产环境的前置时间
  • 在任何时间任何地点生成可部署软件
  • 增强项目可见性
  • 对开发团队的产品建立起更强大的信心

• 持续集成的流程(从开发到部署一直重复的过程)？
  • 开发
  • 测试
  • 编译
  • 打包
  • 部署

• 持续集成的主流工具？
  • 代码托管：
    • gitHub
    • codehub
    • gitee
  • 编译构建
    • Apache的Ant
    • Maven
    • Gradle
    • MSBuild
  • 持续集成工具
    • Jenkins
    • codeShip
    • TeamCity

• DevOps团队基于什么方式践行持续集成？
  • 基于主干开发（trunk-based development）
  • 强烈推荐DevOps团队通过基于主干开发方式践行持续集成

• 版本管理是什么？
  • 版本管理不只是分支管理的范畴，还广泛涵盖了敏捷项目管理和团队协同开发范畴。
  • 版本规划可以帮助产品经理设计产品、制定发布的节奏，调整需求的优先级。

工作流（Git Flow）

• 用于记录历史的分支
  • Git Flow使用两个分支来记录项目开发的历史
    • Master:用于保存官方的发布历史
      • 分支中包含的是可以部署到生产环境的代码，只可以merge，不允许commit
      • 在代码托管平台中，master是要被设置成保护模式的。
    • develop:用于集成各种功能开发的分支
      • 是从master分支中拉取的主开发分支，用来集成最新合入的开发成果，包含要发布到下一个release的代码。

• 用于功能开发的分支
  • 每个新功能的开发都各自使用独立的Feature分支，在创建新的功能开发分支时，父分支选择develop，而不是master。当功能开发完成时，改动的代码被合并到develop。
  • Feature分支向develop合并时，会提交一个请求，只有审核通过才被允许合入。
  • Feature是一个临时分支，它的生命周期随着功能开发完成而结束。

• 用于发布的分支
  • release分支基于Develop分支创建，我们可以在release分支上测试，修改bug等。
  • release分支的创建意味着一个发布周期的开始，任何新功能都不可以再向release分支合并，release 分支只接受修改bug。
  • release是个临时分支，当发布代码合并到master时，打上标签，release分支的生命周期就结束了。

• 用于维护的分支
  • 发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的hotfix补丁分支。
  • 这是唯一一种可以直接基于master创建的分支，一旦问题被修复，应该被合入master和develop分支，hotfix的变更会进入下一个release。
  • 在这之后，master上还要使用更新的版本号打号标签。

工作流（Github Flow）

• Github Flow
  • Github Flow工作流仅具有特性分支和主干分支，非常简单和干净。
  • 将所有内容合并到主干分支和部署，最大限度的减少了库存中的代码量。
  • 它有一个基本原则，任何主干上的版本都是可发布的。

工作流（Gitlab Flow）

• 带生产分支工作流
  • 定义
    • 创建一个反映已部署代码的production分支。
    • 将master合并到production分支来部署新版本。
  • 最大原则叫上游优先，既只存在一个主分支master，它是所有分支的上游。
  • 优点
    • 随时检查出production分支，查看生产代码。
    • 可以清晰的查看提及记录。
    • 可以避免Git Flow中常见的发布、打标签和合并的取消。

• 带环境分支工作流
  • 定义
    • master分支部署测试环境
    • master分支向pre-production分支合并部署预生产环境
    • pre-production分支向production分支合并部署生产环境
  • 优点
    • 这种变更提交只向下游流动的工作流可确保所有变更在所有环境中都经过测试。

• 带发布分支工作流
  • 定义
    • 只有一个master分支
    • 每次需要发布时拉去发布分支，并对发布分支打标签
    • 发布分支以master分支为起点，尽可能晚的创建
    • 在一个发布分支被公布后，仅有严重错误的修复能被包括在该分支中
  • 优点
    • 分支数少，易于管理
    • 发布分支明确，从项目管理维度可以明确的判断bugfix需要合入分支的策略

企业实践

• 不采用分支开发策略，一般在代码中使用开关控制，避免另起分支，也使得通过配置切换功能变得容易，一旦新功能发生故障，很容易切换回旧功能。等新功能稳定，再彻底删除旧代码。
• 主干开发
  • 主干开发的代码，一般提交到主干的头部，保证所有用户看到的都是同一份代码的最新版本
  • 主干开发避免了合并分支的麻烦。

Git

Git是目前世界上最先进的分布式版本控制系统。Git近乎所有操作都是本地执行。

• 常见的版本控制系统？
  • Git
  • SVN
  • VSS
  • CVS

• Git相较于集中式的优点
  • 版本库本地化
  • 本地仓库是服务器仓库的完整克隆。
  • 支持离线提交，适合跨地域协同开发。
  • 分支切换快速高效，创建和销毁分支简单容易
  • 本地磁盘有项目的完整历史，git绝大多数只需要访问本地文件和资源，不需要实时与代码服务器连接。

一次代码修改被成功提交到远端仓库的四个区域：本地工作区、暂存区、本地版本库、远端版本库。

• git文件的三种状态
  • 已修改状态。包括三种文件：
    • 新增文件
    • 修改的文件
    • 或被删除的文件
  • 已暂存状态
    • 对修改的文件执行git add，文件就变成了以暂存状态进入暂存区
  • 已提交状态
    • 对暂存区的文件进行git commit，文件变成已提交状态进入本地的版本库。如果要把本地的代码同步远端仓库，使用git push命令同步。

• git 配置
  • 查看版本
    • git --version
  • 配置用户名和eamil
    • git config --global user.name youname
    • git config --global user.email younemail
  • 查看配置信息
    • git config -l
  • 初始化
    • git init
  • 从远端克隆
    • git clone ssh/https

• 配置忽略文件 .gitignore
  • 有些文件不需要进行版本管理，需要排除。
  • 排除规则
    • /mtk/ 过滤整个文件夹
    • *.zip 过滤所有zip文件
    • /mtk/do.c 过滤某个具体文件
    • !/mkt/one/txt 不过滤某个具体文件

• 本地与git远端服务器传输包括两种通信方式
  • HTTPS
    • 采用用户名密码授信，但这种方式每次操作都要重新输入
    • 为了减少重复操作，需要将用户名和密码存储起来
    • 配置
      • git config --lgobal credential.helper "cache"
  • SSH
    • 根据'ssh-keygen'命令，在本地产生一对秘钥，公钥以.pub为后缀。
    • 把公钥内容黏贴至服务器，就可以使用SSH进行通信。
    • 配置过程
      • 生成ssh-key 'ssh-keygen'
      • 将public key添加到远端仓库
      • 添加ssh配置

• 远程仓库管理
  • 查看所有的远程仓库
    • git remote -v
  • 本地添加远程仓库
    • git remote add remote_name remote_url
  • 修改远程仓库的命名
    • git remote rename old-remote-name new-remote-name
  • 删除远程仓库
    • git remote remove remote-name

• 分支管理
  • 查看所有分支
    • git branch
    • -v 查看分支的最新提交
    • -a 查看所有分支包括远程分支
  • 切换分支
    • git checkeout branch_name
  • 创建新的分支
    • git checkout -b new_branck
  • 删除分支
    • git branch -d branch_name

• Git分支（指针）
  • 本质上是个指向commit对象的可变指针
  • 分支的默认名为master
  • 每次提交都会自动向前移动
  • 新建一个分支，相当于新建一个指针
  • 作用：从某个提交对象往回看历史
  • 识别当前分支
    • HEAD指针指向谁。
    • 做一次提交
    • 切换回master分支

• merge和reabase的区别
  • rebase没有进行合并操作，只是提取当前分支的修改，将其复制在了目标分支的最新提交后面。
  • rebase的提交历史反映了项目过程中发生了什么，关注点在开发过程。
  • merge是一个合并操作，会将两个分支的修改合并在一起，默认情况下会提交合并中修改的内容。
  • merge的提交历史忠实的记录了实际发生过什么，关注点在真实的提交历史上面。

• 常见的开发模式？
  • 主干开发：由于有所人都在主干上开发，每一次提交都会直接影响主干代码，所以需要团队成员严格遵守纪律，从而保证团队高效协作。
  • 分支-主干模式：可以保证主干代码不受损害。

• 使用分支-主干开发，团队成员应该遵循的步骤？
  • 创建开发分支，检出最近的成功代码
  • 本地修改代码
  • 在本地构建编译，确保修改没问题
  • 合入自己的开发分支，并触发分支门禁构建，通过之后进入代码审核再合入，确保代码质量达标
  • 开发进行功能验证
  • 合入到团队主干分支， 并触发主干门禁构建，门禁构建通过之后，通过代码审核合入到主干，保障主干代码质量。

Clean Code

代码可信在华为就是用clean code来衡量。

代码需符合smart原则（clean code衡量的维度）：简洁、可靠、高效、可维护、可测试、可移植。

• 如何评估Clean Code？
  • 专家评审维度指标项
    • 命名准确
    • 注释精简
    • 函数短小
    • 重复极小
    • 依赖最少
    • 职责单一
    • 隐藏细节
    • 合理抽象
    • 测试相伴
  • 工具度量评估指标项
    • 编译告警
    • 冗余代码
    • 危险函数
    • 重复代码
    • 圈复杂度
    • pclint告警
    • 编程规范
    • SAI
    • QDI=>达标和挑战
    • 架构一致

• Clean Code可视化指标
  • 圈复杂度
  • 嵌套层数
  • 有效注释比例
  • 有效代码行数
  • 函数参数个数
  • 局部变量个数
  • 非结构化语句的数量

• 静态代码检查的四个维度
  • 代码重复率
  • 编码风格
  • 圈复杂度
  • 代码安全

• 静态代码检查常用工具

  • splint
  • klocwork k8
  • coverity
  • findbugs
  • PMD
  • Cppcheck

• 静态代码的企业实践

  • 华为云的codeCheck

四、持续测试与反馈（13%）

测试

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

• 软件测试方法
  • 按测试方法有
    • 黑盒测试：测试应用程序的功能。适合集成/系统测试。
    • 白盒测试：测试应用程序的内部结构或运作。适合单元/集成/系统测试。
  • 按测试类型有
    • 功能测试：按软件功能划分，保证覆盖所有功能的各种条件组合。
    • 系统测试
    • 极限值测试：测试特殊条件、特殊环境下是否正常运行。
    • 性能测试：衡量软件具有的响应能力。
  • 按测试阶段有
    • 单元测试：测试每个单点函数。
    • 集成测试：关注模块与模块之间的交互
    • 系统测试：端对端，对整个系统进行测试，使用真实的用户场景和数据。
    • 回归测试：是验证新的代码，是否会对现有功能产生影响。

敏捷测试

• 敏捷测试宣言？
  • 测试是一个活动 胜于 测试是一个阶段
  • 预防缺陷 胜于 发现缺陷
  • 做测试者 胜于 做检查者
  • 帮助构建最好的系统 胜于 破坏系统
  • 团队为质量负责 胜于 测试为质量负责

• 敏捷测试原则？
  • 预防缺陷胜于发现缺陷
  • 持续测试实现快速与高质量
  • 成为全栈测试人员
  • 从质量保证专项质量协助
  • 渴望持续学习

• 如何开展敏捷测试？
  • 测试左移
    • 鼓励开发者自测，在开发阶段尽早开展测试
    • 使用测试驱动开发、行为驱动开发
    • 通过契约测试，解耦前后端和服务间的开发依赖
  • 测试右移
    • 在发布阶段和线上阶段进行测试
    • 灰度测试
    • 线上性能监控
    • 在线拨测

• 测试分层模型 - 测试的金字塔模型
  • UI测试
  • 端到端测试
  • 集成测试
  • 单元测试（比重较大）

• 测试分层模型演进 - 测试的纺锤模型：减少单元测试，增强接口、契约、在线测试。
  • UI测试
  • 契约测试
  • 接口测试（比重较大）
  • 单元测试
  • 在线测试

• 完整的测试过程/测试的四个阶段
  • 测试策略：描述测试工程的总体方法和目标，描述目前在进行哪一个阶段的测试以及每个阶段在进行的测试种类以及测试人力安排。
  • 测试设计：将软件需求转换成测试需求，最终形成测试用例的过程。
    • 设计方法有：等价类、边界值、因果土、正交表、场景分析
  • 测试执行
    • 回归测试
    • 新功能测试
  • 测试报告
    • 合格的测试报告应该包含
      • 产品版本说明
      • 环境描述
      • 测试结论
      • 风险
      • 对产品质量的评价
      • 对技术指标的评价
      • 却缺陷的分析
      • 对覆盖率的分析
      • 测试结果统计
      • 遗留问题清单

• 自动化测试的目的
  • 减少人力成本、降低重复工作
  • 确保新特性引入不影响老特性
  • 版本升级不丢特性
  • 问题不会重复发生

• 提单步骤
  • 发现缺陷
  • 重现缺陷
  • 与开发确认
  • 提交问题单
  • 开发自验证
  • 提交版本
  • 测试验证
  • 关闭问题单

• 问题单应该包含的要素
  • 问题的级别、类型
  • 问题描述
  • 根因分析
  • 处理意见
  • 测试建议
  • 关联的测试用例
  • 开发定位所需日志、截图
  • 环境信息描述

常见的测试方法和覆盖场景

• API接口测试：是测试系统组件间接口的一种测试。
  • 两种测试场景
    • 系统与外部其它系统之间的接口
    • 系统内部各个子模块之间的接口
  • 四个测试重点
    • 检查接口参数传递的正确性
    • 接口功能实现的正确性
    • 输出结果的正确性
    • 对各种异常情况的容错处理的完整性和合理性
  • 测试分类
    • 单Api接口测试：主要关注参数取值和参数取值组合
    • 组合API接口测试：把多个API的逻辑串联起来测试。主要关注功能的完整性和合理性。
  • 面临的挑战
    • 服务不具备独立验证的能力。
    • 自动化用力开发效率低。
  • 三原则
    • 同源：API接口测试的同源原则就是设计、开发、测试、三个活动基于同一源头开展。
    • 独立测试：创建Mock服务使环境解耦。
    • 100%自动化测试：开发自测阶段，开发人员优先，为提高效率应该尽量高效使用自动化。
  • API接口测试的五个步骤
    • 接口梳理
    • API接口参数分析
    • 业务场景梳理
    • 单接口测试设计
    • 多接口组合场景设计
  • API接口测试自动化流程
    • 接口分析
    • 用例设计
    • 接口封装
    • 用例生成
    • 用例执行

• 性能测试
  • 重要性：不仅仅是用户体验的损失，而是会产生不可挽回的经济损失。

• 契约测试（Contract Testing）
  • 定义： 契约测试是一种针对外部服务的接口进行的测试。它能够验证服务是否满足消费方期待的契约。这个契约包含了对输入和输出的数据结构的期望、性能、以及并发性。
  • 它有两个微服务
    • 一个作为Consumer：service的使用者，向provider发起HTTP请求来获取数据
    • 一个作为Provider：service的提供者，接受consumer的HTTP请求并返回数据
  • Contract：契约，一种定义在Consumer和Provider之间的交互方式
  • 保证Provider对Contract的修改永远都基于Consumer的需求，并且是全体Consumer的总和。
  • 契约测试的实践方式
    • 通过Mock技术解除Consumer对Provider的依赖
    • 通过契约测试保证Provider的修改对Consumer保持一致
  • 在Provider的测试环境中，使用契约（Contract）代替真实的Consumer，来验证Provider的修改会不会造成任何契约的失效。

• mock测试
  • 概念
    • mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。
  • mock测试的目标
    • 服务解耦：通过mock解除对其他服务的依赖
    • 分层测试，自动化一切：
    • 精准测试：通过mock技术精准模拟其他服务的返回
    • Mock自服务（yamL同源）：将服务自己对外提供的接口mock化，从而达到与yaml（api接口定义文档）同源
    • TIP：线上测试，也叫生产环境测试

• WebUI测试
  • WebUI测试的场景
    • 冒烟测试（主业务流程）
    • 新功能测试
      • 注意：新功能测试因为需求不稳定，变化比较多，不太适合进行自动化测试。
    • 回归测试
      • 回归测试和兼容性测试，前者执行了大量的回归用例，后者需要这些用例在不同浏览器重复执行，那么完全可以用自动化的方式将重复、低效易错的工作变得更加高效，从而节约人力成本。
    • 兼容性测试（一条测试脚本，多个浏览器执行）
    • 完成手动测试无法完成的工作下班后无人值守测试
  • Web自动化测试的三大优点
    • 更快的测试速度。带来更高的测试效率
    • 更高的测试覆盖率。当测试场景复杂时，纯手工功能测试显然无力覆盖所有用例。
    • 更好的稳定性和可扩展性。 功能测试靠人，自动化测试靠机器。

• 可靠性与安全测试
  • 可靠性设计的四个测试类别和指标
    • 数据可靠性
      • 数据恢复用时(RTO)
      • 数据恢复点(RPO)
    • 系统可用性
      • 故障检测时间
      • 故障隔离时间
      • 故障定位时间
      • 故障恢复时间
    • 升级部署
      • 上线、升级时间
      • 升级中断时间
    • 业务可用度
      • 业务可用度
  • 可靠性测试-Chaos混沌测试
    • 应对随机性故障的预测。

• 在线测试
  • 在线测试面临的三个挑战
    • 如何知道开发人员自测或测试环境中没有问题的服务将在生产环境中工作？
    • 可以收集生产环境中的哪些信息，帮助发布更高质量的产品？
    • 如何检测和应对软件升级后发现的问题
  • 什么是在线测试
    • 在线测试是指在生产环境中开展的，或者利用生产环境数据开展的各种类型的测试活动。
  • 在线测试包含的测试活动
    • 导流测试
      • 原理： 将现网数据引流到研发区验证环境进行测试，通过对比研发区的验证结果与生产环境的真实结果是否一致判断新版本是否存在潜在问题。
      • 测试要点
        • 请求收集：收集生产环境用户真实请求
        • 数据同步
        • 流量回放
        • 结果对比
    • 灰度测试：在灰度发布环节，将灰度用户作为测试数据进行预发布验证
    • 部署测试
      • 原理： 正式发布前进行一轮冒烟测试，快速验证现网环境是否正常。
      • 测试要点
        • 测试时机：在生产环境部署后快速启动部署测试
        • 测试数据：基于生产环境的真实数据请求
        • 测试范围：执行核心功能和常用功能所对应的测试用例
        • 测试结果：核心功能或者常用功能用例执行失败立即定位解决或回退
    • 在线持续测试
      • 原理：在生产环境中进行 7 * 24 小时持续不断地对现网功能进行拨测，以便于尽早先于用户发现问题并协助研发人员快速修复上线。
      • 测试要点：
        • 筛选用例：筛选重要功能对应的测试用例
        • 定时拨测：定时（5分钟、1小时）对重要功能进行拨测
        • 现网告警：用例执行失败并发送告警短小，提示告警登基
        • 处理上线：研发人员根据告警快速处理并快速修复上线

测试度量指标体系和质量评估

• 测试度量指标体系：用来衡量一个好的测试需要执行的相关操作。
  • 过程度量
    • 覆盖率
      • 代码覆盖率
      • 接口覆盖率
      • 需求覆盖率
      • 漏测率
    • 执行率
    • 测试效率
      • 执行时长
      • 自动化率
      • 问题发现率
  • 结果度量
    • 功能测试
      • 通过率
    • 性能测试
      • 吞吐量
      • 时延
    • 安全测试
      • 漏洞数
      • 红线满足度
    • 可靠性测试
      • MTTF(衡量可靠性的参数:平均失效时间)
      • MTBF(衡量可靠性的参数:平均无故障工作时间)

• 测试退出条件：测试满足退出条件说明当前质量是可控的。
  • 当达到了必要的信心级别风险可接受时
  • 当发现缺陷的代价 > 缺陷发生引起的代价时
  • 当达到测试完成标准（退出/成功标准）时

• 测试能力成熟度评估
  • 初始级：测试混乱，缺乏成熟的目标测试，测试可有可无
  • 定义级：测试目标是验证软件符合需求，会采用基本的测试技术和方法
  • 集成级：测试贯穿整个软件的生命周期，建立在满足用户和需求上。
  • 管理和测试级，测量级：测试是有度量和质量的控制过程。
  • 优化级：具有缺陷预防和质量控制，建立起测试规范和流程，并不断改进测试。

五、持续安全与审计（8%）

DevSecOps

DevSecOps是在DevOps实践基础上，在持续构建的各阶段引入针对产品的安全保障活动，强调开发、运维/运营、安全团队的融合运作，是DevOps的增强和完善。

DevSecOps基于“安全问题，人人有责”的原则。它强调开发人员可以怎样把安全检查与他们的集成和部署流水线构建到一起。

• 安全贯穿始终，Gartner给出的最佳实践有：
  • 安全控制尽可能的自动化和模块化
  • 对所有的应用实施一个轻量化的威胁建模
  • 通过IAM和基于角色的权限控制来实现职责分离
  • 在开发过程中扫描开源软件
  • 在开发过程中扫描漏洞及配置文件
  • 扫描自定义的代码、应用及API
  • 将脚本、模块作为敏感代码进行对待
  • 衡量系统完整性并确保加载正确

安全策略和工具

• 操作和资源可管控
  • 什么是操作全程可管控？
    • 资源操作+业务操作

• 如何实现操作全程可管控？
  • 配置安全策略：通过严格的策略限制可以访问业务资源环境的人员，杜绝越权访问。
  • 风险识别和处置：预定义风险高危操作行为，对于高危行为进行权限控制，限制低权限人员执行高危操作。
  • 操作可审计、追溯：记录操作人员的字符、图形化操作、操作过程可回放，实现事后追溯和举证。

• 如何实现资源全程可管控？
  • 风险可识别：
    • SA-云服务基线管理，提供了五个方面的风险
      • 身份认证
        • 检查是否启动IAM用户
        • 检查租户的用户列表，是否至少有两个已启用的用户，且其中一个用户所属的用户组不是admin用户组。
      • 访问控制
        • 网络ACL规则检查
        • 检查所有网络ACL的规则是否存在不安全规则，既是否存在开放过大的访问空策略。不安全规则，既方向为入方向，动作为允许，协议为任一类别协议，原地址为0.0.0.0/0（所有地址），源端口为1-65535或0，目的地址为 0.0.0.0/0（所有地址），目的端口范围为1-65535或0，或者特定的业务端口，如22。
      • 日志审计
      • 数据安全
      • 基础防护
  • 操作可审计：
    • 云审计服务(CTS)通过配置追踪器，云审计服务可以实现安全审计，问题定位，资源追踪。
  • 安全策略：
    • 统一身份认证(IAM)：策略根据授权的精细程度分为两个策略。
      • 细粒度策略
      • Role-Based Access Control（RBAC）测录

• 态势感知SA（Situation Awareness）
  • 概念：是可视化威胁检测和分析的平台。
  • 态势感知的功能
    • 总览
    • 态势感知大屏
    • 威胁检测
    • 威胁分析
    • 安全编排
    • 主机漏洞扫描
    • 网站漏洞扫描
    • 应急漏洞
    • 主机基线检查
    • 云服务基线检查
    • 告警设置
    • 日志管理
  • 态势感知能够检测的云上安全风险有
    • DDoS攻击
    • 暴力破解
    • Web攻击
    • 后门木马
    • 僵尸主机
    • 异常行为
    • 漏洞攻击
    • 命令与控制

• 云审计服务(Cloud Trace Service/CTS)
  • 概念
    • 是华为云安全解决方案中专业的日志审计服务，提供对各种云资源操作记录的收集、存储和查询功能，可用于支持安全分析、合规审计、资源跟踪和问题定位等场景应用场景。
  • 云审计服务的功能主要包括
    • 记录审计日志
    • 审计日志查询
    • 审计日志转储
    • 事件文件加密
    • 关键操作通知
  • 日志审计模块是信息安全审计功能的核心必备组件，是企事业单位信息系统安全风险管控的重要组成部分。

• 统一身份认证（Identity and Access Management/IAM）
  • 概念
    • 是华为云提供权限管理的基础服务，可以帮助安全的控制华为云服务和资源的访问权限
  • IAM无需付费即可使用，只需要为账号中的资源进行付费。

• 如何实现业务操作可管控？
  • CBH策略
  • CBH审计
  • SA-漏洞管理

编码安全与工具

• 安全编码（Secure Coding）
  • 概念
    • 是一种开发计算机软件的实践，可以防止意外引入安全漏洞。缺陷、错误和逻辑缺陷始终是导致可悲普遍利用的软件漏洞的主要原因。

• 软件研发安全的目标
  • 确保数据是完整的，未被篡改的
  • 确保数据不被非法访问与窃取
  • 要求保护资源在需要时可访问

• 安全典型案例-c/c++案例：
  • 字符串操作不当带来风险
  • 源字符串长度大于目标缓冲区
  • 危险的堆操作及带来的风险
  • 命令注入
  • 不安全函数使用
    • 如memcpy、strcpy。
    • LInux系统都整理输出了它的一个替换的安全函数集，如 memcpy替换为memcpy_s，通常都是以_s结尾。

• 安全典型案例-Java案例：
  • mybatis使用不当导致SQL注入风险
  • OS命令注入
  • 字符串操作不当带来风险
  • 目录遍历攻击
  • XML文件使用相关安全风险

• 危险的堆操作有？
  • 内容拷贝时未判断目标内存长度的有效性（目标内存过小）
  • 内存申请完毕后未判断空指针（空指针引用）
  • 使用已经释放的内存
  • 调用不匹配的内存管理操作（new,delete,malloc,free混用）
  • 重复释放内存（double free）
    • 重复释放内存会导致内存管理器出现问题，在一定情况下重复释放内存，可能导致堆溢出漏洞，可以被用来执行恶意代码，具有很大安全隐患。

• 堆管理不当带来的危险
  • 拒绝服务攻击
  • 执行任意代码

• 典型错误-直接执行命令，未对命令字符串做校验
  • 系统中应该尽量避免使用Runtime.exec()，通常建议使用系统的JDK提供的API来实现对应的功能。若涉及到一些JDK未提供的API，可优先使用本地方法调用实现。

• 开源静态代码分析工具
  • 目的：使用自动化工具执行安全代码审查可以清除许多低挂的果实，例如SQL注入，跨站点脚本，反序列化漏洞等
  • 对于Java程序，可以用一个名为“FindSecBugs”的工具对代码进行深入分析。

漏洞扫描与工具

• 漏洞
  • 概念：是指计算机系统安全方面的缺陷，使得系统或其应用数据的保密性，完整性、可用性、访问控制等面临威胁。
  • 漏洞会影响到很大范围的软硬件设备，包括操作系统本身及其支撑软件。

• 常见的漏洞按照分类可以分为三大类：
  • 主机漏洞
    • 内存破坏类漏洞
    • CGI类漏洞
    • 输入验证类漏洞
    • 配置错误类漏洞
    • 系统本地补丁
    • 常见协议弱口令
    • 木马病毒
  • Web漏洞
    • SQL注入攻击
    • 跨站脚本
    • 文件包含
    • 远程代码执行
    • 主流CMS漏洞
  • 数据库漏洞
    • Oracle
    • MySQL
    • SQL Server
    • DB2
    • Informix
    • Sybase

• 其他
  • SQL注入漏洞、XSS漏洞是web应用上的漏洞
  • 永恒之蓝漏洞：发生在windows系统上的越权漏洞
  • 0-day漏洞：是已经被发现（有可能未被公开），而官方还没有相关补丁的漏洞
  • 镜像漏洞：是指Docker这类容器化结束中镜像所包含的漏洞。

• 漏洞分类
  • 基于威胁类型分类
    • 获取控制
    • 获取信息
    • 拒绝服务
  • 基于技术类型分类
    • 内存破坏类
    • 错误逻辑类
    • 设计错误类
    • 错误配置类
    • 输入验证类
  • 基于利用位置分类
    • 本地漏洞
    • 远程漏洞

• 漏洞排名
  • 注入、XSS长期出现，是Web安全中最常见攻击行为。

• SQL注入
  • 概念：是指将不受信任的数据作为命令或查询的一部分发送至解析器，会产生注入缺陷。
  • 后果：导致数据丢失，破坏或泄露给无授权方，缺乏可审计或是拒绝服务。注入有时可导致主机被安全接管。
  • 预防措施：
    • 净化用户输入
    • 利用正则表达式对传入参数做白名单校验
    • SQL语句使用参数化查询
    • 对SQL语句采用预编译等

    动态拼接查询语句存在注入风险，不宜使用。

• 跨站脚本(XSS)
  • 概念：本质上看，跨站脚本实际上是一种恶意代码执行的方式。主要原因在于网站对于用户提交的数据过滤不严格导致问题产生。
  • 简称为CRoss Site Scripting，因为容易和css层叠样式表混淆，为了区分，简称为XSS攻击。
  • 危害：
    • 盗取用户的cookie信息。 模拟用户和网站交互，获取用户的数据和信息。
  • 攻击方式分类有三种
    • 反射型：跨站代码存在于链接中，请求链接时，经过服务端反射回来。
    • 存储型：跨站代码存储于服务端。
    • DOM型：前端操作获取dom中的数据在本地执行
  • 跨站请求伪造CSRF：从攻击方式上，它并不属于XSS攻击。

• 反射型XSS攻击的实施步骤
  • 用户正常登录服务器，得到一个包含session的cookie。
  • 攻击者通过某种方式让客户打开一个包含攻击信息的页面，如发送广告邮件。
  • 用户打开该URL会发现是一个服务器上的一个正常页面
  • 但是该页面的html标签包含了js脚本，通过js脚本可以读取用户的cookie值，并发送给攻击者。
  • 攻击者获取cookie后，利用其中的session信息，就可以进行会话劫持，仿冒用户登录站点，并进行后续攻击行为。

• 安全测试阶段的安全漏洞扫描主要包括哪些内容？
  • 主机漏洞扫描
  • Web漏洞扫描
  • 端口扫描
  • 安全配置合规检查

• 漏洞扫描通常的执行流程包括
  • 分析被测对象
  • 选择对应的扫描服务
  • 配置工具参数
  • 确认扫描报告
  • 修复已知漏洞

• 主机漏洞扫描案列
  • 使用有漏洞的三方件
  • 协议使用不安全算法

• 安全配置扫描案例

  • Linux扣了复杂度不合规
    • 简单的口令容易被暴力破解，在系统设置的时候，应强制用户使用健壮口令。
    • 口令必须包含大小写字母、数字、特殊符号，业界规范要求密码长度至少 14个字符。
    • 口令要进行加密存储

• 针对口令的加固措施

  • 登录延迟
  • 锁定账号
  • 验证码
  • ip白名单+告警
  • 日志

六、持续部署与发布（24%）

持续部署

持续交付以及持续部署等概念的核心：将技术行为与业务决策解耦。

• 耦合？
  • 耦合就是对某元素与其他元素之间的链接、感知、和依赖的量度，这里说的元素可以使功能对象，也可以值系统、子系统、模块。

• 系统耦合的三个级别
  • 代码级耦合
  • 组件级耦合
  • 服务级耦合

• 持续交付
  • 概念： Continuous Deliver缩写为CD，是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定持续的保持在随时可以发布的状况
  • 目标：让软件的建置、测试与释出变得更快以及频繁，减少软件开发的成本与时间，减少风险
  • 持续交付以持续集成为基础。
  • 持续交付的实施框架
    • 分支模型
    • 技术架构
    • 数据库

• 持续部署（continuous Deployment）
  • 在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署优质的构建版本，把部署到生产环境的过程自动化。
  • 目标：代码任何时刻都是可部署的，可以进入生产阶段。

• 持续发布的主流工具？
  • Ansible
  • Puppet
  • SpringBoot
  • CCE
  • Kuberetes
  • ServiceStage

微服务架构

微服务是当前和未来的主流架构，带来的核心价值是能缩短业务上线周期和保证业务运行高可靠。

• 应用架构的演变
  • 第一代：单体架构
    • 紧耦合
    • 系统复杂、错综交互，动一发而牵全身
    • 完全封闭的架构
  • 第二代：SOA架构
    • 松耦合
    • 大团队：100-200人
    • 按年、半年、月升级发布
    • 集中式：计划内停机扩容
  • 第三代：微服务架构
    • 解耦
    • 小团队
    • 按天、周升级发布
    • 可拓展性：自动弹性伸缩
    • 高可用：升级、扩容不中断业务

• 微服务架构
  • 跟传统的单体式架构不同，微服务可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务不会相互影响。
  • 微服务带来了更高效和更经济的弹性能力。
  • 微服务的特征
    • 小：small services,粒度小，且专注一件事。
    • 独：own process，单独的进程。
    • 轻：lightweight mecharnisms,轻量级的通信机制，通常是HTTP/REST接口。
    • 松：independently deployable，松耦合、可独立部署。
  • 微服务底座（CHASSIS）
    • 是一种微服务模式。
    • 横切面问题有：
      • 日志框架
      • 健康检查
      • metrics
      • 分布式追踪
    • 在这种模式中，用户并不需要自己去处理横切关注点，而是将他们交给专门的框架来处理，用户可以更聚焦业务逻辑本身，简单、快速的开发微服务。

• 微服务框架 - Spring Cloud
  • 是一系列框架的有序集合
  • 利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，如以下，都可以用Spring Boot的开发风格做到一键启动和部署。
    • 服务发现注册
    • 配置中心
    • 消息总线
    • 负载均衡
    • 断路器
    • 数据监控
  • Spring Cloud通过Spring Boot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

容器技术

• 容器
  • 相当于软件行业的集装箱。
  • 容器是操作系统内核自带能力。
  • 容器是在Linux内核实现的轻量级高性能资源隔离机制。
  • 容器实现了快速交付和部署
  • 关键价值
    • 快速交付和部署：一站式部署/运维容器应用，一键式滚动升级
    • 提升资源利用率：更细粒度地划分资源
    • 保障业务高可用：秒级弹性扩容，快速响应并发高峰
    • 复杂系统管理简单：单一重型应用解耦拆分为多个轻量级模块，每个模块升级、伸缩更加灵活轻松。

• 容器技术：容器技术在云计算领域可以分为两大类
  • 以Docker为代表的容器引擎技术
  • 以K8S为标准的容器编排技术

• docker
  • docker是容器技术的一种，它是将任何需要运送的代码进行封装、转移、管理的标准化工具。
  • 提供了统一的软件打包能力。
  • 有两个版本，免费开源和商用版
  • docker的技术特点
    • 容器镜像定义了统一的软件交付标准。
    • 文件挂载提供了更小资源占用的运行环境。
    • 共享OS内核使容器本质上只是一个进程，秒级启停。
  • docker的技术优势
    • 统一的软件交付标准可以屏蔽环境差异，使能DevOps。
    • Docker为应用提供了一个统一的环境，避免应用在不同主机上因为环境不同而产生问题。
    • 更小的资源消耗，提高资源利用率，匹配微服务架构。
    • 极速的弹性伸缩、故障恢复、解放运维生产力。
  • docker的三个关键技术
    • Namespace：实现容器运行环境的隔离。
      • 负责运行环境的隔离，既每个容器都是一个独立进程，每个容器相互不可见，包括进程隔离、网络隔离、文件隔离
    • Cgroup：实现容器运行的资源隔离。
      • 是负责运行资源的隔离或者说独占，可以为每个容器指定资源数量，互相不侵占。
    • Union Filesystem(UnionFS)：一种分层，轻量级且高性能的文件系统。 支持对文件系统的修改作为一次提交来叠加。
      • 是解决应用运行的小型化统一标准，容器镜像提供了容器运行的基础，但容器镜像并不等于容器。
  • Docker镜像
    • Docker镜像文件Image，提供了一个快速部署的模板，包含了已经打包好的应用程序和运行环境，基于Image可以快速部署多个相同的容器。
    • Docker镜像是一个特殊的文件系统。
    • 镜像的特点是分层存储。
    • 实际上容器镜像是一系列分层的只读文件。
    • 优点
      • 多个容器可以共享Image存储，节省存储空间。
      • 部署多个容器时，base image可以避免多次拷贝，实现快速部署。
  • Docker镜像的生命周期
    • docker pull 从镜像仓库拉去一个镜像
    • docker push 推送镜像到镜像仓库
    • docker build 将DockerFile构建为镜像
    • docker tag 为镜像打上一个标签
  • Docker容器的生命周期
    • docker run 运行一个容器
    • docker stop 停止一个容器
    • docker start 启动一个容器
    • docker restart 重启一个容器
    • docker kill 杀掉一个运行的容器
    • docker pause 暂停一个容器
  • Docker发布系统工作机制
    • build
    • ship
    • run
  • Docker的重要组件
    • Docker引擎
    • Docker客户端
    • 镜像仓库
  • DockerFile:文件指令集，描述如何自动创建Docker镜像
    • DockerFile是包含若干指令的文本文件
    • DockerFile由4部分组成
      • 基础镜像指令
      • 维护者信息
      • 镜像操作指令
      • 容器启动指令
    • DockerFile常见参数
      • FROM<image>
      • WORKDIR
      • RUN
      • EXPOSE
      • VOLUME
      • CMD

• 容器编排
  • 概念
    • 一组互相连接的操作系统（实体机/虚拟机/容器）形成一个整体的资源池
    • 可以扩展到上千个节点，具备自我修复，扩展和收缩能力
    • 作为环境抽象层存在，使得应用不必关心所运行的节点

• Kubernetes简称K8S
  • 概念
    • 是用于自动部署，扩展和管理容器话应用程序的开源系统。
  • 是业界公认的容器编排领域的事实标准
  • 是完全的开源软件，社区开源版本直接运用于生产的风险大，所以各大厂商都用开源版本做了商业险增强、测试。
  • 容器编排系统以集群做为一个整体，一个集群看做一个完整的k8s的产品。
  • k8s的整体架构
    • master管理节点
      • api server：提供了客户端组件，管理cluster的各种资源。
      • scheduler：负责决定将Pod放在哪个Node上运行，调度。
      • controller manager：负责管理Cluster各种资源，有多种controller组成，包括：replication controller、namespace controller。
    • Node(Worker)：运行工作负载的节点，也叫worker。它运行容器，node由master统一管理。node负责监控并汇报容器的状态，同时根据master的要求管理容器的生命周期。
      • kubelet：管理Pods和它们的容器、镜像、卷等。
      • kubeproxy：提供统一的访问能力，转发service请求到Pod，如果有多个副本，kubeproxy会实现负载均衡。
      • kubectl：k8s的命令工具。
    • 第三方组件
      • ETCD
      • Docker
      • 监控
  • k8s关键概念 - POD
    • pod是k8s最小工作单元，包含一个或多个容器，pod中的容器会作为一个整体被master调度到一个node中运行。
    • pod中所有容器使用同一个网络namespace，既相同的IP地址和Port空间，这些容器可以共享存储。
    • pod是能够创建、调度、管理的最小部署单元，是一组容器实例的集合，而不是单独的应用容器
    • 从生命周期来说，pod是短暂的而不是长久的应用。
    • pod被调度到节点，保持在这个节点上直到被销毁。
  • k8s关键概念 - ReplicaSset
    • ReplicaSset,是副本控制器，主要作用是控制deployment应用副本的数量。
    • ReplicaSset解决了Pod的扩容和缩容问题
    • 通常用于无状态应用，因为无状态应用会涉及到扩缩容
    • 确保Pod一定数量的份数（replica）在运行，如果超过这个数量，控制器会杀死一些，如果少了，控制器会启动一些。
  • k8s关键概念 - deployment
    • deployment既在k8s中部署的无状态的应用
      • 典型代表：nginx,tomcat
      • 不必为应用保持状态/持久化数据
      • 每个实例对于同一个请求响应的结果完全一致
      • 实例重启会丢失运行态数据
    • 无状态应用的本质就是一个应用的多个实例之间完全没有区别，每个请求在不同的实例返回的结果都是一样的，k8s对他们的处理也是随机，比如缩容，会随机杀掉几个容器。
    • 对于用户来说，用户会建一个development， development会自己建replicset， replicset会建pod
  • k8s关键概念 - statefulset
    • statefulset既在k8s中部署的有状态的应用
      • 典型代表：mysql,redis
      • 每个实例具有唯一的网络标识符
      • 生命周期的操作将有序的在不同实例进行
      • 一般会挂载持久化存储保证数据持久性
    • 有状态应用本质是在运行过程中会保存数据或状态的工作负载称为“有状态工作负载”，每个实例都是唯一的。
    • 有状态应用除了数据之外，每个实例都是一个独立的，如mysql。会区分主从实例，那么在重启之类的操作的时候，每个实例的重启都是有顺序的。
  • k8s关键概念 - DaemonSet
    • DaemonSet是一个特殊的应用对象，可以让所有的node节点上运行某个程序
    • DaemonSet能够让所有的node节点运行同一个pod
  • k8s关键概念 - service
    • service定义了pods的逻辑集合和访问这个集合的策略。pods集合是通过定义service时提供的label选择器完成的。
    • service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理
    • service抽象使得前端客户和后端pods进行了解耦
    • k8s service支持TCP和UDP协议，默认是TCP
    • k8s支持两种基本的服务发现方法：环境变量和DNS
    • service负责提供容器的访问，是通过4层协议访问，通过端口进行区分。
    • service定义的是一种四层转发，也可以理解为四层负载均衡。是通过iptables(或IPVS)的方式实现的，只支持随机转发。
    • service的三种类型
      • ClusterIp:使用集群内的私有IP
      • nodePort：除了使用clusterIp外，也将service和port映射到每个node的一个指定内部port上，映射的每个node的内部port都一样
      • loadBalancer：使用一个clusterIp & nodePort，但是回想cloudprovider申请映射到service本身的负载均衡
        • loadBalancer跟nodeport其实是同一种方式，区别在于，loadBalancer比nodeport多了一步，可以调用cloudprovider去创建LB来向节点导流
  • k8s关键概念 - ingress
    • ingress提供了7层访问，在集群提供7层负载均衡能力，一般通过nginx实现网络转发
    • 七层负载均衡采用了增强型弹性负载均衡，在四层负载均衡的基础上支持了URL配置，通过对应的URL将访问流量分发到对应的服务。同时，服务根据不同URL实现不同的功能。
    • 通过配置公网类型和私网类型的负载均衡实例可以实现公网的七层路由转发和内网（同一VPC）的七层路由转发。
    • service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。
    • ingress是授权入站连接到达集群服务的规则集合
  • k8s工作原理
    • controller-manager会持续watch各类set，定期同步，保证最终一致性，而scheduler会持续watch集群的node共调度使用，kubelet会持续watch被调度到本节点的pod，执行生命周期动作。
  • K8S manifest
    • 通过 K8S manifest文件可以用yaml形式来描述在k8s中以pod的形式运行的应用容器，以及要运行多少个应用的副本。

• docker和k8s的关系
  • docker容器是基于操作系统层，打包了软件对环境的依赖，保证统一软件交付在开发、测试、生产不同环境的一致性。
  • k8s是容器集群的管理，提供资源的管理和容器的调度技术，提供容器应用生命周期管理、弹性伸缩、监控运维的基本机制，决定容器之间如何进行交互。
  • 由docker和k8s所带动的容器标准化大幅简化了各种环境管理工作，提升了部署流程自动化程度，因此大大加速了DevOps理念落地进程。
  • 容器化技术docker和k8s，促进了CI/CD的流程，降低了应用从构建到部署的流程复杂性，加速业务的快速迭代。

自动化部署

一切既代码，说法最早来源与基础设施既代码。

一切既代码，实际讨论的就是自动化。

一切即代码(基础设施既代码)，是一种思想，通过可重用的代码实现IT环境变更的自动化，并对代码进行版本控制。

• 容器编排对基础设施即代码的价值是？
  • 一次构建，多处运行
  • 一次配置，运行任何应用
  • 让应用生命周期管理变得更加高效

• 没有自动化前的软件部署，有哪些问题
  • 全程人员参与，浪费大量时间
  • 如果节点多，时间成倍增长
  • 人为干预，可能导致认为失误多
  • 无自动化回滚，或者难以回退。

• 常见的开源自动化配置管理工具
  • Puppet
  • Chef
  • SaltStack
  • Ansible:更轻量级。

• Terraform多云资源管理
  • Terraform提供了对资源和提供者的灵活抽象
  • Terraform与其他系统并不排斥

• Marddown
  • 轻量级标记语言
  • 软件文档工具

• jenkins
  • 流水线部署应用
  • jenkins file 是 jenkins核心特性pipeline的脚本，有groovy语言实现。
  • 好处
    • 实现流水线上的代码评审、迭代
    • 对流水线进行审计跟踪
    • 作为流水线的单一可信数据员，能被项目多个成员查看和编辑
  • node为流水线分配了一个执行者和工作区，没有node流水线就无法工作
  • stage代表阶段，一个pipeline可以划分成若干个stage，每个stage代表一组操作。

• 实现一切即代码自动化
  • 通过Jenkins触发自动集成流水线，自动触发容器镜像生成，并通过Jenkins触发terraform，打破了云厂商之间的产品界限，实现容器应用部署至k8s中。
  • Terrafor+容器技术的结合大大降低了云产品使用难度。

编译构建

编译构建是指把软件的源代码编译成目标文件，并把配置文件和资源文件打包的过程。

• 编译构建
  • 输入是源代码、库文件、配置文件、资源文件
  • 输出是软件包：一个可以直接部署的软件，或者是一个可以被其他软件使用的lib
  • 编译器完成编译的过程，编译管理工具完成构建过程

• Java字节码类文件（.class）是编译器编译Java源文件(.java)产生的目标文件，是一种8位字节的二进制流。

• 编译构建的挑战
  • 环境搭建耗时费力，且容易因环境差异引入问题
  • 本地硬件配置不高，编译构建速度慢
  • 突发项目资源消耗大，结束后闲置
  • 多语言不能并行构建

• 编译构建是DevOps的基础
  • CI（持续集成）/CD（持续交付）流水线是DevOps的基础实践
  • 编译构建（build）是CI最基础环节
  • CI的其他环境，如代码检查，单元测试，都高度依赖编译构建

• 流行的编译构建工具
  • JavaScript
    • npm/gulp/grunt
  • java
    • gradle/maven/ant
  • c/c++
    • make/cmake
  • python
    • setuptool/pylnstaller
  • c#
    • MSBuild

• 编译构建实践
  • Maven构建
    • DevCloud：一键式生成Maven构建环境并完成配置
  • CMake构建
    • DevCloud：一键式生成Maven构建环境并完成配置
  • 容器镜像构建
    • DevCloud：基于在dockerFile中的指令，用户可以快速创建自定义的景象

• 云上构建优势 vs 传统本地编译构建
  • 传统本地编译构建：花费大量人力物力，维护成本高
  • 云上构建：开箱即用，专业的编译构建服务

制品和包管理

软件研发过程中的源码和软件制品包（二进制包）都是很关键的资产。

• 源码
  • 源码文件包含：文件名、版本、大小、创建时间
  • 源码文件特点：
    • 修改频繁
    • 一般较小
    • 增量修改
    • 修改增量存储
    • 频繁对比、分支、标签
    • 属性值较小
    • 异地分发简单

• 软件制品
  • 软件制品包通常是源码文件的集合或者编译后的产物，因此主要有二进制包和压缩包两种形式
  • 软件制品包的管理和复用在发布管理有着很关键的作用
  • 软件制品文件包括：文件名、版本、大小、创建时间、依赖、许可、风险
  • 软件制品相对于源码文件，通常较大（M-G级别都有），一般修改也比较少，通常采用覆盖方式。
  • 软件制品一般的生命周期环节也多，因此需要管理更多的元属性来标识不同阶段的状态，通常软件制品不放在源码库中一同管理。
  • 包文件特点
    • 修改较少
    • 通常体积较大
    • 覆盖修改
    • 修改全量存储
    • 没有对比分支标签
    • 属性值多
    • 异地分发较困难

• 软件制品的一般管理方法
  • 包文件通常不放在源码库中管理，而是使用专门的包文件仓库（repository）进行存储并配合包文件依赖管理工具（Maven/npm/lvy等）进行使用。
  • 包文件仓库可以分为本地仓库、私服仓库、中央仓库
    • 本地仓库是指开发者个人pc中包文件的存储
    • 私服仓库通常是企业为了提升包文件使用性能搭建的局域网内共用的包文件仓库，通常使用开源的Nexus，Artifactory等工具搭建
    • 中央仓库是指开源包文件的共享社区

• 软件制品库
  • 软件制品库指能够统一管理各种类型的二进制制品，同时无缝对接现有的标准化构建和发布工具的软件平台。（各种类型有：Binary/Docker/Config/DB/Document/Data/OS Ansible/Tools
  • 软件包及其属性的管理是发布过程管理的基础，是软件开发过程中的重要资产。
  • 软件制品库用于管理软件开发过程中产生的软件包，它是链接持续集成和持续交付的重要环节，软件包的发布评审、追溯和安全控制等操作通常在其中进行。
  • 软件制品库的作用
    • IDE对接
    • 快速获取依赖包
    • 识别开源包风险
    • 中央仓库对接
    • 开源包镜像、提升下载效率
    • 开源包策略管理、过滤有害包文件
    • 构建工具对接
    • 复用私有包，提升构建效率
    • 开源依赖包获取，提升构建效率
    • 部署工具对接
    • 利用有序调度不用环境部署，实现持续交付

• 典型的软件制品
  • Maven：项目管理工具，包含一个项目对象模型，一组标准集合，一个项目生命周期，一个依赖管理系统。
  • pypi：是一个现代的，通用的Python包管理工具。
  • npm：node package manager，是一个NodeJS包管理和分发工具

自动部署

• 部署经过三个阶段的发展
  • 单体结构部署的过程：简单，手工操作
  • 自动化部署：采用脚步，按照提前准备好的逻辑，执行部署
    • 自动化部署包含应用管理、环境管理、部署、编排、执行等功能
  • DevOps阶段：以应用为中心的微服务快速发布诉求，通过流水线触发部署任务，实现标准化，版本化的部署。

• 传统部署缺点
  • 容易出错，效率低
  • 依赖人员、耗费大量人力成本
  • 流程繁琐，操作复杂
  • 对于机器集群部署服务实现困难

发布管理

软件发布：将开发好的应用程序正式公布出来的过程。

• ITIL中定义的发布管理目标
  • 规划、协调软件和硬件的实施
  • 针对分发和安装对系统实施的变更而设计和实施有效的程序
  • 确保与变更相关的硬件和软件是可追溯和安全的（正确的、经过批准和测试的版本才能被安装）
  • 在新发布的规划和试运行期间与用户进行沟通并考虑他们的期望
  • 保障发布软件的原始拷贝被安全存放在最终软件库，配置信息存储在配置管理数据库

• 发布的目标
  • 发布的目标是提供软件、仓库、软件发布、发布包下载、发布包元数据管理等功能，通过安全可靠的软件仓库，实现软件包版本管理，提升发布质量和效率，实现产品的持续发布。

• 部署与发布的关系
  • 部署：在特定环境上安装指定版本的软件，部署可能与某个特性的发布有关，也可能无关。
  • 发布： 把一个/组特性提供给所有或部分客户。
  • 将部署和发布解耦，实现低风险发布。提升开发人员和运维人员快速且频繁部署的能力。
  • 代码和环境架构要满足：特性发布不需要变更应用的代码
  • 按需部署，让特性发布成为业务和市场决策，而不是技术决策。

• 发布模式
  • 基于环境的发布模式
  • 基于应用的发布模式
    • 基于应用的发布模式更安全
      • 轻松回滚
      • 缓解性能压力，优雅降级
      • 采用面向服务架构提高恢复能力，服务解耦
      • 将代码部署真正与特性发布解耦
      • 实现假设驱动开发和A/B测试
      • 实现Dark Launch黑启动（案例：Faceback聊天功能，Baidu关键字联想功能）
    • 缺点
      • 有代码侵入
      • 特性开关也是技术债务，需定期清理
      • 同时增加测试的复杂性，需要打开所有特性开发，还需要测试特性开发功能本身是否正常

• 单服务器组发布
  • 传统数据中心中，机器资源比较紧张，应用机器基本是预先静态分配好的，原来应用A运行这n台机器上，那么下次升级发布的应用A也运行这n台机器上，称为单服务器组发布方式。
  • 包含蛮力发布，金丝雀发布、滚动发布

• 双服务器组发布
  • 弹性按需分配，为一次发布两组服务器，一组运行现有V1老版本，一组运行待上线的V2版本，再通过LB切换流量方式完成发布。
  • 具体发布策略
    • 蓝绿发布、金丝雀发布、滚动发布功能开关，AB测试、影子测试

• 发布方式
  • 蛮力发布：完全靠手工，发布过程中会进行人为的中断，进行应用升级。
    • 优势：简单成本低
    • 劣势：服务中断，用户受影响，出问题回退也慢
    • 适用场景
      • 开发测试环境
      • 非关键应用，用户影响面小的
      • 初创公司，在业务闲时进行
  • 金丝雀发布：先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版进行线上测试，启动的这个新版本，就是金丝雀。
    • 双服务器的金丝雀：对蓝绿部署的一种简单优化，待金丝雀验证通过再发全量。
    • 双服务器的滚动发布：对蓝绿和金丝雀的进一步优化，按批次增量滚动发布，提供更平滑的用户体验。
    • 优势：用户影响小
    • 劣势：发布自动化程度不够，发布期间可引发服务中断
    • 适用场景
      • 对新版缺乏信心
      • 用户体验要求较高
      • 缺乏足够的自动化发布工具研发能力
  • 滚动发布：取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用，周而复始，直到集群中所有的实例都更新成新版本
    • 优势：用户影响小，体验平滑
    • 劣势：发布和回退比较慢，发布工具比较复杂，LB需要平滑的流量摘除和拉入能力
    • 适用场景
      • 用户体验不能中断的业务
      • 有一定的复杂发布工具研发能力
  • 蓝绿发布：保证系统不间断提供服务。包含两个集群，部署过程中，并不停止老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。v1版本成为蓝组，v2版本成为绿组。
    • 优势：升级切换和回退速度非常快
    • 劣势：
      • 切换是全量的，如果V2版本有问题，对用户体验有直接影响。
      • 需要两倍机器资源
    • 适用场景
      • 对用户体验有一定容忍度的场景
      • 机器资源有富余，可按需分配
      • 暂不具备研发复杂发布工具能力
    • 和金丝雀对比：金丝雀发布方式优势是有一个生产流量的金丝雀验证过程，可以减轻V2可能有问题的风险和影响面
  • 功能开关-toggle、featureflag、Switch:利用代码中的功能开关来控制发布逻辑。是支持现代devops理念，灵活定制和自助完成的发布方式。
    • 优势
      • 升级切换和回退速度非常快
      • 实施简单，成本相对低
      • 灵活定制和自助完成
    • 劣势
      • 切换是全量的，如果V2版本有问题，对用户体验有直接影响。
      • 对代码有侵入，需要定期清理老版本逻辑，维护成本高
    • 适用场景
      • 对用户体验有一定容忍度的场景
      • 已有配置中心或开关服务
      • 暂不具备研发复杂发布工具能力
  • A/B测试：用来测试应用功能表现的方法，例如可用性，受欢迎程序，可见性。
    • 优势
      • 用户影响小
      • 生产流量测试
      • 特定目标用户测试
    • 适用场景
      • 核心关键业务，比如涉及资金的
      • 具备一定A/B测试平台研发能力的
  • 影子测试：采用比较复杂的流量复制、回放和对比技术实现
    • 优势
      • 对生产用户完全无影响
      • 可以使用生产真实流量进行测试（复制对比）
    • 劣势：
      • 搭建复杂度高，技术门槛高
      • 外部依赖不能太多，否则测试部署成本很高
      • 没有回退间隔
    • 适用场景
      • 核心关键业务，比如涉及资金的
      • 具备一定影子测试平台研发能力的，包括流量复制、数据库导出复制和分发比对系统

自动化交付流水线

流水线实现devops模式下持续开发、持续测试、持续集成、持续部署，持续监控这些活动的编排并自动化执行，结果反馈，实现商业敏捷。

流水线是一个或多个自动化任务或人工任务组合起来的进行交付的工具。

把一个任务或者多个任务或特定的任务特定的顺序来运行起来达到交付。

流水线可以让部署成为一个日常的低风险工作，来解决开发和运维岗位之间的长期冲突。

流水线运作，让管理者看到流水线中的一切反馈或者数据帮助决策。

流水线中可以加入子流水线。

在流水线中我们可以将所有构建，部署逻辑一同写入流水线脚本。实现简单化管理。

• 为什么需要流水线
  • CI/CD无缝结合快速迭代，提升交付效率
  • 每个环节都会有反馈，实现快速的反馈循环
  • 每个环节都可设置质量门禁，实现质量的层层保障
  • 开发、测试、运维人员协作参与，提高员工参与感

• 流水线的功能实现
  • 工作流编排：按需制定自动化工流程
  • 自动触发流水线：通过配置
  • 流水线定期执行：人休息而版本级交付不休息
    • 计划功能提供流水线定时执行能力，支持多种模式
      • 每日定时模式：允许选择每日多个时间点执行
      • 每周定时执行： 可以选择具体日期及时间
  • 支持多种任务：构建、代码检查、部署、测试等多种自动化任务
  • 质量管控：支持多重门禁，未通过则终止执行
  • 其他：
    • 自定义权限
    • 准确报错，异常提示联动在线帮助平台
    • 开发对接Jenkins任务

下一章

HCIP-Cloud Service DevOps Engineer V2.0 华为认证（考点纪要二）