做Support的主要强调什么技能

bombhuauto

各位好，

澳洲职场新人，目前主要做tier2的Support工作，对现在的工作有2个感受。

1. 感觉工作中技术含量很低，与人沟通也主要邮件为主，对沟通能力要求很低（会写会看就行）。感觉长期发展很容易被人替代。请问是不是我的错觉？

2. 做Support是否对具体熟悉什么编程语言不重要？因为工作中接触的代码虽然种类很多（前段页面，中端代码，后台数据库），但是都比较基础，感觉有点像万金油。目前是“成功”做到了全看得懂但完全不会写。请问是不是我的错觉？

beinlich

mark,等高人回答

matrix

什么类型的公司？support什么？

kawara

Level 2 需要耐心。并不需要技术能力。当然做好任何技术工作逻辑思维能力都非常重要

点点妞

Communication and Co-operation, Use your brain to follow the process and understand what is change control

kksp

一直都很好奇，support感觉是要解决问题的，但是又不需要掌握真正的技术。。。

xiaoxiaomt

哪类公司？

bombhuauto

点点妞 发表于 2014-1-17 15:59
Communication and Co-operation, Use your brain to follow the process and understand what is change c ...

感觉有点无招胜有招的感觉。很难描述。

其实把握事件的紧急程度。处理先后。本身就满难。。

bombhuauto

kksp 发表于 2014-1-17 16:01
一直都很好奇，support感觉是要解决问题的，但是又不需要掌握真正的技术。。。 ...

个人感觉做Support还是不要钻研代码太深，容易陷进去，其实把对应的事情给对应的人才是最重要的，是把。

kksp

bombhuauto 发表于 2014-1-17 16:22
个人感觉做Support还是不要钻研代码太深，容易陷进去，其实把对应的事情给对应的人才是最重要的，是把。 ...

我还想说如果楼主担心就没竞争能力就专研一下技术转去编程呢

bombhuauto

kksp 发表于 2014-1-17 16:24
我还想说如果楼主担心就没竞争能力就专研一下技术转去编程呢

从编程转出来的。


现在觉得技术难点不是很多，如果碰到技术上不会的，下班回家google一下也就会了。
但是很多事情如何定位，如何处理合适，处理到什么程度这个很难啊。。。。

bombhuauto

kawara 发表于 2014-1-17 15:56
Level 2 需要耐心。并不需要技术能力。当然做好任何技术工作逻辑思维能力都非常重要 ...

能不能再详细说说，举个例子。

逻辑思维，IT出身的且能来这里的中国人问题都不会很大把。

点点妞

bombhuauto 发表于 2014-1-17 16:16
感觉有点无招胜有招的感觉。很难描述。

其实把握事件的紧急程度。处理先后。本身就满难。。

是的，技术要求倒在其次，工作协调能力更重要。

gifox

bombhuauto 发表于 2014-1-17 15:31
从编程转出来的。

还下班google，上班的时候来google啦，什么时候google没有了。我该失业了。

ericlao2013

technical skill 和 none-technical skill都需要。
这个行业起点低，但是做到较高的级别也不容易。
优点是不用加班，而且年头越长，经验越丰富。

gifox

1 其实沟通能力很重要。不是说用email就要求不告。应该说对于英文要求不高，不要你写文绉绉的东西就是了。plain english搞定，还有一图胜万言。support需要和客户以及基本内部所有的team沟通的，包括了销售，开发，ba, consultant ,product manager，support的队友....有时你要求人家做事，催人家做事。但是又不要得罪人，还有有时需要人家百忙里面抽时间看你得事情，指点你。都是要维护好关系的。比如很多程序员都怪怪的，你得配合他们得思维模式。

还有，不只是email沟通吧。有时直接找那个人有它的优势。就是可以让那个人马上回答你的问题。有的人喜欢拖的。所以也要打电话，如果是同一个building的，直接过去找人阿。还有我之前提过，我有时会被professional service或者 sales抓去跟客户开会的。尽管我不是主导会议，更多是备询。

2 技术的确时万金油阿。因为当你发现问题所在以后，谁负责那个部分就要交给那个team去作啦。e.g，你发现是core product 问题，交上详细得bug report. 如果是network 问题，就当然要指向客户的network admin，如果是数据库问题你要交给客户的dba或者自己的dba处理。不过你的都知道一些，你才知道怎么样isolate问题，指出问题，证明问题。

还有些东西的能力也不知道该怎么说，比如吧，R&D team最讨厌人家交上来的bug report不好，发现是configuration issue, environmental issue，或者根本就是解释不清楚怎么reproduce话就比较不爽。经过多年的训练，我这方面作的相当好。有时其它人交的bug report不行，R&D会让我解释一下的。

待续。

gifox

ericlao2013 发表于 2014-1-17 16:14
technical skill 和 none-technical skill都需要。
这个行业起点低，但是做到较高的级别也不容易。
优点是 ...

