软件开发平台 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价值观

Nicole Forsgren博士在DOES上的演讲,说过一句话:Architecture matters...Technology doesn't

最近也遇到越来越多类似的问题,例如:业务方向不明确的情况下,如何拆分微服务?

我们通常的观点是“架构是服务于业务的,太过超前的架构是浪费”,由此可以想到架构与业务其实也有相似的关系。

参考Nicole的句式,从DevOps涉及到的几个维度出发:业务、架构与技术;人、流程与工具;原则,方法与实践,于是便有了如下的几句话:

  • Business matters...Architecture doesn't. Architecture matters...Technology doesn't.
  • People matters...Process doesn't. Process matters...Tool doesn't.
  • Principle matters...Method doesn't. Method matters...Practice doesn't.

本文中暂且把这些观点称之为朴素的DevOps价值观。之所以朴素,是因为这只是一个比较原始的想法,称之为价值观是因为具有相当的普适性。同时,如果这些观点有幸真的可以逐渐形成价值观,它也应该是简单质朴的。

业务、架构与技术

下面,让我们先来看看业务(Business)、架构(Architecture)与技术(Technology)这个维度:

  • Business matters...Architecture doesn't.

    架构是服务于业务的,关于初创公司,新型的业务,是否需要采纳微服务,回答是视情况而定的,但通常建议从单体应用开始。

    微服务的价值与挑战一样明显。

    初创公司,业务方向还在不断探索,服务的边界是模糊的,即使对微服务的技术储备足够,也不建议此时就搞微服务架构,用最简单直接的方法搞定快速变化的业务诉求。

    用贷款买房来类比架构投入,自己出的首付款就像是前期在架构上的投入,贷款就好比是减少一定的架构投入,所需承担的技术债务:

    • 贷款买房,预期的是未来的房产的增值,贷款的利息相较起来是可以接受的。

      创业期也是同样,此时承担一定的技术债务是明智合理的选择。

    • 一味追求全款买房,就会错过买房的最好时间窗口。

      业务的时间窗口更短,需要不断的快速试错,期望在架构层面一步就位是不现实的。

    • 不能贷款过多,否则无法承担月供。

      架构可以一开始简单些,原始一些,但基本的质量和NFR还是需要满足的;而一旦找对业务方向,又需要快速展开,所以架构在初期具备一定的扩展能力还是需要的。

    • 要定期清理债务,房贷车贷过多,即使是有力偿还,生活质量也会下降,脱离了原始购房改善生活质量的初衷。

      技术债务也需要定期偿还,定期清理,不能让因为技术债务产生的额外时间成本,大于承担技术债务所带来的机会成本。

    这其实是一个经济杠杆,用短期或长期的负债,来换取时间成本和机会成本。所以做架构也好,做DevOps也好,需要有经济的头脑。SAFe第一条原则Take an economic view,也有这层含义。这是一个平衡,一场与时间的赛跑,但总而言之,业务诉求高于一切。

    以上所说的都是因为业务战略需要,主动有意识的承担技术债务。如果是无意识的负债,那个叫做奢侈浪费,原本就应该消除。

  • Architecture matters...Technology doesn't.

    《圣经·旧约·创世记》第11章记载,当时人类语言相通,同心协力,联合起来兴建希望能通往天堂的高塔,即巴别塔。“来吧,我们要建造一座城,和一座塔,塔顶通天,为要传扬我们的名,免得我们分散在全地上”。此举惊动了上帝,为了阻止人类的计划,于是他悄悄地离开天国来到人间,改变并区别开了人类的语言,使他们因为语言不通而分散在各处,那座塔于是半途而废了。

    架构如此重要,所以一旦业务相对清晰一些,就要根据业务需要,考虑逐渐切换到微服务架构,才不至于堆积太多技术债务,对于可扩展性、可规模化、可部署性等也都至关重要。

    优雅的良好的架构更加重要,不要让微服务成为另一座巴别塔。理论上微服务可以最大化利用各种语言的优势,但如果没有好的服务切分与架构设计,微服务只会变成更大的灾难,只会是碎片化而不是去中心化。微服务的目的是更灵活的协同,如果服务之间缺少沟通,就背离了微服务设计的初衷。

    Google内部有开发三大语言,分别是官方编译语言C/C++、官方脚本语言Python、和官方UI语言Java。坚持三大语言意味着内部沟通的顺畅,没有使用最新的技术和语言,并不影响,反而有助于Google快速成为世界领先的公司。

    团队效率高于个人效率,统一技术栈带来的收益,往往大于使用最新技术栈带来额外的维护和沟通成本。Etsy在2010年,决定大量减少生产环境中的技术,统一标准化到LAMP栈。“与其说这是一个技术决策,不如说是一个哲学决策”。这让所有人,包括开发和运维,都能理解整个技术栈。另一个例子,Etsy在2010年引入MongoDB,结果是“无模式数据库的所有优势都被它们引发的运维问题抵消了”,最终Etsy还是选择放弃了MongoDB,迁移到MySQL。

    DevOps也并非只有Web应用、SaaS或是开放平台才适用,我们听到太多传统银行的转型案例,主机开发的案例,技术并非DevOps的绝对先决条件,虽然开放平台可供选择的工具会多一些,后面我们还会就工具进行讨论。

    技术圈总是喜欢追逐潮流,总是存在各种鄙视链,就像曾经出现的PHP与其他各种语言的互喷群。还有类似于容器编排技术,大家一窝蜂的从Swarm、Mesos向K8s迁移。但对于企业而言技术永远不是第一位的,最新的未必是最合适的,永远追逐最新的技术,往往丧失了自我的思考和技术的积累。

