2025上半年,最新 AI实践都在这!20+ 应用案例,任听一场议题就值回票价 了解详情
写点什么

企业 DevOps 探讨:“谁构建、谁运行”原则的理论基础

  • 2015-08-31
  • 本文字数:2175 字

    阅读完需:约 7 分钟

这样的场景大家想必不会陌生:我们正与家人共度美好时光,突然刺耳的电话铃声嗡嗡响起,我们的注意力也为之吸引。听筒中的尖叫声告知,我们的应用程序——也就是那些定期受到内存泄漏侵扰、但重启之后又能恢复正常的小冤家们——现在终于彻底起义了,服务器资源在几分钟之内就被其彻底榨干。目前该应用已经无法正常起效,而运维团队除了尝试重启与回滚之外无法可想——而最新的一份正常副本已经是几个月之前的版本。没人知道这段时间里系统经历了哪些变更,只有我们自己能够解决这场危机——但现在的我们身在家中,距离办公室和自己的宝贝计算机数英里之遥。

类似这样的状况在传统企业 IT 模式下可谓相当常见,而开发与运维团队也因此始终站在对立面之上。不过我们完全可以扭转这样尴尬的局面。DevOps 不止适用于初创企业,对于成规模的大型组织机构也同样有效。正如自动化机制与客户服务一样,“谁构建、谁运行”的理念完全可以在 DevOps 模式之下显著改进企业 IT 的交付效率与效果。

在传统环境下,开发人员、架构师与工程师共同构建起一套解决方案,而后将其交给运维团队打理。有时候前者会提供必要的指导资料来协助后者解决生产环境下可能出现的问题,但有时候前者对生产环境却知之甚少,这意味着他们根本拿不出什么可行的指导性信息。当这些团队彼此之间相互割裂时,各个团队自然不清楚对方的工作方式以及实际需求。运维团队通常依靠运行手册、SOP(即标准化运维规程)或者其它一些固有机制来解决生产流程中出现的问题。这些方案确实能够帮助我们快速解决问题,但却无法从根本上揪出乃至清除问题的来源——这有点像用口香糖修补渗水的船底,最终整条船都逃不过沉没的命运。

DevOps**** 能够带来更好的解决方式

不过云计算的出现不啻为一种福音,它破除了这道看似难以逾越的高墙,让我们能够在很大程度上将基础设施作为软件进行管理。其由 API 驱动的特性允许大家以对待代码的方式对待基础设施,这意味着开发人员能够顺利解读其中的涵义。现在每个人都能够拉近自身与基础设施间的距离,而良好的运维效果自然也就成了随之而来的关键性诉求。

与此同时,软件的运作方式更趋向于一类服务,客户则要求我们不断对服务做出改进。他们也许能够容忍偶尔出现的错误,但前提是我们有能力立刻修复这些错误并保证其不再发生。为了顺应这一系列转变,我们需要关注细节线索并解读客户并未明确传达给我们的信息。跟我们一样,客户也在忙于处理各类事务,因此当他们打来求助电话时、其内心一定是相当烦闷的。虽然与客户间的交互确实是种增进了解的机遇,但我们还是最好能主动发现问题并防患于未然。不过要得到准确的分析结论,其难度甚至高于传统开发与运维团队之间的顺利沟通——运维人员可能主张快速以治标的方式清除异常,而开发人员则更多考虑到安全性等其它因素、并因此抱持着相对较低的运维效果预期。

所有这一切都成为大家摆脱传统 IT 模式,转而选择新型 DevOps 理念的有力理由——在后者的指导下,开发与运维团队将团结在一起并拥有共同的关注方向。对于那些希望在企业当中贯彻 DevOps 文化的领导者,我一直强烈建议他们遵循“谁构建、谁运行”这一基本原则。下面我就结合亲身经历,聊聊这一原则为企业带来的收益与影响:

·面向生产环境的设计思路。“谁构建、谁运行”原则会促使开发团队认真考量自己的软件成果是否能够在生产环境下带来与设计目标相符的运行效果。这将帮助技术团队避免最令人头痛的紧张局面,即开发人员想尽办法对已有软件成果进行调整,从而保证其能够在截止日期之前与自己并不熟悉的生产环境相契合。在我自己的从来经历当中,已经无数次见到过这类让人想想就抓狂的状况。大家可以在部署过程中解决生产环境与开发环境之间的一部分差异因素,根据预期运行相关测试,而后观察这些变更会在系统的其它位置引发哪些 bug。

