首页>>互联网>>DevOps->中国devops有哪些(2023年最新整理)

中国devops有哪些(2023年最新整理)

时间:2023-12-02 本站 点击:0

导读:今天首席CTO笔记来给各位分享关于中国devops有哪些的相关内容,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

关于DevOps 的那些事

在2008年多伦多举办的敏捷大会(Velocity Conf 2008 )上,Patrick DeBois 和AndrewClay Shafer 先生首次提议讨论“敏捷基础架构”这个话题。在第二年的敏捷大会上有一个具有里程碑的意义技术分享,来自Flickr公司《每天部署10次》的分享,它激发了随后Patrick DeBios在同年十月,在比利时的根特市举办的首届DevOpsDays活动,这个活动是两天的日程,为了大家方便在twitter上的传播,人们把DevOpsDays这个词简写为 “#DevOps” 。 此后,“DevOps”一词问世了,这个词所包含的理念和实践一时在越来越广大的人群中产生了共鸣,随后成为全球IT界在各种大会和论坛里热议和讨论的焦点话题,很多大型IT论坛也都开设出了DevOps专题讨论。这就是DevOps这个词的由来。

DevOpsDays活动随后在Patrick DeBios等相关核心发起人的推动下,在全球范围内蓬勃发展了起来。2010年在美国山景城(Mountain View) 举办的DevOpsDays 活动中,Damon Edwards先生使用“CAMS”这个缩写,高度概括和诠释了DevOps,即文化(Culture)、自动化(Automation)、度量(Measurement or Metrics)和分享(Sharing)。随后Jez Humble先生将“L”精益 (Lean) 原则也加入其中,最终变成了CALMS。

♣ Culture(文化)- 是指拥抱变革,促进协作和沟通

♣ Automation(自动化)- 是指将人为干预的环节从价值链中消除

♣ Lean(精益)- 是指通过使用精益原则促使高频率循环周期

♣ Metrics(指标)- 是指衡量每一个环节,并通过数据来改进循环周期

♣ Sharing(分享)- 是指与他人开放分享成功与失败的经验,并在错误中不断学习改进

“CALMS”完全吻合Patrick DeBois先生所一向倡导的“DevOps is a human problem” (DevOps 是关于人的问题) 的理念 。

从DevOps概念的产生,到如今它在全球范围内的蔓延和认同,已经经历了9个年头的时间。它的火爆推广也伴随着IT行业的迅速变迁和发展,现在已经到了移动互联网时代的后半场,国内的信息化建设已经完成了很多年;如今各行各业的企业也都亟待完成全方位的数字化转型。IT信息技术的先进程度标志着一个企业的核心能力,任何一个成功的企业,敏捷高效的软件开发创新实力和IT管理综合能力不只是门面而已,而是实实在在的市场竞争能力。DevOps倡导打敏捷、持续交付和ITIL三种实践的组合拳,同时应用精益生产理念为基础的管理思想,这正在逐渐地被广泛的接受和认可。

在过去的几年中,国内的各种IT大会也蓬勃发展,其中DevOps相关的专题和分会场也颇受人们的关注。各种云计算、运维等IT技术的社交媒体也都非常重视DevOps这个话题的分享。一个专属于DevOps社群的、国际性的、有影响力的DevOps大会正呼之欲出。在这样的时代背景下DevOpsDays大会北京站在2017年的3月18日来到中国,在同年的8月18日上海,还要举办DevOpsDays Shanghai站的大会。

下面列举一些DevOpsDays大会的相关数据,数据来源于DevOpsDays.org 网站。从2009年到2016年,已经在全球的61个城市/国家成功地举办了117场。

下图是在过去九年中DevOpsDays大会在各个城市/国家的分布和举办次数。

今年也就是2017年预计举办30场,其中已经有18场确定了举办城市和日期;还有12个城市的召开日期待定;这不包括年内还可能会提出申办的城市。以上数据的统计时间在2017年三月。

随着国内BAT等互联网巨头的崛起,互联网公司的开发运维经验也越来越多的在国内的各种技术大会上传播。从最近这两年(2016年和2017年)的技术活动日程中可以看出,国内互联网从业人员也不约而同的用DevOps来定位和分享自己的优势和经验。他们是传播和分享运维侧DevOps实践的先头部队。

出了技术论坛的分享之外,很多线上线下的大会、论坛和讨论组也都越来越热议DevOps这一专题。国内其它相关流派的人群,例如敏捷和精益等,也对DevOps的蓬勃发展表示比较惊讶,DevOps与老牌的敏捷和精益等阵营也产生过一些争论。但这一切的发生也都增加了人们对于DevOps的更深入的兴趣。

在培训认证这方面,Exin DevOps Master是一个国际认证的培训;其它公司和组织也正在举办关于DevOps工具链的培训,这些培训则注重于技术实操,关注在构建端到端的流水线的搭建方面。从DevOps的职位招聘方面,可以看到DevOps工程师相关的职位越来越多了,在职位需求中DevOps这个技能成了加分项,DevOps相关工具的技能也或将成为简历的亮点。在IT行业内不管是开发还是运维团队的人,都开始了学习和接受的过程。