人、流程与工具

接下来,再让我们看看人(People)、流程(Process)和工具(Tool)这个维度:

  • People matters...Process doesn't.

    最近敏捷微信群里沸沸扬扬的CMMI之争,我们不去论述谁是谁非。早先很多公司也进行过CMMI级别的评估,CMMI应该是团队做到一定程度,拿来对自身进行现状评估,用以指导下一步改进的参照。CMMI模型的初衷是好的,设置也还合理,模型事实上也是在演进的,只是被不合理的使用了。

    所以模型也好,流程也好,使用它们的人,以及用法,才是最重要的。这就好比聚贤庄一战,乔峰用一套太祖长拳,打败天下英雄。太祖长拳,号称三岁孩童都会的拳法,为何可以在乔峰手里发挥如此巨大的威力?具体的武功招式,方法流程,并不重要,重要的是看谁来用,如何用。

    关于流程的另一个问题:如果流程是最重要的,那么到底是流程要求的多好,还是流程要求的少好?

    Henrik Kniberg在《Kanban vs/with Scrum》里,对RUP、SCRUM、KANBAN等方法的约束给出了最直观的感觉:RUP有120多个要求、XP有13个、SCRUM是9个、而KANBAN只有3个。RUP是最重视流程和方法的,而KANBAN是最不重视的,孰优孰劣?很难讲,我们并不能觉得RUP就一定不如KANBAN,RUP在实际采纳时需要裁剪,只是因为裁剪的过程对人的能力要求太高;Henrik说:“Scrum和RUP的主要区别在于,RUP给你的东西太多了,你得自己把不需要的东西去掉;而Scrum给你的东西太少了,你得自己把需要的东西加进来。看板的约束比Scrum少,这样一来,你就得要考虑更多因素”。一边是需要裁剪,另一边是需要增加,所以执行到最后,成熟的团队的研发流程,大抵都能找到很多相似之处。

  • Process matters...Tool doesn't.

    现在一提到DevOps,大家谈的比较多的,是如何用工具搭建流水线、如何用工具搭建容器化开发平台、持续集成应该用什么工具、自动化测试应该用什么工具,诸如此类。

    我们常见的持续交付工具有太多是5年前、10年前甚至更早就推出的工具。如果工具是实施DevOps的关键,那么十年前就有这些工具,理论上当时我们就应该成功实施了DevOps,实际上我们又做的如何呢?

    工具是重要的,没有工具是万万不能的。但工具不是万能的,比工具更重要的是使用工具的方法和流程,比流程更重要的,是执行流程和使用工具的人。

    简单如SVN,复杂如Clearcase,我都看到过在此基础上,实施持续集成非常成功的企业。

    Martin Fowler对CI的定义和建议,从2006年至今,居然未曾修改过。

    即使到现在,又有几个人敢拍着胸脯说,真正能把CI这些实践做到的?

    所以流程也好,工具也罢,最重要的是执行的人,而对人而言,关键的是思维模式Mindset,我们可以称之为原则Principle。

    由于工具本身对于DevOps的也扮演着不可或缺的角色,因此在结束这个维度的内容之前,让我们来看看针对DevOps在工具链上的要求:自动化、标准化,那么有什么样的工具能帮我们提供落地实践的基础。

  • 华为云DevCloud服务

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

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

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

