公司主页 投诉建议 专家网 Bug登记 需求管理 客户服务网

中联论坛

查看: 1080|回复: 4

oracle服务请求旅行记

[复制链接]
  • TA的每日心情
    奋斗
    2016-11-7 12:11
  • 签到天数: 1 天

    [LV.1]初来乍到

    发表于 2016-11-7 12:00:02 | 显示全部楼层 |阅读模式
    扫描关注微中联,带你进入中联人的微世界
      在上个世纪,IBM因为自身原因,造就了不少巨头公司,因为不愿意自己生产PC的CPU造就了INTEL,因OEM操作系统造就了微软,因为习惯项目开发不愿意开发套装应用软件造就了SAP,本来关系数据库理论也是IBM提出的,但将其发扬光大成就了世界第二大软件公司的却是ORACLE。
      我们公司99年从7版本开始使用ORALCE,公司所有的产品基本都是ORACLE的,所以我们也号称是基于ORACLE的数据库应用技术公司。ORACLE的强大不用多讲,市场份额说明一切。ORALCE强大,但是作为最主流的C/S方式需要访问数据库,还必须在客户端安装数据库访问组件,并且对于组件的安装也有很多技巧需注意。如果缺乏经验,定会被莫名其妙的错误信息搞得不知所措、花费不少时间,所以此组件素来被很多研发与实施人员诟病。而从Windows版本的12CR1(12.1.0.1.0,2013年8月发布)发布后,其访问组件实现了全托管方式访问。此方式最大的优点就是无需安装部署、设置注册表、配置环境变量、没有32位与64位之分,仅需要引用一个组件就可完成几乎所有对Oracle数据库的访问相关工作,对于使用者来说简直就是莫大的“福利”。
      在2013年8月全托管的Oracle数据访问组件才发布时,查看了其功能说明文档,发现有诸多功能都不太完善,且考虑到稳定性的问题,替换该组件的事宜也就被暂时搁置了。ZLBH从2015年初至今,配合新产品的研发,从里到外做了较多调整。在2015年12月底新产品整体框架基本成形后,恰逢客户端直连数据库需求的提出以及对后续产品实施难度的考虑,Oracle数据访问组件替换可行性的分析与相关验证事宜再次启动。在验证过程中发现,组件经过两年时间的打磨,功能已基本成熟,初步判断能够支撑当前产品的功能要求。在经过综合考虑后,决定替换组件。而服务请求旅行也由此拉开了序幕。
    一、初次旅行的伤痛

    ·启航
      在2016年3月初替换了组件。因为替换前已针对性做过一系列验证,接着替换后的内部评测版本在使用的一个月过程中也未接到任何组件问题反馈,所以对组件稳定性的顾虑也就逐步淡化了。直到4月份进行性能整体排查时发现了两个问题,而此时已计划5月份在重庆九院的三分院上线,距离项目上线时间只有将近一月的时间。问题:
    1)指定连接池的最小连接数无效
    2)创建数据库连接要比以前耗时更多(在测试环境中大概会多400ms左右)
      第一时间在oracle论坛上寻求帮助(Oracle论坛 ODP.NET模块)。一天后获取到对第一个问题的答复——论坛技术工程师转发了一个相关属性的使用说明文档链接,在仔细阅读和验证后发现是我们对该属性的设置存在误区,我们经过相关调整后问题得到解决。而问题二的处理过程就曲则而漫长了。对问题二,论坛技术工程师建议创建SR寻求解决。但当时并不知道所说的SR是什么,在询问老彭等oracle专家后终于得知——可在Oracle付费服务平台上提出服务请求(Service Request),对方技术支持人员可协助登记Bug并申请补丁。
    ·布满荆棘的旅途,一筹莫展
      虽然公司购买了此服务,但以前从来都没有使用过,只有来当第一个吃螃蟹的人了。抱着尝试的心态根据流程试着创建了第一个SR服务请求。可等了一周后,对方工作人员除了将中文描述翻译为E文外没有任何回应。是不是提问方式不对?去仔细检查了所提的问题,除问题的描述采用中文外其他都是严格按照其规范填写未发现什么不妥。正在束手无策的时候,收到个高紧急度的ZLBH服务要我处理,由此联想到是否因为所提交的SR紧要程度不高而未被及时处理呢?返回去检查,发现登记问题时标注的严重性为第3级(问题等级1~4对应紧急度、严重度高到低,通俗来讲第3级属于并不紧急问题)!立马重新创建了一个SF,将严重性标注为最高并且将问题采用E文描述,这一次技术支持人员当天则给出了回应。
      在与问题处理人员接上头后,首要问题就变成与对方工程师取得联系并进一步交流和确认问题。由于对方工程师在印度,交流语言是E语,然后还存在时差和他上班时间的因素(当时那个工程师的上班时段是印度时间的下午5:30~凌晨2:00,而这个时段正好是我们的下班时段)。在电话交流和留言两种方式中,E文口语拙劣的我只好选择留言这种及时性比较低的方式。就这样配合工程师进行问题原因的排查定位,往往进行一次沟通就是一个工作日。在遇到E文表述不当导致相互不能正确理解的情况,就会出现要花几个工作日才沟通到一个点的状况。期间简直就是煎熬!最终对方根据我上传的一系列跟踪日志分析,怀疑是数据库服务端存在问题,让我重新创建一个关联SR询问服务端技术工程师。
      这时恰逢我们的付费服务账号到期,已不能创建新的SR,而对方也不再继续提供支持。经过一月的漫长等待,新的服务账号终于申请下来,才又重新创建了SR与服务端工程师进行一系列沟通验证。
      这次动了个心眼,让两个相关SR的工程师进行了沟通交流,让他们明确此问题应该由谁为主来处理并跟进。最终明确由负责组件的SR工程师继续跟进,而此时已经是6月,从问题登记那天算,已经跨了两个月,但可笑的是问题并没有实质性进展!还好这个问题没对我们当前上线的项目产生关键性影响,否则只有回退我们的程序版本,并做大量的合并修改,那将是相当不小的工作量并会引入产品稳定性的风险。(当时的主要影响——客户端登陆后主界面的打开耗时比以前慢两秒左右,用户体验肯定不好!)
      虽然目标是明确的——督促对方确认问题,并且能明确给出解决的时限。只可惜这次白忙一场!
    1.png
    图1:严重性1级问题联系人设置
    ·收拾心情再启航,不虚此行
      经过了前面痛苦的沟通过程,痛定思痛,对沟通中存在的问题进行反思:
    1. 服务工程师都是研发人员,对于组件内部处理比较熟悉,根据日志能够锁定问题范围。但我对这部分的理解相当有限,没法跟上对方的思路,在整个配合过程中总是被牵着走,毫无主动性可言。
    2. 除了各自掌握的知识存在差异,语言上的沟通也存在障碍。虽然印度工程师沟通时很有礼节(每次必说谢谢)有问必答,回答内容也比较直接。但有时沟通中会出现一些较为专业的术语,我需要搜索半天才能搞懂,十分影响沟通效率
    3. 沟通采用讨论版留言方式,时效性较差,再加上工作时差等因素,整个过程效率就显得十分低下。
      思考后决定换一种思路与对方工程师来确认这个问题——由我来“协助”他重现问题,然后由他来进一步分析,而不是像之前那样“协助”他来分析定位问题。这样一来就能降低沟通成本,只要他确定是组件问题,后续就交给他们自己的研发人员内部处理即可。
      于是,在与其明确数据库和组件的版本后,我单独编写了一个能重现问题的简单Demo程序,传给他让其在重现。意想不到的事情又来了——对方告知,在他的环境中不能重现,且怀疑此问题可能与网络环境有关,需要进一步验证问题原因。囧!然而网络原因我早已考虑并排除过!与之沟通,但对方仍然表示怀疑,想通过WebEx方式远程查看我的实时验证结果。此时才知道还可以有这种最直接的“远程”方式!有次神器,早点亮出来嘛!在通过远程查看方式观看了我的整个操作,并检查并排除了网络环境等一系列因素,最终确认了此问题很有可能是Bug。谢天谢地,总算看到希望了!
      后续在我的配合下,对方也在自己搭建的环境中重现了这个问题,并与组件研发工程师沟通后登记了Bug。此时已经是7月底,从问题登记那天算,已过三个月。
      这是我第一次通过SR方式登记的第一个Oracle数据库访问组件Bug,让我熟悉了SR中的使用技巧,以及应该怎样与对方工程师“愉快”地沟通并快速解决问题,为我后续继续登记组件问题奠定了基础。
    2.png
    图2:Oracle印度工程师通过远程监控方式查看问题重现并确认Bug
    二、再次旅行的精彩
       区卫在得知新版本ZLBH所做的一系列改进调整后,决定升级区卫相关产品线。他们在2016年9月中旬做整体升级测试过程中反馈了一个组件相关的问题,经过反复验证后找到问题的重现规律。在整理了问题重现环境并编写Demo程序后,随即登记了一个SR。一周之后就确认并且登记了一个严重性为1级的Bug(最高等级Bug),最近获得消息此问题已经明确在2016年11月18日发布的补丁中解决。
       虽然此问题从提出服务请求到最终解决横跨两个月,但确实相当顺利!反观我第一次的提问,两个月的时间还处在茫然阶段。对比两次的经历,虽然问题难易本身程度不同,但提问技巧着实起了不小的作用。
    3.png
    图3:区卫反馈托管ODP问题被登记为严重性1级Bug
    4.png
    图4:区卫反馈托管ODP问题明确在16年11月18日发布的补丁中解决
    三、旅行感受
      作为一个被服务者,感受了作为当今全球第二大软件公司提供的有偿服务。每次的服务请求感觉就像一次旅行,充满了对未知的期待、即便最后的目的地并不一定尽如人意,但旅行过程中的经历也能让人成长不少。几次旅行除了对服务提问流程的熟悉与技巧的掌握外,对其服务平台提供的SR服务从规范和服务人员也有些许感受。
    ·流程规范
      整个提问过程采用引导方式。除问题的基本信息外,需要你确定出现问题的具体产品,产品问题的版本以及问题类型等。对于一些必填项的对应提示信息也比较清晰,方便提问者填写。当你把这些基本问题描述清楚后,会根据问题的关键字以及产品和对应版本从Oracle的文档库中查找出相关的文档供你查阅。
      除此以外,你还可以尝试在其论坛上提问,很多来自世界各地常混迹在论坛的大牛会毫不吝啬的传授你使用上的小技巧与注意事项。
      如果前面两步都还不能解决问题,才会让你填写一些更加详细的内容或者上传附件以帮助其后续的服务人员快速的响应服务请求(毕竟每个SR服务都收费不菲)。这样的方式应该是比较合理的,首先很多使用上的基础问题都能够通过查阅文档的方式解决,然后再通过引导提问的方式(并不繁琐),让你在提问的同时进一步对问题进行梳理和思考,一定程度上避免盲目提交不必要的SR服务。
    5.png
    图5:服务流程创建四步曲
    ·服务人员水平
      正如前面所提到的,服务工程师都是研发人员,对于产品都熟悉,只是熟悉度存在差异、服务水平参差不齐。好的服务工程师会引导你找到问题,会比较注重沟通的效率。
      在提问过程中遇到过工程师自动询问你工作时间,他会配合你的工作时间协助你查找并定位问题。而且当自己思路不清晰时,他会让更加有经验的工程师来继续跟进此问题,不会让你做很多无用功。
      而有的工程师,可能在自己都还没思考清楚的时候就让你做一些无谓的事情。一旦服务请求者自己不够清醒,很可能就被其带到沟里去,既浪费了时间又没解决问题。或者对提问或已确认是Bug的问题跟进处理不及时,需要你多次的询问、催促才会有所进展。
    6.png
    图6:所提托管ODP组件问题列表(状态为80则为已解决问题)
    他山之石可以攻玉,从Oracle服务反观ZLBH服务系统从流程、规范以及ZLBH的服务人员与服务请求者自身水平,确实有不少值得改进提高之处。



    回复

    使用道具 举报

  • TA的每日心情
    开心
    2017-8-16 17:02
  • 签到天数: 81 天

    [LV.6]常住居民II

    发表于 2016-11-8 09:52:31 | 显示全部楼层
    基于微信公众号的客户服务系统
    棒棒哒,简单的涨涨知识
    回复 支持 1 反对 0

    使用道具 举报

  • TA的每日心情
    奋斗
    2016-11-7 12:11
  • 签到天数: 1 天

    [LV.1]初来乍到

     楼主| 发表于 2016-11-8 13:29:43 | 显示全部楼层
    邓留贞 发表于 2016-11-8 09:52
    棒棒哒,简单的涨涨知识

    谢管理员置顶
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2016-8-24 09:55
  • 签到天数: 4 天

    [LV.2]偶尔看看I

    发表于 2016-11-15 09:51:13 | 显示全部楼层
    扫描关注微中联,带你进入中联人的微世界
    不错,给力,威武!!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2017-7-1 15:35
  • 签到天数: 3 天

    [LV.2]偶尔看看I

    发表于 2017-4-1 19:47:36 | 显示全部楼层
    基于微信公众号的客户服务系统
    可惜的SQL SERVER才是.NET的最佳拍档,ORACLE目前还不能支持.NET CORE,微软亲生的已经可以跨平台了。。。
    回复 支持 反对

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    手机版|管理细则|中联论坛 ( 渝ICP备12005023号  

    GMT+8, 2020-7-15 17:27 , Processed in 0.151258 second(s), 30 queries .

    Powered by Discuz! X3.2

    © 2020 ZLSOFT

    快速回复 返回顶部 返回列表