软件开发平台 DevCloud软件开发平台 DevCloud

计算
弹性云服务器 ECS
裸金属服务器 BMS
云手机 CPH
专属主机 DeH
弹性伸缩 AS
镜像服务 IMS
函数工作流 FunctionGraph
云耀云服务器 HECS
VR云渲游平台 CVR
特惠算力专区
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
弹性文件服务 SFS
存储容灾服务 SDRS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属企业存储服务
云存储网关 CSG
专属分布式存储服务 DSS
CDN与智能边缘
内容分发网络 CDN
智能边缘云 IEC
智能边缘小站 IES
智能边缘平台 IEF
人工智能
AI开发平台ModelArts
华为HiLens
图引擎服务 GES
图像识别 Image
文字识别 OCR
自然语言处理 NLP
内容审核 Moderation
图像搜索 ImageSearch
医疗智能体 EIHealth
园区智能体 CampusGo
企业级AI应用开发专业套件 ModelArts Pro
人脸识别服务 FRS
对话机器人服务 CBS
视频分析服务 VAS
语音交互服务 SIS
知识图谱 KG
人证核身服务 IVS
IoT物联网
设备接入 IoTDA
设备管理 IoTDM(联通用户专用)
全球SIM联接 GSL
IoT开发者服务
IoT数据分析
车联网服务 IoV
路网数字化服务 DRIS
IoT边缘 IoTEdge
设备发放 IoTDP
开发与运维
软件开发平台 DevCloud
项目管理 ProjectMan
代码托管 CodeHub
流水线 CloudPipeline
代码检查 CodeCheck
编译构建 CloudBuild
部署 CloudDeploy
云测 CloudTest
发布 CloudRelease
移动应用测试 MobileAPPTest
CloudIDE
Classroom
开源镜像站 Mirrors
应用魔方 AppCube
云性能测试服务 CPTS
应用管理与运维平台 ServiceStage
云应用引擎 CAE
视频
实时音视频 SparkRTC
视频直播 Live
视频点播 VOD
媒体处理 MPC
视频接入服务 VIS
管理与监管
统一身份认证服务 IAM
消息通知服务 SMN
云监控服务 CES
应用运维管理 AOM
应用性能管理 APM
云日志服务 LTS
云审计服务 CTS
标签管理服务 TMS
资源管理服务 RMS
应用身份管理服务 OneAccess
区块链
区块链服务 BCS
可信跨链服务 TCS
智能协作
IdeaHub
开发者工具
SDK开发指南
API签名指南
DevStar
HCloud CLI
Terraform
Ansible
API问题定位指导
云生态
云市场
合作伙伴中心
华为云培训中心
其他
管理控制台
消息中心
产品价格详情
系统权限
我的凭证
客户关联华为云合作伙伴须知
公共问题
宽限期保留期
奖励推广计划
活动
容器
云容器引擎 CCE
云容器实例 CCI
容器镜像服务 SWR
应用编排服务 AOS
多云容器平台 MCP
基因容器 GCS
容器洞察引擎 CIE
云原生服务中心 OSC
容器批量计算 BCE
容器交付流水线 ContainerOps
应用服务网格 ASM
网络
虚拟私有云 VPC
弹性公网IP EIP
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
虚拟专用网络 VPN
云连接 CC
VPC终端节点 VPCEP
数据库
云数据库 RDS
数据复制服务 DRS
文档数据库服务 DDS
分布式数据库中间件 DDM
云数据库 GaussDB (for openGauss)
云数据库 GaussDB(for MySQL)
云数据库 GaussDB NoSQL
数据管理服务 DAS
数据库和应用迁移 UGO
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
可信智能计算服务 TICS
推荐系统 RES
云搜索服务 CSS
数据可视化 DLV
数据湖治理中心 DGC
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
应用中间件
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
API网关 APIG
分布式缓存服务 DCS
分布式消息服务RocketMQ版
企业应用
域名注册服务 Domains
云解析服务 DNS
云速建站 CloudSite
网站备案
华为云WeLink
会议
隐私保护通话 PrivateNumber
语音通话 VoiceCall
消息&短信 MSGSMS
云管理网络
SD-WAN 云服务
边缘数据中心管理 EDCM
云桌面 Workspace
应用与数据集成平台 ROMA Connect
ROMA资产中心 ROMAExchange
API全生命周期管理 ROMA API
安全与合规
安全技术与应用
DDoS防护 ADS
Web应用防火墙 WAF
云防火墙 CFW
应用信任中心 ATC
企业主机安全 HSS
容器安全服务 CGS
云堡垒机 CBH
数据库安全服务 DBSS
数据加密服务 DEW
数据安全中心 DSC
云证书管理服务 CCM
SSL证书管理 SCM
漏洞扫描服务 VSS
态势感知 SA
威胁检测服务 MTD
管理检测与响应 MDR
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
专属云
专属计算集群 DCC
解决方案
高性能计算 HPC
SAP
游戏云
混合云灾备
华为工业云平台 IMC
价格
成本优化最佳实践
专属云商业逻辑
用户服务
帐号中心
费用中心
成本中心
资源中心
企业管理
工单管理
客户运营能力
国际站常见问题
支持计划
专业服务
合作伙伴支持计划
更新时间:2021-03-18 GMT+08:00
分享

