Skip to content

生活

感谢那些信任我的朋友们

10月1日收到邮件,准确的说应该是美国的9月30号发出,收到Oracle 授予了ace项目组相关的荣誉的通知.感谢朋友们的支持,也感谢oracle的认可.

开始从事oracle相关工作的时候就对ace无比神往,可是多年下来,接触了不少带有这个头衔的工程师,有些许的技术让我对此有所失望,甚至十分失望.但愿我持续的努力能不负此荣誉.只碍于时间有限,能做的事情太有限.

此时感觉没有预想中的那样里程碑式的松一口气,反而更加担心自己是否有足够的精力来做一些对数据库技术有意义的事情.才认识到此时才是蹒跚起步阶段.

在此衷心的感谢那些不断支持和信任我的小伙伴们.

生活以及Oracle

总的来讲,我不善于写这种技术和生活交涉的文字。
工作这些年,以技术融入社会,在oracle 数据库这条路越走越远,经常会迷惑自己会想要什么?经常有人在身边说某某在某行发了,在最初的几年确实是怦然心动。技术在最初的几年是无法很明显的改善生活的,这个我已经深有体会,我也想过做其它方面的事情,但是并没有鼓足勇气去放弃自己喜欢的工作。
从实际上讲我并不是一个好工程师,因为我不喜欢钻牛角尖,我喜欢一种感觉,推动以及完成一个项目的成就感,把技术实际的应用施展开来,这种感觉很棒!你会发现没有什么能比把自己的专业知识给予用户解决方案解客户燃眉之急的那种感觉,这可能正是你在这个行业苦苦追寻的,当然我现在发现这是我在追求的。今年早些时候老姚和我聊到这个话题,他的定义就是类销售方向,我的理解就是技术型专家走上了工程师与销售的角色混合之路。

我很想把我的所学每天按部就班整理出来放到blog,人的精力是有限的可是。
我很想把事情做好,却没有足够做完美一件事情的时间,最近理解得很深刻,做事的人不是简单的4个字。且行且稳,路还要远,就想勒夫当年还是一个德乙的球员,如今却是德国国家队教练一样,任重道远,看得远那是应该的,做好眼前事一步步走出踏实的印子那更是必须的。

这是这两天遭遇的错误

在大前天写索引维护碰到asm cannot mount asmdiskgroup的支援电话后就赶赴现场,
趁现在有点空闲记录下这2天遭遇的错误
ora – 00600 [2662]
ora – 00600 [4097]
ora – 00600 [kargrp1]
Linux-x86_64 Error: 30: Read-only file system
CRS-2106:The OLR location /u01/grid/cdata/dydmsdb02.olr is inaccessible
utread:3: Problem reading buffer a6f000 buflen 4096 retval 0 phy_offset
存储控制器背板全坏
存储闪掉电.

数据于当晚就马上抢救回来.当时voting已经损坏,raw信息也已经丢失,系统多路径混乱.
折腾.不过总算不辱DBA使命.

项目工程师在服务现场如何面对客户

本文以Oracle服务为背景,讲述工程师如何面对客户,我觉得讲得很有道理,转到博客,原文摘自转自CSDN.

一. 概述
oracle数据库服务的市场需求也是十分巨大的,国内在做oracle第三方服务的厂商挺多,面对如此众多的卖方选择,面对着令人眼花缭乱的服务商,可以说既爱又恨。爱的是有时候真的能帮自己解决问题,减轻自己的压力,有时候又解决不了问题,让自己也不好交代。
客户工程师各有不同,他们有自己的喜好,有自己的情绪。而对于提供oracle服务的工程师来说,同样有自己的喜怒哀乐。客户的喜好忧愁,与服务商工程师的酸甜苦辣交织在一起,谱写了五彩斑斓的服务与被服务篇章。
作为处于弱势地位的现场工程师,如何去面对处于甲方地方的客户工程师?都值得每个现场工程师很好总结和体味。经历这些真实的挑战,一定对客户是上帝的理解十分深刻。
现场工程师,面对的不仅仅只是技术问题,实际上是一个公司的代表。很多技术也许派不上用场,需要自己灵活处置、随机应变。需要把握一个度,快速、准确、弱势、协调、解释。当然,在现场,具备解决问题的技术能力是必要的,在这个基础上,具备应对现场的过硬的交际能力和心理素质,也是非常重要的,体现了一个人的综合素质,从一方面代表公司形象。

