当前位置: 澳门新濠3559 > 服务器运维 > 正文

那你该如何在这些外包服务的协议中保护你自己

时间:2019-11-18 21:29来源:服务器运维
目前经济形势的大环境要求越来越多的公司松开缰绳,取而代之的是将公司的应用,设备——还有信任——交付在数据中心设施供应商的手里。曾经难以想象的外包服务正成为你公司必

目前经济形势的大环境要求越来越多的公司松开缰绳,取而代之的是将公司的应用,设备——还有信任——交付在数据中心设施供应商的手里。曾经难以想象的外包服务正成为你公司必要生存的一部分。那你该如何在这些外包服务的协议中保护你自己呢?

虽然数据中心的设计在理论上不会发生故障,但它确实会出现这种情况,因此数据中心运营商将面临非常严峻的情况,特别是托管数据中心。

作为合同中最主要的组成部分之一,服务等级协议(SLAs)列出了服务范围以及合约的主要条款,但是不是所有的SLAs都是对等和平衡的。仔细阅读最终商议的版本以及审查服务范围可以有效地帮助你取得一份能够保障你业务所需要的服务等级的合同。

对您的云计算服务进行评估并编写SLA要比为简单连接服务(如虚拟专用网VPN)制定SLA要复杂得多。为了正确评估云计算SLA,应了解云计算体验的细节以及实际上是由谁来提供它们。寻找应用程序的工作流程,因为关键应用程序问题可以毁了一个很好的SLA。此外,要确定你有一个实际可行有效的验证和补救方法。

根据最近发生的一些事情,表明托管数据中心遭遇停电和业务中断的后果是十分严重的。例如:英国电信公司是全球最大的通讯商和托管数据中心商之一,其运营的数据中心今年遭遇两次宕机事件。据报道,由于故障影响,伦敦及其周边地区的语音和数据流量下降了10%,事故时间长达四小时以上。

Peter Sclafani已经与上百家客户商议过SLAs,范围从IPv6软件即服务(SaaS)至托管服务。作为网络自动化公司 6connect的首席信息官,Sclafani经历过审核SLA流程的甲乙双方的角色,并从客户或供应商的角度反反复复审查过上百个合同。

澳门新濠3559 1

尽管在设计和运行数据中心时努力避免中断或事故,但数据中心托管设施并不能避免这些问题,其短期和长期的意外中断都将是代价高昂的。如果客户选择放弃服务,企业可能会因不符合服务等级协议(SLA)而受到经济处罚,也可能会对企业的品牌造成长期的损害,并对业务收入造成损失。

问题:“主合约”包含服务等级协议。作为客户,你通常会关注哪里?

公共云计算服务在其范围内提供了令人难以置信的灵活性和效率,但是其广度范围取决于服务成本、可用性以及性能。这提供了评估云计算SLA中常见错误和最佳实践的信息。其涵盖内容包括响应时间SLA、从网络供应商和云计算供应商处获得保证,混合云计算SLA问题等等。

澳门新濠3559 2

Peter Sclafani:作为一份服务等级协议,我通常会先退一步,首先看附在主合约上的那些文件。确认你拥有所有的参考文件来审查。典型的SLA,作为主合约的一个组成部件,也会拥有同样必要的几部分:

遵循应用程序的工作流程

从数据中心的角度来看,应该做什么或不应该做什么以防止中断事故的发生,是一个非常简单道理。但是,如果作为数据拥有者,并且其数据中心解决方案存在失误,那么这是一个不同的结论。如果企业客户已经做出战略决定,将其数据放在外部数据中心,并进行了风险分析。但这样就真的做好应对最坏结果的准备好了吗?问题是,如果企业客户发现自己处在这种情况下该怎么办?

1、SLA所覆盖的产品/服务的定义。这一部分通常是供应商的禁地因为这只是定义产品或服务。如果你连这个也无法认同,那可不是一个好兆头。

