1. 私有化软件交付流程

在工程化的基础上再结合合理的流程才能够构建完善的私有化交付体系。因为产品的本身差异，流程会有一定的差异，通过在过往的经验中归纳总结出一台适合自己的流程才是好的流程。

软件系统的私有化交付本质类似QQ/微信的安装，目的都是将软件安装到用户的设备上以提供期望的能力，但是系统性的软件要考虑的因素会更多也会更复杂；流程具有阶段性，在不同的阶段应该有不同的结果产出，可以使状态也可以是文档材料等等。

一套私有化项目交付时涉及多个不同角色，其中包含客户、售前解决方案、交付、SRE、研发、QA、运维；其实还有市场销售、项目经理、解决方案、领导及其他支撑的人员在背后默默的付出以保障项目的成功。

在项目合同已经明确之后，项目核心主干其实是围绕软件交付和用户业务上云来进行的。用户业务一般是由解决方案指导，而交付则是有交付人员协调个角色并实施执行。

本文通过大量的项目交付经验归纳总结了常用的流程和节点，对于各个节点的输入、输出及工作内容进行介绍。从需求收集开始，到交付的结束大概分以下几个阶段:

• 背景了解及立项
• 需求收集
• 方案设计
• 规划部署
• 部署资源申请
• 部署资源跟进
• 部署前资源检查
• 部署包输出
• 部署任务执行
• 测试验证
• 环境交付通知
• 项目交付总结
• 项目材料归档
• 交付转运维/技术支持

以下下对内容进行详细的展开说明

1.1. 立项或启动会议

立项或启动会议是有必要的，他能够明确项目的相关方的角色与人员安排，便于项目信息的同步与沟通交流。

1.2. 需求收集

需求收集阶段是收集可能影响 部署的相关信息，包括非技术性问题、技术性问题、用户侧规范问题等。

需要收集的信息是一个不断积累的过程，需要前期项目踩坑后总结，然后不断完善的一个问题列表。

新产品最开始可能很多问题考虑不全，前期需求收集也就不全面，交付过程中会被问题阻塞而延长交付时长，这是正常的情况。强烈建议在项目交付流程中有交付总结阶段，可以总结部署过程中遇到的问题；如果前期了解到该问题，在后续项目中就可以避免，也可以提前预知风险及准备应对策略。

具体需要了解的问题作为一个输入，比如早期部署前可以准备一个收集表格。

信息收集对象会有我方的销售（如：交付哪些产品）、项目经理（如：实施的时间）、客户人员（如：操作系统）和其他人员，核心目的是：尽可能细的在部署前明确影响交付部署的问题，为方案设计和资源申请提供信息来源，为部署实施减少阻塞。

1.3. 方案设计

方案设计阶段主要在全局整体上对各个产品如何部署运行进行规划，要考虑用户对高可用的要求、资源提供方式、网络方案、设备类型等等。

比如用户可能会在欧洲、美洲使用 AWS Kubernetes ，在国内使用阿里云的 Kubernetes，自己机房使用 的 NCS来部署和运行多环境，那就考虑多环境如何规划、组件如何部署等问题。

比如，在产品层面可以大致设计成如图架构：

将设计好的方案同步给输出部署包的团队（一般是交付团队或SRE），并转换成 的部署逻辑。

1.4. 部署规划

部署规划阶段是将解决方案的架构转换成 的部署逻辑。明确哪些组件部署在什么机器上？是否需要高可用多副本？需要多少资源？

当然，如果在前期收集需求时用户有集成的需求，这时还要考虑集成的内容，使用用户提供的服务能力代替 自有的组件。

在私有化交付的场景中，大概率会遇到用户自己运维团队有运维规范要求，尽量在不打破用户运维规范的的前提下将 部署完成。

比如，用户要求在上生产时 MySQL 必须使用他们 DBA 提供的数据库，否则评审不予通过。那在部署规划时，就要减少 MySQL 部署的资源申请，转而向用户申请一个 MySQL 实例。