二. 客户的分类
俗话说,林子大了,什么鸟都有。仅仅对其中一部分进行描述。
从理论上来说,我们是平等的,是一种合作关系,而现实中,我们是一种买卖的关系,确实存在不平等地位,一方是强势的甲方,一方是弱势的乙方。甲方一句话,乙方得客气的做出应答。也许没这种必要,但是,现场大多数就是这种情形。
需要服务的与提供服务的,本应该是一种合作的平等关系,但是具体到人,就变了,这是大家已经习以为常的现实。且看客户的类型。
2.1 热情周到型
有的客户十分的热情,也很周到,在你到达现场前,为你准备好了餐票。解决问题后,会好好的请你吃顿饭,更有甚者,会开车带你去兜风。这种客户一般是条件比较好的客户,而且对于你来能解决他们存在的问题心存感激。(其实没必要心存感激)。
2.2 不冷不热型
这种客户,在你到达、处理问题的过程以及离开时,都没有特别的反应,他们团队的氛围就是这样,大家彼此不需要太多的客套,属于那种非主动,一问一答型。
2.3 先礼后兵型
有些客户对于你的来到,充满期待,对你十分的热情友好,对你提出的要求,尽量满足。但是,如果你不能解决问题,或者弄出新的问题,他们会毫不犹豫的对你进行投诉。并且不允许你下次再来他们的现场,要求换人。
2.4 强烈依赖型
客户对于你的技术,有十分严重的依赖,有时候并非客户不懂,而大多数情况下,客户是不想对可能出现的后果负责,因为做数据库的操作有时候有巨大风险。所以,什么事情,都由你来做,比如扩一下表空间,删除一些不要的文件等。
2.5 自力更生型
有时候在现场,可能会让你觉得,客户买你们公司的服务是不是一种多余,因为,每次都是你们公司主动要求去做一下什么所谓的检查,好像是为了完成合同规定的任务,而去了之后,客户工程师似乎不情愿让你碰任何系统,不允许接入任何机器,你需要做的是,提供保证没有病毒的相关脚本和操作说明。他们自己来操作。
2.6 实力强大型
有时候在现场,客户似乎表现的比你技高一筹,有时候让你感到有点内心打鼓,客户无论是从交流沟通,还是貌似请教,都好像设下埋伏,对你其实在进行试探,这些人既有很快速的操作技能,也具有很深的理论水平。而且他们自己本身就有很强大的dba团队。
2.7 完全不懂型
出于某些原因,客户那边可能临时缺少人手,或者dba刚离职,客户工程师只是临时接手这个任务,或者客户就是刚刚入门,做一个不太重要的系统在维护,实际上让你能教教他,也许一个命令,敲一个字母,都需要向你咨询,这种属于完全不懂型。
2.8 压力巨大型
有时候客户工程师在现场面临强大的压力,通宵达旦,连续奋战,只要没有解决问题,他都面临上级的强大压力,或者是上级也面临这更上级的压力,这种压力是硬性的,一层层传递,最终也必然要传递到现场工程师身上。这种客户工程师可能面临考核的巨大压力,因此,对于实施服务的现场工程师具有非常高的要求,而且要确保能解决问题,并且容易出现情绪问题,容易表现在脸上。
2.9 压榨型
有些客户有一种心态,我买了你们的服务,你们就得听我使唤。而很多第三方厂商,迫于竞争的激烈,对客户是有求必应,对现场工程师也是要求尽量满足客户,进一步助长了此种心态的客户的此种心态。客户认为花了钱,就得给我好好的处理问题,尽量的提供服务,似乎是要把花出去的钱全部捞回来,尽量物有所值。你的所有时间都是客户的,包括你的周末甚至是你的夜晚。就是周末搬个桌椅,都需要你来代劳。

