两地三中心存储复制与切换操作的易用性对比？

      一般采用GUI来查看存储及对应操作状态，GUI在数据展示上更加直观集中，便于观察，但数据的更新可能不及时甚至出现数据错误的情况，所以在进行重要操作时除了在GUI观察操作的进展状态，手动执行命令去检查GUI上显示的数值和命令返回的一致性也是很有必要的，双重核验确认后再进行，求稳不求快。之所以不用CLI去代替GUI展示的功能，主要还是CLI的数据返回没GUI直观，想达到GUI的展示效果常常需要多条命令去执行查看，开的命令窗口相应增多，窗口的切换、来回命令的执行，极大的增加了出错的可能性，更影响操作思路的流畅性连贯性。

     CLI主操作+GUI辅助查看+CLI确认重要指标，CLI的主要操作都可以被完整的logging，不管是做变更记录还是整理笔记，都可以很方便。CLI的命令回显很准确，主要操作的实时准确性都能COVER，整个变更操作也顺心顺手。CLI的窗口多了，不免就“乱”了，乱中出错的风险就大大增加。不管是作为现场工程师，还是变更负责人，思维跟上操作、操作保障实施是最起码的素质，这也是对生产变更的基本尊重。

 存储复制和切换操作，如果是有完整的变更操作窗口，一般会采取上面的方式，至于手动和自动，倾向于半自动。全自动操作确实简单了事，但自动万一出现问题呢？半手工的方式，优势在于思维一直跟随着操作，重要指标都在掌握中，一旦出错、对错误的定位及排查也能够迅速展开。自动化工具的稳定性及自动操作的可靠性，都是风险点。在全自动功能没有十分完美、意外案例少之前，都会采取半自动方式，关键操作手动查-做-查，确保万无一失。
 在这几年里，存储的功能性工具都慢慢齐备了，功能也足够丰富，几年的打磨也具备了相当的可靠性，原厂变更操作也逐步向自动转移。自动化操作肯定是一个趋势，但前提是自动化的安全性与可靠性要有足够的保证。

切换操作方式web和gui方式上相对更直观便捷，更易于一般运维管理员的操作。cli方式就需要确认切换命令的准确无误，并且对运维人员的要求更高些。 在复制上来说，图形肯定流程化的，准确度高些。cli需要编辑命令确保准确性，不过针对大量复制任务来说，Cli要更高效。

对于容灾切换本身的操作，其最大的要求是安全、快速。那么从以上两个要求为基准，我们来判断这几种方式的判断。

首先对于CLI&GUI，我认为GUI方式数据显示的不够及时，而且浏览器本身在极端情况下发生问题的概率很高，所以CLI方式更安全、命令方式更快速，不需要GUI应用工具到命令的一个翻译。

然后，我们来判断手动、半自动以及全自动。手动方式从速度上来讲会慢很多，从安全性上来讲，误操作的概率也是存在的。那么全自动的方式虽然快，但是在面临真正的容灾切换的时候，遇到的情况可能会错综复杂，全自动化的脚本或者工具是不可能覆盖到所有的突发情况，那么从安全性角度考虑，也不是一个合适的选择。因此精心设计好半自动化的操作方式，把操作细分然后聚合形成半自动化工具，这个是一个比较实用的切换模式。

前面那位中金公司的大神解释的很好了。现在存储复制都稳定，没有啥难度。两地三中的存储 建议都是一个品牌的才利于切换（同构），异构就复杂了。单个切换这个活没有什么难度。 难点是切换流程上线依赖关系判断，切换流程是否可跳过，可回退。切面界面不建议web页面方式。这种看似简单易，操作存在很大隐患。首先降低了工作难度普通人员都可操作。普通人员操作傻瓜式点击，当遇到web不响应，网络卡顿，多次点击提交会造成不可预测问题（上下逻辑验证不一定充分，普通人员没有这么高的意识水平，又无法定位日志）。   重要流程切换建议是有命令交互方式的切换流程，可以实时查看日志反馈，利于判断，安全性更高。 有些活降低工作级别不是好事。存储上放的是全行数据。

涉及到这样复杂规模的架构。平时维护和 出现问题时候我们当然希望的是越简单的操作，越清晰的故障报错最好。但很多时候还并不能完全实现我们想要的结果。一般来来说。WEB界面操作简单。直观，适于平时的维护，监控，包括一部分的业务切换，不过在出现问题时，由于设备的一些底层操作并没有提供WEB界面。所以往往在出现问题的时候都需要去CLI界面去进行检查和操作
另外，核心存储的切换，不仅仅要考虑存储层面，上层的业务系统，网络结构都需要随之做出调整，这并不是简单的通过存储设备的WEB界面就能搞定的，更多的时候在两地三中心这样的架构中，已经不仅仅关心存储层面的迁移。而是整个业务系统的迁移。存储，应用，网络都是这业务系统中的一部分，具体怎样迁移在实际过程中都要根据情况去指定。
现在人们在尽可能的去通过整体的系统去整合所有的部分实现一键式迁移，来简化这种业务迁移的复杂性，但多数时候，还是要有经验丰富的人去监控整个迁移的过程，应对随时可能出现的意外。
所以我觉得存储迁移也好，业务迁移也好。通过什么方式操作都不重要。重要的是在问题出现之前吧所有可能出现的问题整理好。形成标准化的操作文档，并且定期进行业务的演练来熟悉整个迁移过程中可能需要的操作。这才是最安全最便捷的

单纯的存储设备，说到切换操作，肯定是有图形界面更加友好。如果配合其他的操作联动，或者集成在自动作业调度系统中，肯定是命令行方式好。
另外，现在单纯某个产品的切换不是关注重点了，而重点应关注需要配合整体的切换调度系统h。实现一键式切换，无值守的自动切换。

特别感谢各位行业专家参与讨论，从各位的回答中受益匪浅，目前行内也在实施相关的容灾项目，虽然具备一定的半自动化业务的切换经验，但好多问题也是边发现探索，边解决总结。
比较赞同CLI为主，WEB GUI为辅的操作建议，command line操作可以迅速直观的确认关键参数和存储状态，对数据的变化也容易量化计算，结果利于保存用于故障排查、流程跟踪、回退依据和审计监管素材，便于封装成半自动或全自动模块，嵌入到整体切换流程之中；WEB GUI的界面数据也是从存储状态信息中查询而来，集中展示存储操作和状态信息， 免去不必要呈现的多余参数， 适合用于辅助切换操作结果确认，总体流程和调度的状态转移确认，针对存储层面切换测试过程可以采用，与业务配合整体操作时， 以CLI封装测试后的半自动模块，加上领导授权等调度流程，形成一套不单用于满足监管要求，随时可以切换操作的高效容灾切换管理工具（需要日常配置变更与管理配套）

从切换操作的可视化方面来看，web操作较为具备优势，非专业人士也能通过简单的web页面点击菜单或按钮就能快速简单实现切换操作，但是从切换效率方面来看，可能还是cli更有优势，cli不过多依赖浏览器等工具，不会出现浏览器工具兼容性问题，能够专业实现切换操作。但是cli需要非常专业的人员才能操作，不分厂商的命令较为复杂，普通人员很难进行操作。