DevOps面面观

本文将从以下几个问题入手,阐述DevOps方方面面的理解,希望通过本文的解读,能对DevOps有更全面更深的认识,并能将DevOps的理论与实践在日常工作中落实。

在开始正式的内容之前先让我们思考以下几个问题:

  1. “快速将产品推向市场” 与 “提供稳定、安全并可靠的IT服务” 是否可以兼得?
  2. 用更少的资源完成更多的业绩,既要保持竞争力,又要削减成本;
  3. 如何解决任务交接出现的问题,例如业务与开发,开发与运维之间;
  4. 运维人员能否和其他人一样,正常上下班,而不用在夜里或者周末加班?

什么是DevOps?众说纷纭

  • WikiPedia上说:“DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。”
  • 百度百科说:“DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。”
  • IBM这样说:DevOps是企业必备的持续交付能力,通过软件驱动的创新,保证组织抓住市场机会,同时减少反馈到客户的时间。

DevOps不只是开发与运维的问题

一般而言,开发与运维有着不同的文化:开发部门的驱动力通常是“频繁交付新特性”,而运维部门则更关注IT服务的可靠性和IT成本投入的效率,降低风险。两者目标的不匹配,在开发与运维部门之间造成了鸿沟,从而减慢了IT交付业务价值的速度。运维从维稳出发,自然希望生产系统部署上线次数越少越好,而上线频度降低,对开发人员是一个负激励:反正我发布的版本也不会上线,反正我再积极也不能实时的体现出来,团队积极性和人员士气都会受到打击。

与此同时,业务部门则希望业务需求尽快的推向市场,而维稳的要求导致价值交付用户的速度被延缓,价值无法迅速得到反馈验证。

发布列车变成3个月一趟车次时,业务人员习惯于自己的需求无法快速得到满足,能想出的方法就是把所有的业务需求都设置成最高优先级,去抢占发布窗口。所有人都这样想这样做,拥堵就此产生,真正高价值的需求无法得到快速交付。(试想,如果每天有十次发布,大家还会拼得头破血流去抢一个发布窗口么?)

上线频度低的另一个副作用是,单次上线中包含的变更规模变大,风险也随之增加。事实上,减少上线次数不仅不会降低风险,反而让每一次上线都变得像一个火药桶,危机四伏。

从大处着眼

究其根本,DevOps目的是提升业务交付能力

  • 如何快速的交付想法?
  • 如何让客户进行尝试(从而获取反馈)?
  • 如何快速响应客户反馈?

DevOps不应该只是IT内部的几个部门玩的游戏。必须跳出IT的角度,端到端(业务端到客户端)分析,才能弄清公司需要依靠IT的哪些工作来支撑业务目标,支撑企业战略 ,从而实现更完整、真正的DevOps。需要将IT变成一种能力,融入公司的日常运作中,融入业务活动中。在快鱼吃慢鱼的时代,需要快速试错,不断整合来自市场的反馈。