1.5. 资源申请

资源申请阶段是用户准备资源的过程。部署依赖的机器只是其中最常见的资源，但不是唯一的资源。

这个过程如果准备的充分，部署过程会比较顺利，但是如果申请项缺失遗漏，可能会有阻塞项目部署进度。

比如：用户环境有防火墙端口限制，但是在资源申请时遗漏某个端口放通导致部署的服务无法调用。而这时一般情况只能再次向客户提交申请，这个周期的时长因客户差异快则1-2天，慢的可能需要1周时间才能放通，对项目按时交付影响较大，而且会让用户感觉不专业。

在资申请时，用户如果涉及跨部门申请资源时，可能有些资源会调整，不一定都能够满足所有的资源申请需求。比如，申请的虚拟机资源太多无法满足，要求缩减资源申请。

这是就需要多方人员进行讨论协商，用户考虑资源多，但我方考虑高可用、稳定、便于管理等因素，不合理的减少资源可能会带来一定风险。多方达成一致才能保障项目的正常进行。

1.6. 资源检查

资源检查阶段主要是检查用户是否按照需求准备资源。

用户资源可能由于某种原因没有按照要求准备，这时如果出差到客户现场部署才发现用户没有准备好，可能会白跑一趟。

比如，用户说资源都准备好了，可以过来实施了。结果去到现场后发现用户没有申请 SSH 登录权限，机器都无法登录，部署也就只能继续延期了。

资源检查的方式一般是使用工具+人工的检查。比如，工具检查机器CPU内存是否按需提供，磁盘是否格式化挂载；人工检查域名是否合法等。

1.7. 配置编写

配置编写阶段是根据环境信息编写 部署时配置，通过该配置工程渲染出实际执行的配置文件。

通过配置工程可以减少配置的编写工作量。 有几十个 helm chart 包，每个chart包都会有一个 values.yaml 文件，通过该文件来安装chart。

在每个chart包中会一些公共的配置，比如 harbor 镜像仓库的地址用户名密码信息、 MySQL 地址信息、公共服务的地址信息等等，将这些信息通过配置工程填写一次，然后批量渲染到各个 chart 的 values.yaml 文件中，安装时不在需要修改配置文件。

如果部署时一个个 values.yaml 填写也可以，就是太耗时间也更容易出错。

1.8. 部署包输出

部署包输出阶段是根据部署配置要求输出在线或离线的部署包。

私有化交付和平常自己搭建环境有较大的差异。对于政府、银行、证券等部门对安全审查要求较高，在他们的生产环境部署软件基本都是完全离线的，就是说在部署过程中无法访问外网获取文件。平时感觉 yum -y install wget 很方便，但是在客户环境不行，不通外网也没有软件源，无法安装，这时就需要在前期输出部署包时准备充分，尽量减少上传文件次数。

如果中间文件缺少了，重新上传一次就需要重走流程，周期会变得更长。

那在离线场景下需要准备哪些文件呢？这其实和需要交付的软件本身的依赖有关，不会完全一样的，但是可以提供一个参考：

操作系统依赖：

• hostos（内核参数调整封装的软件包）
• ntp

安装部署依赖：

• helm
• kubectl
• ansible
• python

产品部署依赖：

• docker
• cfssl
• cni-ovs
• kubelet
• lxcfs
• socat

产品本身组件：

• ceph

公共文件：

• docker image镜像
• helm chart 包
• tmp-registry 的镜像
• 私有化的配置工程

其他文件：

• 部署文档说明材料
• 其他可能会用到的材料

这里分了几类提供参考，按照产品部署的需求准备文件即可，如有遗漏文件下次部署前考虑进去即可。

1.9. 环境部署

环境部署阶段就是实际执行部署过程，将软件部署到目标环境中。