三. 客户的要求
3.1 快速响应
有客户曾经对我说,购买你们的服务,其中一个非常重要的因素,就是看重快速响应的机制。一般客户问问题,都要引起重视,有时候客户是在不经意间提出,有时候是比较正式的提出,无论客户自己是否重视,都应该引起你自己的足够重视,否则,可能会引起客户的不满,严重的会导致投诉。
3.2 技术靠谱
有一些客户对提供服务的工程师有比较苛刻的要求,甚至要求通过他们自己设置的面试与笔试考核,其他的客户可能要求不是很高,但是都要求技术工程师的技术要靠谱,一般来说,技术不好的工程师,往往会在一些好说话的客户、不重要的系统上先熟悉,练练手,有机会再进入重要客户的重要系统。如果没有一定的技术实力,很容易引起客户的不满意。如果一问三不知,客户也会对你失去信心。
3.3 问题的精确定位与处理
对于问题原因的精准定位,是一项非常重要的技能。也是所提供服务的质量体现。有经验的工程师能够快速熟练的去验证问题,而不太有经验的工程师,会逐一尝试排查,最终找到问题症结。不管怎样,如果对于问题的分析不合理,不具有说服力,客户可能是不会接受的。
3.4 超出合同范围的过分要求
有时候可能客户会提一些超出你能力范围的,甚至是合同范围的要求,超出能力范围的事情可以找公司协调资源,寻求帮助,但是超出合同范围的事情,你只能跟销售反映了。比如如果只是做数据库的维保服务,而客户要求你检查主机硬件,或者提出一些诸如要求你们公司组建什么水平的试验室等等的要求。

四. 问题和矛盾
4.1 有些不能解决的矛盾,这是在现实中客观存在的。
不是所有的问题都是能解决的,不是所有的技术问题非得技术手段来解决。很多问题是目前的水平没办法解决的,这些是客观存在的。就算是原厂派资深的工程师,也解决不了问题。
4.2 合同中的技术实力与现场中区别甚大
有时候,客户认为,签合同时候说的天花乱坠,合同签了之后,实际上没那么强,没那么好,甚至有很大的落差。会让客户产生一些不满。

五. 应对客户的技巧
5.1 答应客户要办的事情,一定要办。
许多时候,很多工程师,在离开客户之前,回家心切,或者想早点离开客户这里,免得又会有什么问题来麻烦自己,只要客户问的问题,往往口头上满口答应,表示回去后再看看,不过可能回去没看,没引起重视,或者忘了,就容易引起客户投诉。
答应客户的事情一定要给一个结果,不管结果如何,都要给客户反馈。
5.2 表现一种姿态
很多时候,说实在的,可能解决不了问题,但是你至少得有个姿态,表明我确实尽力了。从服务态度上加分,如果问题没解决,又一副大爷般的神态,那结果往往也会不妙。
5.3 同客户工程师搞好关系
同客户工程师搞好关系,其实也是一个工程师的能力体现。一旦同客户工程师的关系做好了,处理问题起来就会得心应手,如果跟客户关系搞不好,相互暗中抱怨,平添一堵墙。比如请客户吃顿饭,或者天南地北的说一通,或者一起深入的沟通一些他们关心的其他问题。对客户表现出一种真诚、职业、热忱、敬业的品质。搞好关系实际上是解决问题的一种润滑剂。
5.4 注意同其他厂商的工程师保持通畅的沟通
在现场,往往会有多家厂商,共同来做一件事,大家实际上有一个共同的目标,就是让系统高效稳定的运行,大家的目标是一致的,出了问题大家相互支援,尽量不要造成那种有事情相互推诿扯皮,这样大家都不好受。
5.5 其他力所能及的帮助
作为培养客户关系的一部分,适当的满足一下客户的其他要求,也是有帮助的,比如给客户拷贝一些技术资料,给客户做一个小小的培训,以解答客户心中的疑惑,往往会有很好的效果。
5.6 提交详细文档
客户工程师有很多时候,对发生的问题,需要有个技术文档,以便下次遇到同样问题,知道原因,并可能会采取措施避免,有的可能需要一份报告,向领导交差。不管怎样,事后提交一份友好、专业的报告,都是非常必要

最近的一些杂事

1.Blog主机空间迁移

由于朋友的vps的ngix缓存设置出问题导致我的博客不能登录控制后台,朋友一直没时间去调整ngix对应的内存参数恢复运行,我只好把blog迁移到现在的主机空间。

