云服务器内容精选

  • 跟踪项目状态 每日站立会议跟踪任务进度。 迭代开始后,项目组通过每日站立会议沟通每个工作项的当前进展,并对工作项状态进行更新。 使用卡片模式能够简单直观的查看迭代中各工作项的当前状态。 进入“迭代”页面,单击图标,切换到卡片模式。页面中展示了处于每种状态下的工作项卡片,通过拖拽工作项卡片即可更新其状态。 迭代评审会议验收迭代成果。 在到达迭代的预计结束时间前,项目组召开迭代评审会议,展示当前迭代的工作成果。 “迭代”页面提供了迭代统计图表,团队可以方便的统计当前迭代的进度情况,包括需求完成情况、迭代燃尽图、工作量等。 进入“迭代”页面,单击“统计”,即可展开迭代进度视图。
  • 购买并配置云容器引擎 本节中使用的是云容器引擎CCE。 通过控制台可购买CCE集群。 其中集群及节点的必要配置建议参照表1与表2,表中未涉及的可根据实际情况选择。 表1 CCE集群购买配置 配置分类 配置项 配置建议 基础配置 集群类型 选择“CCE Standard 集群”。 计费模式 选择“按需计费”。 集群版本 根据需要选择,建议选择最新版本。 网络配置 容器网络模型 选择“容器隧道网络”。 虚拟私有云 选择已有的虚拟私有云,如果列表中没有合适的选项,单击“新建虚拟私有云”完成创建。 子网 选择已有的子网,如果列表中没有合适的选项,单击“新建子网”完成创建。 容器网段 勾选“自动设置网段”。 表2 节点配置 配置分类 配置项 配置建议 计算配置 计费模式 选择“按需计费”。 节点类型 选择“弹性云服务器-虚拟机”。 节点规格 选择2vCPUs 8GiB及以上规格即可。 操作系统 选择公共镜像中的Euler镜像。 节点名称 输入自定义名称 。 登录方式 选择“密码”。 密码 输入自定义密码 。 网络配置 节点IP 选择“自动分配”。 弹性公网IP 选择“自动创建”。
  • 方案概述 本文以“DevOps全流程示例项目”为例,介绍如何部署应用至CCE与E CS 。 开展实践前,需要完成编译构建。 样例项目中预置了以下3个部署应用。 其中,第一个用于CCE部署,第二、三个用于ECS部署。 表1 预置应用 预置应用 应用说明 phoenix-cd-cce 部署至CCE流程对应的应用。 phoenix-sample-standalone 部署至ECS流程对应的应用。 phoenix-sample-predeploy 向ECS中安装依赖工具操作对应的应用。 父主题: HE2E DevOps实践:部署应用
  • CodeArts前端DevOps实践 本文主要以CodeArts产品自身为背景,简要介绍一些在前端性能优化方面的优秀实践方法和常见问题。 在开始本文的内容之前,先简单介绍一下华为云CodeArts。CodeArts是华为云一站式云端DevOps平台。简单来说,就是在云端提供了从需求到运维的端到端DevOps工具链。CodeArts的目的是为研发团队提高研发效率,降低研发成本。 本文的主题是前端的性能优化,而性能优化的解决过程与一个希腊神话故事十分类似。这个故事讲述一个名叫西西弗斯的国王,由于犯了错误,被惩罚在一座山坡上不停的推石头。这位国王不停推石头的过程,与我们持续的进行性能优化的过程很像,而石头就是我们要不停优化的问题,发现有问题又要重新来,或者一步一步来。几乎所有大型网站在做性能优化的时候,可能都是在重复的推那个大石头。 我们为什么要做性能优化?下面让我们来看几个数据: 第一,40%的用户如果在一个网站加载时长超过三秒之后就会离开这个网站。 第二,用户转换率和网站的响应时间进行关联的结果基本是,响应时间越高,性能越差,转换率越低。 之前在知乎上有一个很出名的讨论,有个人分享他把网站的响应时间从10秒提高到2秒,效率提高500%的心得和过程。当时很多人评论他讲得好,但还有更多人批判这个问题,原因就是为什么你最初能够容忍一个响应时间为10秒的产品上线?其实很多团队都存在这样的问题,每天聚焦在做优化的事情,反而忽略了第一次的10秒是怎么产生的。就好像西西弗斯的那个故事里的大石头,它为什么会出现?比如突然有一天我们被告知,用户说网站性能太差,无法承载响应的需求,这个时候团队内部才决定痛定思痛,好好做网站性能优化的事情。第一步往往是对网站进行分析,看能否找到其中的问题是什么。然后通过这些问题逐步去分析,并且做大量的技术验证,去定位并确定问题,这一步帮助我们知道这个石头是怎么来的。在这个阶段,让我们来看看有哪些好的实践。 首先,尽量利用一些第三方的平台工具,例如谷歌的Page Speed和YSlow、Lighthouse。这些工具提供了很多关于单一应用的检查项。用好第三方平台工具,能够快速对你的网站进行检验,去发现这里是否有问题,然后给我们某一个维度的检查报告。我们不能也全部依赖于工具的检验结果,也需要基于业务本身去一个一个验证,得出一个优化的结论,每一环验证好打上勾,最终的结果呈现出性能的提升。我们在提升的过程中往往发现,很多问题是规范方面的不足,这时就需要思考为什么在开发过程当中会犯这样的低级错误。 基于前面的过程,团队往往会组合出适合自己的工具链。但当我们一次次的开始推我们的这个大石头时,会发现石头特别大、特别累。于是我们希望前端工作人员能够安静独立的尽快解决这个事,不被打扰;我们会想团队要求能否少点需求,在这各阶段大家都停一下,一起把这个任务过了,让网站得到一些提升。 我们可能经过一个月的攻关,确保每个团队把自己的工作做好了,发上线了,客户得到了好的反馈,网站性能提升了,团队很高兴终于把这个石头推向山顶。但是过一两个月,又有人说页面速度变慢了,有些模块的响应速度完全不能忍受。问题的来源可能很多,我们的开发人员要专注于交付,项目进程中会出现人员的变动,很多之前在项目中积累的好实践会丢失掉。然而这些问题是无法避免的,可性能的提升也是刻不容缓的,难道团队要每隔一两个月就要做一次这样的攻关,又去推一遍超级大的石头吗? 在CodeArts的开发过程中也出现过这样的问题,而CodeArts团队针对这个问题的思考是不推这个石头了,为什么一定要积累到这么庞大的问题,而不是把石头敲碎,每次带一点呢。于是CodeArts开始基于这个角度思考如何进行性能优化,不要做任何专项的改进,而是把问题敲碎,放在每一个迭代当中。 回到开始,我们想一下之前要做的性能优化的事情,简单来说可以分为两个部分。第一个部分是固化的部分,包括CDN的建设、所有Web上的容器设置。CodeArts使用的是前端的Angular框架,关于Angular框架本身的演进与优化,再到基于业务实践自己抽取的或者实现的主权库以及公共的部分,我们把它看做是固化的部分。固化的意思是说在组织过一次集中的攻关之后,经验和效果很容易被传承下来。它的改动不涉及业务,所以它的变化频率本身比较低,而且一般这种公共的东西会有专门的架构师去看护。对于这部分内容,做了一部分优化之后就会有很好的效果。这其中还有网站劣化的部分,有可能每一个特性就是100到几百毫秒的差别,但是一个不注意,积累到一定程度之后,就会出现我们最开始所说的10秒页面。对于这部分问题CodeArts前端团队会怎么做?这就要回到DevOps的三步法,从左到右的流动,从右到左的反馈,以及持续学习的迭代。 这里的关键是第二步,从CodeArts面临的问题角度来看,就是我们怎么知道产品的每一个服务,每一个页面在什么时候开始发生了性能的劣化,就像那个石头一样是慢慢长大的。我们能否在每天,每个月,每个迭代随时发现它的变化,然后把石头敲碎,前提就是能否及时得到反馈。如果团队自身都不知道产品的性能是怎么样,靠外界,靠用户,靠其他人了解,到那个时候一看,石头就已经非常庞大了。所以核心的第一点是反馈,那么如何建立这个反馈? 第一,要有主动、实时的、前端定制化的监控。这里有几个非常关键的方面: 前端定制化。这种监控手段非常多,有各种各样的监控工具,大部分的实现原理是源于浏览器的关键节点。CodeArts本身基于开源的项目做了定制化的监控,一是将浏览器里面所有关于监控的指标细化了。 按照框架的要求,定义一些对产品要求更适合的指标,并且监控数据是实时的,并不是采样。监控的数据会提供给开发人员,每一个前端的开发人员会隔几天观察一下页面服务的现状表现如何,监控生成的结果一目了然,会帮助他们知道问题是由于网络还是由于基础框架、业务写法、效率、接口,通过前端主动化、定制化的监控,可以快速识别,且降低交付成本。 第二部分是被动的例行的性能验收。CodeArts团队会从测试验收的维度思考问题,有的团队确实疏忽了,或者初期没有建立起主动的意识,就需要靠被动的性能验收去给团队展示,让大家知道网站目前的情况,看到每一个页面发生的变化。 有了这两个主动的和被动的监控数据存在,让整个前端团队能够掌控到网站在性能上的实时变化,知道现在发生了什么问题,哪一块是我们的弱点,哪一块需要我们的开发人员去注意,哪一块需要公共架构成员去关注,这些都是非常重要的需要可视化的东西。 建立了相关的 数据可视化 以后,要怎么推行它?正如上文所说,要避免以前的那种专项的运动,因此要把每一次的性能优化放在每一个迭代,实际上影射的就是DevOps的第三步,每一个小迭代的快速优化和快速学习。这并不是一个技术活,这个问题的解决不依赖于某个技术手段或工具,因此这才是最麻烦的问题,它要求参与的每一个人有这方面的意识,提供了自动化工具和监控的可视化数据,但是不去实施,那么前面所做的所有努力就都白费了。针对这个问题最好的解决办法就是沟通,每一次的站会、周会,整个团队上下要有一个沟通的机制。在团队内部建立起良好的沟通氛围,所有数据可视化,且进行展示,团队的成员可以自发认领,且对于任务不惩罚,多主动激励,培养团队成员的主观能动性,在一次一次迭代过程中,让大家能够主动的去承担,去找到这些问题。最后很关键的一点是及时的激励或及时的反馈,每一个迭代都要看到客观数据的变化。因为前面已经建立了主动的和被动的监控数据,每次的迭代中你做的努力,或者你的松懈,会直接在下一周,或者下一个迭代会议里面产生相应的数据变化。这种可视化的反馈数据会产生及时的激励,让团队看到付出的所有努力都是值得的,那些主动思考问题、解决问题的团队一定会在可视化中脱颖而出,而不愿意改的问题一定会被放大出来。 最后回到原点,上文中一直吐槽西西弗斯,但换一个角度看他,还有一部分非常值得我们去学习的地方,就是一直向上不停歇,无论怎样,他永远在那个死循环里面推石头,也像CodeArts的精神,就像迭代一样,不断提升自己。一千个读者眼中有一千个哈姆雷特,希望本文中基于CodeArts分享的所有前端性能优化,以及实践上的尝试,能给各位开发者带来一定的启发,也希望文中提到的内容也能够为你日常的工作和实践提供帮助。 父主题: DevOps概览
  • 监控和跟踪项目状态 每日站立会议跟踪任务进度。 迭代开始后,项目组通过每日站立会议沟通每个工作项的当前进展,并对工作项状态进行更新。 使用卡片模式能够简单直观的查看迭代中各工作项的当前状态。 进入“迭代”页面,单击图标,切换到卡片模式。页面中展示了处于每种状态下的工作项卡片,通过拖拽工作项卡片即可更新其状态。 迭代评审会议验收迭代成果。 在到达迭代的预计结束时间前,项目组召开迭代评审会议,展示当前迭代的工作成果。 “迭代”页面提供了迭代统计图表,团队可以方便的统计当前迭代的进度情况,包括需求完成情况、迭代燃尽图、工作量等。 进入“迭代”页面,单击“统计”,即可展开迭代进度视图。 仪表盘跟踪项目进展。 仪表盘提供了强大的项目进度跟进能力,包括需求进度统计、燃尽图、工作完成度、工时统计等,可随时查看项目的当前进展。 您可以使用内置的仪表盘报表卡片(详细使用方法请参考使用仪表盘),也可以根据需要自定义报表。
  • 验收标准 按照服务合同约定的范围,各服务子项验收标准提交交付件,客户官网单击验收确认、签字并盖章(含电子件)。 验收流程针对华为负责的文档类交付件; 交付件的验收以SOW中对交付件的描述和要求为准; 对交付件的验收应着重于对文档实质内容的验收,凡交付件实质内容符合本工作说明书约定的,应予通过验收和接受。少量格式、词汇、修饰等方面的不符不应被作为不验收的理由,但华为应就格式、词汇、修饰等方面的不符处按客户要求在合理的时间内进行修改; 在项目进程中,所有交付件都将经过客户和华为日常讨论和评审,以保证双方对文档内容的认识一致并缩短交付件的验收时间。客户应对华为提出的意见或要求及时提供其建议及批准。根据项目的实际情况,部分或所有交付件在验收签署之前将经过项目组评审、业务部门评审、并向领导组汇报。客户应负责在SOW约定的验收时点前推动(包括组织和安排顾问资源)并及时完成所有内部评审和汇报; 华为将根据上述评审和汇报的反馈意见,在5个工作日内完成对交付件的修改,并在指定的工时内提供全部服务由客户验收; 如果因非华为原因导致完成交付件审核和批准需要更多的时间,华为项目组将依据按工作说明书定义的变更控制流程签订的变更申请延展团队工作时间并获得相应付款; 在交付件验收签署后,如果要求对任何交付件的内容作增减,华为将对该增减所带来的工作复杂性及风险性进行评估(如对服务费用、时间计划和资源配备等的影响),包括由此带来项目费用及时间计划的更改,在得到双方的同意后予以执行; 对“企业软件研发能力诊断” 服务的交付件验收应着重于文档实质内容,凡交付件实质内容经客户确认,应予以验收通过。
  • 服务内容 服务项 服务内容 企业软件研发能力诊断-园区版 主要针对区域政府客户提供的批量企业诊断套餐,从多维度对10个团队的研发能力进行评估,展现企业研发能力的优势与不足,并给出提升优化建议和解决方案,牵引企业持续提升研发能力。园区版可叠加购买 企业软件研发能力诊断-标准版 主要针对单个公司提供的诊断服务,从多维度对一个团队的研发能力进行评估,展现企业研发能力的优势与不足,并给出提升优化建议和解决方案,牵引企业持续提升研发能力 企业软件研发能力诊断-增量包 主要针对单个公司研发团队较多时提供的诊断服务增量包,从多维度对一个团队的研发能力进行评估,展现企业研发能力的优势与不足,并给出提升优化建议和解决方案,牵引企业持续提升研发能力。需要先购买标准版再购买增量包
  • 责任分工 共同责任 双方商定并确认具体服务目标及范围; 完成合同签订。 客户 提供详细准确的需求和场景; 诊断期间,客户需要指派一位项目负责人协助华为云专家,便于项目的顺利落地。此负责人应该承担双方的协调管理,并审核、验收华为云服务; 客户方需要协调具体的人员配合华为云专家达成企业软件研发能力诊断服务的实施,包括但不限于业务人员、管理人员、技术骨干等; 审核并确认华为提供的赋能计划和交付件。 华为云 接收用户的赋能申请,协调敏捷与DevOps专家赴与客户商定地点进行赋能; 赋能前,按照客户所选服务项,制定赋能计划和报价清单供客户审核确认; 赋能期间,依确认后的计划为指定学员进行赋能和技术指导; 赋能结束后,根据所选赋能服务项,出具交付件清单。
  • 服务交付件 将交付件整理后邮件提供给客户审阅,待客户负责人审阅通过并确认签字,赋能完成。交付件包括: 服务项 服务子项 交付件 备注 企业软件研发能力诊断 收集企业信息 《企业基本信息收集表.docx》 企业软件研发能力诊断-增量包不涉及该交付件 制定诊断计划 《诊断服务计划表.docx》 现场调研与访谈 - 制定调研总结 《企业研发能力诊断评估报告.docx》 编写诊断报告草案 《XX公司软件研发能力诊断报告.pptx》 专家评审 - 诊断报告定稿 《XX公司软件研发能力诊断报告.pptx》 《企业研发能力诊断评估报告.docx》 《区域诊断报告-华为XX合作调研报告模板.docx》(仅园区版涉及) 解读诊断报告 《XX公司软件研发能力诊断报告.pptx》 《区域诊断报告-华为XX合作调研报告模板.docx》(仅园区版涉及) 企业软件研发能力诊断-增量包不涉及该交付件 客户验收(企业/政府) -
  • 责任矩阵 阶段 服务条目 客户 华为 备注 阶段一:前期准备 收集企业信息 R S 企业软件研发能力诊断-增量包不涉及该服务条目 制定诊断计划 S R 阶段二:研发能力调研与诊断评估 现场调研与访谈 S R - 制定调研总结 S R - 编写诊断报告草案 S R - 专家评审 S R - 诊断报告定稿 S R - 阶段三:诊断验收 解读诊断报告 S R 企业软件研发能力诊断-增量包不涉及该服务条目 客户验收(企业/政府) R S
  • 修订记录 发布日期 修订记录 2023-06-12 第十次正式发布。 部署服务修改环境配置,增加主机器群管理。 2023-02-25 第九次正式发布。 代码托管更新UI。 部署增加环境配置。 2023-02-16 第八次正式发布。 CloudIDE服务更名为CodeArts IDE Online。 代码检查、流水线上线新版UI。 2022-12-07 第七次正式发布。 软件开发平台更名为软件开发生产线。 项目管理服务更名为需求管理。 2022-08-11 第六次正式发布。 根据产品新UI布局更新截图。 2022-06-30 第五次正式发布。 在“部署应用(云容器引擎)”章节中,根据CCE服务新UI更新“购买并配置CCE环境”说明。 在“释放资源”章节中,根据CCE服务新UI更新“删除集群”说明。 2022-06-10 第四次正式发布。 在“实践准备工作”章节中,增加“开通软件开发生产线”说明。 2021-10-10 第三次正式发布。 在“构建应用”章节中增加“配置基础依赖镜像”说明。 在“部署应用(云容器引擎)”章节中增加“调整yaml文件配置”说明。 2021-03-09 第二次正式发布。 在附录中增加“构建加速”说明。 2020-10-21 第一次正式发布。 父主题: 华为端到端(HE2E)DevOps实践
  • 云原生Cloud Native的“纹身” Native的意思是辅助、原生,DevOps与Cloud Native背后共同的东西是文化。DevOps不仅是我们的工作内容,更是工作方法,同时也在形成一种工作的文化。 华为Cloud Native转型之路,也是把文化赋予华为的研究过程的纹身过程。这是基于DevOps的精髓和支柱。 华为在云端领域的DevOps是云的基座,云渗透在ICT的很多领域,目前华为云推出一百多个云上的服务。在云的基座上,TATO所代表的内容是:T代表Team(团队),A是Architecture(架构),T是Tools(工具),O是Operations(运维)。 DevOps实践的第一步是来自于人的思想和观念的转变、科学的变化,科学的背后是思想和理论的变化,文化需要人在思想上做出改变,也需要人去承载这种思想改变。华为CodeArts转型经历了几个阶段,最初华为以盒子类的通信设备为主,盒子是以前大规模的软件开发过程,软件都是上亿行甚至几亿行代码的软件,要求可靠、稳定,每一款通信设备都有很长的研发周期。
  • 华为公司管理过程的变化 《科技想要什么》一书中,将科技比作生物。生物是在不断进化,伴随着科技生物的进化,科技生物的研发方法也在不断的进化。华为公司在过去三十年,从小型做硬件、做CT通信产品的公司,成为跨ICT公司,研发理念和思想上也在不断变化。经历了初步的CMM持续交付、持续集成到敏捷、DevOps,直到最新的进化状态CodeArts。下图是华为公司在过去三十年研发能力和研发方法以及研发的工具进化的过程。