我在一家小型开发公司工作，他们越来越多地被要求根据特定配置为我们的产品制定正式的 SLA。
从开发的角度来说，我对此感到满意，但是，如果从硬件/平台的角度来看特定目标不切实际，那么我说从软件角度来说我们会满足这些目标是没有意义的——客户只关心整体系统的可用性。
从平台角度来看，我应该关注什么？什么样的指标和水平？
此外，还存在哪些陷阱（例如从软件角度来看，我永远不会承诺修复时间 - 我不知道是否必须重写整个产品来纠正某些问题，因此说我们可以在 5 天内修复它几乎是不可能的 - 从硬件/操作系统/平台的角度来看，我应该避免承诺什么）？
答案1
我在这个领域有丰富的经验；我为几家财富 5 强公司做了很多工作，这些公司像 ISP 一样运营他们的数据中心，为需要托管和支持服务的各个公司部门提供服务。
它们通常有两个指标，称为 SLA（服务水平协议）和 OLA（操作水平协议）。
SLA 是通过所使用的硬件类型来满足的。在谈论 SLA 时，我们使用级别来描述它们。SLA-1 表示零停机时间，SLA-2 表示停机时间最多为 1 小时，SLA-3 表示停机时间 8 小时，等等……SLA 是通过使用冗余设备来满足的。在一家公司，我们使用大量 Cisco 来实现高可用性（Cisco CSM 和 GSS 设备）。在谈论 SLA 级别时，我们通常谈论 HA（高可用性）和 DR（灾难恢复）。在公司拥有多个数据中心的情况下，HA 组件通常是每个数据中心的属性，而 DR 是跨数据中心的属性；两者都以 RPO（恢复点目标）和 RTO（恢复时间目标）来衡量，以表示 SLA 级别。
从根本上讲，OLA 指的是某人（人类）对需要人工干预/纠正措施的事件的响应速度。OLA 通常也以响应时间来衡量；它们使用相同的 RTO/RPO 目标。我咨询过的一家公司使用 6 个级别作为其 OLA 指标。以下前 3 个级别就是一个例子：
OLA-1：RTO 0 < 2 小时 OLA-2：RTO >= 2 & <= 4 小时 OLA-3：如果不是数据中心故障，则 RTO >= 24 小时 & <= 30 天，如果直流故障 > 30 天。
推动 OLA 和 SLA 指标的因素是所谓的 CIA 评级。CIA = 机密性、完整性和可用性。应用程序的数据应由为该应用程序付费的业务部门进行分类。CIA 将帮助推动 OLA 和 SLA 应该是什么样子。CIA 级别的每个部分都被赋予一个从 1 到 3 的数字。因此，例如，CIA 评级 1-1-1 将代表高度机密、最高完整性级别和最高可用性级别。CIA 评级 3-3-3 是最低的。因此，CIA 评级 3-3-3 通常映射到 SLA 和 OLA 级别 6，其中 SLA-6 和 OLA-6 是最低（最长响应时间）保证。
获得 CIA 评级的方法通常在于确定如果数据被盗（机密性）、被泄露（完整性）或系统瘫痪（可用性），企业将损失多少钱。因此，如果机密数据被盗，企业将损失 1000 万美元，则其 C 评级为 1；如果数据丢失并不严重，只会给企业造成 1,000 美元的损失，则其 C 评级为 3。
这通常是我为其提供咨询的大公司处理此类事情的方式。
答案2
我不会承诺硬件问题的修复时间，软件问题也是如此。你永远不知道什么时候会等供应商修复某个关键错误。就 SLA 级别而言，我发现它们往往是“有人会在 X 小时内解决你的问题”的形式。当然，X 取决于他们支付多少钱，但根据我的经验，1 到 8 小时之间似乎是正常的。
答案3
如果有人要求您提供软件安装位置的硬件问题恢复服务水平协议 (SLA)，答案是“否”。您可以承诺响应时间，但如果不控制整个硬件/操作系统/软件堆栈，您就无法承诺解决时间。
也许你的客户正以一种尴尬的方式告诉你，他们确实需要为你的产品提供托管服务？这样他们就可以避免他们担心的任何内部问题，直接给你开一张支票。
答案4
签订 SLA 时需要考虑的一件事是，SLA 本身毫无意义，必须与 SLA 一起遵守，以防不履行 SLA 而受到处罚。
例如，我们的 ISP 为我们提供 100% 的网络 SLA，但我们可以获得的最大金额是每月的账单，这个金额非常低，因为现在带宽很便宜，远远低于网络故障时我们损失的金额。
此外，合同中通常写的是某人对问题做出反应的速度，而不是解决问题的实际时间。因此，如果他们让你承诺在较短的时间内做出反应，那么就让实习生上夜班，帮你整理工单，直到你醒来，一切就绪。
根据我的经验，所有这些 SLA 业务实际上意义非常小，甚至没有意义。