云计算服务买家对于云计算SLA的最关键错误是忘记所有应用程序都是真正的工作流程。一个通过网络连接从用户发向应用程序的请求通常是由多个组件组成的。然后,该请求会导致产生流向其他组件的工作——在云计算内的或者返回数据中心的——以及对位于云计算内外数据库的多次访问。最终,通过网络向用户返回响应结果。

对最坏情况做好准备的最好办法是不断地解决这个可能性。如果失败,组织的努力准备和对流程的认识将为其提供减轻失败的资源和工具。如果企业没有考虑或者没有这样做,那么建议从以下几个方面评自己的情况。

2、“可用的”这个字的定义很关键,还包括围绕在它周围的服务指标。

如果SLA只关注于这一过程中的某一点(例如与公共云计算托管相关的一部分),那么SLA是没有用的。如果这一工作流程的任意部分中断,那么应用程序就会发生故障。如果这一流程中的任何部分发生性能问题,那么应用程序的使用体验质量就会受到影响。当其他环节只是得到笼统的保证时,那么只是针对云计算内性能或可用性的严格要求是没有任何好处的。

(1)分散风险

3、当SLA的条件无法满足后,供应商的响应和升级流程的描述。

让所有参与者都确保SLA

首先,当企业制定数据中心战略时,应避免将所有数据放在一处,这样做会增加风险因素。同样的道理,也避免将所有关键应用程序放在同一位置。考虑将主要的数据存放在一个位置,并将备份数据存放在另一个位置。然后逐步了解每个场景,并确定任何级别的故障将产生怎么样的影响。每年重复一次这个过程。

4、当SLA条件无法满足后,整治流程的定义。

评估云计算SLA的另一个问题是无法让所有相关参与者都确保SLA。云计算工作流程通常涉及三方——企业本地自有网络的员工、让员工访问云计算的网络供应商以及云计算供应商。具体可能还涉及企业的数据中心(网络与托管)和提供“云计算至数据中心”连接的另一家网络供应商。供应商通常不会撰写或接受用于处理他们所不涉及工作流程环节的SLA。你需要让他们同意成为他们为此收取一定费用的“主要承包商”或者为所涉及的每一方得到或编写一份SLA。

(2)信任但要验证

你或许可以想象到第二,第三和第四部分是通常需要修改的地方。这些细节通常都是在一开始让供应商获利的地方。比如,作为一个数据中心,一条网络带宽出现严重的数据包丢失可能会使你的应用无法使用,但是当协议中出现的“可用的”的参数依然满足时,你就没有足够的证据来提出赔款申请。

通常SLA中的最大问题是网络连接问题,因为在大多数情况下,除了在云计算本身内部的情况外,云计算供应商是不会提供网络服务。如果你希望严格的SLA,那么你将需要为网络服务编制一份SLA。所以,你应当首先确认你的云计算供应商是否会提供一个VPN或者他们是否能够与你所使用VPN服务的供应商进行协作。在很多情况下,你仍然需要使用互联网来实现用户的连接性,但是VPN将为你提供一个你希望获得保证的坚实网络边界。

企业从服务提供商获得审核记录,更重要的是认真审查。在许多情况下,托管数据中心需要审计是否符合HIPAA,SOX和PCI等规定。然而有时候,这种审查可能是由不完全了解IT或数据中心如何运营的人员来完成。因此,企业需要安排了解数据中心如何可靠运营的专业人士进行审核。这些第三方审核通常比他们自己识别的风险要容易得多,并且可以提供的信息更加丰富。在大多数情况下,与发生中断事故的成本和运营成本相比,通过审查和验证措施减轻风险的成本通常是最小的。

不幸的是,SLA的复杂程度依据所签约的不同类型的服务会产生很大的变化。在一个数据中心的合约中,一份SLA可能会包罗万象,从环境条件比如温度和湿度,到网络联通问题比如延时或可用性,以及甚至管理化/云服务牵涉到服务器、虚拟机、备份服务等。需要考虑如此众多的可能性,一份SLA的真正问题是从法律的角度来审查供应商的灵活性。假设会有几轮的反馈和变化,但是平衡一下合同金额和你的法律费用也是很重要的。

