软件配置管理

软件配置管理

软件配置管理的目标

• 通过软件配置管理获得两种基本能力，它们分别是可追溯性和可重现性，从而提升软件整个生命周期管理的安全性，并提高团队协作效率
• 可追溯性是指任何人在获得授权的前提下，能够找到该软件的任何变更历史，即对任何一次软件变更，都可以准确的回答5W1H
• 可重现性是指任何人在获得授权的前提下，能够重现从过去到现在之间任意时间点的软件状态

软件配置管理的范围

• 软件配置管理的范围包括需求、源代码、软件（部署）包和环境，它们是软件生命周期中各阶段的制品

软件包配置管理原则

• 一切皆有版本
• 共享唯一受信源。需求仓库、代码仓库、软件包仓库
• 标准化与自动化

软件包版本管理

包管理的反模式

应用程序所依赖的软件包将它们与程序源代码放在一起，提交到版本控制库中，在需要的时候，与源代码一起检出，就可以工作了

常见问题

• 大量的软件包以二进制的形式存在于版本控制仓库中，而大多数版本控制系统对二进制文件的管理是非常低效的，而且有I/O瓶颈，且无法有针对性的进行传输优化
• 大量重复的软件包版在版本仓库中
• 公共软件包的协调工作增加

集中式包管理服务

建立统一软件包管理系统，将所有软件包都放入其中，并且对企业内部团队提供稳定的查询、获取和申请等服务

优点

• 统一存储，空间占用少
• 一致性。全公司使用统一的副本，是所有软件包的唯一来源
• 安全省心。可以对软件包进行统一的安全扫描、法律审计管理。当某软件包出现安全漏洞时或风险时，可以及时掌握该软件包的使用范围，定位风险点，制定统一的风险应对策略
• 下载速度快。在公司内网，软件包的获取速度较快

软件包的元信息

• 为每一个软件包设置元信息，它包含：其自身唯一标识信息；来源信息（例如由谁提供、源代码在哪里、现在的状态如何等）；依赖关系信息

包依赖管理

• 显示声明依赖
• 自动管理依赖
• 减少复杂依赖

包依赖的3大类问题

• 依赖过多或者链条过长

• 依赖冲突

  想办法令被依赖库的两个不同版本可以在同一环境下运行
  
  打平依赖
  

• 循环依赖

  分裂依赖
  
  每次升级时使用阶梯型升级法
  

环境基础设施管理

基础操作系统层与标准应用层是应用软件运行的基础上下文，也被称为环境基础设施，变更频率低是它的特点

环境准备的4种状态

“蛮荒”。以“人脑+手工”为代表

• 开发人员自己就可以搞定所有与软件部署相关的问题
• 所有与环境准备相关的知识都存储在于个别骨干开发人员的头脑中。他们是团队的核心，环境部署的“英雄”

“规范化”。以“文档+私有脚本”为代表

• 要求提供正式的上线部署文档。通常会总结出一个环境准备指导说明书。每次软件部署上线时，开发人员提交一个上线操作说明，详细写明软件上线步骤，交由运维人员来执行
• 要有规范的上线部署流程。在这个阶段，运维工作特点是通过人工流程建立协作秩序，并详细记录每次的操作记录
• 利用私有化脚本，提升个人效率
• 在这个阶段面临的挑战有：流程通过“人”来维护，经常有遗漏、文档通过“邮件”跟踪，查找不方便、审计工作量大。由于手工工作量大，常有人绕过流程、自动化脚本不规范，而且经常出错，导致部署过程中断

“标准化”。以“办公自动化”为代表

办公自动化的好处有

• 流程在平台固化。软件开发团队与运维团队之间的互动协作统一在同一个平台上，协作流程受控
• 部分内容的标准统一。例如简单的部署操作可以通过模板配置方式由平台自动化执行
• 可以部分复用。通过各种配置方式，减少工作量
• 审计工作比较容易。所有信息保存在平台上

办公自动化存在的挑战

