写点什么

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

2015 年 8 月 31 日

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

2015 年 8 月 31 日 12:39450

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

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

详解GaussDB(for MySQL)服务:复制策略与可用性分析

华为云开发者社区

数据 路径 可用性 华为云 GaussDB

设计模式中的单例模式并不完美

架构师修行之路

设计模式 单例模式 23种设计模式 高并发系统设计

联盟链有自己的路要走

Leonbond

区块链 联盟链 公有链

对于容器技术的看法

倾心煎蛋

信创舆情一线--工信部开展网络安全技术应用试点示范工作

统小信uos

数据处理能力相差 2.4 倍?Flink 使用 RocksDB 和 Gemini 的性能对比实验

Apache Flink

flink

百度大脑人脸离线识别SDK升级盘点,Linux ARM版本上线

百度大脑

人工智能 人脸识别 百度大脑 sdk

原创 | 使用JPA实现DDD持久化- O:对象的世界(2/3)

编程道与术

Java hibernate DDD JDBC jpa

微服务架构下的核心话题 (二):微服务架构的设计原则和核心话题

xcbeyond

架构 微服务 设计原则

如何将FastDFS存储数据平滑迁移至XSKY对象存储?

XSKY融合存储

EasyDL的数据集、模型与代码的版本管理:灵活管理效率提升

百度大脑

人工智能 模型训练 百度大脑

当百度遇上新基建:开放是基本原则 做智能时代的赋能者

百度大脑

人工智能 百度 AI 新基建 百度大脑

第九周作业

Geek_a327d3

Flag: 给自己定个小目标

Fen9Pi

个人感悟

影调:光影交响曲

北风

摄影 风光 影调 光影 人像

计算之美(1/12)

我的偶像是木子

数据结构 算法

环信大学:模型的边界!

环信

如何设计一个优秀的组件

Lee Chen

前端进阶训练营

设计模式之假如需要一百万个对象

架构师修行之路

有它的加持,单机玩转百亿大数据不是梦!

易观大数据

【DevOps】Jenkins持续集成流水线(中)

Man

DevOps jenkins CI/CD JACOCO FINDBUG

Gitlab 部署配置

wong

gitlab

零基础建网站必备技能,看这一篇就够了

北柯

程序语言 网站搭建 编程网站

英特尔十代酷睿携手机械革命X3-S 纵享顺畅游戏之巅

飞天鱼2017

什么是深度强化学习?

华章IT

学习 智能体

直播平台在贝壳找房中的实践与运用

陈威威

架构 分层架构 直播 分层思维 多元场景应用

如果不懂编程,请看这里!!!

代码制造者

学习 编程 低代码 零代码

为Z3 Air-赋能,十代酷睿引领游戏5GHz新时代!

飞天鱼2017

设计模式之——单例模式你真的会吗?

诸葛小猿

设计模式 单例模式 Singleton 饿汉式 懒汉式

.net core快速开发平台,learun自主工作流引擎设计规范

力软.net/java开发平台

【译】代码中如何写出更有意义的命名

Jackey

代码质量

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