思考混合云计算工作流程

(3)签署书面协议

同时记住任何SLA的黄金准则,当已经到达赔款的时候:你永远不会得到比你付出的更多。如果在SLA之下有一个停机或者其他的可用性损失,这起故障事件永远也不会被标题为“损失”。赔款永远也不会超过你每月支付的那个特定的服务。

混合云计算中的“边界交叉”也会产生SLA问题。工作流程遵循应用程序和业务逻辑确定的路径,如果这些路径在数据中心和云计算之间形成了多个可变交叉,那么就出现了性能与可用性风险。当确保性能或可用性时,你的云计算供应商是无法触及工作流程模式的移动目标的,因此应试图确保你不会在你希望公司保证的工作流程中引入明显的变量。如果你无法做到这一点,那么你将不得不撰写一份非常详细复杂的SLA来解决所有的变量,而且很多供应商根本就不会接受它。

企业需要知道数据中心托管提供商将如何处理中断事故。在与供应商签订合同时,坚持签署书面协议,承认双方同意在什么情况将造成中断。这一点至关重要。事实上,数据拥有者发现有时协议并没有涵盖他们的想法。此外,还要书面上保证供应商在中断期间所提供的服务,并承诺在可接受的时间内恢复。

问题:在一个服务等级协议中,哪些针对环境的可变因素是最容易拿出来讨论和商榷的?

定义云计算SLA的边界

(4)备份策略

Sclafani:服务等级协议中讨论的最多的两个方面是关于可用性定义或除了信用赔偿过程的正常运行时间。

SLA中的最后一个问题就是违规行为的检测,以及处罚和补救程序。一般而言,你或者你的云计算供应商或者其他的网络合作方都不会根据其中某一方的参数测量结果来接受一份SLA。好的SLA会在各方都同意的基础上定义一个边界测量点供独立测量使用,从而进行状态验证。你自己的SLA应确定这些点、将进行的测量以及用于确定是否违反SLA的被测条件。

企业一定要了解自己的业务面临的风险,并为最坏的情况做好准备。大多数托管数据中心都有一个替代的站点,可以处理基本的灾难恢复,以确保他们的客户对运营几乎没有影响。大多数公司仍在追求在数据中心(托管数据中心,云计算或者内部部署)中部署双活数据库。虽然有些双活部署接近成功,但在尝试使用灾难恢复备份时,其中断却让人痛苦。数据库没有企业期望的那样完整,数据丢失或应用程序在故障转换期间很可能受到影响。

正常运行时间是针对产品或服务,你可以指定某些环境变量。对于数据中心来说,这一般就要从温度,湿度开始,一直到网络延时和应用特定的性能。

通常,包交换网络和云计算服务的可用性和性能违反都是基于一个相当长的报告期的——即每周或月的停用情况。所以最好采用“停机间隔时间”这样的协议而不是简单的故障次数,因为后者无法涉及平均修复时间。响应时间SLA也是很难成文的,因为我们很难正确地测量响应时间。如果你的SLA中包括有响应时间,那么就需要花时间来让双方确定将如何对响应时间进行测量。

(5)了解(并记录)流程

正常运行时间的商榷一般会包含实际度量和间隔,比如温度和时间。对于一个托管项目的SLA,交谈就会侧重于可接受的温度范围和时间间隔,如在成为一个故障事件之前所能接受的范围。

补救或处罚始终是一个棘手的事。很多用户认为,如果发生SLA违反(也就是通常所谓的间接伤害),那么他们就可以根据业务损失得到赔偿。这种情况是极少发生而且代价昂贵的;与其试图通过谈判来兑现这一协议,还不如花功夫想办法让你的应用程序具有更高的可用性。

