服务打包：需要跟研发沟通，确认每个服务要部署的版本，手动导出镜像到服务器，再生成私有化部署的服务包。 配置文件内容修改：由于每个环境都是独立存在的，服务器、中间件的地址以及账号密码等信息在每个环境中都不一致，当时通过 sed、awk 命令批量替换配置文件内容操作不规范，导致错误频发，反复调试。 Nginx代理调整：服务进程会拆分到多个服务器节点，路由全靠手动配置。 服务器环境初始化脚本：在客户环境中安装Docker + 各种中间件，由于客户系统版本不同，而且大部分客户不提供外网环境，每个包都要定制化。 部署后的验证：因为自动化测试覆盖不完全，部署后需要测试同学到客户现场配合验收。
半自动打包：在发布前，提供一个Excel，让研发将测试通过的代码版本填到表格中，由程序读取tag后自动生成私有化部署包。 配置文件模板化：每个后端服务的配置文件均使用 Jinja2 语法来进行编写，模板中的 key 和 value 由运维同学负责维护。针对不同的环境，在部署时通过模板渲染的方式生成配置文件。 增加对服务器及环境的限制：针对客户提供的服务器系统、硬件等约定了一个支持的范围，并针对支持的系统开发了一系列的自动化脚本，可以批量初始化环境。 完善的自动化测试：使用 golang 开发了一套覆盖全部 api 的自动化集成测试工具（siber），减少了90%的人工测试时间。
多产品线的组合部署以及按业务功能的拆分部署 支持的场景比较单一，无法适配客户对于poc场景快速部署的需求
全面拥抱 k8s 。 把所有业务线下能独立的功能全部拆分成单独的模块，并独立维护模块之间的依赖关系。 按部署场景，把支持的部署范围缩小成单机部署、高可用部署两种场景。单机采用 docker-compos 编排，高可用使用 k8s 。 开发一套系统，可以在系统上选择要部署的模块、场景来进行自动化打包。
SaaS 迭代速度太快，私有化部署的发版完全跟不上节奏。 已部署客户的环境版本太多，维护成本超出预期，急需快速升级。 一些早期部署的客户，由于运行时间过长，导致磁盘使用率过高，影响业务。 高可用的中间件宕机一台节点，外部并不会有感知。这就导致再次发生问题时，高可用机制变成了空壳。 AI 能力模型定制化场景较多。
完全放弃 docker-compose 编排的单机部署，改为单机 k8s、高可用 k8s 两种部署方式。这个做法当时收到了很多反对的意见，比如部署过程问题较多、维护复杂等等。不过好处也很明显，就是发版速度提高了很多，从原来的1、2个月变成了现在的1、2周。 在内部 CI 流程中记录 SaaS 发版的服务的 tag、配置文件模板、路由、模型之间的关系，并在私有部署发版时通过选择指定的 tag 来进行发版。 让研发同学配合，提供可回滚的数据库迁移工具，并针对已有客户的部署场景，产出定制化升级方案。推动客户升级。 部署监控工具、在售后服务中增加巡检的服务。
环境标准化：统一使用 k8s 环境作为底层，istio 作为代理层，服务通过 helm 管理。 服务标准化：统一端口号、配置文件路径、日志路径。统一使用无状态模式运行。 外部依赖标准化：支持客户自己提供的中间件，并对客户的中间件进行检查，判断是否满足部署要求。支持客户自己提供的 k8s 集群，只要提供集群 api 的访问权限，我们就能部署。
私有部署前置检查工具：验证客户环境是否满足私有化部署要求，并承担初始化环境的角色。工具运行完成后，会在本地记录环境信息，如服务器信息、中间件信息、端口信息、代理信息等等。 私有部署自动化打包工具：基于 SaaS 发版时记录的服务、配置、路由、模型之间的关系，根据指定的 tag 生成私有化部署包。 自动化部署工具：基于前置检查工具生成的结果和客户选择的功能来进行自动化的私有化部署。
现存问题 产品组件多，客户量多。 服务没有完全标准化。比如 UiBot Commander 的定制化部署、IDP 产品的第三方模块。 客户环境多样性：不同的安全限制，各种修改配置。 适配性做的不好 当前只支持标准的 Centos/Red Hat 7.x 系统。但如 Ubuntu、CentOS 8.x 甚至 Windows 都有适配需求。 对于政府行业国产化操作系统、硬件的适配。 服务层面对中间件的选型、版本的要求，范围比较小。 当前无法对客户提供的容器云进行适配。
