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

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

2017-10-31 06:23

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

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

  从构建阶段到传输至生产运行阶段,容器在每个阶段都面临着安全风险。容器防护需要在整个栈及部署过程中引入一种分层安全策略。

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

  《Re:从 0 开始的微服务架构》专题的第五篇文章,我们来看如何用 Docker 支撑微服务。

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

  在本文中,我们将会深入研究主数据管理场景中微服务架构的适用情况,并且会分析在问题域中,如果需要计算密集型的任务,基于微服务的架构所面临的挑战,比如在计算无消费信贷组合的预期损失的时候。

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

  我们理解您使用ad blocker的初衷,但为了InfoQ能够继续以免费方式为您服务,我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单,感谢您的理解与支持。

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

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

  《Re:从 0 开始的微服务架构》专题的第五篇文章,我们来看如何用 Docker 支撑微服务。

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

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

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

  在本文中,我们将会深入研究主数据管理场景中微服务架构的适用情况,并且会分析在问题域中,如果需要计算密集型的任务,基于微服务的架构所面临的挑战,比如在计算无消费信贷组合的预期损失的时候。

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

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

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

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

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