在事故出现的时候,所有各方都进入危机模式。了解(并记录)企业的托管服务提供者如何处理自然灾害和故障组件等事件很重要。那么采取什么步骤和顺序?企业要问的一个重要问题是在发生故障时谁可以访问?事故发生后,其他企业也会访问这个服务器。企业需要准确了解其是否可以访问,访问权限,谁能访问,以及在访问时允许执行的操作。此外,还要知道在修复期间将采取什么额外的安全措施来保护其数据。

商榷是可行的,但是另外很重要的一点是需要确认你准备选择的供应商的诚实度。假设你承诺了一定量的电量负载,同时供应商同意维持一定量的温度阀值。一旦你在机柜中安装了设备导致出现热点,你有可能会碰到一种情况是当此热点温度导致一起宕机事故,供应商可能不用负责,因为这是由于客户自己出现的问题。

用户报告说,SLA中最有用的处罚是一个自动升级条款。如果发生SLA故障,应向供应商运营中心报告这一故障。如果在规定时间没有解决这个问题,或者故障发生频率超过了某一阈值,那么就应向供应商的管理链发送这一故障通知——让更高层人员来负责检查问题并亲自与你联系讨论状态更新和补救措施。这一条款可确保高级管理人员能够关注你的问题,从而提高问题解决的概率。

这个过程的重要组成部分是通信协议。开放沟通对于有效管理情况至关重要,并为企业的管理者提供更新信息。企业需要知道谁是主要联系人,联系谁来获取更新,以及更新的频率。另外,定期验证联系人的姓名和电话号码。重要的是,如果呼叫列表中的电话号码作废或联系人员离职,那么这种情况将会更糟。

还要考虑到你作为用户的行为可能导致一起SLA事件。比如,假设你承诺每个机柜的电量负载为6kW。如果你将用电使用率超过80%的时候,有可能会被供应商归结为一起“不在SLA范围内”的事件因为客户的原因以及触发动作。我们见过讨论客户提醒和针对线路超过既定阀值而征收罚款的合同。我们还见过这样的情况,供应商具备拔硬件电源的权利,目的是将电源的消耗控制在80%的阀值以内。

对于SLA 中的经济处罚,应将处罚金额限于在中断期间服务成本以下作为基线,如果中断情况严重,那么可加上整个测量间隔服务成本。你是否有机会得到这样一个惩罚性条款将取决于你的合同规模以及你成为供应商未来客户的潜力。

(6)保存记录文档

另外一个争论的焦点是供应商用来计算赔款信用的方法。确保你理解他们的流程和条款,防止任何不开心的事情发生,比如赔款的一个附加条件等。有时,这些条款是可以一起商榷的,但是成功的因素很大程度上依赖于供应商。

原文链接:

文档不仅适用于托管数据中心,而且适用于所有与数据中心业务相关的公司。在调查中发现,许多客户没有记录他们的日常运营流程和程序。就算有记录,也没有经常进行更新。文档对于在发生灾难时做好准备至关重要,这其中包括:了解应用程序运行的位置,知道中断哪些受到影响最大,谁需要了解更改等。

问题:面对服务等级协议的商榷,一个潜在客户需要学习哪些方面的知识?维护窗口和其他宕机的情况如何来处理?

【编辑推荐】

(7)了解失败案例

Sclafani:事实上,讨论的筹码是了解有竞争力的服务等级协议和在供应商选择的时候要货比三家。对于撰写SLA的供应商来说,一份SLA永远都是合理的,但是他们一般还是会来跟你确认条款是否合适。

在评估过程中,大多数托管数据中心商都会告诉企业,系统是如何安装的,以防止服务中断。他们还给为企业提供满意的客户的推荐和参考。但他们通常不会告诉他们失败的案例。

千万不要掉入市场的陷阱。比如,某些供应商可能做出一个超乎寻常的声明如当没有达到预期SLA时,返还1,000,000%的服务费用,但是前提限制是你能够为此服务支付多少。如果你将这一条拿出来谈,不要期望会有任何有效的结果。但是一个供应商100%正常运行时间的保障