• 由于系统部署还有很多比较复杂的操作，仍旧需要人工参与
• 两次上线部署差异对比仍旧相对困难

“自动化”。以“受控式自动化脚本”为代表

简述

• 这一阶段的典型特点是由平台管理自动化脚本，即所有自动化脚本都是公司资产，被平台记录和保存
• 这一阶段的自动化运维脚本有两种形态，一种是以操作过程式为主，另一种是以状态声明式为主
• 状态声明式脚本是指在脚本中指定环境的目标状态，由定义该状态声明规范的平台执行这个脚本。在同一个环境下，无论该脚本被执行多少次，执行结果都是一致的

过程式脚本

操作过程式脚本是通过模拟手工执行步骤的自动化命令执行。在同一个环境下，自动化脚本可以被多次执行，每次执行后的环境状态可能不一致，或者出错

• 该方式的益处

  符合原有思考习惯，只要将原来的手工操作步骤用脚本语言实现即可
  
  灵活。可以通过手工操作办到的，基本上这种过程式脚本都能办到，不受任何约束
  

• 该方式的不足之处

  需要花费较多的管理精力。必须知道的两件事包括：一是在执行脚本之前，系统的原有状态是什么样子的；
  二是执行脚本到底做了哪些具体操作，而且在同一环境下多次执行同一自动化脚本，
  其结果可能使环境处于一种“未知”状态
  

状态声明式脚本

• 该方式的益处

  可以明确地知道，无论在何种情况下，无论谁执行了这个脚本，系统最后都会达到同一种状态
  
  如果将其放在代码仓库，通过版本diff功能，就可以直接对比两次环境的差异点
  

• 该方式的不足之处

  学习成本高。事实上，这种状态声明式语法就是一种DSL，用于描述环境部署领域的专有操作和状态
  
  当这种声明式文本数量较多时，文件管理方面也同样存在困难
  

• 该模式的运行模式。“拉模式”（Pull）、“推模式”（Push）

软件配置项的管理

二进制与配置项的分离

配置信息的版本管理

• 环境配置项。该类配置项的对应值与其所对应的环境相关，且常与环境本身的定义相互绑定
• 应用配置项。该类配置项与信息安全控制及应用程序自身有关
• 业务配置项。该类配置项与应用程序所执行的业务行为相关，每一配置项设置有默认值。例如特性开关

配置项的存储组织方式

配置漂移与治理

它是指随着时间发展，由于各种未预期原因而做出的配置修改引起计算机或软件服务偏离了我们所希望的配置状态，被称为配置漂移

这种漂移通常是由于人的临时修改引起的，但结束后忘记恢复

典型场景

• 配置修改无记录

解决方式

• 好的软件配置管理流程可以解决配置漂移问题
• 例如：将静态配置放入版本控制库，并禁止直接登录到主机环境修改配置信息，只能提交修改到代码仓库，并通过自动化方式进行生产环境中配置的修改，那么就可以避免由于人为操作遗漏造成的配置漂移

不可变基础设施与云应用

必须满足的3个条件

• 系统运行环境（包括所有层次）的准备均以自动化方式完成
• 一旦完成准备工作，该基础设施的任何一个层次均不得更改
• 如果因为某种原因需要对该系统进行更改，则必须使用另一个不可变系统环境来替代它，而不是对原系统环境进行变更

实现不可变基础设施

• 物理机镜像技术和虚拟机镜像技术
• Docker容器技术
• 云原生应用

优势

• 简化运维工作
• 部署流程自文档
• 持续部署不停机，故障更少
• 减少错误和威胁
• 多类环境基础设施的一致性
• 杜绝了“配置漂移”
• 被测试的即是被使用的

挑战

• 为不可变基础设施建立一整套自动化运维体系，在初期就需要较高的成本
• 生产环境中突发问题的修复时间可能会稍长
• 对大规模软件服务来说，将大尺寸镜像分发到多台宿主机上需要消耗大量的网络资源，时间消耗也会不少，因此必须有相应的平台工具支持
• 有状态存储的软件服务并不容易被直接替换