写点什么

企业 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:391091

评论

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

SRE运维解密-应对过载

董哥的黑板报

微服务 SRE 限流 SRE实践

OpenTelemetry系列 (四)| 如何使用Java Agent来实现无侵入的调用链

骑牛上青山

Java javaagent 调用链 OpenTelemetry 微服务调用链

Web入门:CSS下拉图片

小院里的霍大侠

JavaScript Web 初学者 入门者

Web入门开发【二】

小院里的霍大侠

编程开发 初学者 入门实战 Web入门

架构实战营 3-5 消息队列备选架构随堂练习

西山薄凉

「架构实战营」

SDK更新不了问题解决

芯动大师

android hosts SDK 教程

WEB21

Lenyi

网络安全 CTF ctfshow 爆破

Flink 1.16:Hive SQL 如何平迁到 Flink SQL

Apache Flink

大数据 flink 实时计算

数据可视化图表系列解析——饼图

Data 探险实验室

数据分析 可视化 数据可视化 可视化数据 可视化工具

spaa 22

黄敏

架构实战营 3-4 架构设计后期随堂练习

西山薄凉

「架构实战营」

【IntelliJ IDEA】连接https报错问题: E230001: Server SSL certificate verification failed:

No8g攻城狮

svn IDEA

HTTP请求首部字段

穿过生命散发芬芳

HTTP 12月月更

2022-12-25:etcd可以完全替代zookeeper,原因是k8s用的etcd,不用担心不成熟。请问etcd部署在k3s中,yaml如何写?

福大大架构师每日一题

云原生 k8s etcd k3s 福大大

Flink 在米哈游的应用实践

Apache Flink

大数据 flink 实时计算

架构误区系列10:不合理的分层

agnostic

软件分层

【IntelliJ IDEA】idea 2018版本中没有SVN按钮或者图标的解决方法

No8g攻城狮

svn IDEA git 学习

设计模式之美——里式替换(LSP)

GalaxyCreater

设计模式

架构训练营模块三作业

张建闯

架构实战营

SAP MM SPED输出报错-No authorization for delivery from shipping point US##-之对策

SAP虾客

SAP MM SPED VL31N 公司间STO

学生管理系统

KING

运维进阶训练营 -W09H

赤色闪电

运维

【web 开发基础】PHP 中的预定义数组详解续集 (48)

迷彩

post GET 文件上传 PHP基础 预定义数组

模块三-外包学生管理系统的架构文档

悟空

学生管理系统架构

WEB23

Lenyi

网络安全 CTF ctfshow 爆破

Web入门开发【四】

小院里的霍大侠

Web 编程开发 初学者 入门实战

2022年浪过的那些城市

SAP虾客

杭州 2022年 无锡 东莞 SAP项目

安卓、iOS、小游戏三端同发?介绍给你一个新方式 - 普洱WebGL

僵尸浩

typescript 小游戏 Unity3D

【架构设计】你的类足够“专一”吗

JAVA旭阳

Java 架构

FFA 2022 主会场 Keynote:Flink Towards Streaming Data Warehouse

Apache Flink

大数据 flink 实时计算

基于Go的缓存实现

俞凡

架构

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