我为一家小型开发公司工作，他们越来越多地被要求根据特定配置为我们的产品制定正式的 SLA。
从开发方面来看，我对此感到满意，但是如果从硬件/平台的角度来看，我们会从软件的角度实现特定的目标，那么我说这些目标是没有意义的——客户只关心整体系统可用性。
我应该从平台的角度看什么？什么样的指标和水平？
另外，有什么问题（例如，从软件的角度来看，我永远不会承诺修复时间 - 我不知道我是否必须重写整个产品来纠正某些问题，所以说我们可以修复它5 天可能是不可能的——从硬件/操作系统/平台的角度来看，我应该避免做什么）？
我在这个领域拥有丰富的经验；我为几家像 ISP 一样运营数据中心的财富 5 强公司做了很多工作，这些公司需要托管和支持服务的各个公司部门。
它们通常有两个指标，称为 SLA（服务级别协议）和 OLA（操作级别协议）。
通过使用的硬件类型来满足 SLA。在谈论 SLA 时，我们使用级别来描述它们。SLA-1 是零停机时间，SLA-2 是长达 1 小时的停机时间，SLA-3 是 8 小时等等……通过使用冗余设备来满足 SLA。在一家公司，我们使用大量思科来创建高可用性（思科 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 将是高度机密、最高完整性级别和最高可用性级别。中央情报局的 3-3-3 评级是您可以达到的最低级别。因此，CIA 评级 3-3-3 通常映射到 SLA 和 OLA 级别 6，其中 SLA-6 和 OLA-6 是最低（最长响应时间）保证。
您如何获得 CIA 评级通常相当于弄清楚如果数据被盗（机密性）、受损（完整性）或系统停机（可用性），企业将损失多少钱。因此，如果机密数据被盗，可能损失 1000 万美元的公司的 C 等级可能为 1，或者如果丢失的数据并不严重并且只会让公司损失 1,000 美元，那么您的 C 等级可能为 3 .
这通常是我咨询过的大公司处理此类事情的方式。
我会很慢地承诺修复硬件问题的时间，就像在软件上一样。你永远不知道什么时候会等待供应商修复某个关键错误。就 SLA 级别而言，我发现它们往往采用“有人将在 X 小时内解决您的问题”的形式。X 如果当然取决于他们支付多少，但根据我的经验，1 到 8 小时之间似乎是正常的。
如果您被要求提供 SLA 以修复您的软件恰好安装的硬件问题，答案是“否”。您可以承诺响应时间，但如果不控制整个硬件/操作系统/软件堆栈，则无法承诺解决时间。
也许您的客户以一种尴尬的方式告诉您他们真的需要为您的产品提供托管服务？这样他们就可以避免他们担心的任何内部问题，然后给你开一张支票。
签订 SLA 时要考虑的一件事是，SLA 本身绝对没有任何意义，必须与惩罚一起遵守，以防 SLA 未履行。
例如，我们的 ISP 在网络上为我们提供 100% 的 SLA，但我们可以收回的最大金额是我们每月的账单，这真的很低，因为现在带宽很便宜，远不及网络中断时我们损失的金额.
此外，合同中通常写的是某人对问题的反应速度，而不是实际解决问题需要多长时间。因此，如果他们让您承诺缩短响应时间，只需在夜班安排一名实习生为您洗牌，直到您醒来，然后就可以了。
根据我的经验，所有这些 SLA 业务实际上意味着非常非常少，如果有的话。