免费下载案例集|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:391033

评论

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

在线图片水印平铺工具

入门小站

工具

也许你曾对怎么样才算认真做事情感到好奇,这本书给我三个启发,我想与你分享。

叶小鍵

Pulsar Manager - Use Docker

ZHOUWEI

Apache Pulsar

《社会心理学》-怎么说服他人(整理稿)

箭上有毒

8月日更

如何写好一篇自媒体文案:把握节奏引起共鸣

石头IT视角

架构训练营模块5-作业

sophiahuxh

OLAP 简介

LeifChen

OLAP 多维分析 8月日更

JavaScript 中 Array map() 方法

HoneyMoose

Rust从0到1-高级特性-不安全的Rust

rust unsafe 高级特性 不安全

浪潮云IBP机器学习平台通过中国信通院可信云评估 荣获“先进级”认证

云计算

Linux之wget命令

入门小站

Linux

vue入门:组件概述

小鲍侃java

8月日更

【设计模式】观察者模式

Andy阿辉

C# 编程 后端 设计模式 8月日更

iOS开发:真机调试提示XXX, but code signing identity Apple Development问题

三掌柜

8月日更 8月

JavaScript 中 Array map() 方法

HoneyMoose

Java双刃剑之Unsafe类详解

码农参上

Java unsafe 8月日更

计算机字符编码的前世今生

vivo互联网技术

Unicode utf-8 编码 ASCII 字符集

Regan Yue带你一起学习微软AZ-900认证的有关知识「 第Ⅲ章」

Regan Yue

云计算 微软 8月日更

分享 6 个实用的 Vue 技巧

devpoint

Vue Vue3 8月日更

python--构造方法笔记

加里都好

架构实战营 - 模块五作业

Julian Chu

架构实战营

JVM集合之开篇点题

阿Q说代码

JVM hotspot 8月日更 栈式架构 寄存器架构

介绍一个好用的网络工具traceroute命令

liuzhen007

8月日更

Lodash 是什么

HoneyMoose

ElastricSearch第三弹之存储原理(详细+易懂)

阿Q说代码

ES 8月日更 flush Refresh translog

从字节码探索代理模式

4ye

Java 后端 字节码 代理模式 8月日更

【Flutter 专题】65 图解基本 TextField 文本输入框 (二)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 8月日更

手撸二叉树之从根到叶的二进制数之和

HelloWorld杰少

数据结构与算法 8月日更

Python代码阅读(第11篇):展开嵌套列表

Felix

Python 编程 Code Programing 阅读代码

架构实战营 模块五 作业

一雄

作业 架构实战营 模块五

kafka - 基础介绍

旺仔大菜包

kafka

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