服务设计之容量管理.docx
- 文档编号:29407784
- 上传时间:2023-07-23
- 格式:DOCX
- 页数:29
- 大小:35.43KB
服务设计之容量管理.docx
《服务设计之容量管理.docx》由会员分享,可在线阅读,更多相关《服务设计之容量管理.docx(29页珍藏版)》请在冰豆网上搜索。
服务设计之容量管理
容量管理
容量管理贯穿于服务生命周期的始终。
容量管理的关键成功因素就是在服务设计阶段已经考虑到它,因此,容量管理的内容包含在本书籍中。
容量管理首先在服务战略阶段得到支持,在服务战略阶段,决策和业务要求与客户结果的分析影响着业务活动模型(PBA)的开发、服务的水平(LOS)和服务水平包(SLPs)。
这提供了需要调整容量以满足需求的预测性的指标。
意图、目的与目标
“容量管理的目的就是保证在IT的所有领域有成本合理的IT容量,并且及时地满足现在及将来的业务需求。
”
容量管理的意图就是对所有的容量及服务和资源相关的性能问题进行关注和管理。
容量管理的目标是:
生成和维护一个合适的和最新的容量计划,反映当前和将来的业务需要
在业务和IT的其他领域提供容量和性能相关问题的建议和指导
通过管理服务和资源的容量及性能,保证服务性能满足或超过所有既定的性能指标
为性能和容量相关的故障及问题的诊断和解决提供帮助
评估容量计划的所有变更所带来的影响,评估所有服务和资源的性能和容量
保证提高服务性能的主动措施在成本合理的情况下得到实施
范围
容量管理应该关注所有的IT性能和容量问题。
技术管理职能如网络支持、服务器支持、运营管理等实施大部分的日常管理任务,可以为容量管理提供性能信息。
容量管理应该包含包括硬件和软件在内的所有技术领域,适合于所有的技术组件和环境。
容量管理也要考虑空间规划、环境系统容量和人力资源的某些方面。
但是只有人力资源的缺失能导致SLA或OLA目标的违背、端到端性能的延迟、满足将来任务和计划的无能(例如,因为操作人员的缺失以致不能装载磁带,从而导致夜间数据备份不能及时完成)。
通常情况下,容量管理是一种线性管理责任,虽然服务台员工使用同样的容量管理技术。
人力资源安排、员工水平、技能水平、能力水平都应该被包含在容量管理的范围中。
容量管理的驱动力应该是组织的业务要求和规划能够提供与SLAs(OLAs)一致的服务水平所需要的资源。
容量管理需要了解整体的IT和业务环境,包括:
通过业务活动模型(PBA)来了解当前的业务运营和要求
通过服务组合来了解将来的业务规划和要求
通过SLAs和标准运营流程来了解服务目标和当前的IT服务运营状况
IT技术、容量、性能的所有方面,包括基础设施、数据、环境、应用程序等
了解所有这些可以使容量管理能够保证服务的当前和将来的容量和性能的所有方面可以成本合理有效地提供。
容量管理也需要了解新服务传递的可能。
需要了解新技术,如果合适的话,应客户的要求改革和传递这些服务。
容量管理需要重新确认技术变更的比率可能增加并且新技术可以被安全使用以保证IT服务在改变业务期望时仍然让用户满意。
需要在服务战略和服务组合间建立一种直接的联系以保证在将来的服务规划中把新兴的技术考虑进来。
容量管理应该包括:
通过性能、效用、IT服务的生产能力、基础设施、环境、数据、应用程序组件、正常产出、服务报告、组件容量和性能等监控业务活动模型和服务水平计划
进行调优以便现有的IT资源达到最有效的使用
了解用户对IT资源所达成的当前和将来的需求和将来的生产预期
可能与财务管理一起影响需求管理
生成一个容量计划可以使服务提供商提供符合SLAs所规定质量的服务并且能够有足够的时间安排来满足将来服务组合和SLRs所规定的服务水平
为服务或组件相关的任何故障和问题的确认和解决提供辅助作用
在成本合理和满足业务需求的情况下对服务或组件的性能进行主动性地改进
管理巨大的分布式IT基础设施的容量是一件复杂的和高要求的任务,尤其是IT容量和财务投资一直增加的情况下。
所以对增长进行规划显得更有意义。
因为在分布式环境下单一组件的更新成本通常情况下会少于在集成式主机环境下的组件更新成本,所以经常有许多的组件需要更新。
当需要购买很多组件时,单个组件的成本由于规模效应而减少。
容量管理可以用于服务组合和采购过程以保证在与供应商谈判中达成最好的交易。
容量管理提供单个组件当前的和计划的资源效用的必要信息可以是组织有把握地做出决定:
哪个组件需要更新(如:
更大内存、更快的存储设备、更快的处理器、更多的带宽)
什么时候进行更新----理想状态下不能过早,否则导致超出容量的过多支出;也不能太晚,否则导致不能有效利用新技术、瓶颈、不连续性能、最终地,客户不满意和失去生意机会
更新的成本是多少----在预算的生命周期中把容量管理的预期因素和计划因素考虑进来以保证计划性投资。
如果没有容量管理的信息输入,许多其他管理过程的效率会大大降低。
例如:
变更管理在可用性的容量方面能够评估任何变更的效果吗
实施新服务时,服务级别管理能保证新服务的SLRs达到了吗现存服务的SLAs将不会受到影响
问题管理能够诊断由低劣性能所导致的故障的潜在原因吗
IT服务持续性管理能够准确确定关键业务流程的容量需求吗
容量管理是一个前瞻性的过程,当进行实施时,可以在业务事件和影响发生前预测到它们。
好的容量管理保证服务和组件的设计与性能不会出现惊险的情况。
在组织中,容量管理和服务战略与规划流程有密切的双向的联系。
基本方面上,组织的长期战略包含在业务规划的更新中。
服务战略反映业务规划,业务规划来自于组织对外部因素如竞争性的市场环境、经济前景、法律法规和内部的人力、供应能力等容量的理解。
通常会开发一个短期的战术计划或业务变更来实现短期或中期的必要的变更从而可以进行全局的业务规划和服务战略。
容量管理也需要了解短期、中期和长期的业务规划以便提供最新的理念、趋势及硬件软件供应商所开发技术的信息。
组织业务规划驱动特殊的IT服务战略,容量管理需要熟悉服务战略的内容,并为服务战略输入重大的和不断的信息。
合适的时间合适的容量,这是很关键的。
服务战略可以为容量管理在识别新技术、硬件、软件的获得和实施的时间方面提供帮助。
业务价值
容量管理负责保证IT资源按计划的方式来提供连续的服务水平,其能够与当前和将来的业务需求相符合,这些需求在SLAs和OLAs中被一致同意和文档化了。
容量管理结合业务规划,提供了容量规划来指导支撑业务规划所需的的IT资源和资金以及支出费用的成本调整。
策略、原则与基本概念
容量管理保证IT服务和系统的容量和性能以最节约成本和时间的方式符合业务的既定需求。
容量管理本质上是一种平衡:
成本和所需资源的平衡:
保证依据业务需要所购买的容量是成本合理的,并对这些资源进行最有效的使用。
供求平衡:
保证IT处理能力的有用性供应与当前和将来的业务需求相符合。
为一种特定的资源管理或改变需求也是必要的。
容量管理过程和规划必须融合于服务生命周期的所有阶段,从服务战略、服务设计、服务转换、服务运营到服务改进。
从战略的角度来看,服务组合包含所有的IT资源和功能。
服务导向架构的出现、虚拟化、IT服务条款(provision)中的价值网络使用在容量管理中都是关键的因素。
在初始的设计阶段就应该把恰当的容量和性能带到服务和组件中来。
这样不仅可以保证新的或变更的服务的性能符合期望的目标,还可以保证所有现存的服务能够继续符合它们的所有目标。
这是稳定服务条款的根本。
整体的容量管理过程以持续地成本合理地方式使IT资源和能力符合不断变更的业务需求。
这就需要对当前的资源进行调优和优化并对将来的资源规划进行有效的估计,如图例所示。
容量管理是一种极其技术、负责、高要求的过程,为了达成必要的结果,它需要三个3个支撑的小过程。
容量管理的关键活动之一就是生成一个规划,把资源利用和服务性能的当前水平进行文档化,并在慎重考虑服务战略和规划后,预测将来能够支撑业务活动的IT服务所需要的资源需求。
这个计划应该清楚地显示任何所做出的假定。
它还要包含任何量化的资源、成本、收益、影响等方面的建议。
需要在预定的时间段内生成和维护容量规划。
它本质上是一个投资规划,所以需要每年公布一次,并且与业务或预算生命周期一致,还要在将来预算的协商前完成。
在服务规划中,考虑到变化的情况,每季度更新一次规划是必需的,可以增加预测的准确度,还可以提出或提炼出一些建议。
这需要额外的活动,但是如果它被定期地更新,容量规划会变得更加准确并能反映变化的业务需求。
容量规划的内容参见附录J。
业务容量管理
业务容量管理把业务需求和规划转变为对服务和IT基础设施的需求,保证IT服务将来的业务需求得到及时地量化、设计、规划和实施。
这可以通过对各种服务所使用的当前资源利用情况的现存数据来预报、建模或者预测将来的需求来完成。
这些将来的需求来自于服务战略和服务组合,如新流程和服务需求、变更、改进和现存服务的增长。
服务容量管理
服务容量管理关注于端到端性能、现实状况的IT服务使用和工作负载的容量的管理、控制和预测。
它可以保证服务目标中符合SLAs和SLRs的所有服务的性能得到监控和测量,并可以记录、分析和报告所收集的数据。
如有必要,可以实行主动的措施来保证所有服务的性能符合既定的业务目标。
这通常是由具有使用端到端服务传递技术的所有领域的知识的员工来执行的,还经常需要向组件容量管理的专家寻求建议。
如果可能,应该把自动化的阈值控制技术应用于运营服务,来保证服务目标被违背或威胁时能够及时地得到识别,并使减少或避免潜在影响的成本合理的措施得到实现。
组件容量管理
组件容量管理关注于对单个IT技术组件的性能、使用和容量进行管理、控制和预测。
这保证拥有限定的资源的IT基础设施内的所有组件得到监控和测量,并可以记录、分析和报告所收集的数据。
同样地,如果可能,可以使用自动化的阈值控制技术应用于所有组件,来保证组件使用或性能的服务目标被违背或威胁时能够及时地得到识别,并使减少或避免潜在影响的成本合理的措施得到实现。
这三个子管理过程有许多相似的活动,但是每一个有其不同的关注点。
业务容量管理关注于当前和将来的业务需求,服务容量管理关注于支撑业务的现存服务的传递,而组件容量管理关注于支持IT条款的IT基础措施。
每个子管理过程在容量管理中所扮演的角色如图例所示。
容量管理所使用的工具应该符合组织管理架构并且与IT系统和自动化处理的其他管理工具进行集成。
服务运营中的监控和控制活动将会为容量管理的支持和分析工具提供良好的基础。
活动、方法与技术
容量管理的一些活动是被动的,还有一些是主动的,这些主动的活动包括:
在性能问题发生前采取必要的措施解决它
生成当前组件使用情况的趋势分析,估计将来的需求,为计划的更新和增强使用趋势分析和阈值控制技术
建模和趋势分析IT服务中的潜在变化,识别IT基础设施和应用中的服务和组件需要作出的改动,从而保证适当的资源处于可用状态。
在违背As和服务目标或性能问题出现之前,保证所有的变更被预算、计划和实施
在成本合理的情况下主动寻找改进服务性能的机会
调优和优化服务和组件的性能
被动的活动包括:
监控、测量、报告、回顾服务和组件的当前性能
响应所有容量相关的阈值事件并采取正确的行动
对特殊的性能问题做出反应和协助。
服务台可能把低劣性能故障归结于技术原因,这就需要使用容量管理技术来解决它们。
关键信息:
容量管理的主动活动越成功,需要的被动活动越少。
业务容量管理
业务容量管理的主要目标是保证IT服务的将来业务需求(客户结果)能够被考虑和理解,同时保证在合理的时间跨度内支撑新服务或变更的服务的充足IT容量被规划和实施。
图例显示了业务活动模型是如何影响业务容量管理的和服务是如何使用的。
容量管理必须随容量需求的改变而改变。
新服务或者变更的服务被要求来支撑变更的业务。
现存的服务需要修改以提供额外的功能。
陈旧的服务被淘汰,从而释放出一些空闲容量。
结果是使满足客户SLRs和SLAs的能力也会受到影响。
容量管理的责任就是预测变更所需要的容量和管理需求。
新需求可能从许多不同的来源(sources)和由于许多不同的原因引起容量管理的注意,但是供应需求的最主要的来源应该来自需求管理的业务活动模型和为服务组合所生成的服务级别包。
例如升级以便利用新技术的建议,或解决性能问题的一个调优活动的实施。
图例显示了需求管理的循环过程。
在所有的战略、规划和设计活动中尽可能早的把容量管理包含进来,例如:
协助和支持服务战略的开发
参与IT战略和政策的回顾与改进
参与技术架构的回顾与改进
关键信息:
容量管理应该优先被客户接纳,而不是最后的选择。
如果在这些过程中容量管理能早些参与进来,IT容量的规划和设计就会与业务需求紧密地结合,并能保证完成和维护服务目标。
协助同意服务级别要求
容量管理应该协助服务级别管理(SLM)依据服务/系统响应时间、期望生产能力、使用模式和用户数量来理解客户容量和性能的需求。
容量管理应该提供一定情境下的可能解决方案以便在谈判过程中有所帮助。
例如,如果用户数量少于2000,则可以保证响应时间低于2秒;如果多于2000用户的连接数,则应启用额外的网络带宽来保证所要求的响应时间。
或者保证降低响应时间是可以被接受的。
建模、趋势分析或者应用定型技术经常被用于此来保证预测能够准确地反映现实状况。
设计、获得或修改服务配置
容量管理应该参与到新服务或变更服务的设计中来,并且为硬件和软件的采购提供建议,这种情况下,性能和(或)容量是重要的因素。
在一些例子中容量管理其作为变更咨询委员会的一员是通过变更管理来达到新需求的实施的。
为了平衡成本与能力,容量管理获得可供选择的解决方案的成本并建议最合适的成本合理的建议。
核实服务等级协议(SLA)
服务等级协议应该包括期待服务能力和性能要求的详细情况。
容量管理建议服务级别管理(SLM)监控可达成的目标和服务设计基于其上。
容量管理应该充满信心,即服务设计符合SLRs,并且可以提供通过建模、趋势分析和定型技术获得未来增长的能力。
支持服务等级协议谈判
使用预测技术的结果可以验证服务性能。
这可能需要服务等级管理给予这些结果重新谈判服务级别协议。
容量管理通过建议潜在的解决方案和相关的成本信息为SLM提供支持,重新谈判则显得是必要的。
一旦要求可以达到,服务级别管理的职责就是同意服务级别并签署服务级别协议。
控制和实施
所有对服务和资源的容量的变更必须遵循所有的IT流程,如变更、发布、配置和项目管理流程以保证对所有变更的控制和协调是适当的,以及保证任何新的或改变的组件在他们的生命周期中被记录和跟踪。
服务容量管理
服务容量管理的主要目标是识别和理解IT服务、资源的使用、工作模式、高峰与低谷,并保证服务达到SLA目标,例如保证IT服务表现得如所期望的那样。
服务容量管理主要关注于管理包含在既定SLAs或SLRs中的目标所决定的服务性能。
服务容量管理保证服务符合既定的服务目标。
可以对被监控的服务所提供的数据进行趋势分析,从而在趋势中建立正常的服务等级。
通过对这些等级进行定期监控和对比,可以定义、识别和报告异常情况。
这样,容量管理可以显示任何服务的服务级别管理的违背或丧失。
存在这样的情况,即涉及容量管理的故障和问题来自于其他流程,或者识别到某项服务可能不能符合SLA目标。
在某些情况中,潜在失败的原因并不能由组件容量管理决定。
例如,分析失败的原因,可能会发现是因为容量不够或者没有单个组件是超额利用的。
然而,即使程序的设计或编码是效率低的,仍需要管理服务性能,也需要管理单个硬件或软件资源。
服务容量管理应该监控服务负载和事务处理情况来保证它们仍处于既定的限制和阈值下。
成功的服务容量管理的关键是预测问题,如果可能,可以通过监控性能上的变更和监控变更所带来的影响。
这样,其实它是另一个子流程,是主动的、预测性的,甚至是优先的,而不是被动的流程。
然而,它需要对特殊的性能问题做出被动地反应,这种情况已经存在多次了。
对正在使用的每个服务的性能要求的知识和理解、对应用服务变更的效果的评估、所采取的措施,这些来保证达到所需服务性能的要求。
组件容量管理
组件容量管理的主要目标是识别和理解性能、容量及支撑IT服务的技术的单个组件的使用,包括基础架构、环境、数据和应用程序。
这可以保证当前硬件和软件资源得到最佳使用从而达到和维持既定的服务等级。
IT基础架构下的所有的硬件组件和许多的软件组件都有限定的容量,达到或超过这一容量,可能引发性能问题。
组件容量管理关注于处理器、内存、磁盘、网络带宽、网络连接等组件。
所以需要持续不断地收集资源利用的信息。
需要在单个硬件和软件的组件上安装监控器,然后对其进行配置以便收集必要的数据,这些数据需要在一段时间内进行累积和存储。
这项活动通常在服务运营部分通过监控和控制得到实施。
对组件容量管理进行实时反馈应该应用于这一子流程中。
同服务容量管理一样,成功的组件容量管理的关键也是预测问题,如果可能,也需要以主动的和预测性的方式进行。
然而,组件容量管理需要对特定的问题做出被动地响应,如容量不够或者组件的无效率使用所引起的问题。
这种情况也是存在的。
来自于对正在运行的服务的资源使用的知识和理解,对服务使用的变更效果的估计,对硬件和软件更新的预算和规划。
可供选择的是,对现存资源与服务进行平衡可以达到当前资源的最有效率的利用。
容量管理的支撑活动
本部分所描述的活动对支持容量管理的子流程是必要的,这些活动可以以被动的或主动的甚至优先的方式进行。
各子流程间最大的不同是被监控和收集的数据及对数据分析的视角。
例如在基础架构中单个组件的利用水平,如处理器、磁盘和网络连接,是与组件容量管理相关的,事务处理产出比率和响应时间是和服务容量管理相关的。
对于业务容量管理,对在线服务来说,事务处理产出比率需要转化为业务量,例如,以销售发票或订单的形式。
容量管理最大的挑战是理解业务需求和业务负载之间的联系,并能转换为对服务和资源的负载和利用的影响和效果,所以可以在每一层级上设置合适的阈值。
调谐(tuning)和优化活动
应该重复地进行一系列的活动并形成一个自然的循环,如图例所示。
这些活动提供了基本的历史性的信息和触发因素,对容量管理的所有其他活动和流程是必要的。
应该建立对所有组件和每个服务的监控。
如果可能,这些数据应该使用专家系统来对比利用水平和阈值。
分析的结果应该以报告的形式表现出来,并包含合适的建议。
一些控制机制的表现形式应该对这些建议做出响应。
如平衡服务、平衡负载、变更并发数量、增加或删除资源。
在这些活动中所累积的所有信息应该存储在容量管理信息系统(CMIS)中,这样,当循环再次开始时,监控发生的任何变更以保证他们能够产生有益的效果并为将来的行动收集更多的数据。
利用监控方式
应该对特定的操作系统、硬件配置、应用程序等实行不同的监控方式。
重要的是监控能够收集容量管理所需求的对于某一组件或服务的所有信息。
典型的监控数据包括:
处理器利用情况
内存利用情况
事务处理类型所占用的CPU百分比
输入输出比率(物理的和缓冲区的)和设备利用情况
队列长度
磁盘利用情况
事务处理比率
响应时间
批处理时长
数据库使用情况
索引使用情况
命中率
并发用户数
网络流量比率
在考虑所要包括的数据的时候,还要把监控容量(如吞吐量)收集的数据和监控性能(如响应时间)收集的数据区分开来。
服务容量管理和组件容量管理都需要这两种类型的数据。
监控和收集的数据需要结合在服务中需要的所有组件,从而监控端到端的用户体验。
需要在整体的资源利用水平上收集数据,还要收集每个服务在每个组件上的负载的详细情况。
这需要贯穿于整个技术、主机或服务器、网络、本地服务器和客户端(或工作站)之中来进行。
监控活动的一部分就是监控正常操作水平的阈值、基准或配置。
如果超出了指标,应该进行报警和发布异常报告。
这些阈值和基准应该由当前记录数据的分析结果所决定,并可以在组件和服务水平上进行设置。
所有的阈值设置都应低于组件或服务超常利用的水平或者低于SLAs中的目标。
这样,在将要达到或达到阈值时,仍然有机会在违背SLA或资源被过度利用之前采取正确的行动,只是存在一段性能不佳的时期。
这些事件、阈值、报警的监控和管理在服务运营书籍中有详细的讨论。
通常得到业务容量管理所需要的关于当前业务量的数据是很难的。
这些数据可能派生于对服务容量管理和组件容量管理可用的数据。
响应时间监控
许多SLAs把测量用户响应时间作为众多目标之一,但是,同样地,许多组织在支持这一要求是存在很大的困难。
IT和网络服务的的响应时间可以由以下方式监控和测量:
在客户端和服务器应用软件中注入特殊代码:
这种方式可以提供完全的端到端响应时间或者提供中间时间点来分解整体的响应时间到其组成部件上。
通过这些工具所得到的数据可以提供实际的响应时间,如同某一个服务的使用者所感觉的一样。
在终端模拟软件中使用“机器人脚本系统”:
这些系统由带有终端模拟软件的客户端系统(如浏览器或者远程登陆系统)和特殊的脚本软件组成,可以生成和测量事务处理和响应情况。
这些系统通常提供的是样本的端到端服务响应时间,不过对于提供代表性的响应时间仍然是有用的,特别是对多阶段的事务处理或复杂的交互来说。
这些只是提供了样本的响应时间,不是实际的响应时间,不像某一服务的使用者所感觉的那样。
使用分布式的代理监控软件:
通过带有监控软件的分布式代理系统监控网络的不同节点(如网络上的不同国家)可以得到关于服务响应时间的有用信息。
这些系统可以用来生成访问某一网站的来自不同地域的汇报并提供周期性的测量数据,如同某一网站的国际用户所感觉的那样。
然而,再次强调一下,收到的数据只能作为响应时间的指标,不能作为实际的用户响应时间。
使用特殊的被动的监控系统:
跟踪客户端系统的有代表性的样本数。
这种方法依赖于特殊网络监控系统的连接工具,通常作为“嗅探器”插入到网络上的合适节点。
这些工具就能够监控、记录和测定网络中通过某个特殊节点的所有流量了。
一旦记录下来,就可以分析这些流量数据从而得到关于服务响应时间的详细信息。
再次强调,这只能用于估计实际的用户响应时间,虽然这些信息通常非常接近现实世界中的状况,但是这依靠于在IT基础架构中的监控的位置。
在一些情况下,需要使用一系列系统的组合。
响应时间的监控是一项复杂的流程,即使它是一项运行于私有网络的内部的服务。
如果是外部的网络服务,这一流程会因为不同组织和技术的卷入而变得更加复杂。
虚构:
拥有一个主要网站的私营公司使用外部供应商实现的网络监控服务可以提供网站可用性和相应能力的自动报警。
监测点自身的可用性和速度低于被监控网络的可用性和速度,这样,监控服务所得到的是监控服务自身的可用性和相应能力的数据,而不是被监控网站的数据。
提示:
当需要实施外部监控服务时,需要保证监控服务的水平和性能承诺超出被监控服务的水平和承诺。
分析
需要对监控所收集到的数据进行分析以便从正常的利用水平和服务水平中识别趋势,或者建立基准。
通过定期监控和对比基准,可以定义单个组件或服务的阈值利用的异常条件,可以报告在SLA考核中的违背或有惊无险的情况并做出相应的行动。
同时,这些数据也可用来预测将来的资源使用情况,或者监控实际的业务增长是否与预测的增长相抵。
对数据的分析可以识别问题,例如:
基础架构中的瓶颈或热点
在有可用资源的情况下负载分发的不恰当
不恰当的数据库索引
应用程序设计中的无效性
工作负载或事务处理比率出乎预料地增加
调度或内存使用的效率低
每个组件和服务的使用需要在短期、中期、长期中得到考虑,并记录下最小、最大和平均的使用情况。
经常地,短期指的是24小时,中期指的是1--4周,长期指的是1年。
随着时间的过去,各个IT服务所使用资源的趋势就会变得明显起来。
通过记录使用情况中的任何导致高峰或低谷的因素,这可以提高信息的有效性----例如,业务流程或员工的变
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 服务 设计 容量 管理