不用加班这事要看你自己的位置，公司的性质。

如果出现P1 production system down, P2 critical function down的时候。是不是可以心安理得到点下班，第2天上班继续呢？我是不行的。
还有就是如果是全球的team呢？好像我之前的公司support 是follow the sun，全球4个shift，分布美国，欧洲和澳大利亚（每2个shift都有一定重叠时间用来交割合作）。如果要和美国的team沟通，我当然可以发一个email第2天才等回答啦，不过那样子就每天只能交换email一次。有时我是主动牺牲点时间，凌晨（美国）或者傍晚（欧洲）开会或者email交换来保证我们可以多交流意见的。

事实上这些事情都可以让上面的management记住你。

sdfacre

A good support usually knows everything including the business and code.

before you get bored with the job, ask yourself, 'Do I know everything?'

To take one step further, think about how to improve the business and the system, as you are the one who knows the business and the system, and what issues user is having (the system is having).

ericlao2013

gifox 发表于 2014-1-17 17:22
不用加班这事要看你自己的位置，公司的性质。

如果出现P1 production system down, P2 critical functio ...

你很敬业

对于24*7 的P1，一般要求做好handover就可以下班，大多数客户比较理解就可以正常off shift，有时客户真着急就是不放电话，那是要耗一段时间。

gifox

3 咔哇说的逻辑能力很重要。如果一个复杂的问题出现了，你没有答案。不知道发生什么事情，以前没有发生过。怎么办？就是要分析问题，问正确的问题。比如我有过一个客户。从旧系统升级到新系统时migration 的速度很慢。他们没有办法按期完成着急了，到底哪部分出错？是他们用的软件问题，是网路问题，是migration的utility问题还是哪里除问题。搞了很久。后来他们CTO 都找我们Sales VP 吵了。因为他们的系统涉及到好几个不同的Products，有我们的几个products，有第三方的products。 最后是我建了一个把他们实际production的系统简化以后的lab（要把哪些东西简化掉也是要思考一番的）.反复就各种可能性进行测试。比如说如果把储存从网路储存改到本地硬盘，得到的数据还是一样。那么我们可以排除掉网路延迟....最后发现是他们的archive 系统比较特别。因为法律规定，那个系统是不会删除掉任何数据的，同一个文件重新archive的话，会生成同一个文件的不同版本。这个系统是用一个sybase db来为每一个进入的文件建立一个entry。在migration的情况下，进入archiving system的文件数字会上涨到平时的成千上万倍。所以sybase db就成了瓶颈。这是我把很多其它可能性排除掉以后才发现的。

4 立刻学习的能力，就是放狗的能力。有时客户说的东西其实我不知道他在讲什么，就是靠放狗。跟他解释时还得表现出一个专家的样子。我又试过一个泰国的客户在最后列印的PDF 文档里面泰文无法正常显示。我研究好久才发现他们有一个文件用来map字符还有泰文，这个文件还是我们公司当时的Pro service人员提供的。推脱不掉阿，我不懂 code page的嘛。也是马上学习。3日后把改好的文件给他们。全靠googel， 我怕我干不了多久。

5通用工具的能力，看log，会比对不同工具生成的log。很重要的。所以一些通用工具就是要懂了。比如说sys internal 里面的process monitor和process explorer是很重要的工具。还有fiddler。一些人爱用wireshark我没有用过。此外doctor watson, appsight等多少知道一些也是好的。IIS log, event viewer, performance mon， ULS Viewer....你要知道log在哪里，怎么配置，大概会记录些什么可以给你什么信息，不可能记住所有细节也要知道log的机构。都要知道。还有其它命令比如ping, nslookup.....这些都是要懂的啦。

gifox

ericlao2013 发表于 2014-1-17 16:30
你很敬业  

对于24*7 的P1，一般要求做好handover就可以下班，大多数客户比较理解就可以正常of ...

不放电话倒不是问题。哪里有P1，P2的问题可以电话里面解决的。我至少需要先看log，做研究测试。搞不好还要开remote session。

谁可以不着急阿，P1可以让他们公司业务直接暂停的。比如以前support过一个保险公司的claim workflow系统。如果system down就是意味着所有的case officer无法工作。肯定要赶在第2天公司开工前修复（事实上SLA也规定了1小时回复，4小时修复阿）。

是可以offload给欧洲的team做，但是起码要和他们开会，一起研究个2个小时让他们100%了解状况还有我收到的资料才行阿。

只是这种事情1年没2次就对了，老是P1估计客户也吓跑了。但是解决一个P1客户满意就人人都知道你了。

背包客

做support要记得让子弹飞一会儿

gifox

6 上面有人提过跟process还有 change management的很重要。的确， ITIL 对于support是很重要的，不过奇怪的是澳村不走ITIL，公司内部流程搞ad hoc的公司不少。ITIL里面support相关。2项 incident management还有change management.

