本文主要是介绍Canonical Juju 的一个奇怪编排部署，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一周前的一个项目扩容出现了异常，进行了操作回滚，未对线上业务造成损失。
现象是这样的：
通过基于 Canonical Juju-GUI 在一组节点上部署了某个组件，在把这组节点添加到集群后，有4个节点上出现了同一组件的2个instance、这4个异常节点中的3个发生了组件配置文件全部丢失的现象。
BD的现场产品支撑粗暴地下结论为：短时间内重复点击了组件部署，导致组件配置文件被替换。
但我认为这个论调很牵强，在时间先后上构不成必然的因果关系。
整个操作过程如下：
20：30分开始部署业务组件，有6个节点因部署结果相应不正确而进行了第二次部署，两次部署时间间隔 34秒47毫秒；
由于该项目同时有另一个组件配置变更，协商后决定顺序执行这2个变更操作（扩容操作为后者）。21：30分开始操作扩容变更，检查全部节点上该组件的配置文件未发现异常，按照既定计划向集群中添加Node，全部Node添加成功。大约3分钟后，开始向新的集群节点中添加磁盘，该过程中发现了有2个节点添加磁盘失败。根据控制台输出的日志，发现是这2个节点中中组件配置文件全部不存在了。
至此，中止本次扩容操作，开始数据止损、确保数据安全。
现在，来谈谈为什么不能认同 BD 产品支撑给出的结论：
一 、驳“短时间内重复点击了组件部署”
首先，通过回放扩容操作录像，可以确认针对故障节点所在组的全部节点进行了两次批量部署，这两次批量部署的时间间隔是 34秒47毫秒。这个时间间隔在响应时间不超过5秒的产品规格中，不能算是“短时间重复操作”。
其次，根据Juju-deploy的日志记录，部署组件的action日志中显示，重复的两次操作事件开始时间间隔只有3秒，这个时间差和回看录像发现的34秒47毫秒相差太大。另外，重复操作波及到的14台机器中只有4台上有创建2个instance的action事件记录。
二、驳“重复部署instance时配置文件被覆盖为空”
首先，如果是重复操作部署产生的结果，那为何同一批14个节点中只有4个产生了2个instance、且这4个节点中只有3个节点上的配置文件发生了丢失？难道不是被波及的14个节点的配置文件全部被在第二次部署时覆盖掉吗？
其次，根据 Linux 命令行工具的实验结论，通过tar解压一个空白文件夹是不会把已有的同名文件中的文件清空的。此外，在组件的install工具脚本中并未看到对已存在的同名文件夹进行删除的语句。因此，“重复部署instance时配置文件被覆盖为空”这个论点在事实上是不成立的。
再次，为什么节点上的配置文件丢失是在第二次部署结束后的90分钟以后、且在instance使用该配置文件的过程中发生的配置文件丢失？“重复部署instance时配置文件被覆盖为空”这个论点与既有事实自相矛盾，无法解释为什么配置文件在使用中发生了丢失。
BD的产品支撑给出的论点根本无法解释以上两个大方向的问题中的任何一个疑问。
接下来的3天，我作为交付方代表主持了此次项目扩容事故的全面调查，产研、交付、运维、联合售后专家委员会、项目经理一致认可的结论是：基于Juju的交付工具存在产品缺陷，当前项目中的这个交付工具版本尚未修复过已经发现的产品BUG。
在调查过程中，根据查阅的产品BUG汇总表，发现BD的产品研发对Canonical Juju进行了自研化修改，修改后的Juju存在的一个严重缺陷是：通过这个交付平台部署软件时，软件封包时的默认配置信息会被Juju工具平台删除，但这并不是一个必然的现象，而是只有在向既有集群中扩容新节点时才会发生。这个产品缺陷，最早在2023年9月就被作为业务环境重大生产事故报告过。2024年3月又有一次作为业务环境重大生产事故被在联合售后组会上通报过。
更可怕的是，这个问题刚刚本次扩容当天的那个组件配置变更中发生了，在本次扩容中发生了这个问题，当天经历了这个问题的产研支撑竟然没有提示这个问题、在事故发生后的原因定位过程中居然还在避重就轻地往人员操作方向引导我们的调查思路......
事件有了结论，也该总结一下工程管理中的警示与教训了：
1）在非标准化产品交付过程中，一定要指定专职的DTA和SOP执笔，要充分考虑当前工程中的工具软件的缺陷与规避问题的方式；
2）不要盲目相信产品研发和产品规划提供的“标准操作”，他们提供的工作成果只能作为参考、不能直接执行，一定要贴合运行中的项目实况进行剪裁修改；
3）要取得方案执行的主导权和话语权，争取得到高层领导在资源和人力方面的支持，未取得绝对支持前不可妄动；
4）事故发生后不要慌，要原原本本说明自己“做了什么、没做什么”，客观地描述事故发生过程
5）被指名参与项目执行方案评审的产研、交付、运维、技术专家，必须亲自登录到目标业务环境中了解业务系统使用的组件是什么、组件版本是什么、该版本的组件已知产品缺陷是什么、在当前评审的执行方案中应当注意什么问题、如何规避已知问题。
6）项目活动执行方案评审，必须严格执行三审排期制度、绝对不可走过场式地临时评审，要确保每个执行方案评审意见有事前会签、事后反馈。
这篇关于Canonical Juju 的一个奇怪编排部署的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
