QA 和生产环境在高可用性中的关键作用

QA 和生产环境在高可用性中的关键作用

对于管理现代应用程序的IT团队而言保持高可用性推出更新可能充满挑战。实现可靠性的关键在于将质量保证 (QA) 环境与生产环境分离。这看似微不足道，但对于发现潜在问题和增强维护工作的信心至关重要。

QA环境作为高可用性的测试场地

QA环境是生产环境的副本。它提供了一个沙箱，可以在其中对新功能、配置变更和补丁进行全面测试。除了功能测试之外，QA环境还支持流程验证、性能基准测试、负载测试和安全验证。

这些活动至关重要，可以在瓶颈、漏洞或集成问题有机会影响最终用户或损害您的环境之前，识别它们。对于分布式系统或云架构QA 环境可以帮助模拟网络延迟、数据库复制延迟以及其他操作边缘情况，这些情况如果不经过测试，可能会中断业务运营。

生产环境与最终用户体验

生产环境是最终用户依赖系统稳定运行的环境。任何计划外停机或故障都可能直接导致业务损失，从收入损失到声誉受损不等。

通过将生产环境与正在进行的开发和测试工作隔离，IT 团队可以确保运营稳定性。配置完善的生产环境应包括：冗余策略故障转移机制和监控工具在部署前已在质量保证环境中通过测试验证。

通过结构化部署流程实现平稳过渡

高可用性不仅仅意味着保持系统正常运行，它还包括使更新可预测。QA 环境可以支持结构化的部署流程，从而实现分阶段发布和蓝绿发布等多种策略。在 QA 环境中预先验证的回滚流程，能够帮助团队在出现意外问题时快速恢复。结构化的方法使更新可预测，并有助于维护客户信任。

将质量保证环境与生产环境分离的运营优势

拥有独立的质量保证 (QA) 和生产环境也有助于合规性、审计准备和跨团队协作。测试系统和生产系统之间清晰的界限有助于运维和开发团队高效协作。它还有助于为监控、故障排除和维护提供可重复的框架。灾难恢复计划。

高可用性策略中的质量保证和生产环境

质量保证 (QA) 和生产环境在确保系统平稳运行方面发挥着至关重要的作用。通过隔离环境、进行全面测试以及谨慎管理部署，IT 团队可以减少停机时间、保持高可用性，并实现无缝更新过渡。这些实践有助于确保系统在发展过程中保持可靠性和弹性。

准备好提升质量保证和生产环境的高可用性了吗？申请演示了解 SIOS 如何帮助团队自信地部署更新并保持关键系统运行。

作者：Tristan Allen，SIOS Technology公司客户体验软件工程师

經 SIOS 授權轉載

高可用性思维的危险性：关掉它，再打开它——

高可用性思维的危险性：关掉它，再打开它——

“关机重启。” 任何有过电脑故障排除经验的人都听过这条建议。它臭名昭著，是最常见的技术解决方案，而且似乎能让每个人都变成IT故障排除高手。问题在于，它从来都不是真正的解决方案；它只是碰巧能解决大多数问题而已。通过关机重启，我们能迅速恢复运行，但却永远无法真正找到问题的根源。

为什么在高可用性系统中“关闭再重新启动”存在风险

此外，在高可用性的世界中，“关闭它”可能会造成巨大的问题。即使是几分钟的……停机时间对于那些必须确保关键基础设施持续运行的公司来说，这可能是一个重大问题。正因如此，作为SIOS的技术支持人员，我们很少给出这条臭名昭著的技术建议，但我们确实有自己的一套应对方法。

许多致电SIOS寻求技术支持的人都遇到了以下问题：Windows Data Keeper如果遇到镜像问题，系统会提示运行“cleanupmirror”命令。在特定情况下，该命令可以快速解决重大问题。它实际上会彻底删除镜像配置及其所有残留数据，以便我们可以重新创建镜像，摆脱之前存在的所有问题。请注意，此命令不会删除任何数据，只会删除系统间的镜像复制。

该命令无需停机，但意味着在镜像完成重新同步之前，系统可用性会受到影响。这是我们在技术支持中常用的故障排除步骤之一，但就像“重启”一样，它有时会掩盖更严重的潜在问题，而且有时也可能矫枉过正。

今天，我想谈谈这样一个案例：运行 cleanupmirror 命令虽然帮助客户解决了燃眉之急，但差点让我们忽略了一个相当严重的问题，这个问题可能会影响到很多客户，不过这个问题其实有一个非常简单的解决方法。

迁移过程中实际遇到的 DataKeeper 镜像问题

支持团队加入时，客户已经排查故障相当长一段时间了，他们开始感到恐慌。他们正在进行最后的尝试。切换在进行迁移测试时，DataKeeper镜像开始出现问题。此时，他们的关键基础设施瘫痪，他们担心这会影响业务运营。情况十分危急，但幸运的是，我们的支持工程师表现出色。他们权衡了压力、时间紧迫和寻找有效解决方案的迫切需求，运行了久经考验的“cleanupmirror”命令，随后重建了镜像并使其恢复正常运行。他们帮助客户摆脱了困境，一切又恢复了正常。值得庆幸的是，他们还要求客户发送日志，以“确保万无一失”。

