生产环境中发生存储故障如何决策，是进行本地解决故障？还是立马进行容灾切换？

这个需要具体问题具体分析，一般生产环境故障以本地故障解决为主（同城双活例外）目的在于能快速恢复业务功能，容灾切换需要按照业务连续性计划进行领导小组决策，而不是随便切换的，再说灾备环境容灾不一定所有的系统都有涉及即使有容灾也还得看灾备的级别（数据级、应用级）及RTO和RPO目标；一但生产环境故障还主要以快速恢复业务为主，保险公司随着互联网应用系统增加，对于业务的连续性和可用性要求也越来越高，生产中心需要做好HA设计，有能力的同时也需要考虑两地三中心同城双活异地灾备（或多城多活）设计规划，从而提高业务的可用性和连续性。

这个问题属于业务连续性管理范畴，可以从三个方面来考虑：

1、管理规范方面。按照业务连续性管理规范，应该建立应急管理领导小组和制定各类业务系统、关键设备故障恢复应急预案。当故障发生时，由应急管理领导小组根据故障实际情况，按应急预案下达灾难恢复指令并实施。因此，一定要按照业务连续性管理相关的国家标准和监管指引提前建立并不断完善应急预案及相关制度流程，开展常态化演练持续提升应急能力。

2、应急处置方面。目前业界有十分成熟的业务连续性方法论可供参考，也有许多领先厂商可以提供咨询服务。针对应急处置方面来说，一般涉及损害评估、事件定级、处置建议、处置决策、灾难宣告及切换恢复等环节。应该按照应急管理规范和流程，提前制定与各类灾难相应的应急预案。

3、存储容灾方面。发生故障时存储如何应急，涉及容灾技术架构、应急处置能力、存储承载的业务影响范围等诸多方面内容。具体到本话题，判断选择本地修复还是容灾切换，RTO是其最重要的技术指标，即选择两套应急方案中恢复业务系统所需时间较短者。需要注意的是，此RTO是指恢复业务系统的所需时间，而不仅是恢复存储功能时间。

就个人所见，大部分都是本地解决，暂时还没遇到过特殊情况。
就国内情况来说，目前虽然很多企业都做灾备双活，但都不是随随便便就能切，每次切换演练都是场面十足，很多人盯着，带故障切换更是异常慎重了。
PS： 这里说的是灾备切换，不含本地双存储的情况。

这个要根据业务影响分析报告中如何定义的，本次故障影响的范围，受影响业务系统重要程度，停机最大容忍时间等多个因素共同决定的。所以每个行业每个用户实际情况都不一样。
类似如下图

1、本地存储故障，是否已经影响业务，影响的时间是多少？ 根据业务的重要程度，正常容灾切换的时间大概为30分钟，如果业务比较重要，并且在30分钟内已经无法确认故障可恢复，那就要决策切换同城容灾。当然前提是容灾环境必须可用。
2、如果存储只是发生故障，但是并未影响业务，在线维护风险可控，数据备份，可以在维护时间点本地解决故障。但是如果维护可能导致数据丢失的风险，并且是涉及核心账务类数据库，也可以考虑切换同城，维护完成后，再切回。

这个问题与灾备体系、平时灾备演练效果、业务运行的故障时长、业务等级、RPO/RTO等都有关系，不能准确地决策，进行本地 本地解决故障还是立马进行容灾切换 ，如果灾备切换比较成熟，灾备体系建设比较好，当本地存储故障短时间内无法解决时，就可以进行快速切换，恢复业务。当然如果灾备不经常使用，没有把握做切换，也没法进行决策。
这个具体问题具体分析。
我们这边是双活架构，有一次存储写I/O很慢，体现在数据库写操作上，业务交易收到了很大影响，当时直接关闭一个数据中心存储，业务立马恢复，前后只用了10分钟。我讲这个例子，主要是在处理问题时，让决策层做选择时，要提供决策的素材，让决策层有足够的把握去决策。

有没有业务影响，就是线上业务，如果是单纯的存储冷备那种可以先沟通预先处理故障，有线上业务影响就切换，先恢复业务后处理故障，主要还是看你们内部的一个优先级

你说的这个问题比较复杂，如果存储发生故障影响业务运行了，而且在一定时间内不能解决估计需要切换到灾备了；一般在生产中心存储会有同城灾备的，同城要么是同步复制要么是双活，而且在同城也会有相应主机连接存储，如果在当时环境比较严重可以果断切到同城；像你说的这种情况极少

根据应用的重要性、业务等级和系统架构来判断，决策依赖条件较多。一般来说不建议立即进行容灾切换，应根据预案进行故障原因判断，因为如果进行存储容灾切换，将会涉及诸多业务应用，恢复时间较长。如果有本地冗余存储高可用，可以立即进行本地切换。但是如果判断可能长时间无法识别原因或需要进行本地恢复时间较长，则建议果断决策进行容灾切换。