原则、方法与实践

最后让我们来看看原则(Principle)、方法(Method)和实践(Practice)这个维度:

  • Principle matters...Method doesn't.

    敏捷的方法有很多,讲了很多年也还任重道远。

    丰田TPS被各大车企学习了30年,没有哪家能学到真经的。有人说,丰田生产模式,最重要的是背后的KATA,即丰田套路,如何使得改善和提高适应性成为组织日常工作的一部分,而KATA的书出版到现在也快10年了,好像依然没有多大改观。

    敏捷的方法有很多,SCRUM、精益看板等,SAFe是大规模的敏捷,DevOps也有很多种模型。比模型更重要的是背后的原则,虽然这些模型从表象上相差甚远,但其背后的原则却十分相似,比如敏捷宣言的十二条原则、SAFe的九大原则、以及DevOps的CALMS原则。

    方法论的表现形式有很多,具体落地执行又根据不同企业千变万化,但不变的、相通的,是背后的原则。好比张三丰教张无忌自己新创的太极剑,张三丰教的快,每次的招式还都不同,张无忌学的快,忘的更快,“不坏,不坏!忘的真快”,武功招式始终是下乘的,心法精髓才是上乘,守住了心法,招式就可以随时创新,不必拘泥。

  • Method matters...Practice doesn't.

    《雷神3》里的桥段,奥丁的女儿海拉轻易的就捏爆了雷神之锤,索尔灵魂出窍,一时仿佛看到他已故的父亲奥丁。他向他的父亲求助。奥丁:索尔,你是锤子之神吗?那锤子,是为了让你控制你的力量,让你更专注,它不是你的力量的来源,你才是。

    DevOps原本就是偏实践层面的,有很多实践归纳,比如下图的Gartner的DevOps模式和实践图,还有DevOps地铁图。但这些实践都只见树木不见森林,缺少彼此之间的关联和依赖,需要方法将其串起来。这也是为什么一套辟邪剑法的剑招,缺了葵花宝典的心法,就稀疏平常沦为三流一样。

    从Practice,到Method,到Principle;也就是是从Doing,到Thinking,到Being的过程。Being DevOps并非一蹴而就的事情,需要从实践做起,心里要有方法论,过程中始终严守原则。但又不能固守着那把实体的锤子,方法也好,实践也好,都只是达成目标的途径,而原则才是指南针。

  • 朴素的DevOps价值观
    • 首先,业务、架构、技术,人、流程、工具,原则、方法、实践,这九大元素不能孤立的来看,原本就是相辅相成,密切相关的。

      Principle背后,其实是人的Mindset思维模式,而一堆人遵循同样的Principle,就演化成了文化Culture。方法Method也好,流程Process也好,最终都由实践Practice通过工具Tool落地。DevOps、微服务和容器的三剑客,也是方法、架构与技术与工具的极佳结合。

    • 其次,所有这些元素都重要,缺一不可;但不要舍本逐末,需要了解什么是根因,什么是手段。

      技术、工具、实践,都是服务于方法和流程的,需要遵循核心的原则,最终的目的是为了商业的诉求,为了快速的价值交付。方法、实践、工具,都是形;原则、Mindset、人,才是根。

    • 最后,本文的DevOps朴素价值观

      殊途同归,不管是CALM/CALMS,还是SAFe的CALMR,或者是Nicole Forsgren/Jez Humble/Gene Kim的《Accelerate》中的能力成长模型,都只是对同样问题的不同解读。

以上是本文对于DevOps思想的阐述;DevOps是什么,DevOps有很多面,每个人心中都有自己的DevOps,这里的所谓朴素的价值观,只是一种解读方式。只希望能为各位开发者,在读后带去更多的思考,找出更适合自己的道路。

本文参考资料:

  • 《一文收录16张DevOps “拍照神图”》,许峰

分享:

    相关文档

    相关产品

关闭导读