据我观察DevOps方面的厂商在最近3年呈现爆炸式的发展。我把他们分为三类:

目前国内大部分企业慢慢地开始关注了DevOps,大型传统企业也开始逐渐地从各个角度做试点和尝试。试点的角度和方向各不相同,有的从底层基础架构的容器化开始,有的从交付部署流水线的自动化开始;总的来说还处于初级的尝试阶段,还没有大规模成体系的推广。

综上所述,目前国内DevOps发展的阶段还属于起步阶段。就像是ITIL/ITSM在2003年左右的状态。由于DevOps是去中心化的,所以没有唯一、权威的上游厂商的存在,各种理论实践的争执和PK都将终止与解决问题和提高效率的话题上,因此它具有百花齐放百家争鸣的发展条件。个人认为DevOps的实施和落地也不会完全依赖于传统的大型咨询厂商的咨询工作,由于它应该是在企业的内部,在内驱的作用下,自生长出来的;它必须是服务于企业的业务价值流的优化,加速业务价值产出的;而与之相关的工作和责任的担当,外部力量是很难以等量替换和承担的。

在谈这个话题前先看一下DevOps相关工具集的全貌,如下图所示:

最上面的箭头流程图表示了一个业务服务的全生命周期:开发协作、软件构建、质量测试、交付部署和投产运维。前三个阶段偏传统开发组织的工作内容,后两个阶段基本可以和运维组织的工作对应上。在每个阶段下可以看成是一个大分类,这些分类中还包含若干个小分类。这些工具可以粗放的划分为商业软件和开源软件两类;也可以分为SaaS服务类和企业内部部署型。大部分开源工具都有活跃的用户社区和群众基础,这给企业入手这些工具带来了很大的便利。在需要商业支持的场景里还可以选择使用这些开源软件的企业版。

Docker容器技术在最近三年中异军突起,持续交付的技术门槛因此被降到最低,软件生产供应链的格局和效率被彻底提升;基于Docker的微服务架构实践的热度和成熟度也与日俱增。因此,国内的传统企业纷纷试水DevOps和容器技术,在最近两年的各种技术大会中,我们可以看到国内各个行业出现了在不同维度上的DevOps先行者。他们分享的主题大多集中在自动化运维、容器化和PaaS平台的等项目经验。

从国内众多DevOps实践中,我们能看到下面三个技术尤其重要和火热:

以上三种技术相辅相成,有着比较深刻的关联。首先微服务和持续部署各自解决了特别多的传统IT的问题,这些问题都是长期以来制约企业业务发展的难题。容器技术由于它的快速、轻量、微服务化的天然特性,很好的从不同侧面支持了持续交付和微服务架构。容器可以为持续交付提供弹性和高速的系统资源,环境管理和利用率提高了很多;容器的不可变性的特点也更好地支持了微服务架构。

我把DevOps的按照不同的技术特征做了从到1.0 到2.0的时代划分,并尽量通过以下维度比较与传统方式的差异。

我比较认可和接受的企业实践DevOps参考框架如下,其中包含了所需的最佳实践,如下图所示。

(上图来源于:Exin DevOps白皮书)

下面简要描述一下这四大支柱型最佳实践:

由此可见DevOps在企业,特别是大规模传统企业的落地和推广还是比较复杂的。虽然相关的最佳实践都是已经存在了很多年的;但是,通过DevOps的价值观重构企业从研发到交付到运维的价值流谈何容易。基于我的IT从业经验,我似乎感觉到DevOps不能单独依靠自顶向下的推广,当然高层领导的支持依然是重要的和必备的支持条件之一。 可能还需要中层的带动和底层的创新;借鉴生产制造业已经久经考验的精益制造实践也是势在必行。总之DevOps运动会在近几年给IT行业带来较大影响。

国内有哪些好些的项目管理软件

主流项目管理软件大概就是Oracle、SAP、Microsoft、智邦国际等等,项目管理解决方案帮助企业有效管理与调整项目及其相关资源,从项目的建立到中间运转再到最终项目任务的全面完成,贯穿着项目的整个生命周期。通过登录、交互和查询分析,使项目的参与者及时地了解和掌握项目运行的综合状况,把握项目的进度,控制项目的成本,实现项目效益的最大化,保证项目的顺利执行和各相关方之间协同的执行项目任务和工作。主要功能集客户、会员、代理商、经销商、批发商、零售商、用户、粉丝管理于一体,客户身份快速识别,客户信息一键查询,客户咨询实时响应。统一管理全渠道客户,打造线上线下全部打通的客户管理体系,客户场景数据全部留存,客户鉴别、变更、服务,杜绝客户流失。

极狐(GitLab)宣布完成A轮融资,专注DevOps开源生态建设和产品打磨

