1. 软件私有化交付的特点
软件私有化交付时一般都不会太顺利，在不同的阶段，不同的角色或维度会有各种各样问题，这些问题有些可能会决定整个项目是否延期，有些问题甚至影响项目能否成功。
在项目早期，如果能评估到一些痛难点，提前准备相关的应对策略，将会给产品的私有化交付提供很大的帮助。
站在交付方，以私有化交付全局的维度来分析项目交付前后的痛难点，可以分三大类，分别是用户侧、交付侧和工程售后侧。
1.1. 用户侧痛难点
- 产品功能需求多样
标准的产品不满足企业的需求，需要软件提供商按照企业的需求进行产品的修改或适配，但是跨企业的协同效率相对较低，经常出现返工修改以及环境频繁升级的问题。
- 集成要求多
软件在企业内部安装部署需要集成企业内已有的生产运维体系。比如集成用户的统一登录平台，集成用户的监控告警系统等。
- 资源准备周期长
时间长,或者资源变更修改时流程长。由于企业内部资源申请需要经过多层的审核和审批，如果不符合企业规范要求调整申请又需要从新审批流程，这个周期可能是周，甚至是月。
- 企业业务上线规范复杂
用户有自己的上线运维规范，交付软件需要满足他们的运维或安全的规范。例如有等保三级，性能指标、安全扫描、上线时间窗口短等等规范要求，但这些在做产品时可能没有全部考虑到。
也有一些企业要就生产环境部署只有由自己公司的技术人员操作，不允许外部企业人员安装部署操作。
- 用户侧的变更
由于设备搬迁、网络变更、设备升级、关机等没有，导致无法展开交付。
没有按照部署规划要求准备资源。讨论好的资源需求申请，由于客户内部的某些原因无法按照前期规划的方案交付，或用户准备的资源环境不稳定。
- 客户验收要求高
验证项目验收时，要求合同约定的条款或临时提出一些验收要求需要满足。例如临时需要故障演练，要求配合项目做等保认证测评，要求协助企业推广等等。如果客户关系好可能会顺利一些，如果客户关系有较多的矛盾可能会导致项目周期变长，成本增高。
1.2. 交付侧痛难点
- 交付实施人员技术要求高
交付过程涉及操作系统、Docker/Kuberentes、交付产品本身以及用户流程和基础设施等方面问题，需要交付人员有较强的技术基础和用户沟通的能力。
- 部署工具不完善
在产品的早期可能会有部署工具不完善，部署过程冗余复杂，耗时耗力。
- 测试验证复杂
在部署完成后，为了保障交付质量的，一般都会要求有测试验证的流程，对于自动化测试无法覆盖还需要人工手动回归来保障交付的环境质量。交付产品越复杂，测试验证也就会越复杂。
- 跨企业协同困难
在项目开始部署前，都会设计部署实施方案并和用户沟通，但由于双方没有对齐导致的方案和资源不一致，现场实施时受阻。即使可以调整方案，但依旧会给项目带来延期的风险。
- 用户的网络隔离与限制
企业考虑到安全等原因，网络无法访问互联网，在交付实施过程中遇到问题时查找资料，寻求远程协助以及下载更新文件都是受限的。
- 部署包较大，上传文件时间长
使用容器化私有交付时，一般都是将程序构建成离线的 Image 镜像。Image 镜像即使通过镜像层的复用降低了整体的大小，但由于交付系统本身的复杂导致依旧会有大量无法复用的层，结果就是离线镜像包或部署包比较大。特别是传统企业用户的网络质量和带宽并没有互联网企业那样好，这就导致了项目交付用到的部署包即使用移动硬盘复制到客户现场，上传到实际的部署运行环境依旧会花费较多的时间。
1.3. 工程售后侧痛难点
- 基础设施多样
在私有化场景下，不同的企业客户有自己独有的基础设施。比如不同的硬件，有的客户采购了华为的服务器硬件，有的客户采购了 HP 的服务器硬件，也有的客户自己定制服务器。操作系统也是各有不同，例如在企业内部常见的操作系统有 CentOS/Debian/Ubuntu/Redhat/统信 UOS/麒麟OS等等。CPU 架构也可能不同，有 x86 的服务器，也有 ARM 的服务器。
- 私有化的产品复杂
如果私有化的产品本身比较复杂，在私有化版本发布时需要真正的能够理解产品并对私有化交付体系有较深刻认识的负责人来把整体控私。否则由于私有化技术选型、版本的管理、自动化的封装、场景的认知不足、准备的材料缺失或者其他考虑不周全导致产品的交付和管理复杂且混乱。
特别是做了微服务改造后，组件的数量可能成倍的增长。交付部署和运维考虑的内容也变多，什么服务治理、高可用、安全、性能、多机房、备份恢复等等问题就变得复杂。
- 产品本身质量不高
由于新功能的加入频繁的需求变动，导致产品功能不稳定 Bug 数量比较多，QA 的测试把控不到位的话，会导致现场交付时分析定位和解决 Bug 。现场定位解决问题不仅不方便，同样会消耗较多的时间。
- 文档材料缺失
在做私有化时，建议提供匹配的文档工程师。企业在进行外部采购时，有些材料是强制要求有的，否则不会验收该项目。而且，如果每次用户有文档需求时都是首次准备，质量是否高暂且不说，给用户的感觉也不好，显得不够专业。
- 项目数量逐年增长
项目数量的增长本身说明产品卖的好，但也会带来运维和售后的成本增长。在合适时间应该做好人力的评估，及时扩充团队和人员，否则会给当前的员工带来较为繁重的工作任务进而导致人员流动较大。
- 客户环境离线，后期维护难度大
由于网络离线无法及时收取异常告警信息，需要用户收取到告警反馈给售后人员，可能由于技术的差异导致问题定位和修复过程不顺利。由于离线，一些预期内的变更或升级需要出差客户现场，支持的成本比较高。
- 用户基础设施影响
如果交付的是软件产品，由于基础设施如机器、网络、电源等都是由用户其他部门维护，基础设施异常时，会影响上层的软件的稳定运行。
- 规模化后运维升级成为最大的痛
对于 bug 的修复可以在时间上排期修复，整体问题不大。但是对于安全问题的修复提供的时间是非常有限的，比如之前 2022 年 log4j2 的安全漏洞。
在少量项目时即使有突发事件也能支撑，但是当项目规模上来后比如有上百个售后的项目需要同时修复安全问题，如果产品修复方案足够简单让用户自己操作还好，如果都需要原厂人员支持修复，那是一个个的不眠之夜～～～
1.4. 小结
由于上述的一些原因导致软件在私有化交付时交付周期长，交付质量差、交付成本高。如果成本太高，这个项目可能就由于投入太多而亏损。
为了保障软件私有化的正常交付，在进行架构设计和技术选型时应该结合当前主流技术体系，选择合适的解决方案。