服务需求控制管理:每种需求都是必需的吗

发表于:2020-8-31 11:59

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:肉松蛋卷    来源:博客园

分享:
  一讲,我们探讨了如何通过提高互联网服务的效率,降低对公司服务容量的要求。今天我们讨论另一个有效手段——互联网服务的内部需求控制管理。
  互联网公司内部,往往有很多后端服务,比如Key-Value,也就是键值数据库服务。公司内部对这些后端服务,会有很多使用的需求。需求自然有合理的,也有不是很合理的。我们要做的,就是确保那些合理的需求,能够使用这些后端服务,并且将那些不合理的需求,尽量挡回去,或者,让提出需求的内部客户提高容量使用效率。
  你不要小看了互联网服务的需求管理,它对保证容量供给和服务质量很重要。因为公司给一个服务的容量总是有限的,如果不能控制需求,那么有限的容量很快就会被用光,从而影响公司的正常运行。
  今天我先讲讲服务需求控制管理的总体目标,然后分享一整套大规模需求控制管理的方法给你。这套方法是我在多年实践中总结出来的,实践证明它是行之有效的。
  为什么要做服务需求控制?
  想做好大规模需求控制的管理,你就需要先宏观地弄清楚服务需求控制的目标。
  一个公司要想成功、有效地运行互联网业务,它就应该尽量让各个内部服务的容量需求和供应尽可能接近。
  如上图所示,左边是公司业务增长,导致容量需求越来越大;右边是公司预算成本有限,容量供应有限。
  我们总是希望这两者能够匹配,越接近越好。如果容量供应不能满足服务需求,那么会导致部分业务的发展受到阻碍。如果容量供应过量,就会有闲置容量,造成浪费,从而降低公司基础架构的效率。
  要降低容量需求有两种方法,一种就是第33讲我们谈过的提高服务效率,另外一种就是这一讲要说的控制需求。这二者最好互相配合,共同努力。
  需求控制管理难在哪里?
  现在我们就来看看需求控制管理要怎么做。不过,要理解这套方法为什么是这样的,又为什么可以说它是“行之有效”的,你需要先了解做需求控制有哪些挑战。我总结一下,主要有下面几个方面的挑战:
  一是很多公司,尤其是大公司,服务的规模会越来越大。这个规模表现在很多方面,包括服务数量很多,使用服务的客户也很多。注意这里的客户不仅仅是外部客户,更是内部客户。这就要求我们的工作不能仅靠一个人或者一个团队,必须是分布式的。
  二是服务的内部客户的容量使用情况很不一样。有的客户对容量使用量很小,增长也不快;有的使用量就很大,或者飞速增长。这就要求我们,在宏观上需要对客户的使用设置一定的配额,否则一个服务的容量,一旦被某些客户用光,其他客户的性能就会非常差。
  三是内部客户的资源使用可能不稳定。客户使用的不稳定,会导致特别大的峰值出现,对服务的稳定性造成影响。所以,我们必须在微观上,实时监测客户的资源使用情况,一旦发现超出期望的效率衰退,就需要及时通知客户,让他们尽快解决。
  四是停止服务的代价高。一个内部客户一旦开始使用一个服务,就很难让人家离开。所以必须严把入口关,不要随意地让服务上马。
  五是资源使用效率的提升,必须要经常与用户沟通,和用户一起不断地提高使用效率,同时也需要开发一些工具来帮助用户。
  需求控制框架如何构成?
  我把整个需求控制的框架按照逻辑,分成了五大模块。如下图所示,我们一个一个地来展开阐述。
  服务入口控制:需求审核
  第一个模块是服务入口控制。一个服务的需求在开始使用服务之前,必须进行上马前的审核。这个审核,需要统筹考虑需求优先级、和什么产品相关、对公司业务的影响、需求量的大小和轻重缓急、是不是已经计划好的等很多因素。
  每个服务需求的请求,要求以任务的形式进行,审核人员要定期的处理这些任务。为了帮助审核人员做出适当的决定,请求者最好提供足够的信息。一般来说,按照刚刚提到的几个方面来准备就可以,越详细越好。
  出于平衡利益的考量,审核人员的组成十分多样,至少要包括服务开发团队、运维团队,以及提供容量的团队。为什么这样设置呢?给你举个例子,服务的开发团队,可能希望服务的内部客户越多越好,因为客户多的话,这个服务就变得越来越重要。服务的运维团队,可能更关心服务和系统的稳定性,不要出现各种性能和可靠性问题。而提供容量的团队为了保证容量供应,可能不希望用户有太多的需求。
  经过审核后,每个请求会产生几种不同的结果:或批准,或拒绝,或需要客户提供更多信息,或者要求客户降低请求的大小,又或者推迟这个请求。
  之所以把这个审核放在第一位,是因为我在实践中发现,很多的客户请求都是“拍脑袋”想出来的,其实根本不合理,而且请求的大小,往往是狮子大开口。当你审核一个“需要几千台服务器容量”的请求后,你必然要与提出者沟通。而在很多情况下,他们的请求在沟通后降到了只需要几台服务器。
  这个“沟通”也不难,你只要对每个请求多问几句,比如这三个“劝退”问题:
  你为什么有这么大的需求?
  你能讲讲你的理由吗?
  能不能推迟一下这个请求?
  差不多有一半客户在答完这三个问题后会降低请求的大小,甚至很多会直接取消请求,说:“仔细考虑后,我们其实不需要这个请求。”
  分布式的需求控制管理和效率提升
  第二个模块是分布式的需求控制管理和效率提升。
  为了适应大规模服务的场景,需求控制的方法必须是分布式的。我们一般是把整个公司的各种使用,分成差不多10到15个产品组,比如按照产品种类来分。这样我们就可以针对这些产品组,分别合作,让每个产品组设置特定人员和团队来和我们合作。
  为什么这么做呢?因为只有这样,我们的工作才能合理扩展。
  我曾经为一个互联网服务做过三年的需求控制,学到了很多经验和教训。这个服务有几千个内部客户,如果只有我一个人和所有的客户打交道,根本行不通,累死也做不过来。
  更重要的是,每个产品组的内部人员,其实才是最适合审核本组需求的人,因为他们对这些请求最清楚。这个请求到底需不需要?请求的大小到底合不合适?由他们来做审核,远远比我做得好。
  产品组级别的审核,本质上是一种有效的,可扩展的分布式模型。而且,除了需求控制和审核,还有其他一些类型的工作,也更适合在产品组级别执行。比如下面我们会提到的配额限制等。
  采用这个模式,所有的服务需求,都会先确定是哪个产品组,然后将需求任务分配给产品组,让他们进行产品组级别的审核。产品组的审核决定也不是随意决定的,同样要基于几个因素,包括请求的优先级(例如功能的重要性)、增长配额以及产品组内下层团队之间的协作等。
  宏观需求增长控制:设置增长配额
  第三个模块是在宏观上控制增长,也就是设置增长限额和配额。我通过四个问题来阐述。
  1.在哪个级别设置增长配额?
  我刚刚讲了,每个产品组会对自己内部的服务需求进行审核。如果没有产品组级别的配额限制,产品组有可能胡乱批准他们自己的请求,从而滥用这个服务。如果对他们的服务需求,加上配额限制,事情就好办了。所以,增长配额必须设置在产品组的级别。
  另外,在产品组下面的级别,也可以设置配额。因为有的产品组很大,内部也有几十甚至几百个团队,所以每个团队也需要设置相关的增长配额。这也有利于产品组内部的协调。这里的要求就是,产品组内部的配额总和,必须不能超过产品组级别的总配额。
  2.怎样设置增长配额的频率?
  这个设置可以是一年、半年,或者是一个季度。太频繁会增加工作负担,但是时间太长也有弊端。所以,我们一般都是半年或者一年设置一次。如果是一年,一般是年初设定一年的增长配额。
  3.如何设置增长配额的大小?
  每个产品组的实际配额大小也需要考虑几个因素,比如产品的特征、重要性、预期增长、产品发布计划、内部客户端效率等等。对每个产品组的情况都了解后,就可以根据实际情况和业务影响,来平衡各个产品组的配额。当然前提是,总体配额不超过总容量。
  4.如何及时地控制需求的增长,保证不超过配额?
  我们需要搭建一些工具和配额使用情况面板。这样就可以每天监控每个产品组的资源使用情况,并将使用情况与增长配额进行比较。如果产品组的资源使用量,连续7天比每日的配额快,我们就通知产品组,并创建对应的任务。
  任务的优先级别在一开始要设置成最低的。但是如果产品组的使用量,已经超过了年度总增长配额,那么你可以将任务更改为高优先级来解决。如果有连续3周以上的实际使用量,都超过了年度总增长配额,并且产品组没有采取任何措施,那么对应的任务就会提升优先级到最高级。
  微观增长控制:资源使用的实时监测
  第四个模块是在微观上进行增长控制,就是实时地进行资源使用检测。
  产品组对一个互联网服务的使用有很多实例。虽然每个实例的情况都不同,需要区别对待,但不会变的核心点是:每个使用服务的实例,都需要进行实时的、微观层面的监测,以确保它的效率不衰退。
  一旦你发现实例的效率衰退,就需要及时地通知这个实例的所有者。一般是以任务的形式发给客户,让客户诊断和根因,然后解决。
  这个部分,和刚刚讲过的宏观层面的配额限制是互相呼应的。只有在微观增长方面检测和控制得好,才能更容易保证配额不超标。
  资源使用效率:不断提升
  最后一个模块,就是不断提升资源使用效率。最好的措施,就是我们上一讲说过的提高服务效率。这里的服务效率,主要是客户端的效率,目的是满足内部客户基本要求的情况下,尽可能地降低资源量。
  但我们实际中碰到的一个难点是,内部客户通常只对自己的指标比较了解,比如QPS,或者数据的大小。既然我们的最终目的是节省成本,那么,就需要让客户直观地了解指标和成本的对应关系,比如1TB的数据相当于多少钱。
  有了指标和成本的对应关系,产品组就能方便地按照任务的重要性来安排工作、调配人员。一个能节省1千万元的任务,当然比只能节省1百万元的任务更重要。
  为此,我们针对每个互联网服务,都提出了一种易于计算和理解的对应指标。比如,对某个存储服务,我们就考虑了数据大小和QPS这两个输入指标,然后根据整个服务的成本来做映射。一般来讲,为了反映最新的服务状态,这个指标是需要定期更新的,例如,服务增长、硬件效率、服务效率等。
  总结
  这一讲我们讨论了容量控制的管理方法,这套方法可以有效地降低服务的容量需求,也就节省了公司的运营成本。实际执行这条管理方法的核心是:在不影响公司正常发展和内部客户合理需求的条件下,尽量降低内部客户对每个互联网服务的需求。
  总体来讲,这套方法的核心是分布式和系统性。对于新的内部客户需求,要进行审核以确保需求请求是合理的。而对于现有客户的需求,要在宏观级别,确保需求配额不要超过;在微观层面上,确保资源使用效率不退化,还要不断地寻找效率提升优化的机会。
  唐代诗人岑参有首很有名的边塞诗,有两句是描写塞外的寒冷:“将军角弓不得控,都护铁衣冷难着。”说的是边塞都护府的将军,手冻得拉不开弓,几乎不能控制弓箭了,铁甲也冰冷得让人难以穿着,非常辛苦和困难。我们做容量控制管理的工作也着实不容易,需要和各个内部客户产品组打交道,互相理解,为了共同的目标和公司的利益一起工作。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号