| 3月 30, 2026 |
主动-主动 vs. 主动-被动 |
||||||||||||||||||
| 3月 24, 2026 |
博通/VMware：是时候将高可用性与虚拟机管理程序解耦了 |
| 特征 | VMware HA（vSphere Foundation） |
SIOS LifeKeeper 和 DataKeeper |
| 故障转移触发器 | 仅限主机/硬件故障。 | 应用程序、操作系统、存储或网络故障。 |
| 应用智能 | 没有。这是一次“黑匣子”式的重启。 | SAP、SQL、Oracle 等系统的恢复工具包。 |
| 云灵活性 | 需要特定的 VMware 云堆栈。 | 原生支持 AWS、Azure、GCP 或混合环境。 |
| 存储模型 | 依赖于 vSAN 或共享存储。 | 通过本地 NVMe/SSD 构建无 SAN 集群。 |
| 许可 | 复杂、基于核心、捆绑包较多。 | 可预测、便携、以应用为中心。您可以选择永久使用权或订阅制。 |
利用应用级高可用性，重获基础设施自由
SIOS 让您可以灵活地按照自己的方式保持高可用性，同时评估您与博通的长期合作关系。
选择 SIOS，您即可自由地在不同平台之间迁移工作负载。VMware，Nutanix或者，无需重写脚本或重新培训团队即可使用公有云。正常运行时间取决于应用程序环境的健康状况，而不仅仅是服务器的电源指示灯。
如果您感觉即将续约陷入僵局，那么是时候将高可用性从虚拟机管理程序转移到应用程序层了。
立即申请演示了解 SIOS 如何在 VMware、云和混合环境中提供应用级高可用性。
作者：Margaret Hoagland，SIOS全球销售和市场营销副总裁
经许可转载SIOS
如何提高技术支持中的客户满意度
如何提高技术支持中的客户满意度
我们的客户遍布全球。我们说着不同的语言，身处不同的时区，分布在不同的国家。但在技术支持方面，我们有很多共同之处。我们都希望在遇到问题需要帮助时获得最佳支持。那么，我们究竟想要并期待获得最佳支持，这究竟意味着什么呢？支持实际上是指IT团队吗？
6 客户对技术支持团队的期望
以下是我们的客户告诉我们他们对技术支持团队的期望。
倾听客户的声音
客户（和其他人一样）都希望被倾听。与客户沟通时，重要的是让客户描述问题。作为支持工程师，请做好笔记，认真倾听客户的描述，并提出后续问题以收集重要信息。不要在客户说话时打断他们。为了确认您理解了客户的陈述，请总结客户所说内容。概括行动方案，确保每个人都理解一致。不要在客户描述问题之前就自以为知道问题所在。
与真人交谈
顾客仍然更喜欢与“真人”交谈而不是自动语音/人工智能/聊天机器人。客户喜欢直接与了解产品的客服人员对话，而不是听从脚本。没有什么比打电话寻求帮助时，却不得不经历多个自动化流程才能联系到“真人”更令人沮丧的了。很多时候，你最终会原地打转，回到最初的问题！宝贵的时间可能就这样白白浪费在试图联系到“真人”客服人员上。 顾客来电寻求帮助我们强烈建议您通过视频会议与支持团队实时沟通问题。一图胜千言！根据我们的经验，如果无法提供直观的视觉信息，也无法让客户实时提问，那么解决问题所需的时间将会大大延长。
全天候24小时服务
我们的客户遍布全球，他们希望随时联系客服。我们提供每周7天、每天24小时全天候支持。为了满足这一需求，我们在全球各地设有多个团队，全天候24小时提供服务。客户需要我们的时候，我们随时待命。我们制定了相关流程，以便在我们的团队成员需要紧急协助时，及时升级处理案例。关键停机问题这会影响客户的业务。我们的客户使用我们的高可用性和灾难恢复软件，而我们的技术支持团队随时准备提供帮助，从而强化了这一目标。
经验丰富的支持工程师
客户没有时间跟无法提供帮助、需要把电话转接给其他人的客服人员通话。客户希望直接与能够解答他们疑问、解决问题的支持工程师沟通。SIOS我们始终致力于确保客户能够快速联系到我们经验丰富的技术支持团队成员，以便尽快解决问题。根据我们的客户调查，客户对我们的技术支持团队非常满意！我们的支持团队平均拥有16年的支持经验；这种专业技能使我们能够快速有效地解决各种问题。问题能够迅速得到解决，通常无需升级案件。转至另一组客户。客户很欣赏那些经验丰富的员工，他们可以通过视频会议提供基于多年经验的实时帮助。
保持透明
客户重视透明度，他们想了解真相。不要做出无法兑现的承诺。务必确保客户明白您将采取哪些措施来帮助他们解决问题，以及您何时会再次与他们联系。在推进过程中，向客户解释需要执行的步骤，并确保在执行任何步骤之前都已获得客户的批准。许多客户在对其系统进行更改之前都需要获得预先批准。系统为了保持透明度，及时向客户提供支持流程的最新进展至关重要。即使你的更新内容只是“我们仍在分析日志”，也要告知客户，让他们了解最新情况。不要说他们想听的话，要告诉他们真相。
客户调查
对于客户提交的每一个技术支持案例，案例结束后我们都会向客户发送一份调查问卷。这让客户有机会提供反馈，以便我们的团队能够持续改进产品、文档和支持服务。我们的支持团队每周至少查看一次客户填写的调查问卷，并回复客户的疑问、想法和改进建议，告知他们我们针对这些反馈采取了哪些措施。客户经常感谢我们快速解决他们的问题，并感谢我们认真对待他们在案例结束后留下的反馈，展现了我们对他们成功的承诺。
客户对全天候高可用性/灾难恢复技术支持团队的期望
客户联系技术支持HA/DR产品他们希望听到的是真人而非机器人的声音。他们期待与经验丰富的客服人员沟通，这些客服人员不仅能够解决他们的问题，而且在整个过程中都保持透明。通过提供全天候24小时的人工服务，我们向客户表明，无论何时何地，只要他们需要帮助，我们都会随时待命。如今的技术支持不仅仅是解决工单，更重要的是建立信任、倾听客户的需求，并在客户需要帮助时始终保持可靠和诚实。
正在寻找了解高可用性/灾难恢复 (HA/DR) 的技术支持团队？安排时间与SIOS HA专家会面了解我们如何实现高可用性、自动恢复和可靠的集群部署。
作者：桑迪·汉密尔顿SIOS产品支持工程总监
经许可转载SIOS
保障建筑物安全：维护和安防系统的高可用性
保障建筑物安全：维护和安防系统的高可用性
在本集中TFiR：我们来谈谈，主持人 Swapnil Bhartiya 接受采访戴夫·伯明翰SIOS Technology 的客户成功总监谈到了高可用性和弹性为何对企业至关重要。楼宇维护和安保系统伯明翰解释了这些系统与其他楼宇技术的区别，以及它们之间经常存在的交互方式，并阐述了不间断运行对于保障居住者安全和楼宇功能的重要性。对话探讨了组织如何平衡安全性和可访问性，人工智能、机器学习和物联网等新兴技术在提升可靠性方面的作用，以及通过冗余、监控和风险规划来确保系统可用性的最佳实践。
作者：Beth Winkowski，SIOS Technology Corp. 公共关系部
经许可转载SIOS
通过模块化和抽象化设计高可用性
通过模块化和抽象化设计高可用性
迄今为止，本系列文章探讨了技术设计与修辞之间的相似之处。技术方案的“修辞”，即传达意义和目的的策略，是通过设计模式和概念来呈现的。设计模式和概念作为概念基础而存在，其意义在实施过程中转化为可应用的形式。
如前所述，这种连续性和完整性概念基础确保解决方案始终保持符合维护、改进和长期可靠性标准的要求至关重要。外部影响解决方案设计的因素挑战旨在维护解决方案设计中提出的概念基础的目标。这些外部因素可能与既定原则相冲突，因此，解决方案中使用的工具、应用程序和平台必须经过慎重选择。
在本博客系列的第三部分也是最后一部分中，我们将探讨模块化和抽象化作为一种设定界限的手段，以确保范围广泛的项目能够继续从结构良好、论证合理的设计中获益。
高可用性设计原则：为什么模块化和抽象化至关重要
在探讨模块化和抽象化这两种策略之前，首先需要理解为什么要实施它们。我们可以用一个类比来说明：演讲者为了说服听众接受自己的方案，首先需要阐述几个基本要点。这样，他们就能逐一提出并论证论点的各个支柱。
演讲者首先必须建立“A蕴含B”和“C蕴含D”的基础，在此基础上才能构建“B和D蕴含E”的论证。这种策略确保了“A蕴含B”的推理不会与“C蕴含D”这一独立论点相互干扰，从而避免削弱后者。这种策略之所以被广泛运用，是因为它允许演讲者论证的每个组成部分独立存在。即使“C蕴含D”的论证存在缺陷，也可以通过其他方式加以修正，而“A蕴含B”的论证仍然有效。
这种结构的原因与技术系统采用去中心化的原因相同——销售点系统的问题可以单独解决，而无需将修复工作扩展到数据库、API、网络架构等等。上述策略当然是指模块化和抽象的概念。
高可用性架构中的模块化
首先，谈到模块化，它指的是用自包含的组件构建系统。从修辞意义上讲，“A蕴含B”和“C蕴含D”这两个论证仅仅是推理模块，它们被组合成一个完整的论证。
更具体地说，模块化组件（例如前面例子中的销售点系统）允许在问题产生的模块内部完全解决问题。解决方案中的每个模块都像一个构建块，单个构建块中的问题无需拆卸整个解决方案即可解决。
抽象化作为可扩展基础设施设计的一种策略
与模块化密切相关的是“抽象”。抽象是指确保整体解决方案的设计独立于构成该整体解决方案的各个模块的设计，并且与这些模块的设计无关。
此外，抽象作为一种设计策略，其核心在于每个模块都是独立且与其他模块的设计无关的。当解决方案采用抽象元素时，这些元素可以被重用并应用于各种用例，从而在整个项目中加深理解。
设计“不碍事”的高可用性
当设计采用模块化组件时，需要划定边界。这些边界确保每个模块都能“互不干扰”。当组件被抽象化后，每个模块的内容就更容易理解。
反过来，这些边界构成了一种结构，通过这种结构可以理解设计；而边界内的抽象则为理解用例的基础提供了切入点。模块化和抽象所提供的结构，与修辞在构建理解目的的框架中所起的作用相呼应。
利用模块化高可用性解决方案管理复杂的网络架构
随着技术解决方案的不断开发以应对日益复杂的问题，对这些解决方案设计中稳固框架的需求也日益增长。网络架构通常是众多本身就十分复杂的解决方案的最终产物，它完美地诠释了日益复杂的问题以及对稳固设计框架日益增长的需求。此外，网络架构往往面临着持续增长的挑战，因为它必须整合为实现业务目标而不断扩展的庞大系统网络。
在此基础上，解决方案架构还必须采用以下解决方案：高可用性和/或灾难恢复这会造成设计冲突的发生，但可以通过模块化和抽象化的策略轻松缓解。
在SIOS高可用性软件中应用模块化和抽象化
好处高可用性软件无需繁琐的设计和临时拼凑的解决方案，即可实现高可用性。SIOS LifeKeeper 就是一个符合设计规范的高可用性工具示例，其运行原理能够与使用环境无缝集成。
LifeKeeper 采用模块化设计，不会对受 LifeKeeper 保护的系统之外的系统提出任何要求。LifeKeeper 还有助于将基础设施组件抽象成易于管理的小单元——协同工作以确保可用性的系统被分组到一个“集群”中。
通过这种抽象，环境的逻辑依然清晰——理解一个集群的构成是理解所有集群的基础。设计的各个层级可以根据其用途进行理解；无需对不同实现方式的差异进行特殊标注和考量。由于各个集群独立于其他集群或外部解决方案组件运行，因此可以划定一个边界，将每一层级的设计元素包含在其中，从而避免与其他基础设施层级发生冲突。
利用 SIOS 保护套件构建长期弹性基础设施
就像任何软件或工具一样，SIOS 保护套件SIOS LifeKeeper 和/或 SIOS DataKeeper 会影响其使用环境的设计。虽然这些模式的引入源于 LifeKeeper 和 DataKeeper 的保护环境，但 SIOS LifeKeeper 和 SIOS DataKeeper 精心挑选了所使用的模式，以确保这些模式能够实现整个解决方案的抽象和模块化。由于 LifeKeeper 和 DataKeeper 实现了分层抽象，这些实用程序的引入有助于与 IT 基础架构集成，从而保持解决方案设计的一致性。
由于采用了特定的设计模式，由 SIOS Protection Suite（LifeKeeper 和/或 DataKeeper）保护的集群构成了一个抽象且模块化的元素，能够无缝集成到现有的设计和解决方案中。LifeKeeper 和 DataKeeper 的功能远不止简化单个系统或各个集群的管理；它们还与部署过程中遵循的原则相契合。
借助 SIOS Protection Suite，基础设施的创建变得更加简单高效。该套件提供了一种简便的方法来理解系统在设计中的作用，同时还提供了一种简便的方法来实施高可用性和灾难恢复。管理员可以将 LifeKeeper 和 DataKeeper 作为工具，在未来数年内更好地理解、操作和改进解决方案。
了解高可用性如何在不增加复杂性的情况下支持您的基础架构设计。立即申请演示！
作者：Philip Merry，SIOS 的客户体验软件工程师
经许可转载SIOS