对于安装和部署，涉及的流程比较复杂，随着后续的维护和管理，流程也会发生变化。配置和不稳定的过程导致安装部署交付效率与预期差距较大。现有流程如下：上述流程存在以下问题，相信很多中小企业都或多或少涉及到这些问题。整体表现1）在代码实现上，流程相对臃肿硬编码，流程变更风险高。2）资源申请填写信息过多，信息不够简洁，对业务方不够友好。3）目前的资源流程比较复杂。属于定制开发。如果在其他进程中也有类似的配置，代码复用率就低。资源审批4)资源交付时间比预期的要长。一方面体现在审批流程上，另一方面体现在资源交付的试错上成本高5）目前不支持测试环境的数据库资源申请工单，创建数据库的过程需要人工引导，对主机资源池进行过滤6）资源下发时，如果有资源配置与工单不匹配，则无法下发，工单需要重新编辑7）主机资源池的链接目前是人为控制的，需要手动输入主机信息。没有资源池和资源预申请流程数据库资源下发的门槛管理8）流程执行失败，重试流程检测某个环节出错的概率高，导致整个部署出错的概率高10）新版本数据库的接入使得原有模型难以兼容，新环境部署目前多部署在手动模式11）如果申请的是单实例，一主两从，集群环境，无法支持和适配。数据库权限下发12）业务资源申请时，资源下发后的权限下发流程可能不明确，后期变更概率大，如果手动申请，需要提交自动化在线协作表（builddatabase),authority申请协同工单（需要再审批一次）,建表（自动化在线协同工单或对象操作协同工单），对于不熟悉流程的开发者来说，流程会显得复杂，不清晰足够的。相应的改进策略和方向如下。总之，我们希望先做好占90%以上的资源预申请和预配置的基础工作。当业务提交申请时，DBA只需要处理额外10%的配置管理部分。整体表现1）在代码实现上，流程相对臃肿，硬编码，流程变更风险高改进策略：基于配置式流程编排，在设计初期就考虑流程变更，以及通过多进程的配置和编排实现支持不同的业务场景，比如支持单实例、一主一从、一主两从，流程相似又不同，不同类型的需求可以通过配置不同的流程2)资源申请填写的信息过多，信息不够简洁，对业务方不够友好改进策略：优化当前前端配置，去除不必要的信息和必填项，减少至少20%的填充项目。3）目前的资源流程比较复杂，属于定制化开发。如果其他进程也有类似的配置，代码的复用性就很低。改进策略：对于流程安排和任务配置，可以通过通用配置和通用服务来实现，提高代码重用和稳定性建设。资源审批4)资源交付时间比预期的要长。一方面体现在审批流程上，另一方面体现在资源交付的试错成本高。改进策略：对于测试环境的资源交付，实际上是数据库交付，可以简化流程实现对于开发环境的资源交付，可以直接去掉审批环节，线上环境的资源交付将是稍后通过虚拟化多租户模型实现。目前仍保留现有的审批环节，资源成本的反映有待商榷。5)工单目前不支持申请测试环境的数据库资源，需要人工指导创建数据库的流程改进策略：上述主机资源池筛选6)在资源交付中，如果有工单中不匹配的资源配置，无法交付，需要重新修改工单的数据改进策略：资源池的配置可以差异化，但需要考虑适应性.资源配置按照优先级可伸缩性标准实现。比如业务申请8C8G的数据库资源，目前资源池中有5个实例资源：① 2个4C4G，2个8C8G，1个8C16G，那么可以使用2个8C8G② 2个4C4G、1个8C8G、1个8C16G可按1个8C8G、1个8C16G规格发货，其中8C16G优先绑定主库③ 2个4C4G、1个8C8G和2个8C16G可按2个8C16G的规格发货7）主机资源池链路目前为人工控制，需要人工录入主机信息，资源池和资源预置无门槛管理应用流程改进策略：在资源快速交付方面，资源层可以拆分为主机资源池和数据库实例资源池，主机资源池和实例资源池用于构建层。实例资源池只保留可用资源。资源使用后，需要在资源历史明细中归档，宿主资源池需要通过流程与系统部门对接。为此，主机资源池需要考虑实现阈值告警，并提供必要的接口供系统部门回调。数据库资源下发8）如果流程执行失败，重试流程检测相对较弱，需要人工做一些额外的处理工作。)新版本数据库的接入使得原有模型难以兼容，新环境的部署目前多采用手动方式部署。使用通用流程配置任务详细信息。对于任务对象，需要考虑序号的全局唯一性。数据库权限下发12）业务资源申请时，资源下发后的权限下发流程可能不明确，后期变更概率较大，如果手动申请，需要提交自动化在线协作表（buildadatabase),permissionapplicationcollaborationsheet(requiresanotherround审批),buildatable(自动在线协同表或对象操作协同表),开发流程不够熟悉的人员，流程会显得复杂，不够清晰.改进策略：对于资源申请文件的处理，适度提供更灵活的支持方式，尽可能减少提交多个工单的方式。对于一般任务流程的整体设计，主要按以下方式进行分层。图片会较少涉及比较详细的部分，比如任务依赖，超时处理等，主要以基本的流程执行方式为主。其中，编排层实现流程的编排和流程任务的配置。这里涉及到基本信息，不涉及具体的实现细节。应用层是一个独立于业务的数据模型。需要在业务层定义一个全局唯一的批号（batch_no）。可以理解为一个全局唯一的对象ID。任务执行层主要是通用任务的实现，其中流程任务的配置细节是根据应用层的数据配置和流程任务的配置相结合，形成任务细节的注册，比如当submitting和deployment请求的时候，就是任务详情的执行计划。流程任务详情日志维护流程任务详情的执行日志和状态。如果任务执行成功，相应的任务详情记录状态将被更新。否则，如果失败，则需要激活重试机制。本文转载自微信公众号《杨建荣的学习笔记》，可通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号。
