【AICon】 如何构建高效的 RAG 系统?RAG 技术在实际应用中遇到的挑战及应对策略?>>> 了解详情
写点什么

客户服务在企业 DevOps 体系中拥有关键性作用的两大理由

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

    阅读完需:约 8 分钟

客户服务是企业机构在实现 DevOps 文化过程中所必须重视的三大基本原则之一。

如今的世界充斥着各类技术解决方案。无论我们抱有怎样的需求,都能够在市场上找到大量足以起效的方案选项。对于那些专门负责交付技术解决方案的朋友,良好的工作成果意味着我们不仅需要提供出色的产品,同时也要提供理想的客户服务。客户服务的水平越高,客户从竞争对手处物色替代性产品的可能性也就越低。

从传统意义角度看,客户也就是那些购买我们产品及服务的群体——他们可以是 Amazon.com 网站上的购物者,也可以是使用 AWS 方案的企业受众。

而在企业 IT 内部,我们的客户往往正是自己身边的同事。作为内部相关者,他们可以是企业中的任何一位成员,且需要借助技术方案的力量来完成自己的日常工作。有时候他们来自其它业务部门(例如市场营销、销售或者其它团队),而有时候他们自己也同样属于技术人员。

那么在内部 DevOps 体系当中,到底是谁在消费相关产品及服务呢?当然,具体答案需要具体分析,不过通常来讲应该是企业中的应用程序开发人员及其它技术团队,因为加快产品开发速度正是集中式 DevOps 所要实现的首要目标。相较于传统模式下只关心自身所面临挑战因素的队伍,能够与各个部门协作并征求其意见的集中式团队将能够更为准确地预测出客户需求,从而拿出更理想的客户服务方案。

在企业当中,至少有以下两大重要理由支持着我们将客户服务作为优先考量:

1.以客户服务为核心的机制能够改善IT**** 品牌效应

二十年前,企业技术体系由且只能由 IT 部门负责支持,那个时候技术就是复杂性的代名词。曾几何时,从业者需要具备丰富的专业知识储备才能顺利搞定相关工作。而且与主张“谁构建、谁运行”的 DevOps 文化不同,当初的企业倾向于将这部分权力集中在少数人手中,只有他们了解如何购买及部署技术方案。这就意味着 IT 客户——具体来讲,也就是企业中的其他成员——在满足自身 IT 需求时几乎没有什么选择空间。

不过时至今日,客户已经拥有更多产品及解决方案,且足以顺利应对自己的实际问题。技术的消费化趋势正不断凸显,越来越多的普通员工正以前所未有的热情使用计算机、智能手机、网站以及应用等手段在家庭或者办公环境当中处理工作。这种趋势也彻底改变了技术领导者看待客户服务的方式——特别是着眼于企业内部环境。

根据我的个人经历,当人们发现了一种更为便捷的工作进行方式时,他们往往会不假思索地加以运用。而如果他们无法从 IT 部门处获得所需要的服务,则会将寻觅的目光投向他处。如果 IT 部门无法快速提供对应的审核版本,编辑部成员可能会从网站上直接下载新型编辑软件。人力资源部门可能在内部日程环境之外寻求其它规划工具,而市场营销团队则可能雇用第三方对品牌网站进行重新构建。技术业界将这种作法统称为“影子 IT”,这种趋势将使大规模 IT 环境下的管理与安全保障工作变得难以实现。不过从实际角度分析,影子 IT 之所以客观存在,其核心原因在于 IT 部门所提供的方案并不能让内部相关人士满意、或者后者不知道该如何从 IT 部门处获取自己需要的技术支持。

建立一套以客户服务为核心的集中式 DevOps 体系往往能够很好地解决以上难题。当大家设身处地为客户着想时,我们就有能力理解他们的需求及关注方向,并思考如何解决这些需求并将解决举措融入企业整体。不要简单粗暴地表示“你不能用这种方式处理工作”,而应该询问“你想达成的目标是什么,我又该如何有效地帮你解决问题?”每当应用程序团队实现了某项 DevOps 原本无法交付的成果,后者都可以从中学习到具体实现方式并意识到自身的不足之处,进而思考是否该在未来的工作中作出针对性调整。DevOps 团队能否通过一系列努力来满足未来可能出现的需求?在多数情况下答案恐怕会是否定的,不过有时候我们也确实能够做出一些尝试——但企业应当对此类变更进行认真评估。无论如何,如此一来 IT 部门将逐步成为企业当中的“实现者”、而非业务人员传统印象中的“拒绝者”。通过这种合作方式,内部客户将更乐于同 DevOps 员工并肩战斗、而非主动避开。

