如何处理SaaS停机：分步指南
为…做好准备 SaaS停机，应制定一份书面计划，其中包含步骤、立即事件响应和清晰的沟通。
本文概述了需要考虑的关于停机对业务和客户信任的影响的步骤，并结合了策略和案例研究。
概念概览
-
类别： 事件管理，SaaS可靠性
-
适用于： B2B SaaS，数字提供商，SaaS平台
-
主要目的：
最大限度地减少停机时间并保护客户信任
-
相关概念： 服务水平协议 (SLA), 冗余, 客户留存， 根本原因分析 (RCA)
-
增长阶段：
规模化、PMF之后、企业级就绪
建立全面的事件响应计划
诸如 事件响应计划 是时间管理策略的关键部分，应根据系统的进展和任何过去的事件进行彻底更新和修订。
- 定义角色和职责： 为您的团队成员分配明确的角色，例如事件指挥官（负责指挥响应的人员）、技术负责人（负责故障排除和解决的人员）以及沟通负责人（负责与客户沟通的人员）。这有助于建立明确的参数，并在紧急情况发生时减轻模糊性。
示例：
| 角色 | 职责 |
| 事件指挥官 | 协调响应，做出决策，分配资源，与利益相关者沟通。 |
| 技术主管 | 排除并解决技术问题，必要时上报。 |
| 沟通主管 | 管理内部和外部沟通，更新状态页面，起草客户通知，并回复咨询。 |
| 客户支持主管 | 处理客户咨询和投诉，提供更新，并将问题上报给相关团队成员。 |
| 领域专家 | 提供关于应用程序或基础设施特定领域的专业知识和专长。 |
概述升级程序。 建立明确的升级路径，确保问题由合适的人员及时妥善解决。了解何时将事件上报给更高级别的经理或外部支持团队。
创建沟通模板。 考虑为涉及事件的各种情况（例如，服务降级、部分中断、完全中断）创建模板。这些模板应包含相关详细信息，例如受影响的服务、解决问题的预计时间以及正在采取的补救措施。务必根据不同受众（例如客户、公司利益相关者或合作伙伴公司）适当地修改这些模板。
由...制定的事件响应计划 Slack 阐述了定义角色、建立沟通渠道和准备状态更新模板的流程。
免费SaaS停机响应清单
借助这份事件响应与恢复清单，快速应对SaaS故障。
-
针对监控、冗余和故障转移的事前准备检查
-
分步响应序列：确认、更新、解决、补偿
-
事故后根本原因分析和纠正措施清单
-
填写字段以记录严重性、停机时间及受影响客户
设置实时监控和警报
应对停机的首要防御是 预防性监控。此类监控有助于及时发现问题，并可能影响其发展成全面中断。
当 选择工具包，有必要考虑您正在运行的技术基础设施以及正在开发的应用程序。同时考虑基础设施监控（服务器、数据库、网络）和应用程序性能监控（APM）这两个类别。
设置阈值 对于重要的指标，例如响应时间、错误率、CPU 使用率和内存使用率。此外，创建 警报 每当这些阈值被突破时，通知您的团队。最好根据团队的偏好，通过 email、SMS 或 Slack 发送警报。
这种做法在 SaaS 公司中很流行，其中许多公司使用 Datadog 以快速检测并解决事件。
免费SaaS停机响应清单
借助这份事件响应与恢复清单，快速应对SaaS故障。
-
针对监控、冗余和故障转移的事前准备检查
-
分步响应序列：确认、更新、解决、补偿
-
事故后根本原因分析和纠正措施清单
-
填写字段以记录严重性、停机时间及受影响客户
实施冗余和故障转移机制
SaaS 冗余 指在您的基础设施中拥有应用程序、服务器等多个实例，以防其中一个发生故障。这种方法有助于缩短服务恢复时间。
- 为了提高基础设施的性能和可靠性，您可以考虑实施一些关键的冗余措施。其中一种方法是部署两个或更多网络服务器，并将它们部署在不同区域，通过使用 地理冗余。该系统允许负载分配，这与网站的持续运行有关，即使某个服务器发生故障也能保证运行。
- 另一个选择是 复制您的数据库 到多个服务器或可用区，通过数据库复制实现。此功能旨在支持数据保护和访问能力。
- 如果您正在使用 云基础设施，有几个 内置冗余功能 可以利用，例如多个可用区或区域。
Netflix 在AWS中通过多个可用区运行，此配置与其实现高可用性和故障恢复的目标相关。
免费SaaS停机响应清单
借助这份事件响应与恢复清单，快速应对SaaS故障。
-
针对监控、冗余和故障转移的事前准备检查
-
分步响应序列：确认、更新、解决、补偿
-
事故后根本原因分析和纠正措施清单
-
填写字段以记录严重性、停机时间及受影响客户
确认停机
透明度 在停机事件期间非常重要。在检测到服务中断后及时公开通知，这与确认问题并启动解决流程相关。这种沟通可能会影响信任的建立和预期的调整。
选择沟通渠道：
- 在您的状态页面中包含有关中断、受影响服务、解决问题的预计时间以及任何已知变通方案的信息。
- 利用推特和领英等社交媒体平台来扩大您的受众，并简要概述情况。
- 向受影响的人发送电子邮件，提供详细解释和最新信息。
保持诚实和透明。 准确评估问题范围并做出可兑现的承诺至关重要。向客户提供有关停机原因的信息。记录当前正在采取的解决措施。
提供时间表。 估算解决问题所需的时间 (ETR) 并提供一个范围，即使是大致的。随后，用最新信息再次更新ETR。在没有充分理由的情况下设定期望可能会导致负面情绪反应。
模板：
| “我们正在经历影响[service/feature]的服务中断。我们的团队正在积极解决问题，并将每隔[time interval, e.g., 30 minutes]提供更新，直到问题解决。对于由此可能造成的不便，我们深表歉意，并感谢您的耐心等待。” |
免费SaaS停机响应清单
借助这份事件响应与恢复清单，快速应对SaaS故障。
-
针对监控、冗余和故障转移的事前准备检查
-
分步响应序列：确认、更新、解决、补偿
-
事故后根本原因分析和纠正措施清单
-
填写字段以记录严重性、停机时间及受影响客户
定期提供更新
一个需要考虑的重要事项是 让您的客户了解情况 事件解决的状态。还需要提供解决完成所需时间的预估，并以简单的方式说明停机原因。
Facebook 2021年宕机事件 表明为何状态页面必须部署在独立于产品的独立基础设施上——他们的页面随着服务一同宕机，迫使他们将更新发布到第三方平台。
免费SaaS停机响应清单
借助这份事件响应与恢复清单，快速应对SaaS故障。
-
针对监控、冗余和故障转移的事前准备检查
-
分步响应序列：确认、更新、解决、补偿
-
事故后根本原因分析和纠正措施清单
-
填写字段以记录严重性、停机时间及受影响客户
提供道歉和赔偿
致歉 并说明延期的理由以及由此产生的情况。通常不提供辩解，也不将责任归咎于其他方。
提供 根据服务中断的范围、持续时间和严重性，向客户提供服务抵免或折扣。考虑提供其他福利，例如免费试用或以折扣价获得高级功能。请考虑客户的具体情况并适当地进行补偿。
在2019年， Salesforce 修改了其基于服务水平协议（SLA）的信用政策，从而为客户因服务不可用而损失的时间提供信用补偿。
免费SaaS停机响应清单
借助这份事件响应与恢复清单，快速应对SaaS故障。
-
针对监控、冗余和故障转移的事前准备检查
-
分步响应序列：确认、更新、解决、补偿
-
事故后根本原因分析和纠正措施清单
-
填写字段以记录严重性、停机时间及受影响客户
分析、学习和改进
产品或服务问题的发生可能导致 审查 对相关流程及其效率的影响。通过分解事件、找出根本原因，并将这些洞察应用于未来以预防类似情况的发生，是充分利用此类分析的关键。
一次彻底的 根本原因分析 (RCA) 包括创建关键事件时间表，解释事件影响，找出根本原因并提出纠正措施。此过程与基本问题的识别和解决方案的选择相关联。
开始 收集日志、指标和其他相关数据 从您的监控工具、服务器和应用程序中获取。与参与事件解决过程的人员交谈，听取他们的评论和见解。
对...的评估 客户反馈 和 支持工单 从网站无法访问之时起即为一个选项。根据与中断事件相关的时间顺序整理所提供的信息。
利用这些信息创建一份 事件时间表。利用这些数据来识别模式或任何异常活动，这可能有助于找到根本原因。
不要立即下结论。考虑所有可能导致中断的原因，无论是技术、人为、机械还是外部因素。
记录您的发现。 准备一份详细的RCA报告，内容包括：
- 事件时间线
- 影响评估
- 根本原因
- 促成因素
- 建议的纠正措施
模板：
| 根本原因分析报告
事件： [服务/功能中断] 日期： [中断日期] 事件时间线：
影响评估：
根本原因：
促成因素：
建议的纠正措施：
|
实施纠正措施。 根据您的RCA结果，采取措施以避免未来的停机时间。这可以包括修补软件错误、更新配置、增加监控和警报，或为您的团队提供更多培训。
传达经验教训。 将您的根本原因分析结果纳入您的纠正措施以及与团队和客户的行动中。这可以被视为致力于改进的标志，并可能影响信任度。
- 内部： 向您的团队展示根本原因分析报告并讨论关键要点。开放的沟通和反馈有助于支持迭代改进的条件。传达有关最佳实践和事件经验教训的信息，以防止类似事件再次发生。
- 外部： 在您的状态页面或博客中添加一个部分，分享RCA（根本原因分析）的主要经验教训。向公众解释停机原因并让他们了解解决方案至关重要。通过承认客户的耐心来赢得一些赞誉。
有关SaaS停机以及如何处理的更多信息，您可以参考以下资源： 如何撰写SLA（服务水平协议）。
的经验 GitHub 表明从错误中学习的重要性。作为对 重大停机 2018年，GitHub重新配置了其故障转移工具，以防止跨区域推广，并重建了其状态报告系统，这些变化被认为会影响类似事件发生的可能性。
结论
停机时间管理 在SaaS应用程序运行期间，这是一个持续不断的过程，需要主动、迅速且永不终止。实施 监控, 备份, 事件响应计划，以及 通信 方法可以影响停机时间的影响和客户信任水平。
SaaS 应用程序停机事件可能提供 信息 用于系统评估和调整，这可能会影响应用程序的稳定性和可靠性。
准备好开始了吗？
我们感同身受。让我们分享我们 19 年的经验，助您实现全球梦想。
常见问题解答
-
当项目遇到问题时，技术问题通常是主要因素。人为错误或外部影响（如网络攻击）等因素也需考虑在内。
-
防范停机时间的最佳方法是预防，这可以通过实施冗余、进行定期维护和执行全面测试来实现。此外，还应采用实时监控以及早发现并解决问题。
-
第一步是承认存在问题，然后就情况与客户公开沟通，告知问题何时能解决的具体时间。通常会提供道歉，在发生重大中断的情况下，可能会评估对用户的赔偿。
-
拥有一个事件响应计划非常重要，该计划应包括角色和职责、上报流程和沟通模板，以确保快速有序的响应。
-
事件发生后，应进行彻底的根本原因分析（RCA）。这包括识别事件的根本原因、采取纠正措施，并与团队其他成员分享经验教训，以避免重蹈覆辙。
简体中文 
English 
Español 
Português 
Português do Brasil 
Français 
Italiano 
Deutsch 
Nederlands 
Polski 
Română 
Українська 
日本語 
한국어