所以最终,DevOps是一个端到端的问题,是产品管理部、开发部、测试部、IT运维部、信息安全部协同工作、共同支持。DevOps尝试建立一个业务价值交付管道,业务规划、需求梳理、计划、开发、构建、测试、部署、运维、监控 ,在此交付过程中涉及到的部门/团队、过程、系统、方法都归属于DevOps关心的内容。

从小处下手

理解了DevOps是一个端到端的过程,我们就会发现整个交付链条涉及太多的领域,导致问题也层出不穷,无从下嘴。因此在实际操作中,我们需要有一个切入点

DevOps的思想以精益与敏捷为核心,通过暴露问题、解决问题,从而实现持续改进。从精益的角度看,在代码投产之前,实际上未产生任何价值,都只是半成品。 要限制半成品,即在制品(WIP)数量,让其尽快流过生产线,让投入产生交付价值。

DevOps是一个复杂问题,我们却希望可以把一个复杂的问题简单化:正如装修时通过加压检查管道是否泄露,是否有阻塞,我们也通过加压的方式来暴露软件交付管道的问题。那么如何加压?以终为始,我们选择业务价值交付的那个点,也就是部署与发布来对整个交付管道进行加压。团队可以简单的问自己一个问题:“能不能一天部署10次?”如果没有办法?那么原因何在?流程不规范?自动化不够?沟通导致效率低下?过程无法复用?环境差异导致回归出错?逐一的暴露问题,解决问题,交付能力自然提升。

需要注意的是,根据《凤凰项目》中提到的TOC约束理论(Theory of Constraints),在瓶颈之外的任何地方做出的改进都是假象,在瓶颈之后做的任何改进都是徒劳的,因为只能干等着瓶颈把工作传送过来,而在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。所以如何识别真正的瓶颈变得尤为重要,在发现问题之后多问几个为什么,力求找到根源原因。

  • DevOps的由来

    Flickr公司的约翰·阿尔斯帕瓦和保罗·哈蒙德在2009年Velocity技术大会关于开发速率的一场演讲,“一天十次部署”,是2009年前后兴起的DevOps运动的一部分,提倡开发和IT运维通力协作,在完成高频率部署的同时,提高生产环境的可靠性、稳定性、灵敏性和安全性。2009年一天十次部署就算很快了,但现在只能算平均水平,2012年亚马逊公司宣布,他们平均每天能开展23000个部署。

    公司

    部署频率

    交付周期

    Amazon

    23000次/天

    分钟

    Google

    5500次/天

    分钟

    NetFlix

    500次/天

    分钟

    Facebook

    1次/天

    小时

    Twitter

    3次/周

    小时

    一般企业

    1次/9个月

    月、季度

    Wikipedia上说,有以下几方面因素可能促使一个组织引入DevOps

    • 使用敏捷或其他软件开发过程与方法
    • 业务负责人要求加快产品交付的速率 (新兴技术趋势,例如云计算、移动应用、大数据和社交媒体)
    • 虚拟化和云计算基础设施(可能来自内部或外部供应商)日益普遍
    • 数据中心自动化技术和配置管理工具的普及
    • 传统的管理方式导致“烟囱式自动化”,从而造成开发与运维之间的鸿沟

通过加大部署/发布频度来撬动整个交付过程

以应用部署自动化作为切入点,由部署自动化,往前倒逼测试自动化、构建自动化;进一步往前,配置管理、变更管理是基础要求;再往前,业务需求与敏捷计划同步关联,通过短周期迭代交付与反馈,加强业务与开发的协作沟通。

同样的,往后端与运维衔接,更小、更频繁的变更,需要让开发人员更多地控制生产环境,更多地以应用程序为中心来理解基础设施;需要定义简洁明了的流程,并尽可能地实现自动化,从而在完成高频率部署的同时,提高生产环境的可适应性。与此同时,可靠性、稳定性、弹性和安全性也同时提升。

由此也促成了开发与运维的协作,通过不断缩减批量规模,实现快速工作流,确保了部署环境时刻准备就绪,按需投产。频繁的发布、意味着每次发布包含的变化更少,每次部署不会对生产系统造成巨大影响,应用程序会以平滑的速率逐渐生长,逐步协调和弥合开发与运维之间的技能鸿沟和沟通鸿沟。