·更理想的员工自治空间。“谁构建、谁运行”理念能够激励每一位员工树立起归属感及责任心,根据我的实际经历,这将帮助企业培养出更多拥有独立能力与责任承担态度的员工,甚至彻底影响企业中的职业发展走向。

·更高的透明度。没人希望在享受个人时光时受到打扰,而且不用想也知道,被紧急电话惊醒的员工会本能地对相关请求做出拒绝。我们的团队当然希望整套环境拥有更高的透明度并实现积极的监测机制,从而保证问题大规模出现之前就得到识别或者关注。除了抢在异常状况发生前找到问题之外,这种良好的透明度也能够帮助我们更为轻松地定位到问题的根源所在。

·自动化程度更高。开发人员最痛恨的就是一遍又一遍以手动方式处理重复工作,因此如果他们发现自己被迫在生产环境下不断解决同一个问题时,他们当然希望能够找到问题的根源并一劳永逸地加以处理——而自动化机制正是为这种状况而生。

·更出色的运维质量。透明度与自动化等因素能够帮助团队获得更理想的执行效率,同时持续提升运维的实际效果。

·客户满意度更高。“谁构建、谁运行”理念促使整个 IT 团队积极理解客户的实际需求。这类知识并不再仅仅为产品或者销售团队所重视,而开始更多地成为以反馈为基础的产品持续改进流程中的组成部分。


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

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

2015-08-31 12:391392

评论

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

如何定义错误码

编号94530

Java 错误码 错误处理

用 Redis 实现消息队列是一个好主意么?

escray

redis 学习 极客时间 3月日更 Redis 核心技术与实战

本科毕业,六年Java开发经验,阿里技术三面+HR面,拿下38*16薪资P7offer

Java架构之路

Java 程序员 架构 面试 编程语言

ProxmoxVE 系列:如何巧妙的用Xshell连接Ubuntu server服务主机

Bob

虚拟机 系统 proxmoxve PVE

智能时代与华为路标:手机影像的文艺复兴史

脑极体

Redis - 缓存穿透、缓存击穿、缓存雪崩

insight

redis 3月日更

[译]用@WebMvcTest测试MVC Web Contorller

麦芽面包

spring unittest

能助我拿3家大厂offer的神级Java面试宝典,你值得拥有

Java架构之路

Java 程序员 架构 面试 编程语言

区块链技术在医疗保健领域的应用展望

CECBC

医疗

C++ 中的 task based 并发

赖猫

c++ 后端 多线程 并发 服务器开发

亚马逊云科技和德甲为 2021 赛季新推出三项赛况统计数据,强化实时比赛分析

亚马逊云科技 (Amazon Web Services)

如何革命社交媒体、实现去中心化?丝绸之路创始人在狱中提出了构想

CECBC

社交网络

ProxmoxVE系列:上传系统镜像&&创建虚拟机

Bob

虚拟机 proxmoxve PVE

Wireshark数据包分析学习笔记Day21

穿过生命散发芬芳

Wireshark 数据包分析 3月日更

学习方法记录

风翱

学习方法 3月日更

数据去哪了?:从一次生产事故聊聊并发编程原子性问题

海拉鲁

Java 并发编程 多线程

员工离职的注意事项

石云升

离职 28天写作 职场经验 3月日更

Java泛型最全指南

xcbeyond

Java 泛型 3月日更

阿里云盘上线了,2T空间免费领

和牛

软件推荐

ProxmoxVE系列:Ubuntu服务器版系统安装

Bob

虚拟机 系统 proxmoxve PVE

多线程-基础

九洲城豪横团团长

在全面拥抱人工智能前,这 6 步您的公司做到了吗?| 云途专栏

亚马逊云科技 (Amazon Web Services)

C++ socket通讯详解及注意事项

赖猫

c++ 后台开发 后端 服务器开发

NoCode 实战 | 零代码应用开发,轻松搞定任务跟踪管理难题(上)

亚马逊云科技 (Amazon Web Services)

ETHAT云矿机系统开发案例丨ETHAT云矿机开发源码

系统开发咨询1357O98O718

深圳正探索利用区块链技术理念打造“数字政府“

CECBC

大数据

数据结构队列

我是程序员小贱

3月日更

第十二周作业

Geek_mewu4t

看东鹏饮料如何从150亿条数据中洞察先机 | 精选案例

亚马逊云科技 (Amazon Web Services)

c++11&14-智能指针

赖猫

c++ 后端

寻找被遗忘的勇气(二十四)

Changing Lin

3月日更

企业DevOps探讨:“谁构建、谁运行”原则的理论基础_亚马逊云科技_Stephen Orban_InfoQ精选文章