现代 SRE 的现实
您已经构建了仪表板、设置了警报并编写了运行手册。然而，您的团队仍处于反应模式，对事件做出响应而不是预防事件。传统监控会在出现问题后告诉您。 SRE 需要在部署之前验证可靠性，而不是事后进行调查。
监控在设计上是被动的
当出现问题时，仪表板和警报会告诉您。他们无法从一开始就阻止断裂的发生。
尽管有 SLO，事件仍然发生
错误预算可以保护速度，但一次错误的部署可能会耗尽您的整个预算并迫使发布冻结。
变化速度破坏了可靠性
每次部署都存在可靠性风险。更快的运输意味着回归生产的机会更多。
尸检为时已晚
从事件中吸取教训很有价值，但损害已经造成。用户受到影响，信任受到侵蚀。
可靠性是 SRE 的责任，而不是指标
可靠性不是仪表板上的数字。这是您的系统在变化、负载和故障下的行为方式。 SRE 负责确保可靠性，但无法确保未验证的内容。
可靠性是变化下的行为
如果您的下一次部署破坏了关键工作流程，则 99.9% 的正常运行时间数字毫无意义。可靠性必须不断得到验证。
SRE 需要验证，而不仅仅是可观察性
可观察性告诉你发生了什么。验证告诉您将会发生什么。从被动监控转向主动测试。
可靠性必须经过测试，而不是假设
您在发货前测试功能。为什么不可靠？每个更改都应该针对故障场景进行验证。
可靠性验证在实践中意味着什么
可靠性验证是具体的，而不是抽象的。这意味着在特定行为投入生产之前对其进行测试。
工作流程退化检测
每次更改后验证关键用户工作流程是否正常运行。在用户之前捕获损坏的结账流程、失败的身份验证和降级的搜索。
故障模式验证
系统地测试您的系统如何处理故障。验证断路器、重试逻辑、优雅降级和超时行为。
变更影响验证
了解每次部署的爆炸半径。映射依赖关系、识别受影响的服务并验证下游行为。
跨版本的回归检测
防止回归影响生产。比较各个版本的行为，以发现性能下降、功能损坏和 API 合同违规的情况。
事件发生前信号生成
在事件发生之前获取可行的信号。了解哪些更改有风险、哪些服务正在降级以及哪些部署需要注意。
容量和扩展验证
在生产中达到预期负载水平之前验证其行为。调整基础设施规模并避免与容量相关的事件。
Zof 如何支持 SRE 团队
Zof 是一个可靠性验证层，可与您现有的堆栈一起工作。不是监控替代，而是主动测试层，可以在事件发生之前防止事件发生。
适合 CI/CD 管道
可靠性验证在每个 PR、每个合并、每个部署上自动运行。无需人工干预。在风险变更到达生产之前阻止它们的大门。
与 GitHub Actions、GitLab CI、Jenkins、CircleCI 集成与监控同时工作
Zof 不会取代 Datadog、Prometheus 或您的可观察性堆栈。它通过在部署前验证可靠性来补充它们，因此您的监视器需要发出警报的事件更少。
适用于 Datadog、Prometheus、Grafana、New Relic、PagerDuty产生可操作的信号，而不是噪音
每个验证结果都是可操作的。清晰的通过/失败状态、具体失败详细信息以及受影响代码的直接链接。没有警觉疲劳，没有误报，没有猜测。
可靠性评分、风险评估、趋势分析帮助 SRE 提高可靠性
将可靠性验证从生产转移到预生产。在 PR 中发现问题，而不是在事后分析中发现问题。使开发人员能够可靠地交付，而不会出现 SRE 瓶颈。
CI 中不到 10 分钟的反馈循环SRE 和平台团队的成果
SRE 团队使用可靠性验证得出的真实结果。
在呼叫待命团队之前发现关键问题
确信可靠性已得到验证，可放心发货
各项服务的可靠性状态一目了然
更少的页面，更少的事件，更快乐的工程师
“我们从平均每月 12 起事故减少到 1 起。我们的值班轮换现在很无聊，而这正是我们想要的。”
企业就绪
专为满足企业 SRE 团队的安全性、合规性和规模要求而构建。
安全第一的架构
- SOC 2 Type II 认证
- 零数据保留选项
- 私有云部署
- SSO/SAML 集成
合规准备就绪
- 符合 GDPR 标准
- HIPAA 就绪
- SOX 审计就绪
- 符合 ISO 27001
企业规模
- 多区域部署
- 高可用性
- 专注支持
- 定制 SLA