DevOps要实现:自动化、标准化、配置化

  • 自动化:全面自动化,构建、部署、测试、升级、扩展、维护、数据卫生、监测、安全和策略管理。通过自动化,倒逼团队高效沟通,倒逼流程规范;自动化手段确保部署任务的可重复性、减少部署出错的可能性。
  • 标准化:(流程,环境,配置)基础环境标准化,运行环境标准化,应用环境标准化/多样化。
  • 配置化:通过配置,尽量避免代码,通过功能开关或者参数设置,来支持A/B testing、灰度发布。

DevOps与云

DevOps要支持云,虚拟化与云技术可以带来DevOps要求的标准化以及自动化。

  • 环境标准化

    无论是针对基础设施还是运行时环境都要求环境标准化,并把这些环境投入开发、QA和IT运维的日常使用,这样就能消除大部分在部署流程中因为差异而导致的问题。不仅应该拿出可部署的代码,还应该拥有部署这些代码的确切环境,并在版本控制中一并控制与检查。

  • 混合云下的DevOps诉求

    在云的场景下,如何利用虚拟化、容器等技术加速环境的创建以及标准化,如何通过自动化的方式加快环境搭建,如何在On-Prem、私有云、公有云,不同厂商不同类型的云的混合模式下,统一流程,统一DevOps的用户感受。

    同时,由应用层的自动化部署,同样可以发现Infrastructure层、Runtime层的问题,虚拟化与云的技术也与DevOps相辅相成,相得益彰。

  • 华为云DevCloud服务

    DevCloud提供软件开发全生命周期的云端DevOps工具链,帮助团队真正实现自动化,标准化,配置化。

    DevCloud提供基于Git的版本控制系统,不只将代码版本化,而是版本化管理一切与环境有关的配置。

    可自定义的自动化部署流水线,提交代码自动触发,帮助团队实现持续交付,为团队带来自动化,标准化。

DevOps实践

  • 不做什么比做什么更重要:相比起向系统中投入更多的工作,将无用的工作剔出系统更为重要;无用的工作、无用的项目、无用的产品,排优先级,筛选出哪些是真正重要的工作。
  • 运维参与研发评审:常见的现象是,运维人员很少被邀请参与架构决策或代码评审,开发代码是否会影响运维环境前期无人知晓,需要让运维人员参与架构评审,从运维角度提出对系统的要求。
  • 非功能性需求同样重要:偿还技术上的债务。每个人都像重视功能性要求一样重视非功能性要求QoS(质量、稳定性、可维护性、持续性、可扩展性、可管理性、安全性、可操作性),非功能性需求对于实现业务目标同等重要,要把非功能性需求设计到产品当中。
  • 整体协作:产品所有者、开发部、QA、IT运维部以及信息安全部通力协作,帮助彼此乃至整个企业取得胜利。
  • 质量为先:上游团队不再给下游团队造成麻烦,开发部将20%的时间用于帮助确保工作顺利的通过整个价值流,加快自动化测试,改进部署基础架构,并确保所有应用程序建立有用的产品遥测。
  • 基础架构即代码(Infrastructure as a Code)
    • 把创建和部署流程自动化,把基础架构当成代码一样对待。
    • 各套环境之间,代码版本、运行时、环境配置需要匹配。
    • 需要将基础环境配置化、版本化管理。
  • 运维服务化:DevOps会让开发部门承担更多的代码部署和维持服务水平的责任,要求把许多IT运维任务转变为自助服务。
  • 版本化一切(Versionlize Everything):应该把所有东西都进行版本控制,不只是代码,而是创建环境所需的每一样东西。
  • ITIL:为了适应DevOps更短的交付周期和更高的部署频率,ITIL流程的很多方面都需要自动化,特别是变更、配置和发布流程等。
  • 云计算:有效的利用云技术,可以为开发和测试人员动态设置基础架构资源,快速获得测试环境。
  • 针对类生产系统进行开发和测试 (环境的标准化),利用可重复的可靠流程进行部署,监控并验证运维质量;
  • 放大反馈回路:快速反馈回路,防止问题代码进入生产环节,并且让代码能够迅速部署投产,从而迅速发现并修复任何产品问题。(编写代码时,单元测试、集成测试、验收测试一直在类生产环境运行,不断确认,代码和环境将会按照预先设定的运行,并且总是处于可部署状态)

