有时候突然把几个不相关的东西连起来，也能找到一些共同的地方。想着最近的事情，脑海中浮现出几个词：“半成品”我对工作中的半成品是相当反感的。综上所述，投入与产出严重不成比例。另一种情况更主观。做任务的人感觉一切都井井有条，但是验收的时候发现问题不是设计理念，而是任务的精细度比较粗糙。态度差不多的话，其实是可以过去的，但显然以后会发生什么，谁又说得准。真正需要的时候，代码逻辑几乎忘记了，重新调试改动。如果这个作品前期能稍微难一点，返工也不会很多。所以在这件事情上，我发现之前对自己和团队成员的要求有点松，以至于稍微有点要求和质量标准，我就会觉得大家有点硬，其实对事业是有害的发展。从0到1的构建主要是为了效率和快速迭代。一些质量标准可以打折扣，要求过高会有些苛刻，但保家卫国难度更大，技术维护更是如此。我们都希望时间的边际成本可以越来越低。在某些基础上建立和改进需要真正的努力。举一个最近和一个半成品交锋的小例子，也是为了鞭策自己按照既定的思路继续往前走。这是安装部署数据库软件的一个例子。按理说，这是一件很简单的事情。如果要选择命令，基本都是个位数的命令，但是还有一些额外的地方需要补充。1）参数文件版本不同，比如环境有5.5、5.6、5.7、8.0等，如何更好的支持多版本2）初始化用户和权限，需要根据业务特点创建一些预设用户，并配置相应的权限，不同版本的语法格式不同，密码插件也有相关影响。3）安装部署通常涉及监控告警、备份恢复等。这些任务可以是可选的吗？4）单机多实例和服务部署方式还是有一定区别的。如何顺利适应？5）新数据库版本支持，如何让已有的接口和部署方式适配MySQL8.0已经推出好几年了，我们内部也做了一些测试和总结，早期直接进入了MySQL5.7版本，也算是积累了3年多的经验，所以果断决定，所有新业务都按照MySQL8.0的baseline来推进。现有的脚本已经好几年没有被触及了。经过一番需求分析，发现这是一个半成品。主要原因有以下几点：1）直接使用脚本的场景非常少。去年，团队努力研发一键部署。由于流程较长，所以比较脆弱，这与这个功能有很大的不同。2）脚本执行不稳定，因为之前的脚本设计中使用了很多零散的脚本，也就是说脚本调整的思路和逻辑比较大，混杂3）增加了8.0的功能，需要改脚本整体来说，涉及的面积比较大4）脚本中也有一些小问题，没有修复。针对这些问题，我做了以下几件事。1）备份好脚本内容后，我开始删除一些过时的逻辑校验代码，去掉一些没有用到场景的逻辑和相关脚本。2)将多个脚本整合为一个，重新组织脚本相关的依赖。3)依赖参数文件模板和脚本模板都上传到配置中心，脚本将通过命令提取4)将原文件夹的脚本结构重构为单个脚本5)修改前端配置和去除冗余无效的配置项，修改调用逻辑6)团队内部进行了简单的演示，团队提出了一些改进建议，修正后发布。经过大量的测试和整理，也在不同的版本中进行了相关的测试和验证。也算是把原来的半成品状态弄出来了，而且是最新版本。接下来，还有一些更详细的事情要做。1）安装部署时间目前在30秒以内，涉及到数据字典的初始化。目前采用的是一刀切的逻辑，后台休眠20秒，保证这个进程的初始化时间足够。其实可以更加动态友好，做动态监控2）考虑使用自制的基于yum的配置方式，重新打包构建一些固化的参数、命令等，这样可以使用yum快速部署之后。3)软件安装部署一体化，提供多版本软件支持和安装，如8.0.19、8.0.204)采用基于压缩镜像的方式，可以将数据库压缩到很小的容量，并且可以需要的时候直接解压启动没错，经过前面的测试，一个可用的数据库镜像大约2M，解压后大约2G~3G（涉及到ibdata、reod等文件的容量）。按照下面的二维码进行操作。转载本文请联系杨建荣学习笔记公众号。
