问题描述

在践行 DevOps 理念时，需要引入大量的工具（诸如 Jenkins GitLab Harboar Nexus SonarQube Rancher Kubernetes 等等）。

针对日常管理，我们面临的最大问题是这些工具集的升级问题。鉴于 DevOps 盛行，这些工具的发布周期短，新版本发布速度快。例如，Gitlab 每月更新次版本，Jenkins 每周更新次版本；

作为开源软件下游的用户，我们要决定是否进行升级、升级带来的问题、升级频率 等等问题。

该笔记将记录：针对升级操作，我们需要考虑哪些问题、我们的所采用的升级策略、相关的升级问题的解决办法。

解决方案

版本选择策略

我们当前采用「版本间隔」的升级策略，具体细节如下：
1）假如官方发布 14.5 版本，虽然经过官方测试，但我们不会升级到最新版本；
2）我们会查看 14.4 版本所修复的问题，来发现 14.3 版本中潜在的问题；
3）如果 14.3 版本中潜在的问题是我们所能接受的，我们将升级到 14.3 版本；

服务升级周期

当前服务升级周期，跟随官方版本发布周期，最快每 6 周进行一次服务升级，最晚 3 月进行服务升级；
若未跟随官方版本发布周期进行升级，则下次升级时将会进行连续升级；

服务升级规范

该升级规范流程借鉴于《华为网路升级规范》，并结合当前的实际应用场景进行调整。

阶段一、前期准备

调研升级环境

1）在开始升级前，需要与 技术负责人、研发工程师 等等多方进行沟通，以进行相关使用及当前配置信息的收集；
2）针对收到收集到的信息，分析服务当前情况以及升级前后服务情况进行对比分析，判断升级前后服务是否正常；
3）静态信息采集分析：当前服务拓扑信息；当前服务版本信息；当前软件许可信息；当前服务配置信息；
4）动态信息采集分析：服务资源使用情况；服务带宽使用信息；服务运行状态；服务网络时延、抖动、丢包率；
5）业务模型采集分析：在调研阶段中，还需要对服务的业务流量走向、业务流量大小进行观察，包括流量走向的变化和链路流量大小，可用于升级前后进行对比；

分析升级内容

当调研升级完成后，需要分析此次升级内容：
1）针对研发需求进行分析、梳理，分析用户服务升级的需求，诸如 问题修复、引入新特性 等等；
2）输出《服务升级变更内容》，在该文档中，明确升级需求、选择目标版本、明确变更内容；

评估升级风险

1）根据调研结果、需求分析结果、升级方案的框架，进行升级风险分析与评估；
2）针对可能出现的风险项目提前制定应对措施，并将对应的风险项对应措施责任人确认；
2）风险评估需要涉及的技术人员参与讨论，将各个风险的责任人明确到具体的技术人员；

输出升级方案

1）根据调研结果、项目分析结果、技术人员风险评估编写相应的升级方案；
2）在升级方案中，需要将升级前 准备阶段、实施阶段、收尾阶段 的详细步骤及过程进行明确；

前期准备：项目背景；环境概述；升级目标；风险评估；
实施方案：升级准备；升级实施；回退方案；应用预案；
升级收尾：服务检查；业务测试；资料移接；项目验收；

关于 实施方案 部分：
1）为进行高效、规范地升级，升级中的每个实施步骤都要提前规划，按照升级操作顺序到最小操作动作、细化到具体的命令行、每个操作步骤执行所需的时间；
2）在升级实施方案中，需要制定相应的升级操作确认记录表，针对每一模块操作的时间点，完成后的结果确认和异常信息记录；

关于 回退方案 部分：
1）当升级失败时（诸如 当升级后业务测试失败、升级时间结束未完成升级 等等）需要将服务退回到升级前初始状态，此时需要按照回退方案进行操作，将服务恢复；
2）在制定升级方案时，需要包含详细的回退方案，同升级操作一样，需要精确到每一步操作，这样当升级失败时可以有条不紊地进行回退；

验证升级方案

1）在执行生产升级前，都要求在实验环境中进行提前验证，将之前的风险点进行测试，并对整个方案的可行性确认，这种使用实验环境验证的过程被称为实验局测试；
2）除了实验局方案验证之外，还需要和用户、升级实施人进行技术评审会，对升级方案中的技术进行论证，同时了解双方的实际需求和存在困难，面对面解决问题；

准备升级内容