不过其实，天天在做。时间就了，随心所欲不越轨了。SLA了然在胸

现在换到新公司，新team。 我的process是我自己写出来的.....变成了不存在follow的问题，我自己决定要做什么怎么做。我和manager有个想法，把澳大利亚本地的support process标准化，用ITIL的角度重新修订。 效果好的话。我们会上书到大老板，建议在总部和全球实施。不过想是这样想，戒慎恐惧，我是不敢奢望事情会很顺利。

7顶住压力的能力。 上来P1，你连发生什么事情都不知道。压力会很大的。不过镇定就是了。习惯了其实没有什么。

8 极其强的产品知识。你要support自己的产品，肯定要非常了解它。我不是让你背下所有东西，很多东西还是知道在哪个手册或者help file里面随时查就知道了。不过我奉劝你比所有人都多走一步。user training，一般的support training都是不够的。基本上结束training 我就忘记了80% 。你要自己花时间（我都花的上班时间去做）要详细了解产品的背后到底在干什么，产品的架构到底是什么。了解多了，帮助很大的。我举个例子，我接触过一个产品，客户报告说生成的文件submit出错。log上不是很清楚到底发生了什么事。但是我知道这个系统会在某个情况下在某种情况下会生成一个临时文件。于是我去检查这个临时文件所在的目录，随后建议客户把那个目录从av扫描中exclude掉。问题解决。这个生成临时文件的事情，公开的documentation里面没有的。我自己平时问出来的。所以要多问问系统背后在干嘛。

bombhuauto

好高深 能提点一下P1和P2是什么吗？

bombhuauto

还有有的时候我会怕担责任 有的事情明明知道但是不敢说 怕被扔一坨屎

gifox

bombhuauto 发表于 2014-1-17 17:15
好高深 能提点一下P1和P2是什么吗？

这个每个公司对于incident的等级划分稍微不一样。

但是P1和P2划分倒是很相似。

P1 = Priority 1 , production system down， 就是系统完全无法启动，比如一个SaaS的公司比如说salesforce.com，其网页无法访问。 这时候基本上support team就鸡飞狗跳，manager半夜都要跳起来，senior support要候命，，客户的IT人员通宵都要把事情解决。我接触到的情况SLA都是2-4小时内恢复。

P2 ＝ critical feature down， 比如一个财务系统，无法为新签约客户建立档案了 ！ 通常1天内要恢复。

遇到上面2种情况，其它case都要让路的了。

frankyfang

g版心思缜密，热心为众，每次看你回帖都是一种学习。。。

ericlao2013

背包客 发表于 2014-1-17 18:03
做support要记得让子弹飞一会儿

这个可以同意

ericlao2013

gifox 发表于 2014-1-17 17:55
不放电话倒不是问题。哪里有P1，P2的问题可以电话里面解决的。我至少需要先看log，做研究测试。搞不好还 ...

感觉你support的是应该是比较高端的应用，所以出问题一定会有log。

有些问题比如整个系统都无法启动，拿不到任何log的，最多给你几个screen shot，就必须打电话开web-conf解决。

各个公司其实对P1/P2定义是类似的，但是实际上客户是不管什么criteria的，很多客户知道P1的响应时间快，无论什么问题都开P1的。我这里绝大多数P1都不是真正的P1。

gifox

ericlao2013 发表于 2014-1-17 18:13
感觉你support的是应该是比较高端的应用，所以出问题一定会有log。

有些问题比如整个系统都无法启动，拿 ...

我support的都是enterprise level application , high complexity low volume。一周大概一个人大概只会close不到2位数的case。有些case处理起来好几天不奇怪。

就算system down也经常会有log的，因为windows还在走。至少有event viewer还有process monitor 可以看。如果是web portal出事，还有fiddler和IIS log。

然后如果把自己product的log调成verbose，那么从服务开始启动的时候就开始生成log啦，通常fail都是服务启动到一 半看看那一个部分出错。比如说要链接另外一个服务不成功。等等。也试过有客户自己upgrade了web portal以后忘记了吧web.config文件覆盖回来。

回到客户不管P1/P2的问题。要分是什么客户。如果是要面对很多end user的，直接和end user沟通的，那么没有办法的。但是在我的情况里面，我的联系人我全部都记得住的啦。很多都见过面。 所以会做2样事情  1）绝对要保障自己要在SLA 响应时间里面回答， 客户都是因为要引起注意才直接log P1 , P2的，想要快点 。 如果响应时间可以做到，他们就没有那么紧张  2） 前提是1）要做好。做好了以后。不是客户submit一个p1它就是P1 阿，看完case description，发现不是P1 ，直接该是什么改成什么。然后发email说我改了。如果他们不同意可以打电话给我或者我的manager。但是很少会出现不同意见的，因为大家都认识。一来2往都知道事情会怎么走。