DevOps与精益、敏捷

DevOps是基于敏捷与精益原则的方法。DevOps是软件开发生命周期(SDLC)从瀑布式到敏捷再到精益的发展。

DevOps超越了敏捷,它的关注点是从SDLC中移除浪费。通常情况下,发现浪费或者瓶颈的形式包括:不一致的环境、人工的构建和部署流程、差的质量、IT部门之间缺少沟通和理解、频繁的中断和等待、部分完成的工作、额外的功能、任务切换等。

DevOps强调流水线,交付管道,与传统生产与制造业有着千丝万缕的联系。

DevOps实施中,可以借鉴精益理论中的很多思想,例如:降低批量规模、减少半成品、缩短并增强反馈回路、价值流图分析、时间线分析、消除浪费,以及敏捷中持续集成、持续测试、持续交付、持续监控、A/B测试、灰度发布、滚动更新等。

三步工作法

目前行业中通常采用三步工作法以实现DevOps:

  • 第一工作法:帮助理解在工作从开发移向IT运维时该如何建立快速工作流

    从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化,需要小的批量规模和工作间隔,绝不让缺陷流向下游工作重心,并且不断为了整体目标(相对于开发功能完成度、测试发现/修复比率或运维有效性等局部目标)进行优化。

    必要的做法是:看板、持续构建、集成以及部署,按需创建环境,严控半成品,以及构建起能够顺利变更的安全系统和组织。

  • 第二工作法:如何缩短以及放大反馈环路,从而在源头解决质量问题。

    价值流各阶段自右向左的快速持续反馈流,放大其效益以确保防治问题再次发生,或者更快的发现和修复问题。这样我们就能在所需支出获取或潜入知识,从源头上保证质量。

    必要的做法是:

    • 在部署管道中的构建和测试失败时“停止生产线”。
    • 日复一日的持续改进日常工作。
    • 创建快速的自动化测试套装软件,以确保代码总是处于可部署的状态。
    • 在开发和IT运维之间建立共同的目标和共同解决问题的机制。
    • 建立普遍的产品遥测技术,让每个人都知道,代码和环境是否在按照设定运行,以及是否达到了客户的目标。
  • 第三工作法:如何建立文化,既能鼓励探索,从失败中吸取教训,又能理解反复的时间是精通工作的先决条件。

    创造公司文化,带动两种风气的形成:不断创世,这需要承担风险并从成功和失败中吸取经验教训;理解重复和练习是熟练掌握的前提。不断加压,从而强化习惯并加以改进。(系统里要经常出些故障,长此以往,再遇到困难就没原来那么痛苦了。)

    必要的做法是:营造一种勇于创新、敢于保险以及高信任度的文化,把至少20%的开发和IT运维周期规划给非功能性需求,并不断鼓励进行改进。

KPI与度量

为了促进DevOps战略,调整绩效考核和激励机制是必要的,按各自为政的KPI考核只会造成部门之间的隔阂,只根据敲出代码的生产力来奖励开发人员,或者根据基础设施的可靠性来奖励运维人员,什么都无法改变;围绕业务系统而不是职责来组织工作,这就是DevOps打破IT分组壁垒的寓意。 团队一起协作,共同为他们的应用和系统负责。

以下是部分度量参考:

  • 开发应用所花费的最高时间(开发速率)
  • 失败部署的百分比(部署成功率)
  • 客户产生了多少问题(客户接受度)
  • 故障恢复的平均时间(团队解决故障的能力)
  • 用户数(用户欢迎度)

本文从DevOps的起源、定义、过程、要求、实践等角度对DevOps进行了解读,希望通过本文的内容,大家可以对DevOps产生自己的理解,活学活用,总结出适合自己的,能够落地实施的DevOps解决方案。

本文参考资料:

  • 《凤凰项目:一个IT运维的传奇故事》
  • 百度百科

分享:

    相关文档

    相关产品

关闭导读