2.以客户服务为核心的思维方式有利于职业发展

在 DevOps 模式当中,应用程序团队需要同时负责运行自己所构建、拥有的技术成果以及客户服务。我很幸运地在自己效力过的每家企业当中,都亲自接触过其关键性绩效指标。这正是彭博公司的核心价值取向之一,我们也将这种思维引入到道琼斯的 IT 部门内,并最终将其作为 Amazon 公司的领导原则之一。

所谓拥有关系,可以理解为任何对某款产品或者服务负责的个人都应当将该产品或者服务视为自身业务的一部分。产品与服务可以体现为任何形式,包括网站、移动应用程序、企业电子邮件服务、桌面系统支持、安全工具、CMS 或者其它任何可以交付给客户的解决方案。

这种拥有关系会带来更为出色的客户服务效果,因为它将责任与信誉与相关产品监督者直接挂钩。反过来,对应的员工也会因此而受到激励,从而更为积极地倾听他人意见、了解潜在的替代方案并不断探索产品该如何实现深层改进。当问题出现时,负责对应产品的员工不能简单地“推卸责任”——他们有意义了解问题的出现原因,并为相关客户提供帮助。

而个人职业生涯的收益也恰恰体现在这里:每个人都希望拥有属于自己的一款产品,并为其保持良好的客户合作关系,这同时也将帮助企业赢得可靠、值得依赖且坚实稳定的声誉。

这还仅仅是客户服务如此重要的两项理由,在规模更大且复杂程度更高的企业中同类因素还有更多,特别是对于那些正在考虑采用 DevOps 机制的企业而言。


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

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

2015-08-31 12:22745

评论

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

需求是被挖掘还是被创造出来的?

Neco.W

产品 互联网 需求

油管博主路透 3080Ti 参数、黄教主烤箱中拿出 DGX A100 预热发布会

神经星星

人工智能 互联网巨头 gpu 互联网 英伟达

Tomcat安全配置

wong

Tomccat security

高仿瑞幸小程序 08 创建第一个云函数

曾伟@喵先森

小程序 微信小程序 大前端 移动

Flink Weekly | 每周社区动态更新

Apache Flink

大数据 flink 流计算 实时计算

如何快速更改qcow2镜像文件

奔跑的菜鸟

云计算

谈谈控制感(3):让孩子更好地成长

史方远

心理学 控制感 教育

全面解读信创行业 关注国产操作系统

统小信uos

操作系统

前浪的经验:区块链软件,一定也要去中心化

WasmEdge

比特币 区块链 智能合约 以太坊 加密货币

初探Electron,从入门到实践

葡萄城技术团队

大前端 Electron SpreadJS

由纪念日想到杨德昌

Elizen

随笔 电影

ThreadLocal到底会不会内存泄漏?实战直接告诉你答案!

刘超

Java 多线程 ThreadLocal

故障的传播方式与隔离办法

Wales Kuo

回顾经典,Netflix的推荐系统架构

王喆

人工智能 学习 推荐系统 netflix

Android10版本引发的生产故障及安全知识归纳

大刘

android https TLS 加解密

定在下午面试的那位候选人,说他不来了

无箭的丘比特

团队管理 面试 简历优化 招聘

怀念小时候吗?

安静的下雪天

个人感想

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (六)测试哪些内容:Right-BICEP

编程道与术

Java 编程 软件测试 TDD 单元测试

物联网技术栈之网关技术

老任物联网杂谈

物联网网关

线程通信知识点扫盲!

Simon郎

Java 后端 多线程

选择适合自己的 OLAP 引擎

程序员小陶

大数据 开源 OLAP

一文读懂阿里云通信的产品体系、技术架构与智能化应用场景实践

阿里云Edge Plus

人工智能 云通信 短信 语音 智能联络中心

游戏夜读 | 关卡设计为什么难?

game1night

猿灯塔-Phaser 使用介绍

猿灯塔

什么是工作

史方远

随想 工作

ZigBee3.0 节点入网流程分析

taox

网络协议

我为什么要开启InfoQ写作

Nick

一杯茶的时间,上手 React 框架开发

图雀社区

Reac

终于有一款组件可以全面超越Apache POI

葡萄城技术团队

前后端分离 服务端 GrapeCity Documents

全球经济动荡下,超流币逆袭而来!

极客编

AtomicStampedReference是怎样解决CAS的ABA问题

捉虫大师

Java

客户服务在企业DevOps体系中拥有关键性作用的两大理由_亚马逊云科技_Stephen Orban_InfoQ精选文章