谁能看到什么，出了问题会怎样

一家公司永远看不到另一家

Stonen 中的每一次读取和写入，都限定在发起请求者所属的组织内。另一家公司的记录不是在界面上被过滤掉：而是被 API 拒绝，并返回专门的错误。

对贵公司业务而言，这意味着：您的客户组合、库存、价格和对话，不会出现在使用同一产品的另一家公司面前——无论是因为输入错误，还是因为误分享了链接。

这种隔离适用于所有角色，包括账户所有者。不存在能看到一切的角色。

每个人只能看到其角色允许的内容

访问权限由 35 项权限决定，组合成四种角色。贯穿所有权限的规则由产品所有者确定：广泛可读，销售操作受限。

完整的权限表——每项权限对应每种角色——是从 API 在每次请求中使用的同一份代码生成的，而不是手工编写。如果表格有误，代码也同样有误。

部分操作必须填写原因才能被接受，拒绝由服务器执行，而不是由界面执行。隐藏一个按钮不等于访问控制。

做过的事都有记录

销售决策以事件的形式记录，而不是一个会被下一次修改覆盖的字段。原始推荐、人的决定、联系方式、客户的回复和最终结果，彼此关联。

对贵公司业务而言，这可以回答诸如“为什么这批石材报给了这位客户？”、“是谁更换了这个商机的负责人？”以及“客户回复了什么，什么时候回复的？”这样的问题——即使在几个月之后，也不依赖任何人的记忆。

这是销售运营过程的历史记录。它不是正式意义上的安全审计日志：Stonen 不单独记录登录尝试，因为身份验证由一个独立的身份系统完成。

密码不存放在这里

Stonen 不保存密码。身份验证由一个独立的身份系统完成，产品只接收“此人是谁、拥有哪些权限”的确认。

实际结果是：停用某人的访问权限不需要改动 Stonen，而 Stonen 出现问题也不会泄露任何人的凭据。

这同时也是一种依赖：身份系统不可用时，任何人都无法登录。产品被设计为在缺少它时拒绝启动，而不是开一道后门。

备份与恢复

共有四层备份，频率各不相同，因为每一层防范的是不同的故障：应用错误、服务器丢失、云服务商账户丢失，以及全部丢失。

恢复流程经过实际演练，而不仅仅是写在文档里：在一次有日期记录的测试中，数据库在约 15 秒内恢复响应。

目前尚不具备：恢复到精确时间点（*point-in-time*）。现实中最坏的数据丢失情况是两次备份之间的时间窗口——约 24 小时。弥补这一点是一项尚未做出的成本决策，并已如实记录。

目前尚不具备的

列出这份清单，是因为有它和没有它做出的决定是不一样的。

• 没有服务器外部的监控。 有一个监控程序能发现“应用宕机了”并发出提醒。但它发现不了“整台服务器都挂了”，因为它本身就运行在这台服务器上。
• 没有签约的服务等级（SLA）。 可用性测量从 2026 年 9 月开始；没有历史数据，就没有在合同中承诺具体数字的依据，而没有依据的承诺比不承诺更糟。
• 没有任何安全认证或外部安全审计。
• 不具备恢复到精确时间点的能力——见上一节。
• 生产环境中只有一家公司。 组织之间的隔离经过测试，但多家公司同时使用时的表现尚未在真实规模下测量。

以上每一项在产品内部跟踪中都有明确的负责人和成本。没有一项被遗忘；其中一些正在等待投资决策。