部署过程可以是自动化脚本 + 手动 部署的方式，但应该尽量的自动化。自动化的过程其实也是部署的标准化过程，当过程足够标准了，部署的人力消耗就会降低，部署效率和质量就会更高。

高度自动化部署是期望的目标，但需要一个过程，在没有“完全实现社会主义社会”前，应该通过多方策略保障任务稳定的进行，比如积累“部署问题FAQ”

交付经验很重要，但太过于依赖个人经验会给团队带来较大的系统性风险。通过问题的整理记录，能够实现部署问题经验的共享，其他实施任务在进行时遇到同样的问题时就能够快速确定问题并快速解决掉，是一个不错的经验共享的方法。

1.10. 回归测试

回归测试阶段是对部署完的环境进行测试验证，保障交付环境满足功能期望。

回归测试结果达成交付、研发、用户的期望即可，不一定非要做到完美，但应该尽可能的做到不遗漏问题。

回归测试也是由两部分组成：自动化测试 + 手动回归的方式。自动化尽可能的覆盖场景，确实无法覆盖的需要通过人工手动回归的方式来验证。

注意： 回归测试的目的是验证部署的功能是否正常运行，不是挖掘 BUG，BUG 应该在版本发布时就发现并解决掉的。

1.11. 交付总结

交付总结阶段是对整个交付过程进行复盘，梳理出交付过程的问题，优化交付实施涉及的各个方面。

最近复盘这个词被污染了，慢慢的变成了贬义词，变成了 PUA 的代名词，但这个行为的本意出发点是好的，算是论语中 “吾日三省吾身” 的现代化表达。

交付实施人员就喜欢复盘。比如如，在 交付中大部分的流程经验都是复盘带来的：

客户现场编写配置太过于耗时且容易出错，那能不能不在客户现场编写配置？-- 配置工程的出现 部署包太大，客户的网络质量差下载慢、传文件流程太长，现场才开始上传文件消耗时间太久不可控。-- 部署包提前提供NOS下载地址给用户，让用户提前下载准备 部署过程总是缺少文件，阻塞部署镜像。 -- 缺少啥文件，离线打包脚本添加进去，下次就会缺少了吧 等等 也可能会遇到产品功能 BUG 或者优化建议 ，一般情况下按照规范提交 JIRA/EP 任务即可。

注意： 复盘的过程不是要追责和甩锅，是为了优化后续的工作

1.12. 材料归档

材料归档流程是将交付实施过程中所有用到的文件都归档保留下来，以便后续查阅使用。

私有化交付不是一锤子买卖，交付实施完成后还需要交接给运维人员，归档的材料就可以作为交接的材料。

具体要归档哪些材料根据产品特性和用户的需求，以及交付转运维的需求来考虑，除了固定的材料外，还可以考虑添加其他的可能有用的材料，只要是交付过程中的输出都可以归档。

1.13. 总结

本文对 私有化交付流程进行了一次剖析，将交付流程大致分成了：需求收集、方案设计、部署规划、资源申请、资源检查、配置编写、部署包输出、环境部署、回归测试、交付总结、材料归档 这几个节点，并对每个节点进行阐述。

私有化交付有一定的复杂度。简单的私有化如 nginx 的安装，复杂的亦如 OpenStack 全家桶的安装，短则几分钟，慢的可能几周。曾经了解过某云的专有云交付，从机房选址，到服务器采购上架，再到软件安装调试，以及业务上云，其整个交付周期可能是数月甚至以年为单位。

高效的交付离不开多方的配合支持和个人全面的技术能力。个人的技术能力强能够快速定位和解决通用性的技术问题，但是私有化交付的目标是交付上层能力软件，不是该产品的研发，终究不能解决所有的问题，这时交付人员作为项目交付阶段的 onwer 来协调各方的后端人员共同解决问题。

软件私有化的目的是为企业带来利益，私有化交付的目的按时按需的交付软件，交付人员的职责是快速、高效、高质量的按时、按需的交付软件以此降低人力成本和提升用户的满意度。