此案的日志有些令人困惑。日志显示：某个卷册已调整大小但客户声称他们在通话中没有进行任何调整大小的操作。有时客户会遗漏重要信息，所以我们一开始以为他们可能在通话中漏掉了这个细节，但这次调整大小的操作实在令人费解。大小的变化非常小，而且所有卷都在第一次切换时同时发生了变化。客户不可能在第一次切换时，一次性减少不到 1GB 的空间来调整其 TB 级大容量硬盘的大小，这显然不合逻辑，所以我们进行了更深入的调查。结果发现，目标硬盘的容量略大于源硬盘，而我们的产品在处理容量不匹配的硬盘时存在问题。

找出根本原因可防止再次停机

一旦我们弄清这一点，就意识到解决这个问题只需要继续镜像即可。这是一个常见、快捷且简单的操作，只需几秒钟就能彻底修复问题。无需耗时数天重新同步，即可恢复高可用性。此外，一旦我们发现这个问题，在下一个产品版本中实现修复也非常快捷方便。

原来，客户的迁移场景比较特殊，由于目标系统的大小无法完全匹配，他们不得不将目标系统的大小略微扩大一些。他们还有几个系统需要迁移，如果我们只停留在“清理镜像”阶段，他们每次都会遇到这个问题。由于我们找到了根本原因，因此能够为他们提供一个快速简便的临时解决方案，以及一个更快捷的预防措施，让他们在执行首次切换之前就能采取。我们还发布了解决方案，以便下一个遇到类似问题的客户能够在几分钟内解决。

为什么根本原因分析在高可用性中至关重要

那么，“关机重启”到底有什么大问题呢？它掩盖了问题的根本原因。这是否意味着你永远都不应该使用它呢？它仍然是最好的技术建议之一。很多时候，你根本不需要知道问题的根本原因，而关机重启就能帮你快速摆脱困境。

对于IT专业人员来说，重要的是，在无需紧急处理问题且有时间先进行调查的情况下，应该这样做。如果时间紧迫，则应该稍后查看日志，尝试找出问题所在。

所以，请随意开关机。做个几分钟就解决问题的魔术师，让所有人都好奇你是怎么做到的。但是……偶尔……也应该花点时间想想，你为什么要开关机……并考虑一下，有没有更简单的解决方法。

要了解更多关于 SIOS DataKeeper 和高可用性解决方案如何帮助您避免此类隐藏问题的信息，申请演示今天我们团队的发言。

作者：Carter Chandler，SIOS Technology公司客户体验助理、软件工程师

经许可转载SIOS

SIOS 合作伙伴关系

SIOS 合作伙伴关系

SIOS 合作伙伴关系在实现高可用性、云弹性和集成基础设施解决方案方面发挥关键作用。

在本期播客中Harry 和 Kelly 将带领听众深入了解 SIOS 的合作伙伴生态系统，从与微软、AWS 和谷歌云的云联盟，到与 Exabeam、Milestone 和 Cimcor 等战略性独立软件开发商 (ISV) 的卓有成效的合作。他们探讨了 SIOS 如何接纳和支持新合作伙伴，分享了多年来构建成功集成方案的经验教训，并重点介绍了合作伙伴驱动的创新未来的发展方向——包括人工智能、混合云和边缘计算领域的机遇。

播客最后提供了一些实用建议和成功案例，展示了强大的技术合作伙伴关系对业务的影响。

经许可转载SIOS

顾客常见误解

顾客常见误解

高可用性 (HA) 和灾难恢复 (DR) 经常被误解。

请收听本播客的完整对话。Greg Tucker 将揭开客户对高可用性/灾难恢复 (HA/DR) 的常见误解——从高估云服务提供商的承诺到误判 SQL Server Always On 可用性组等解决方案的复杂性。Greg 分享了一些可以避免的错误的真实案例，并解释了如何避免这些错误。SIOS帮助客户重新思考他们的 HA/DR 假设，并为希望做出明智、有弹性的基础设施决策的 IT 领导者提供实用建议。

经许可转载SIOS

数据保管员

数据保管员

SIOS 数据保管器提供快速、可靠的块级复制，实现高可用性 (HA)，而无需依赖共享存储。

在此播客Joey D’Antoni深入剖析了DataKeeper如何帮助企业解决在构建高可用性架构时遇到的实际问题。他将DataKeeper与传统的基于SAN的集群进行了比较，探讨了云部署的关键考量因素，并解释了DataKeeper如何实现弹性混合云和多云架构。此外，他还分享了关于SQL Server存储复制和高可用性发展趋势的见解。

对于正在进行高可用性战略现代化改造的团队来说，这是必听之作。

经许可转载SIOS