写点什么

将 DevOps 纳入企业环境引发的思考

  • 2015-09-30
  • 本文字数:2216 字

    阅读完需:约 7 分钟

虽然 DevOps 可以算是相对新鲜的概念,不过在我看来、其本质思路很早之前就已经出现。从这个角度看,目前很多企业已经广泛接纳这一概念并将其作为文化性产物看待,具体而言就是将大量原本孤立的团队融合起来,从而实现速度更快、频率更高且更为可靠的工作成果。

我个人非常幸运地早在 DevOps 文化进入主流视野之前就在自己的职业生涯当中对其有所了解。2001 年,当时我在彭博公司担任开发人员,那时候彭博方面就已经凭借着其对于快速上市、压缩迭代开发周期以及由开发人员自行负责所交付系统的运营工作而享有盛誉。作为其中的一员,我这位开发新手很快就体会到了凌晨四点对系统进行故障排查的感受(那个时段伦敦证券交易所才刚刚开放)。我发现这些熬夜工作的经历反过来成为一种动力,敦促自己尽可能提升系统稳定性,从而避免这类夜不能寐的状况再次发生。

DevOps 文化对于规模较小的初创企业而言往往比较直观,而且这类受众也会将结构调整作为相对简单的任务来看待。不过对于规模更大的组织机构,其中包含的大量技术债务、整体架构惯性乃至尽可能避免风险的固有业务实践思路则让 DevOps 所宣扬的颠覆性看起来有些难以接受。

不过好消息是上述顾虑不一定真有必要,而且在未来几周内我会就 DevOps 在企业环境中的实现这一议题从多个特定角度及其发展战略着手加以探讨。我个人倾向于鼓励企业在 DevOps 的风潮当中向这一新型文化形式进行逐步转移——先从小型项目、迭代、学习以及改进起步。我建议大家考虑首先采取一些组织内部普遍能够接受的战略性实践尝试,并以此为切入点推广相关思维,从而最终让大多数团队能够在处理日常工作时对这类高自动化程度且以连续性运营为基础的文化趋势抱以信任的态度。

当初在担任道琼斯公司 CIO 时,我们针对一支小型团队建立起了自己的一套 DevOps 实践方案——该团队只有四到五名成员,但这已经足以推进实际项目了。不过我们的目标并非创建一个新的团队,而是要借此对企业的整体文化带来影响。通过实现及发明各类框架、最佳实践以及治理手段,并以自动化方式处理种种日常工作,DevOps 最终成为我们驱动创新与加快产品开发的有力杠杆。我们从小规模项目入手,并将成果作为示例向其他同事证明我们能够利用同样的模式在更多项目当中取得成功。整个过程进展不快但却步伐坚定,其间我们不断推出新型功能并改进流程当中的产品上市时间。随着时间推移,原本常常因出现大量错误而令开发团队叫苦不迭的周二及周四版本发布日最终呈现出更具分散性的趋势——开发人员每周都会连续不断地推出数十项发布成果。

对于那些希望在 DevOps 领域作出尝试、但又对原有技术债务抱有疑虑的朋友,我建议大家将以下三项基本原则作为指导思想:

1.将面向客户的服务思路贯彻到企业的每个角落。如今的企业应当将内部利益相关者作为客户来看待。这类客户可以是企业中的任何成员,包括市场推广人员、产品经理或者是开发人员。每位员工或者职能部门都需要对应的技术方案来完成自己的日常工作。而将这类需求作为优先事务处理的团队则能够满足客户的需求,从而避免其另外寻求解决方案(甚至是不合法的解决方案,例如影子 IT),并最终带来理想的成果(例如速度更快、效果更好、成本更低)以及令人满意的客户反馈。相比之下,缺乏优质的服务则可能导致客户希望避开我们,而非与我们开展协作。

2. 尽可能推广自动化机制。根据目前的主流理解,提升自动化水平的真正含义就是最大程度发挥云技术的固有优势,这意味着大家需要利用代码以可靠性为前提对系统进行重构。这一点在规模自动伸缩方面(也就是弹性)表现得尤为明显。自动化机制还能够帮助企业以更为积极的方式推进变更:如果我们犯了错误,则可以快速回滚至之前的状态,并重新开始系统构建。推广自动化机制的其它优势还包括更理想的执行效率、安全性以及可审计性。

3.谁构建,谁运行。根据我的实际观察,这一点是最令传统 IT 部门感到不安的因素。在传统 IT 模式当中,应用程序或者服务的运维工作往往是由那些与资产创建毫不相干的人员来负责的。虽然这种处理方式并非毫无道理(例如选择成本更低的外包服务或者尽可能提高专业集中程度等),但我个人的观点是,这些优势目前已然不复存在了。云技术的出现如今已经接管了与 IT 运维工作相关的大部分高强度任务,而且其中多数运维工作也能够通过软件以自动化方式实现。开发人员显然对软件更为熟悉,这意味着如今已经没有理由将运维职责同任意给定任务进行硬性划分——而这也正是 DevOps 文化的根基所在。而且在自动化机制的帮助下,我们能够更加有条不紊地处理变更情况,并在问题影响到客户之前对其加以解决或者实现系统回滚。我建议大家建立起专门的 DevOps 团队,从而尽可能保证开发团队独立存在,而非将后者作为持续性运维 / 发布流程中的关键性环节。

对于有意愿在 DevOps 方面进行试水的朋友,我的观点是当下正是最理想的入手时机。先从小处出发,并通过增量化改进提升其它团队的满意度并赢得支持。文化层面的转变绝非一朝一夕之功,而我们也应当利用新型与传统等不同类型的方式实现此类改进。随着经验的持续积累,大家将一步步学习到足以指导下一步尝试的知识,同时运用日趋完善的自动化机制实现更为理想的工作成果。


感谢刘羽飞对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015-09-30 10:422043

评论

发布
暂无评论
发现更多内容

提速 10 倍!深度解读字节跳动新型云原生 Spark History Server

字节跳动数据平台

数据库 spark 数据存储 湖仓一体 数据计算

数字货币永续合约交易所app系统开发

开发微hkkf5566

java远程连接ssh的实现

测吧(北京)科技有限公司

Java、

解决方案|电力行业应如何应对数字化转型危机

云智慧AIOps社区

安全 监控 解决方案 智能运维AIOps 故障处理

严禁外传,字节跳动2022秋招Java岗位架构师面试题(暂定版)发布

钟奕礼

Java 编程 程序员 后端 java面试

软件测试 | 测试开发 | Monkey基本参数介绍

测吧(北京)科技有限公司

软件测试、

加密数字艺术背后你关心的几个问题

神奇视野

Hyperledger Cactus(一):架构初探

神奇视野

华为云数字资产链,构建新型数字经济价值

神奇视野

提质增效两不误,揭秘大型软件团队「价值增长飞轮」|直播回顾

万事ONES

[译]为什么程序员不应该长期留在一家公司

宇宙之一粟

成长 跳槽 8月月更

华为终端全面上新,做全场景智慧体验时代的引领者

ToB行业头条

软件测试 | 测试开发 | 如何利用 xUnit 框架对测试用例进行维护?

测吧(北京)科技有限公司

软件测试

CWE 4.7中的新视图 -- 工业控制系统的安全漏洞类别

科技怪咖

【刷题之路 | Java & Python】两数之和(暴力枚举&哈希表)

计算机魔术师

8月月更

共识算法入门

神奇视野

如何用VSS一键自动化扫描软件包/固件,快速排查安全风险

科技怪咖

设计模式的艺术 第二十三章状态设计模式练习(设计一款纸牌游戏软件,该游戏中用户角色具有入门级、熟练级、高手级和骨灰级4种等级。角色等级与积分对应,胜利增加积分,失败扣除积分。入门级有最基本的游戏功能,熟练级增加胜利积分加倍功能,高手级再增加换牌功能)

代廉洁

设计模式的艺术

软件测试 | 测试开发 | 智能音箱语音交互系统简介与测试初探

测吧(北京)科技有限公司

软件测试、

CVE-2022-22965 漏洞分析

科技怪咖

安卓应用及鸿蒙应用安全检测指南

科技怪咖

软件测试 | 测试开发 | 如何用Sonic云真机打王者

测吧(北京)科技有限公司

测试 scrcpy

【Django | 开发】分离上线环境与开发环境(多settings配置)

计算机魔术师

8月月更

软件测试 | 测试开发 | App自动化之dom结构和元素定位方式(包含滑动列表定位)

测吧(北京)科技有限公司

DOM 自动化测试

基于 GitHub 的数据库 CI/CD 最佳实践

Bytebase

GitHub cicd Github Actions SQL审批

【Django | 安全防护】CSRF跨站伪请求和SQL注入攻击

计算机魔术师

8月月更

荣耀智慧服务百亿曝光扶持计划,具体申请规范来了!

荣耀开发者服务平台

卡片服务 荣耀 honor

阿里云基于全新 RocketMQ 5.0 内核的落地实践

阿里巴巴云原生

阿里云 RocketMQ 云原生

深度干货!一篇Paper带您读懂HTAP | StoneDB学术分享会第①期

StoneDB

MySQL HTAP StoneDB 企业号九月金秋榜 实时数据库

测试左移之Sonarqube scanner使用

测吧(北京)科技有限公司

软件测试 SonarQube

软件测试 | 测试开发 | HttpRunner初体验

测吧(北京)科技有限公司

HttpRunner

将DevOps纳入企业环境引发的思考_亚马逊云科技_Stephen Orban_InfoQ精选文章