DevOps知识体系之高效DevOps的基础

DevOps知识体系，高效DevOps的基础，在现代软件开发中，DevOps已经成为了一个非常重要的概念。它不仅仅是一种开发方法，更是一种文化和理念。高效DevOps的基础有以下几个方面：自动化， 协作，可靠性，持续改进

• D E V O P S 知 识 体 系 | 高 效 D E V O P S 的 基 础
  • 高效DevOps的基础
    • 协作（合作）
      • 通过互相支持和多人协同来达成特定结果
    • 亲密性（亲和）
      • 共同的组织目标，同理心和不同团队之间的互相学习
    • 工具
      • 工具能带来加速效果和成本节省，但工具必须适合采用的工作方法
    • 规模化
      • 伴随组织的成长、成熟、甚至收缩，DevOps应该如何做适应性的变化
    • DevOps适用性及限制
      • 不适宜使用DevOps的情况
        • DevOps不是特别适合那些自己没有软件开发团队的组织
        • 组织使用它们自己的软件，而开发者并非自有员工
        • 单体的、紧耦合的IT架构
      • 制约采纳DevOps的因素
  • 规范敏捷（Disciplined Agile）
    • 规范敏捷意味着：
      • 速度稳定（Stabilized Velocity）
      • 适应变化（Adaptability for change）
      • 总是能发布优质的无错误代码（Always release high quality
    • 越来越频繁和快速发布的开发速度应取决于业务变更的频度
    • Ji-Koutei-Kanketsu（JKK）概念，认为100%的完成每个条目
    • 而“做完了”（Done）与“结束了”（Completion）的这些概念，对每个人来说都必须定义清楚
  • 持续交付（Continuous Delivery）
    • 持续交付指的是实现自动应用程序的构建、部署、测试和发布的流程
    • TPI NEXT®（测试流程优化）可以用于提高这个过程的成熟度
    • 一个关键的成功因素是为IT服务建立一个单一的部署管线。
    • 持续交付方法的收效是什么
      • 更快的交付速度：
        • 持续交付方法通过自动化测试和部署流程，可以将软件交付的速度提高几倍甚至更多。
      • 更高的质量保证：
        • 持续交付方法可以确保软件在交付之前经过了充分的测试和验证，从而保证软件的质量。
      • 更高的客户满意度：
        • 持续交付方法可以更快地满足客户的需求，从而提高客户的满意度。
      • 更快的反馈循环：
        • 持续交付方法可以快速地发现和修复软件中的问题，从而加快反馈循环。
      • 更高的团队协作效率：
        • 持续交付方法可以促进团队成员之间的协作和沟通，从而提高团队协作效率。
  • IT 服务管理（IT service management）
    • IT服务的连续性和高可用性是业务存亡的关键因素。
      • 可以通过引入降低风险措施和恢复方案来实现
    • 对于保持有效性而言，持续维护其可恢复能力是最基本的前提条件。
    • 服务连续性是服务保障的必要组成部分。
    • 创建轻量级的只包含所最少必要信息（Minimum Required Information，MRI）的，严格聚焦于业务持续性的轻量ITSM
    • 每个组织的MRI设置取决于他们的业务。
  • 以 TPS（精益管理 Lean）理念为基础
    • TPS的概念包括JIT和自动化
    • JIT意味着要建立一个流水线式的单件流（one-piece flow）的供应链。
    • 自动化意味着尽可能实现自动化并且当生产过程出现缺陷时能停止整个过程。
    • 需要通过敏捷的方法改变工作方式，包括开发和运维之间每周或每天的信息同步
  • DevOps模式与反模式
    • 持续交付中的反模式
      • 三个反模式
        • 手工部署软件
        • 开发完成之后才向类生产环境部署
        • 生产环境的手工配置管理
    • DevOps中的反模式
      • 三个反模式
        • 缺乏文化变革
          • DevOps不仅仅是一个工具或流程，它是一种文化和哲学。
          • 缺乏文化变革往往会使得DevOps实践不能取得预期的效果。
          • 团队需要意识到文化变革的必要性，并且采取行动实现它。
        • 重复手动部署
          • 手动部署很容易出错，也很浪费时间。应该采用自动化部署来节省时间和减少错误。
          • 重复手动部署还会导致不一致性和不可预测性。
        • 缺乏监控和反馈机制
          • 监控和反馈机制是DevOps实践的重要组成部分。
            • 它们可以帮助团队快速识别和解决问题，同时提高系统的可靠性和稳定性。
          • 缺乏监控和反馈机制会导致团队无法及时发现和解决问题，进而影响用户体验和业务运营。
      • 四个反模式
        • blame culture 问责/责怪文化
        • silos 孤岛（仓筒）思维
        • Linear Root cause analysis 线性根本原因分析
          • 对于根本原因分析，有一种隐含的假设，认为系统会一种线性的方式失败（或成功），
          • 但任何复杂的系统都不是这样。
        • Human error 人为错误
    • DevOps模式
      • 三个模式
        • 开发与运维协作
          • Dev 团队和 Ops 团队之间的顺畅协作，每个团队都专注于需要的地方，但也分享需要的地方。
          • 可能有许多独立的开发团队，每个团队都在独立或半独立的产品堆栈上工作。
          • 适用性：具有强大技术领导力的组织
        • 完全共享的运营职责
          • 产品开发人员集成了运营人员。Dev和Ops之间几乎没有分离，所有人都高度关注一个共同的目标。
          • netflix和Facebook 这样拥有单一基于Web的产品组织已经实现了这种模式
          • 适用性：具有单一的主要基于Web的产品或服务的组织
        • SRE团队（谷歌模型）
          • 明确地从开发"移交"到运行软件的团队，即站点可靠性工程 [SRE]团队。
          • 在这个模型中，开发团队需要向 SRE 团队提供测试证据[日志、指标等〕，证明他们的软件具有足够好的标准，可以得到 SRE 团队的支持
          • 适用性：仅适用于具有高度工程和组织成熟度高的组织
      • 三个反模式
        • 开发和运营孤岛
          • 这是 Dev 和 Ops之问经典的“把它扔到墙上”分裂。这意味着可以提早声明故事点
          • Done意味着“功能完整”，但不能在生产环境中工作，并且软件可操作性会受到影响， 因为开发人员没有足够的上下文来处理操作功能
          • 并且运维人员没有时间或不愿意参与开发阶段的工作
        • DevOps团队孤岛
          • DevOps 团队孤岛通常是由于经理或高管决定他们“需要一些DevOps 的东西”并开始一个"DevDps团队”〔可能充满了被称为"DevOps"的人]。
          • DevOps团队的成员很快形成了另一个孤岛，让 Dev 和 Ops 比以往任何时候都更加分离，因为他们保护自己的角落、技能和工具集免受Devs"和“Ops”人员的侵害
        • 开发者不需要操作
          • 这种拓扑结构源于开发人员和开发经理的天真和傲慢，尤其是在开始新项目或系统时。假设 Ops
          • 现在已成为过去【云计算已经不需要运维人员了？〕，开发人员大大低估了运维技能和活动的复杂性和重要性
  • 基础设施
    • 基础设施即代码
      • 是一种使用新的技术来构建和管理动态基础设施的方式。
      • 它把基础设施、工具和服务以及对基础设施的管理本身作为一个软件系统，
      • 采纳软件工程实践以结构化的安全的方式来管理对系统的变更。
    • 虚拟化
      • 优点
        • 快速供应环境
          • 减少部署软件的时间
            • 更容易提供"服务"基础设施
        • 标准化硬件
      • 虚拟机
      • 基本概念
        • 快照
          • 技术分类
            • 物理拷贝
              • 管理简单，不需要监控目标数据的状态
            • 逻辑拷贝
              • 节省空间，若目标数据发生损坏则可能找出快照丢失
        • 模版
        • 镜像
          • 镜像可以迅速恢复出所有的数据，保证业务的连续性
        • 容量镜像：容器都是基于镜像产生的，没有镜像就没有容器。
        • DocketFile：可以通过文本格式的配置文件描述镜像
          • 将代码包下载到构建服务器
          • 通过DocketFile的ADD将代码包加载到容量中
          • Docket Build完成新的镜象
    • 云计算
      • 优点
        • 快速访问，轻松扩展
        • 部署到完全标准化的堆栈
          • 无需担心配置或维护测试，暂存或生产环境或虚拟机映像