升级准备是升级实施前的重要步骤，同时充分地准备也是顺利完成升级的基础，只有充分考虑周全，才会确保万无一失；

升级准备分为：环境准备（硬件、软件）、人员准备（研发，运维）、流程准备（执行时间划分）；

环境准备：预先准备需要升级内容。诸如 硬件、软件、工具 等等。硬件；
人员准备：时间安排；对照表；通告升级时间；
流程准备：升级文档的下发；执行时间的划分；

阶段二、中期实施

检查升级环境

为方便升级回退以及升级之后对比业务是否正常，在正式开始升级之前需要对现网配置、现网数据再进行一次快照，具体包括以下内容：
1）数据备份：现有服务配置进行备份，升级数据备份；
2）数据采集：现有服务动态数据采集（资源使用情况，服务状态，服务版本，业务流量走向，业务流量大小）；
3）业务检查：当升级服务前，对业务进行测试，确保升级涉及的业务在升级前属于正常状态；

执行升级操作

1）现场升级人员按照提前准备好的升级步骤一步步严格执行，无特殊原因不能临时更改实施步骤；
2）针对每个升级步骤，要求执行记录 实际操作升级过程的时间点、执行动作、执行结果；

回退升级失败

1）如果在指定的时间前未完成升级，需按照提前准备的回退方案一步步进行回退，将服务恢复；
2）具体回退范围可根据实际情况，与用户协商部分回退或全部倒回退；

测试升级结果

当升级实施完成后，需要测试服务是否升级成功，需要从以下几个方面进行测试：
1）服务连通状态测试：通过 ping、tracert、第三方软件，来 测试网络连通性、延迟、抖动 参数，确保服务可达性；
1）服务运行状态测试：针对服务运行的动态数据在进行一次采集，并将其与升级前进行对比，确保服务运行状态服务预期；
3）业务应用状态测试：通知应用业务测试人员，以测试服务所承载的客户应用，检查业务服务是否正常；

阶段三、后期收尾

通告用户升级结束

1）针对此次的变化进行简短描述，以使相关用户知晓此次升级的变化内容；

观察服务运行状态

1）服务需进入特殊的观察期，在此期间运维人员通常需要留意服务运行状态，防止出现意外故障；

验收升级结果

升级验收，升级顺利完成并在观察无异常之后，还需要对进行使用维护培训以及资料归档：
1）服务使用培训：针对升级项目，如果涉及新功能、新特性等，需要对研发人员进行培训赋能的；
2）升级资料归档：为便于后期维护，当升级完成后，需要将升级涉及的文档及资料进行归档；

TL; DR

进行升级的优点与缺点

优点

1）引入新的功能特性，更好的协助研发工作
针对下游的使用场景，上游软件将不断迭代出新特性，以解决实际研发场景中遇到的问题；
同时及时引入新特性将更好的支持研发工作，而不会因为需要某些特性时才进行紧急升级；

2）修复已知的问题及潜在的安全漏洞，增加稳定性；
每次的版本发布，软件的相关问题及安全漏洞也会被修复，使得服务将处于安全可靠这状态；

缺点

1）应用程序需要进行兼容性调整；
例如 Kubernetes Cluster 的升级伴随着 apiVersion 的变换，为了能够在新版本的集群中运行，应用程序需要进行修改；

2）新特性新版本将带来额外的学习成本；
通常主版本号的变更，意味着较大的变化，这会带来使用方式的变化，学习与习惯这些新的使用方式需要进行额外的学习；

忽略升级的优点与缺点

优点

1）系统稳定运行，不需要处理升级带来的变化
与前面过程相对，如果不进行升级，就不需要考虑升级带来的变动问题；

2）容易上手使用，并形成相关的知识积累；
鉴于软件版本固定，则相关使用方法的知识积累更多，更容易协助新人快速入门；

缺点

1）系统之间存在依赖关系，导致相关软件无法匹配问题
多个系统之间存在依赖关系，如果某个服务未进行升级，则将导致其他服务仅能在有限的版本内进行选择；

2）服务将出于无法升级状态
如果长时间未进行升级，相关的文档及官方资源可能缺失，长久之后将导致服务无法升级。此后只能进行重新部署，并带来大量的数据迁移工作；

3）已知问题及安全漏洞无法得到及时修复
如果未进行升级，则服务内的已知问题及漏洞将无法得到修复，存在使用问题及安全隐患；