用的去年12月份的备份恢复的,经过一翻波折还是把12月后的文章迁过来了大部分,所以可见保持blog的定时备份还是很重要的。

后续开始会跟紧更新,以前埋下的坑会补上,新的文章更多会关于Rac和dg以及数据库安全,数据库安全部分的比例会占大头。

2.申请参与ACE program

由周亮的推荐参加了ace program的评审,我自己觉得心虚,八成是过不了了。不过还是在某人怂恿下提交了表格和资料,希望不大,就当是给自己装个小胆。

3.一封尘封的邮件

前几天翻luda@ludatou这个邮箱发现了机械工业出版社在13年的5月份时候发了封邮件给我,向我邀稿《大规模数据库的设计与运维》一书,我得瑟一下。虽然这本个邮件收晚了,但是在13年底这个编辑还是找到了我约了另一本关于安全的书籍,压力大起来了。要好好的沉淀。向各位前辈学习。

4.今年公司在杭州帮我招了个dba

呵呵,虽然这个dba水平还不够纯青,但是已经能帮我顶下大部分的活了,特别是database heathly check,这个是让我日复一日操作了那么多年的活儿,终于有人接过我手中的棒子了。这下和老于一起奔波在华东除了上海之外的应急和调优现场,也不知道这算不算同一种生活的另一种方式?说变没变,说没变又有点变。

5.弟弟的ocm

我弟弟考过了ocp,打算年底把ocm给考了,一直督促他学习,这孩子,让家人操了不少心。

 

早上了洗脸刷牙,准备贴发票。

繁忙的生活

最近家里买房子,烦心事一堆。
还要准备安全书籍稿子,Oracle证书升级事情,CISSP考试准备,以及给事业的一些事情做准备,一堆事好忙。

平台

如果现在的公司给予的平台不够,我的最直接想法就是找一个更好的平台,要么就联合几个兄弟直接创建平台了。

一个小bug,SUN平台的oracle job运行

今天碰到了一个bug,sun的系统下运行497天之后,Oracle的job就不能自动运行了,需要重启系统,9i的数据库。
9207修复,坑啊.其他系统在9206之后就修复了.

最近我弟弟来浙江,他在学习Oracle和linux,aix,在给他做大量的辅导.

耽误了blog的更新,
这几天公司也同时要处理大量的工作,忙啊

最近

现在的工作呢,是比较freedom的,可以自己去做好安排,及时的把服务按合同提交即可,然后就是解决突发故障以及保证性能,这应该是大部分乙方DBA的工作内容吧。

我习惯做计划,自己有自己的计划大到5年内,小到1年内,1个月内。而在工作方面,从这几年在这家公司工作的经验累计下来,我习惯把自己的计划排好一个月,然后按周实施计划,这样的话就能够非常的清楚这个月在trouble以及other call事件外的行程以及安排。而我按照全部指定责任的客户排好计划,我发现总是有一个共同点:我一个人是无法完成所有客户的合同面上的人天的。如果中间碰到trouble或者其他事情,我就必须再次去申请调动其他的工程师来支援。这个情况出现得最频繁的是2012年,公司还很不合理的把我指派到三菱银行做架构设计。我觉得当时这个安排是十分有问题的,我一个人的手上有16个客户,每个月都出现service delay的情况,历经一年,朝九朝三。这个情况我也不止反应了一次,而当时整个团队压力非常大,技术部一度只有7个人,顶着巨大压力负责整个华东那么多客户的support。2012这一年我没有很多的时间去陪家人,去做自己想要的事情,大部分时间在路上,在客户现场。我做着我的plan,实施着我的plan,有时候我也很庆幸我顶住了压力,和几个同事熬了过来。

今年以来公司各方面都走了调整,流程也好,还是技术部人员也好,目前整个team已经超过了20人,随着新技术经理的习惯以及安排,客户负责不均的情况得到比较大的改善,而公司也把几个比较有经验的工程师调整到更加有意义的合作support上面,比如集中售前,分享等。而我在晚上时间就更加充足,也和出版商签了合同,关于安全方面的新书也正式开始写了,我会更加努力的更新blog,把自己所理解所学,分享出来。