因此,组织要了解托管服务商的失败案例,需要询问他们是否在过去一年遇到事故,如果有过事故,要了解事故的细节,如何纠正,以及采取了哪些步骤来防止再次发生事故。企业可以在这些案例中学到很多关于托管数据中心的知识,以及他们如何处理这种情况。处理危机才是考验合作伙伴是否合格的时候。

  • 当出现故障而带有小额的赔款时 - 这就是你可以讨论的事情。

(8)了解免责条款

沟通SLA最有效的方式是充分了解供应商控制的领域。比如,一家供应商在转租数据中心空间,而你的要求是超出他们能力范围,有关于他们房东的。那如果期望供应商同意那些使他们业务开发责任或其他超过他们能力范围的条款,就显得很不靠谱。

如果企业对托管服务的合作伙伴失去信心,请务必了解合约中的免责条款,这有助于企业顺利地中止合作。确保合同没有采用模糊的语言描述,避免被不合理的条款所限制。

你也许可以对供应商提供的服务提出一些要求做一些改变。比如,如果他们网络管理是外包给一家第三方供应商,而且你的要求是合理的,你的供应商可能可以和他们的服务供应商合作,做一些SLA的调整。

(9)了解自己的选项

当你考虑到第三方对于供应商SLA的影响,请关注维护窗口。计划中宕机时间的必要性可能会导致一起停电事件,确保供应商不会提议赔款的要求。比如,如果一个网络工程师搞砸了一个路由器配置。一些供应商有可能抓住不统一的维护窗口这一点来绕开他们的责任。如果你的SLA不包含维护窗口,你就有可能无追索权,但是仍然会有宕机时间。理论上,一个SLA应该应用于所有意识到的宕机时间,独立于任何的维护窗口,紧急事件或者其他情况。

大多数托管数据中心的合同期限为几年的时间,在此期间,托管数据中心市场的规模将扩大,新的厂商进入市场。虽然企业可能目前不会寻求采用新的托管数据中心,但应该不断评估其他提供商,或与顾问或经纪人一起审查自己的选择。如果发生失败,企业必须知道移动到新的解决方案的选择。在某些情况下,如果失败是重大的或花费的时间太长,那么后果可能会迫使托管数据中心停止营业,让组织的业务遭受损失。

注意违反SLA后对合同诚信的影响。如果在一个时间段之内出现太多的停电或者一起停电事件超过了设立的时间段,在合同里应该注明一个可能性就是在没有任何惩罚的条件下终止合同。比如,如果供应商在一个月中有3次停电,你应该将你的业务移到其他地方。或者如果你碰到一次长时间的停电,也应该有相对于的一条终止合同的条款。

(10)成为数据中心行家

问题:你是如何监控和记录SLA的统计呢?如服务支持,问题升级,响应时间和服务支持人员的条款。

在英国电信公司的失败案例中,其问题的原因是一个断路器发生故障。虽然有人会认为关键设施会避免单点失败,但证据表明并不是这样。如今,组织运营数据业务,就必须成为数据中心的行家。组织不但要熟知数据中心的知识,而且还要了解市场趋势。

Sclafani:这些方面都是非常重要的,也同时展现了当出现问题后所发生事情的一些潜在问题。基于服务,服务等级协议和供应商的冗余程度,你也许可以拥有几个不同的支持和升级的阀值。比如,如果你选的数据中心是一个完全冗余2N的基础设施,你也许对于一个7x24的“电话随叫随到”的设施服务,以及工作时间驻场的服务会比较满意。如果你的硬件是一套N+1的基础设施,那你就有可能需要一个7x24的驻场服务的合同。

通过询问问题和阅读报告,可以了解数据中心解决方案的各个方面情况。最重要的是,知道潜在的失败点,了解什么情况可能导致中断。人们都希望中断或失败永远不会出现。但是,如果这样做,企业必须为此做好准备好,并指导其团队。最好的建议是在这些故障情况下制定一个计划,并按部就班遵循这个计划。沟通对计划的成功至关重要,因为人们在发生失败可能会不耐烦,但他们必须遵守执行。通过定期检查这些重要领域,将会获得有效地应对中断或失败的知识和经验。

