devops/devopstest_v2.md

# DevOps/CD/CI题目

## 一、选择题（20）

### 1. 验收测试的最佳选择?
    a. Happy Path
    b. 回归测试
    c. alternate Path
    d. Sad Path

a. happy path 相当于做主流程

### 2. 云计算的哪个特性能实现自动部署?
    a.  标准栈
    b.  规模化
    c.  虚拟化
    d.  通用性

a. 标准栈使得自动部署成为可能

### 3. 软件交付过程中，让整个过程自动化，并能够及时发现问题和修复问题，在此过程中,以下实践不是反模式选项是：
    a，要求一份详尽文档，该文档描述了每个步骤中容易出错的地方
    b，开发完成后才向类生产环境部署
    c，提前频繁的做让你感到痛苦的事
    d，手工进行生产环境的配置

c. 痛苦的事情频繁做

### 4. 良好的配置管理过程，是实现开发和部署过程可控和可重复的基础，以下哪个内容不是良好配置管理策略：
    a. 能够再现所需的任何环境。
    b. 为了达到系统运行稳定的目标，固化配置，任何修改都做登记。
    c. 能够追踪某个具体环境的某次修改，并能够追溯修改源，以及什么时间谁做了修改。
    d. 增量式修改，并可将修改部署到任意一种环境中。

b. 不是敏捷策略。影响迭代。

### 5. 每个应用程序都依赖于软件、硬件、基础设施等才可以正常工作，这些内容称作应用程序的环境，环境管理与配置管理同样重要。以下哪种不是良好的环境管理实践：
    a. 环境管理的关键是通过一个自动化过程来创建环境。
    b. 因为环境管理的重要性，一旦系统出问题，派遣资深专家花费不确定的时间来找到问题，并修复它。
    c. 修复某个环境可能需要大量时间，因此，最好在可预见的时间里重建环境，并将其恢复到某个已知的正常状态。
    d. 创建一个类生产环境，配置问题可在早期测试中发现。

b. 自动化、简单化、可量产、可重现，不是依赖资深专家

### 6.  公司打算构建一条部署流水线，公司领导希望实现频繁发布。 有团队成员认为：这条部署流水线最重要的是自动化。团队首先要让它自动化起来。 这种说法对吗？
    a.  是的，这是正确的。部署流水线自动化是提升效率的最重要因素。
    b.  是的，这是正确的。关注自动化部署流水线的创建，克服之后可能遇到的潜在问题。
    c.  不，这是错误的。完成单件流及一个可靠的部署流程是优先级最高的任务。该流程的自动化可以暂缓实施。
    d.  不，这是错误的。首先应当自动化的是测试流程而非部署流水线。

c, 无论何时，所有部署流水线首先应当是单件流程的部署流水线，无需自动化就可高效运行。一旦该流水线稳定确立，就有机会选择可行的流程实施自动化。但是，构建稳定的部署流水线永远比自动化更重要。

### 7. 有很多方法可以使组织趋向成熟，下列哪种方法不会使你的devOps组织更趋成熟？
    a. 明确定义目标定和里程碑，帮助团队成员判断其日常活动是否有价值。
    b. 明确定义流程，支持并促使团队成员逐日改进流程。
    c. 对会议的所有内容进行记录，使你的团队成员可以很方便的了解到每次沟通的内容信息。
    d. 监控并记录每天的活动，以找出小范围内每天取得的进步并予以赞扬。

c, 这无助于devOps组织的成熟。是否要对会议进行全程记录并再次审查，并没有严格的要求。有必要记录达成共识的内容，而不是记录整 场会议。

### 8.  你认为自己的开发团队是一支真正的团队。 你觉得有什么确切的特征表明这是一支团队而不只是一个小组呢？
    a.	该团队遵守在团队会议中共同制定的规则。
    b.	团队召开自己主持的高效会议。
    c.	团队以稳定的工作节奏，朝着共同的目标推进。
    d.	该团队通过质询负责某项工作的团队成员的方式来解决问题。

d 一支真正的团队能够维持稳定的工作节奏，并能够始终向着共同的目标努力。

### 9.  为采用整体方法处理所有基础设施，应当遵循哪两条原则?
    a.
      1	你的基础设施应具备的状态需要通过变更控制配置来确定。
      2	你应当通过监控与事件管理，及时了解基础设施的准确状态。
    b.
      1	需要通过变更控制配置来确定你的基础设施应具备的状态。
      2	你应当通过仪器仪表及事件管理，始终了解基础设施的确切状态。
    c.
      1	你的基础设施应具备的状态需要通过版本控制配置来确定。
      2	你应当通过当前事件与事件管理，始终了解基础设施的确切状态。
    d.
      1	你的基础设施应具备的状态需要通过版本控制配置来确定。
      2	你应当通过仪表盘与监控始终了解基础设施的确切状态。

d, 为采用整体方法处理所有基础设施，应当遵循这两条核心原则。

### 10.  在敏捷和devops中吸收了很多精益核心概念。实施devOps时，将精益的相关概念应用在devOps过程中，有助于成功实施devops。 在此过程中，精益管理的哪些原则或实践方法最有效?
    a. Kaizen(专有词，意为小的、不花钱的持续改善)
    b. 5S - 整理（SHIRI）、整顿（SEITON）、清扫（SEISO）、清洁（SEIKETSU）、素养（SHITSUKE）
    c. Obeya系统(可视化管理)
    d. 单件流与质量检查

d, 创建一个可行的、单件部署流水线将有助于成功实施devOps。devOps中最重要的工作在于构建从开发部门到运维部门的上游流程，尤其是针对单一部署流水线。质量检查（JKK）是能够达成这一目标的最有效的工作行为。

### 11.  持续集成不会单独的帮你修复构建过程，在中后期开展持续集成，意味着在构建过程需要耗费大量工作。 为了使持续集成更高效，早期阶段，一般不会涉及的工作是？
    a. 频繁提交代码到版本控制库
    b. 创建分支，并尽早提交代码到分支
    c. 创建自动化测试套件
    d. 保持较短的构建和测试过程

b. 应提交到主干，分支容易破坏即时集成
持续交付 P46

### 12.  关于版本控制，以下说法不正确的是？
    a. 源代码必须纳入版本控制。
    b. 配置信息必须纳入版本控制。
    c. 为了加快发布周期和提高软件质量，将编译器或其他相关工具的二进制镜像纳入版本控制。
    d. 为了加速打包，将源代码编译后的二进制文件纳入版本控制。

d. 不推荐
  1. 比较大，
  2. 每次重新构建都会重新生成二进制文件，无必要

### 13. 一个开发团队对devOps感兴趣。他们主要感兴趣的对象是持续集成（cI）。他们目前开发并维护着三种主要解决方案及四种次要解决方案。他们采用Scrum实践方法。每次冲刺都需要四周时间，平均每十天到十五天对测试环境都有一次提交发布，平均每个月对生产环境有一次发布。他们想为管理层制定一个定性的商业论证，来支持他们为创建持续集成实践模式而付出的投资与努力。 持续集成有哪些显性收益对该商业论证最为有利？
    a. 每天对测试环境进行一次部署能极大的提高商业效益并且大大缩减开发成本。
    b. 这有助于提升团队精神。由于公司已经在使用Scrum，持续集成将为公司业务带来显著的益处。
    c. 它通过更好的集成测试提高了业务稳定性，同时维持发布速度以防止产生额外成本。
    d. 在生产环境中，每天进行一次信息发布能够提升业务收益，并大大减少开发成本。

d, 更快速的向生产环境发布是持续集成的一大主要益处，此外还包括更快速地发现故障以减少开发成本和故障修复成本。

### 14.  关于使用脚本去构建和部署流程自动化，以下说法正确的是？
    a. 每种环境采用一个脚本，并将其作为版本控制系统的一部分加以维护。
    b. 不同环境使用不同的特定脚本，以解决环境之间的差异问题。
    c. 不同环境采用同样的脚本，对特定的配置采用手动参数。
    d. 采用同一脚本在不同环境中进行部署，并单独管理配置信息。

d, 脚本应当保持一致，才能保证构建和交付流程得到有效测试。环境之间（如URI和IP等）的差异应当作为配置管理流程的一部分予以处理。

### 15. 当有运维侧变更时，运维部门告知开发部门的最佳时间是何时？
    a. 无需告知开发团队。运维侧的变更仅运维团队知晓即可。
    b. 立刻执行。应当尽快通知开发部门。
    c. 次日早晨的Scrum会议中。
    d. 当运维团队已经完成验收测试时。

b, 应当立即告知开发部门，让他们能够预见潜在的风险和问题。

### 16. 考虑对基本部署流水线进行具体解析。 哪个阶段表明该系统在功能性与非功能性层面均发挥作用？
    a. 自动化验收测试
    b. 构建与单元测试
    c. 手动验收测试
    d. 版本控制

a. 自动化验收测试阶段表明，系统在功能性与非功能性层面上工作正常，在行为上它能满足用户的需求和客户的规格要求。

### 17. 开发团队当前在测试中遇到诸多挑战。目前他们使用人工验收测试流程。 开发者认为他们所创建的单元测试是十分周密的，可以避免回退。 在每次发布时，开发团队都需要花费100万在人工验收测试环节。 领导层要求开发团队实施自动化验收测试，以降低测试的总成本并尽可能减少引入生产环境中的代码缺陷数量和回退次数。 在依照自动化需求确定应用程序的验收标准时，应当遵循什么原则？
    a. agile（敏捷）原则
    b. aTaM（架构权衡分析法）原则
    c. dIVEST原则
    d. INVEST原则

d, 验收测试源自验收标准，因此你的应用程序的验收标准的制定应当考虑自动化因素，遵循INVEST原则；
  - Independent(独立性)
  - Negotiable(可协商)
  - Valuable(有价值)
  - Estimatable(可估计)
  - Small(小而少)
  - Testable(可测试)

### 18. 自动化测试是高效软件发布和实现持续交付的基础，以下那一类测试不宜全面自动化。
    a. 容量测试
    b. GUI测试
    c. 单元测试
    d. 探索性测试

d. 探索性测试一般需结合人工测试

### 19.  公司正在使用devOps。该公司实施了持续部署，并具备高度自动化验收测试和每日向生产部交付新软件的稳定部署流水线。公司有一个巨大的数据库及众多用户。该公司具备全面可靠的容量测试策略。由于该公司环境广大而复杂，随着每个新版本的发布，生产部就会出现一些小故障。 什么策略能够最有效地帮助该公司预防这些故障？
    a. 采用金丝雀发布
    b. 自动化容量测试
    c. 降低交付率
    d. 采用蓝绿部署

a.
  - 金丝雀发布:
      包括向生产服务商中的一小部分推出新版本的应用程序，以快速收集反馈。这能够快速发现新版本中出现的所有问题，而不会对大多数用户产生影响，因为工作量是逐渐增长的；同时这一做法还能确定响应时间及其他工作表现衡量标准，减少新版本发布的风险，并帮助尽快发现与修复漏洞。
  - 蓝绿部署
      需要大量资源，因而在该情境中代价高昂。此外，若需要回退，在大型数据库中采用这一策略可能导致故障或只读情况发生。另外，这也无助于容量测试效率的提高。

### 20.  公司正在尝试转变，并开始使用devOps的方式开展工作。你的团队也在经历这一转变。 你正在参与讨论代码提交阶段的最佳实践。 某同事说：“当某一构建遭到破坏且无人担责时，我们应当找出造成破坏的人并要求他们展开工作，以保证他们能修复这一构建。” 这样做合适吗？
    a. 是的。只有破坏构建的人才能够修复它，因此你应当找到负责人，即使这样可能会让人感觉不舒服。
    b. 是的。你应当始终为破坏构建负责。如果你不负责，你的同事将可能强制执行这项规定。
    c. 不，devOps环境中不存在追责。若同事不承担责任，不要强迫他们。
    d. 不，你应当首先修复构建。然后抽出时间，确定相关负责人并进行处罚。

c, Devops文化不提倡强迫任何人做任何事。犯错是可以接受的。团队成员共同协作以克服各种错误或挑战。


## 二、简答题（5）
### 1. 简述devops能带来哪些效果？
    - 快速发布
    - 降低成本
    - 持续反馈，提高软件质量
    - 更关注业务产出，给客户带来价值

### 2. 每个系统都会遇到这种情况：发现一个严重缺陷，必须尽快修复。简述紧急变更过程?
    需牢记：任何情况下，都不能破坏流程，紧急修复版本同样走构建、部署、测试、发布流程，与其他代码变更没有区别。
      - 申请变更(Request for change,RFc)
      - 分析影响
      - 通知利益相关方

### 3. devops文化转变包含哪些?
    - 高效
    - 亲和
    - 协作
    - 高度信任
    - 同理心
    - 非谴责
    - 单件流

### 4. 持续集成不光是一些工具组合，更是一种实践，它的有效性也依赖于团队纪律。简述cI(持续集成)的好处，及为了实现持续集成目标，有哪些良好的实践?
    好处：
      - 软件在任何时候可工作
      - 更少的bug
      - 更低的成本
      - 更快发现bug
    良好实践或纪律：
      - 构建失败后不要向版本库提交新代码, 确保软件一直可工作
      - 本地构建并运行提交测试，测试通过才继续工作
      - 不要将失败的构建注释掉
      - 为自己导致的问题负责
      - 所有人为质量负责
      ...

### 5.  在自动化运维中，要实现基础设施和应用程序的监控策略，通常要考虑哪些方面内容或从哪些方面着手？
      - 采集数据，软硬件运行情况，健康度，统计信息等, 通过SNMP/TR069等
      - 记录日志，解析、分析、统计日志文件，并关注日志等级
      - 建立信息展示板(dashborad),可视化
      - 建立自动通知/告警机制

## 三、论述题（2）
### 1. 在软件发布过程共，我们常常看到测试、运维、开发团队协作不畅导致的流程受阻，部署流水线从端到端来贯穿流程，实现自动化构建、部署、测试和发布。公司推进敏捷/devops，请结合实践，论述如何构建一套部署流水线，以及这套部署流水线如何在实践中更好的实现持续交付。

#### 内容要点： 结合实践来阐述
    1. 部署流水线流程
          - 提交,版本控制库
          - 自动构建和单元测试（可能涉及自动配置管理）
          - 部署二进制包
          - 自动化验收测试(一般做冒烟测试，也可能包括自动化容量、安全等非功能性测试)

          - 运维一键部署到生产环境（容器化,生产环境配置，部署二进制包）
       流程的起点是开发人员向版本控制库提交代码，流水线对提交作出响应，触发流水线的一个实例，编译代码，运行单元测试，执行代码分析，创建软件的二进制包；如果所有单元测试通过，代码符合标准，完成软件打包；之后触发自动化验收。

    2. 构建流水线过程
          - 对价值流建模并创建简单的可工作框架（比如流行的jenkins）
          - 将构建和部署流程自动化
          - 将单元测试和代码分析自动化
          - 将功能（验收）测试自动化
          - 将发布自动化

    3. 一些良好实践
          - 部署流水线的成功的关键之一是各个环节能够尽快得到反馈
          - 项目较大情况下，全量或回归测试可能耗费大量的时间，可能打断持续集成效率，在流水线中往往只做冒烟测试，通常要在一两个小时内完成该过程。
          - 确保生产中部署的包与流水线生成的二进制包是同一个，或者对包做HaSH验证。重新创建二进制包将带来不一致风险。
          - 如果某个环节失败，应停止整个流水线。整个团队对失败负责。
          - 象其他交付的应用一样，对部署流水线进行增量式实现，不断改善和重构。
          - 让每个环节可视化，让大家能够清晰的看到哪个环节有什么问题。


参考<持续交付>第五章相关内容

### 2.  一个电信级应用部署在云上，随着业务不断演进，系统用户和数据量不断增加，云资源的稳定性和系统的复杂性带来的系统服务中断的风险越来越大，系统中断的影响也随之增加。请结合实践，论述从哪些方面来提升系统可用性或提升系统容灾能力。 从以下要点结合实践展开论述：

#### 从以下角度结合应用进行分析：
    架构手段：
        - 冷、热备份，心跳检测保活
              如通过LVS、haproxy、keepalive等方式
        - 集群 & 负载均衡 & 分布式
              负载均衡架构是多个服务做一堆同类的事情，每件事情相互独立；
              分布式的架构则是将一件复杂的事情分解出多个部份，由多个服务去做，再通过架构实现多个分解事情处理结果的合并。
        - 多中心，异地异机房，涉及负载分担和数据同步等问题的考虑
        - 纵向扩容，如加服务器资源，换性能更强的服务器提升服务能力
        - 横向扩容，对业务、数据库、区域等进行划分
        - 业务服务的拆分
        - 数据库的读写分离
        ...

    运维手段：
        - 虚拟化、容器化
        - 监控手段，发现机制和加速处理机制等
        - 演练和一些馄饨学工具故障模拟
        - 自动化运维，监控预警等手段
        - 应急预案
        ...