36氪获悉,极狐(GitLab)于今日正式宣布完成数亿元级别的A轮融资。本轮融资分两阶段进行,第一阶段由淡马锡领投,Alpha Prime、纪源资本、上海人工智能产业基金和诺基亚成长基金跟投;第二阶段由泰康人寿领投,干杯基金和联想创投跟投。创始股东红杉宽带和高成资本也持续加注。本轮融资资金将用于产品研发团队扩充、市场开拓、开源生态建设以及自主知识产权研发 ,扩充本土开源生态,更好服务本土用户和客户,提高本土企业抗风险能力。

根据资料,极狐公司正式成立于2021年3月18日,脱胎于开源平台GitLab。GitLab成立于2014年,主营业务是提供开源的DevOps平台,帮助开发者实现线上合作开发以及版本控制。据了解,GitLab面向企业私有仓库服务的能力让企业开发团队对他们的代码仓库拥有更多的控制,这也是其区别于其他竞品的主要特点。在商业化进展上,该公司已于去年在美股上市,当前市值在70亿美元左右。2021年3月,GitLab宣布成立中国合资公司 “极狐信息技术(湖北)有限公司”,合资方包括红杉宽带、高成资本——这也是极狐公司的由来。

极狐公司创始人兼CEO陈冉介绍,极狐公司的业务主要聚焦于开源生态建设和自主产品研发、运营两方面。首先,开源是GitLab的主打标签之一,极狐公司也将开源建设视为重点。具体来说,极狐公司在2021年5月,携手云原生计算基金会(CNCF)联合发起成立了开源GitOps产业联盟(OGA联盟)。目前为止,共有接近100家会员单位参与其中。

另外在2022年2月9日,极狐公司也发布了DevOps相关的SaaS产品。官网信息显示,极狐当前的产品是GitLab DevOps平台的中国发行版,即一套覆盖管理、规划、创建、验证、打包、发布、运维等环节的一站式DevOps平台,可以帮助团队提高生产效率,将迭代周期从数周缩短至几分钟,加快软件创新发布速度的同时节省开发成本。据公司介绍,当前极狐已有180多个客户。

关于GitLab Inc.和极狐公司之间的关系,公司表示,极狐公司在今后的运营中享有GitLab源代码的持续同步授权,并且无需向其支付任何许可费(License Fee)。GitLab项目在全球拥有超过2600个贡献者的开源社区,其源代码保持每月更新的频率,而更新后的版本均会持续同步独家授权给极狐公司。GitLab和极狐公司使用两个独立的代码仓,其中GitLab的代码仓为上游,极狐公司的代码仓为下游。GitLab社区版和企业版的变更将持续同步到极狐版。极狐公司对极狐版本的更新遵循GitLab为全球贡献者制定的协议,向社区版和企业版进行贡献,将符合GitLab对安全和代码质量的严格标准。据介绍,不到一年时间,极狐公司已经成为除GitLab Inc.以外最大的GitLab开源社区贡献者。

极狐公司创始人兼CEO 陈冉表示,GitLab永久IP的授权,是极狐公司运营的起点—这能让极狐在国内以原厂的身份帮助国内的客户享受到GitLab原厂服务。其进一步解释,极狐公司拥有独立自主的开发权,其目标和愿景是基于GitLab,超越GitLab。所以随着自身技术不断地发,自研产品不断成熟和开源生态不断演进,他认为极狐公司会真正超越GitLab。

并且作为一家独立的公司,极狐公司将管理自己的技术和基础设施——其SaaS服务(jihulab.com)和Gitlab, Inc.的SaaS服务(GitLab.com)将不共享任何基础设施、网络连接、系统、服务、数据或资源。此外,极狐公司为中国用户建立拥有自主知识产权(IPR)的JH代码仓目录,并持有独立知识产权,实现100%的本地化独立运营。在独立性方面,陈冉和投资人强调,本轮融资完成后,外资股东 GitLab Inc. 持股比例将下降到50%以下,进一步落实由中方主导的独立运营体系,极狐公司董事会依然由中方主导。

本轮融资后,公司也计划在自研产品、市场推广的同时,接触更多人民币基金,希望进一步促进极狐(GitLab)的本土化进程。

Devops现在有哪些已知开源的软件和平台?

推荐前几天刚刚开源的一个平台Choerodon猪齿鱼,包含敏捷管理、开发流水线、应用和部署流水线、微服务开发和运营管理等模块。

Choerodon猪齿鱼平台基于DevOps思想和微服务架构设计理念,利用容器技术将敏捷管理、持续交付、运营管理、微服务框架、容器编排等相关开源工具整合为基于容器的企业级应用PaaS平台。

结语:以上就是首席CTO笔记为大家介绍的关于中国devops有哪些的全部内容了,希望对大家有所帮助,如果你还想了解更多这方面的信息,记得收藏关注本站。


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:/DevOps/8199.html