【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

将 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:421755

评论

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

量化交易系统开发案例(详情)丨量化交易源码模式

西安链酷科技

量化交易

ArcNeural V2.1 版本正式发布,重要特性全面解析!

Fabarta

ArcNeural AI 数据基础设施 Data-Centric AI

Defi流动性挖矿系统开发程序(案例)丨defi流动性挖矿源码搭建

西安链酷科技

DeFi质押挖矿

挖矿系统开发详情案例丨挖矿APP源码开发

西安链酷科技

云算力挖矿源码 挖矿系统开发

为什么说 Scroll 上的 PenPad,有望在本轮牛市行情中胜出?

石头财经

华为云开年采购季Web及移动App上云体验,助力软件行业创新发展

轶天下事

XML 简介及用法详解

小万哥

xml 程序人生 编程语言 软件工程 前端开发

量化交易系统开发技术案例丨量化交易开发源码平台

西安链酷科技

量化交易 量化合约

关于招聘这件事,简历方面的一些槽点

芃篙君

面试

为什么说 Scroll 上的 PenPad,有望在本轮牛市行情中胜出?

加密眼界

为什么说 Scroll 上的 PenPad,有望在本轮牛市行情中胜出?

长安区块链

合约交易系统开发案例分析丨合约交易开发源码平台

西安链酷科技

合约跟单 合约量化

defi流动性挖矿系统开发基本流程丨defi流动性挖矿源码程序

西安链酷科技

DeFi质押挖矿 DeFi流动性挖矿

“镐头和铲子”策略:初探AI创新创业中的竞争战略

算AI

创新创业 #人工智能

美众议院通过强制要求 TikTok 剥离的法案; 首个 AI 软件工程师上线丨 RTE 开发者日报 Vol.165

声网

电源常用电路—驱动电路详解

二哈侠

芯片 驱动 电源

市场广泛看好的LaunchPad 平台 PenPad,有望在牛市胜出

BlockChain先知

越影视觉,让AI看见这世界的繁花

脑极体

AI

合约交易系统开发案例分析丨合约交易开发源码平台

西安链酷科技

合约开发

量化交易系统开发案例(详情)丨量化交易源码模式

西安链酷科技

量化交易

量化交易系统开发案例(详情)丨量化交易源码模式

西安链酷科技

量化交易

合约跟单系统开发方案设计丨合约跟单源码(案例)

西安链酷科技

合约跟单

基于大模型和向量数据库的 RAG 示例

Baidu AICLOUD

大模型 向量数据库 langchain 千帆大模型平台 rag

市场广泛看好的LaunchPad 平台 PenPad,有望在牛市胜出

股市老人

defi流动性挖矿系统开发详解方案丨defi流动性挖矿案例源码设计

西安链酷科技

lp流动性挖矿 defi开发

为什么说 Scroll 上的 PenPad,有望在本轮牛市行情中胜出?

大瞿科技

怎么用ai创作ppt?办公必备的自动生成PPT软件!

彭宏豪95

人工智能 PPT 在线白板 AIGC AI生成PPT

Docker中容器的随机命名方式

百度搜索:蓝易云

Docker 云计算 Linux 运维 云服务器

市场广泛看好的LaunchPad 平台 PenPad,有望在牛市胜出

股市老人

《重构:改善既有代码的设计(第2版)》PDF

程序员李木子

阿里通义灵码全面公测,来看看它的水平怎么样?

阿里云云效

阿里云 云原生 云效

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