是否会有一个门户让你看到与供应商看到相同的SLA度量信息?是否会有一个工单系统或者仪表盘让你看到你服务的状态?理解服务支持和升级的流程对于作为一个客户将期望现实化是很关键的,也使你认识到别人对你的期望。比如,你可能对于一个托管的机房有SLA是规定温度,但是管理基础设施的供应商可能不提供查看温度数据的权限。你不得不部署你自己的监控和报警系统来确认真实的情况。这就变得很不现实或不可能的任务。

【编辑推荐】

接着,必须要理解如何处理停电造成的赔偿信用。当在一次停电事件中SLA被侵犯了,“真正停电时间段”——有关你潜在的赔偿信用

可能在一定条件还未满足的前提下无法启动。曾经有过很多次,供应商要求故障工单的递交时间,因为那是有时间记录的。其他供应商有可能要求你给他们的售后服务致电或甚至在SLA赔偿信用生效之前有一个最低停电阀值。这些全都是在你签署SLA之前所需要确认的关键点。甚至对一次停电的回应,你有可能不得不自己做一些监控来确认你供应商的报告。这种错误有可能是停电,温度波动或甚至是关于带宽95%的账单。各种各样的失误在所难免。

SLA还包含一个条件,确保当供应商处理问题时候的响应等级。比如,一家供应商针对故障工单的响应SLA等级为1小时,可能对更高等级的响应SLA需要额外的费用。当跟踪响应时,同样重要的是确认这个时间是如何计算和跟踪的。某些供应商会在自己的工单系统里使用自动回复来作为他们的“第一次响应”。这是一个解决他们SLA需求的小花招。确保你理解他们的支持组织架构是如何工作的,这样你的期望才能和他们的服务相对等。

人员配备的能力描述通常都会或多或少夸张一些,所以重点是响应速度。当我在一次故障事件发生的时候打电话给供应商的时候,我更希望能够在第一时间找到一个有运营经验的人来帮助我。当我选择供应商时,我通常希望了解一下他们服务支持人员的一些工作背景。

我通常会得到两种回复。潜在的供应商的回复是比较透明的,如共享为我项目工作的一些服务人员的工作背景。我可能问这些服务人员问题并以此了解为我提供服务的服务支持人员的一些具体情况。另一种,我就会掉进一个完全的黑洞。供应商会告诉我“所有人都是超级有经验的”,但是没有额外具体描述。当提到运营工作经验的例子,我可能得不到任何回应,可以想象这样的支持团队是没有经验的,而且会发生很多升级事件。

再次看一下你的预算,再决定供应商支持团队的相对重要性。如果你自己拥有一支完善的运维团队,那供应商那边就算经验少一些也不是什么大问题。如果你正试图卸下你团队的任务或者从供应商那里得到一些技术能力,那仔细查看供应商的服务支持人员则是一件重中之重的任务。

澳门新濠3559,问题:哪种调查能够在签订SLA协议之前,帮助潜在客户来测试供应商的升级流程?

Sclafani:既然签署SLA协议是客户/供应商关系中重要的一环,除了“直接电话”之外就没有更好的测试。你已经了解你团队在过去碰到过怎样的问题,所以在工作时间和非工作时间,作为一家客户直接电话供应商的服务支持团队。这才是最有效的方式来测验谁来接听,他们的升级流程是怎样的,同样可以至少获知一起真正事件发生时的情况。同时,这也是一次很好的机会来与服务支持团队进行交流,了解真实的他们是怎样的。

我其他的建议是与此供应商现在的用户进行交谈他们目前为止的经验和感受,最好还能跟他们之前签订可是已解约的客户进行交流。如果你看到的都是无视客户感受或者服务等级不达标,那估计你所期望的SLA也无法达到,快去寻找下一家服务供应商吧。

...

编辑:服务器运维 本文来源:那你该如何在这些外包服务的协议中保护你自己

关键词: