企业级性能管理与容量规划概述.ppt

企业级性能管理与容量规划概述,建立企业级容量规划、性能管理的业务效益,针对业务部门的需求，集成信息科技主管部门、软件开发中心、测试中心及运行中心等部门，通过统一、规范化的管理平台，对业务服务生命周期的容量规划、性能管理的流程。通过对IT资源容量有效的管理及对运行性能持续地监控，降低业务服务中断的风险。提前在新应用开发、测试阶段，建立起性能管理、容量规划的基线，从而了解新应用、或现有应用大版本变更对于现有生产运营带来的影响，从而降低与新的或改进的服务项目相关的风险。提高IT资源容量的利用效率，在恰当的时候及时适量投资，这意味着采购流程再也不需要应付临时的采购或超前于需求而购买过度的容量，从而总体成本降低了。通过在确定变更对IT容量的影响时与变更管理密切配合，防止了由于不恰当或不正确的容量估计所导致的紧急变更，从而降低了业务运作中断的次数。更为灵活的预测使得对业务需求的响应变得更快速和更准确。职业装定制 工服定做,容量规划、性能管理及相互关系,容量规划主要管理以下几个方面：处理容量的购买成本相对于业务需求来说，是否合理以及处理容量是否以最有效的方式(成本vs容量)被加以利用？当前的处理容量是否足够满足业务当前以及未来的需求(供给vs需求)？现有的处理容量是否发挥了最大的效率(性能管理、调整)？额外的处理容量准确地讲应该在什么时候形成？是否知道未来需要什么样的IT容量以及何时需要这种容量？容量规划与性能管理是互为包含的关系，是一个循环的交互关系:性能管理：为优化整体运营绩效而评价、监控和调整IT基础设施组件的性能的活动。容量规划：根据容量管理数据库分析当前的情况、预测IT基础设施未来的使用情况以及为满足预计的IT服务需求而需要的资源，从而制定容量计划的过程。建模：使用分析、模拟和趋势预测模型来确定服务的容量需求以及确定最佳的容量方案的过程。模拟需要分析各种不同的情形，并分析各种“如果怎么办”式的问题。职业装定制 工服定做,通过获取系统性能信息,全面掌控历史性能与容量趋势依据当前系统信息,预测业务增长的情况下,系统资源的使用的和性能响应,目标:,维持现有IT服务能力的成本相对于组织的业务需求而言是合理的吗？现有的IT服务能力能满足当前及将来的客户需求吗？现有的IT服务能力发挥了其最佳效果吗？,方法:量化管理,致力于解决以下问题:,评价和改进现有服务能力，确保服务水平的承诺评估当前IT资源的使用，确保高效地使用资源分析并预测未来的业务需求，据此确定当前最佳容量以及未来应当配置的容量和对应的服务水平能力,容量规划和性能管理目标及方法,容量和性能管理是一个持续的管理流程,容量规划和性能管理是一个持续的管理流程,流程负责人设计并确定容量规划和性能管理流程流程负责人设计并确定该流程的角色和责任技术专家分析并确定管理需求，相关指标以及需要使用的工具,对于优化建议，技术专家负责规划优化行动技术专家负责利用相应的调优工具，进行相应的系统或应用的调优工作优化后仍不满足要求，容量规划师负责提出增容建议,各管理环境的数据采集专家负责建立数据采集机制数据采集专家根据流程定义的采集周期定期地使用相关的工具采集所需的容量和性能指标并进行存储,容量规划师根据容量管理报告，根据历史信息定期预测未来容量需求 对于增容建议，容量规划师负责制定相应的容量规划,各管理环境的数据评估专家根据已存的容量和性能指标，生成所需的性能管理报告、异常报告以及容量管理报告技术专家根据异常报告分析异常指标，结合性能管理报告找到异常原因并提出改进建议(优化或增容),流程负责人负责监督管理流程的执行流程负责人定期向上级汇报容量规划和性能管理的结果,容量和性能管理是一个持续的管理流程,容量规划和性能管理是一个持续的管理流程,重要角色企业系统性能架构师从宏观把控性能与容量的需求，技术以及流程业务代表作为业务部门的代表，提供性能标准，未来新业务开展及已有业务增长情况数据评估与采集专家采集，存储基础数据，生成所需的报告容量规划师跟踪项目确保与容量相关的服务级别合乎既定的要求技术专家作为某个特定领域的资深技术人员，深入分析优化的可能性并优化流程负责人类似于项目经理的角色，确保流程合规执行,容量和性能管理的人员组成,容量和性能管理的人员组成,管理报表分类,报表类型管理层报表，技术层报表概况、趋势、异常、详细报表固定报表(日、周、月、年趋势)和交互报表专业条线报表专业条块分类主机系统，分布式系统网络系统存储系统专业报告类型性能报表健康检查报表性能对比报表系统容量报表容量预估报表业务条线交易种类和渠道统计报表,主机平台容量和性能管理报表,性能管理日报生产主机系统性能健康检查日报生产主机系统性能管理日报生产主机操作系统专业性能日报生产主机系统RMF III日报生产主机联机子系统性能管理日报生产主机数据库子系统性能管理日报生产主机批量性能日报生产主机存储性能及容量指标日报性能管理周报生产主机系统性能健康检查周报生产主机系统性能管理周报性能管理月报生产主机系统性能健康检查月报生产主机系统性能管理月报系统容量管理报表容量预估管理报表,哪些由性能容量工具产生？哪些需要系统手段产生,分布式系统平台监控系统硬件资源的性能报表,系统信息包括虚拟空间利用率、页面读写错误情况、物理内存和虚拟内存使用情况、CPU利用率、平均负载情况磁盘资源包括空间利用率、节点(i-node)利用率、磁盘读写繁忙程度等。进程包括CPU利用率的进程、耗用内存最大的十个进程、进程利用情况列表其它监控资源磁盘性能RPC调用的性能情况用户访问情况服务器网络使用情况文件情况,网络硬件资源的性能报表，端口或线路的质量和使用率,网络设备级报表CPU利用率内存利用率Buffer利用率端口、线路的报表：端口速率带宽利用率丢包率错包率SAA,存储容量和性能管理报表,与系统有关的性能管理,参照主机系统、开放系统相关的内容就存储子系统本身而言卷和数据的均衡分布是使性能达到最大的最重要的因素需要考虑cache block与文件系统及数据库的匹配联机交易系统最重要的IO性能指标是每秒的IO数和响应时间其次是吞吐量批处理应用吞吐量是最需要重点考虑的采用TPC等工具来实现对存储性能的监测。其中TPC所监测到的存储前端性能指标，可以和服务器上取得的RMF report，IO stat的值相对应。监测存储前端的卷的性能参数包括IO rate,data rate,response time，读写比，IO块大小等，其中读操作的cache命中率是判断IO特性的重要指标后端性能参数主要包括array和rank级别的IO rate,data rate，response time，NVS full等参数，可以判断存储后端是否存在瓶颈，这些参数通常无法在服务器上取得通过取得的性能指标，结合disk magic和capacity magic可以对存储更好地planning,容量、性能管理贯穿在整个解决方案的生命周期中,异地灾备中心,运行中心及同城灾备中心,开发中心,测试中心,数据中心,信息科技主管部门,SLA的性能需求,业务部门,建立 容量、性能管理委员会，由一部三中心的人员组成按照SLA形成、维护性能的KPI技术研究（产品性能白皮书，性能基线）定期的容量规划评估会根据容量预测，安排资源采购,性能监控及跟踪性能、容量信息收集，分析，评估系统性能调优,新应用性能预估、建模大版本变更性能预估、建模应用性能调优应用性能建模,按照SLA进行性能测试压力测试,需求、设计,开发,测试,发布,生产,研讨：公司在构建企业级容量评估、性能管理方面需要做哪些改进？,思考一下组织架构？规范流程？人员技能？辅助工具？预算开销？,企业级性能、容量管理总体功能架构,投资回报,服务级别报告,性能报告技术条线，业务服务,管理报表记录/结构定义,SQL 查询,被管理技术模块,数据收集,企业级性能、容量管理总体平台参考架构,TivoliPerformance Modeling,RMF,SMF,Enterprise Portal,开发中心,测试中心,数据中心,信息科技主管部门,性能管理的定义,性能管理就是计划、定义、测量、分析、报告和调整计算机资源性能的过程。这些资源包括：主机系统硬件，如CPU，I/O等操作系统和子系统，如z/OS，CICS，DB2等数据网络应用系统服务历史趋势分析和报告以及资源容量的规划也是和性能管理相关的重要内容,性能管理的目标,性能管理的目标就是：通过有效地使用资源来达到性能服务水平(SLA)的承诺。通过对性能的调整降低响应时间、提高吞吐量，在满足SLA的基础上减少消耗。,性能管理的目标,统一的性能报告,制定性能管理的标准和程序手册,性能管理的组织架构性能管理人员和他们的职责性能管理所适用的环境性能测量的标准报告的需求性能管理工具历史文件趋势分析性能管理例会报告和解决性能管理中的问题,。,。,性能管理的主要模块,数据收集：每日收集性能数据，积累形成周、月、年度等数据为性能分析和趋势分析提供原始数据；数据保留：制定性能数据的保存介质和期限；信息处理：日常规定的性能报告或管理层要求的报告处理作业；信息报告：主要以管理层的要求为主。主要针对性能瓶颈的分析和确定何时需要进行升级。,性能管理周期,当解决了一个瓶颈后，重新测量、重新评估性能来验证没有造成别的限制并确保所做的变更升效了,性能管理的步骤,定义服务水平目标（SLA）和度量标准收集性能数据从性能数据中创建有价值的报表分析性能报告来确定是否满足了目标识别系统中的潜在瓶颈分析可疑瓶颈处的详细性能数据决定从哪可以获得所需的资源验证是否消除了性能瓶颈,主机性能指标-宏观性能指标,响应时间(Response Time)外部吞吐率(ETR)和内部吞吐率(ITR)系统饱和点(SDP)资源使用率(Utilization),主机性能指标-宏观性能指标 响应时间,主机性能指标-宏观性能指标 吞吐率,ETR:按照Elapse Time来测量，注重系统容量；ITR:按照CPU时间来测量，注重CPU的容量,提问：对于相同的工作负载,哪个系统更好？,主机性能指标-宏观性能指标 系统饱和点,SDP的定义是，为保证一个系统在小间隔内的使用率不超过100%，最大的平均大间隔的使用率。大间隔、小间隔的选择（例如1小时、1分钟），决定于用户的忍耐程度。例如，用户在一小时内不能容忍任何一分钟的使用率达到100%，那么小时平均使用率就不能超过计算出的SDP值。假设，小时平均值为80%，而此小时内分钟峰值为92%，则SDP=80*100/92=87%,混合工作负载时响应时间与CPU利用率关系图,主机性能指标-微观性能指标 I/O,IO Response=IOSQ+Pending+Connect+DisconnectIOS Queue Time:表示在z/OS中设备等待的时间.Pending time:表示从发出SSCH指令直到Channel和I/O控制器之间开始对话.Disconnect time:I/O操作已经开始，但是Channel和I/O控制器之间没有对话.Connect time:Channel和I/O控制器Cache之间作数据传输或交换控制信息.,应用性能指标,不同的代码编写方式对系统性能的影响是不一样的应用程序性能指标体现在代码的编写方式CICS指令写法DB2 SQL语句写法文件组织方式及定义属性其他如果应用程序存在性能问题，ITR往往不会线性增长，导致不能正确预估系统容量如果某支交易存在应用程序性能问题，往往会影响其他80%正常交易的运行,性能管理的工具,联机工具Tivoli OMEGAMON 系列SMFCICS CMFDB2 TraceRMFz/OS Management Console后处理工具Tivoli Decision SupportCICSPADB2 PE应用性能分析工具Application Performance Analyzer 高级管理系统包括性能数据仓库以及报表/展现工具,性能管理交付件,性能管理手册性能管理的系统和数据仓库,各种日常报告和趋势分析报告、系统资源调优/升级建议等性能管理日志,性能管理自动化及其主要需求,全面的数据源采集，支持技术人员在对性能问题进行深层次的分析时能够及时获取所需的所有数据，提高问题分析的效率数据采集、加工与存储应形成一个高度自动化的流程根据管理需要，采集关键的性能指标性能分析支持中长期分析和短期分析通过生成日趋势、周趋势、月趋势报告支持长期历史趋势分析性能好坏的评判通常是通过与历史同期性能数据对比得出的相对结论提供面向业务的性能统计信息易于扩展及维护，尽量避免由于核心系统软件升级，SMF数据格式改变时所带来的开发维护工作量,难点,直接从SMF中抽取并加工数据，确保主机性能容量数据的完整性生产SMF数据的庞大，要求数据抽取的高效率支持对用户自定义数据包括业务数据的采集存放。例如为主机成本核算系统提供参数数据（交易与业务的对应表、业务与部室的对应表等）确定由于新需求或核心系统软件升级引起的SMF格式变更，所带来的开发和维护工作量实现高度自动化的统计加工机制设定历史数据的维护策略，自动清理大量的过期数据,实现方法,采用专门管理工具，做到：实现SMF数据抽取、统计加工、存储以及报表生成的高度自动化在出现SMF格式变更时只需通过打补丁的方式即可支持提供最佳管理经验的样本报表，提高实施速度利用一个现有的、不太繁忙的LPAR进行性能容量管理每天晚间通过批量方式自动提交SMF数据采集作业，自动生成固定报表考虑所在系统和数据库的性能，建议只采集管理所需的数据根据用户角色对用户访问权限进行设定对原始数据表设定过期清理策略对特定时间段，建立专门的数据表，永久保存,性能趋势分析功能 可以生成日报、周报和月报等性能趋势报表性能健康检查功能 可以对异常指标进行提示完善数据采集功能 通过批量作业方式完成对SMF等历史数据的全面采集 报表功能 可以生成概况、趋势、异常、详细等各种类型的性能报表图形化视图功能 提供Web图形报表展现短期性能分析功能 可以收集RMFIII数据，并存储到性能容量数据库中，通过SQL生成相应报表 用户分级访问功能 可以提供多角色报表访问功能,具体的功能要求,原理示例,SMF数据,其它日志数据,日志收集器,性能容量数据仓库,各种性能容量报表,SQL,数据采集流程,主机平台容量规划,容量规划的定义,容量规划就是根据容量管理数据库分析当前的性能和容量情况、预测IT基础设施未来的使用情况以及为满足预计的IT服务需求而需要的资源，从而制定容量计划的过程容量规划包括了系统建模，即使用分析、模拟和趋势预测模型来确定服务的容量需求以及确定最佳的容量方案的过程。建模需要分析各种不同的情形，并分析各种“如果怎么办”式的问题当前、历史趋势以及容量规划也是和性能管理相关的重要内容,容量规划的目标,容量规划的目标就是：在恰当的时间增加容量来达到服务水平(SLA)的承诺。通过对容量的科学分析和预测，准确预测出未来的容量需求和服务水平,创建容量规划数据库,业务预测,服务数据,技术数据,财务数据,CDB,管理报告,容量规划,技术报告,容量规划报告,容量规划报告描述了当前及未来对IT基础设施容量的需求、IT服务需求方面的预期变化容量规划报告还说明了在考虑未来服务级别需求的情况下，以可接受的成本提供SLA中约定的服务级别而需要做出的变更容量规划报告不仅需要描述预计的变更，而且要指出相关的成本容量规划报告应当每年进行一次修订，同时为保证其准确性应当每季度进行一次审查容量规划报告是容量规划流程最重要的交付件容量规划报告应当包含性能预测、升级点、基础设施升级的预计成本等方面的信息,容量规划自动化,根据性能容量管理数据库分析当前的情况、预测IT基础设施未来的使用情况以及为满足预计的IT服务需求而需要的资源，从而制定容量计划的过程使用分析、模拟和趋势预测模型来确定服务的容量需求以及确定最佳的容量方案的过程。建模需要分析各种不同的情形，并分析各种“如果怎么办”式的问题容量规划的效益：防止由于不恰当或不正确的容量估计所导致的业务风险前瞻性地科学预测为容量采购的决策提供了依据，避免超前于需求而购买过度容量的采购行为，从而节省总体成本关键点-确保满足服务水平-及时的、主动的、前瞻性预测-性能是核心指标(而不是利用率),上级主管部门有时会问难以量化回答的问题-如果不升级，情况会糟糕到什么程度?-如果升级，情况会好到什么程度?-在下次升级前，可以维持多长时间?需要借助于方法论及自动化工具进行量化预测-模拟方法-分析方法 需要具备性能建模的能力,驱动力一：量化,不断变化的复杂环境 工作负载的性能取决于多个因素：-负载优先级-高优先级负载的占比-CPU的数量与速度-Paging-I/O子系统的限制-LPAR的影响 性能难于推测 没有适当的工具，容量规划将只能依靠“拍脑袋”,驱动力二：预测,实现方法,科学的预测手段：精确、简便易用预测多维度：不仅关注CPU的性能，还要关注存储的未来增长以具有代表性的高峰期数据为基准，而不是某段均值建立周期性预测机制环境变化时，需要重新依据新基准值进行预测不能忽略低优先级负载的性能,运行环境基本不变，包括交易模式、应用和系统不变业务行为规律不变，根据业务行为规律，建立不同时期的模型分别进行建模预测重大变更发生时，例如新应用上线或系统核心组件升级，需要重新建模预测最佳实践：建立容量规划自动化操作流程，每月建模预测,准确预测的前提,系统建模,系统建模主要用于预测基础设施的运行状况建模方法线性预测(趋势分析，大致预测)分析性模拟(结果可靠性不高)仿真模拟(预测复杂环境较准确)系统实际运行基线(最准确，但代价最高)建模结果应包括反映服务水平的核心指标，为容量规划提供量化依据,仿真模拟技术示例,根据实际数据，选择具有代表性的时间段建立模型模型生成过程中，时间被划分成多个时间片。在每个时间间隔(最小间隔为0.01秒）的开始，模型会检查每个工作负载。对于联机交易来说，模型会决定是否产生一个新的交易。模型将根据平均到达率来产生新的交易模型产生后，将确定工作负载运行情况，确定每个工作负载的交易率和单个交易消耗的CPU以及I/O率等模拟指标利用假设条件，基于模型进行模拟运算，得出预测结果,仿真模拟方法,根据一个特定的时间段内的实际系统的运行情况创建一个模型选择的时间段非常重要，因为模拟会以此作为基准，来比较不同的预测场景最佳实践是挑出一个典型的系统利用率比较高的时间段（不必盲目追求所有高峰期中的最高点）模拟不是试图去预测未来的平均性能情况，而是预测接近于最坏性能的情况，这种情况通常会导致服务中断,模拟数据收集与预测,从SMF记录中生成CPU和工作负载报告作为基础数据可以通过选择若干天的某个特定时段来缩短报告的大小最佳实践是选择五个连续工作日的高峰时段的系统利用率 依据长期历史趋势分析出的交易增长结果作为预测假设条件，预测未来保持现有环境或假设硬件升级的情况下，CPU利用率和响应时间,主机平台应用容量评估,54,系统资源CPU资源内存存储应用交易处理容量衡量标准吞吐量(每秒处理交易数)响应时间,应用容量评估,55,基准理论 吞吐量与CPU使用率的关系,56,基准理论 响应时间与吞吐量的关系,57,20%的交易消耗80%的资源20%的交易在某些情况下，微小的交易量变化会影响整个系统的交易处理在真实环境中，会同时有许多不同种类的交易并发运行，因为不同交易占用的CPU资源不一样，因此对系统影响也会不一样，在实际环境中，应尽量避免长交易（高CPU消耗）的大量运行，比如可以通过设置TCLASS来保证系统资源的分配。通常情况下，批量作业相当于长交易,基准理论 二八定律,58,理想情况下，单系统交易处理的拐点在98-99%左右多节点环境下，因为并行耦合器有一定的内耗，通常情况下，从单系统到2节点的系统，内耗在10-12%左右随节点数目的增加，每增加一个节点，内耗会增加2%左右耦合效率计算公式,基准理论 多节点内耗,59,I/O对交易处理能力的影响如果交易有I/O问题，则交易响应时间与吞吐量往往不呈线性关系，工作负载的增加对CPU利用率的变化也不呈线性关系。并行耦合器CPU利用率对交易处理能力的影响理论上，并行耦合器的CPU利用率超过50%，会对交易处理有一定的影响,其他因素对交易处理能力的影响,60,确保交易不存在明显的I/O问题如果交易存在有I/O问题，就无法通过增加CPU资源来提升交易处理能力。避免并行耦合器的CPU利用率过高，不要超过50%确定交易混和比例尽量与真实生产系统接近考虑联机交易和批量作业间的互相影响明确测试目标通常以交易响应时间为标准明确交易优先级别,压力测试前提,61,当交易响应时间合乎性能指标时，计算不同工作负载的ITR分析ITR是否线性增长，如果线性增长，以此ITR值来估算系统容量配置估算时，应考虑I/O对交易的影响，工作负载越大，I/O竞争越多，建议工作负载应尽量接近真实生产系统环境,测试结果分析,What is Performance?,响应时间描述系统的速度 联机响应时间 批量运行时间吞吐量描述单位时间内系统处理的业务量 每秒交易数（TPS）每小时记录数容量描述系统拥有的各种资源总量 处理器颗数以及处理器速度 磁盘空间 网络带宽,性能指标分为三大类：响应时间，吞吐量，容量,对于新应用开发而言，容量估计工作开始的越早越好,全面的了解业务规模，各项应用与系统指标是进行精确性能估算的前提,如今的系统通常都包含了异构的客户机和服务器，跨多个地理区域和逻辑层级,性能架构师必须端到端的考量整个系统结构，包括涉及到的单个组件的特征和应用的特性,系统是如何组织的？逻辑层级，地理区域以及系统的拓扑逻辑系统内各个组件的功能系统内有哪些资源可供调用？它们的性能特征又如何？应用变更的影响有多大？批量与联机响应时间补丁策略,有多种实现方法有“胖”客户端与“瘦”客户端根据具体配置进行分析网络流量非常关键,客户机服务器,系统结构,绝大多数新系统的架构,把若干个单一功能的组件用多个逻辑层级的方式组装起来网络是性能的关键所在良好的用户体验是一个极其重要的需求小心美工负载难以预测 要充分考虑到可扩展性,基于Web的系统,系统结构,操作系统,通讯控制器,交易中间件,数据库,等待I/O,服务时间,处理时间,CPU(milliseconds),#I/O,SELECT-one row,35,2,FETCH-next,10,0.1,DELETE-one row,60,4,典型的原子资源消耗,处理器服务器,组件特性,内存 尽可能消除页面调度（paging）估算工作集（working sets）分别考虑系统自身的消耗以及各组件的消耗 千万别按照软件的最小需求配置内存 任务调度逻辑 管理混合负载 优先级 抢占式（preemptive）时间片,多处理器 集群 与 共享内存并行(SMP)必须考虑换算系数11 2！服务时间取决于单一处理器的速度 处理器的比较 MIPS rPerf ROLTP tpmC SPECint(Unix),服务器是多用户多任务的,其他相关的考虑,工作站是单用户的,通常几乎没有I/O操作（除非出现paging）服务时间很大程度取决于技术希望技术的变革GUI服务时间可能占主要部分慎用拍脑袋的方法,处理器工作站,组件特性,磁盘通常是影响性能的关键设备,寻道,查找/延时,读写,随机物理I/O,15 ms,顺序物理 I/O,6 ms,Cached I/O 命中,大约2 ms,Cached I/O 未命中,同物理 I/O,平均逻辑顺序数据访问,1-3 ms,磁盘访问,Typical Service Times,I/O设备,组件特性,随机与顺序访问 磁盘Cache 尽可能减少物理数据访问 实际效果取决于负载 磁盘阵列物理磁盘结构与逻辑磁盘结构是不同的 性能特征因此更为复杂 SAN存储区域网络 每个节点都应当被看作一个独立的系统 性能与容量需要单独估算,磁盘的考虑,组件特性,CD和DVD 类似于磁盘设备，但是要明显慢于磁盘（通常100ms）磁带 主要用于备份、恢复 高效的数据传输率（通常比磁盘高）加载时间较长，无法随机访问 虚拟磁带库(VTL)是指将磁盘仿真(虚拟)成磁带库 打印机 打印时间常作为性能考量的关键 打印速度并不总是关键因素 估算总体打印效率,其他输入输出设备,组件特性,网络对于系统性能来说至关重要，而且可能非常复杂,性能指标带宽 有效数据传输率决定了网络服务时间，考虑时以最低速的链路为准延时 从网络上一次往返花费的时间，所有等待时间之和。和带宽有可能有关，也可能无关。经验之谈 计算有效带宽时使用10 bits/byte以包容起始位，中止位，校验位等无效信息。,网络,组件特性,总结,时间和预算永远都不够标准的性能架构方法论随时都可以使用但是要有裁剪，根据项目的特性慎重思考把精力集中到最有风险的领域多听听别人怎么说.爱因斯坦的一句话：Everything should be made as simple as possible,but no simpler,学无止境！,在学习中前进,在实践中领会,通过项目实战不断提升自我,用开放包容的心态去面对,