HP技术支持工程师“Shell_HAT ”

Shell_HAT ChinaUnix社区Shell版版主，惠普技术支持工程师。

擅长领域：
工作中主要用到UNIX、数据库等方面的知识，业余时间也喜欢在Windows里面写一写BAT、VBS等脚本。


无风之谷：
Hi,HAT兄，很高兴能采访到您，在Shell版您是大家公认的热心版主之一，首先，向所有的CU网友介绍下自己嘛。

Shell_HAT ：
接到风兄这个采访，真有点受宠若惊的感觉哦。看看以前被采访的，动不动就是CXO之类的，相比之下咱有点忒普通了，嘿嘿。
2006年毕业之后，出于一个工作上的小需求，开始在几个DOS论坛学习BAT脚本。偶尔看到有人用sed和awk处理文本非常简洁高效，于是顺着这条线来到了CU。潜水学习、回帖讨论、被高手指出代码的不足、自己改进…….混着混着，就变成版主了

无风之谷：
作为一名技术支持工程师，如何做好这门工作？

Shell_HAT：
扩展知识面，培养解决问题的能力，提高沟通能力。

无风之谷：
很多朋友对技术支持不理解，认为技术性不强，您怎么认为？

Shell_HAT：
仁者见仁智者见智吧。要说写代码，C/C++/Java/.NET什么的，技术支持人员可能也有两把刷子，但大多比不上开发人员；要说测试，LoadRunner/QC/QTP什么的，技术支持人员可能只是听过，跟测试人员自然不在同一条水平线上。
但是技术支持也有自己的特点：知识面广。有人说，技术支持就是什么都略懂，但是什么都不精。UNIX、Windows啥都会，但不一定是专门的系统管理员；Shell、Perl、Python、BAT、VBS啥都能写，但不一定仅靠这些吃饭；Oracle、DB2、SQL Server、MySQL啥都能玩转，但不一定是专职DBA。还有WebSphere、WebLogic、Apache、Tomcat等等，啥都可能遇到。总结成四个字那就是：综合能力。

无风之谷：
技术支持这个岗位除了要求技术能力外，对个人的沟通能力也有很大的要求，如何将IT方面专业术语、解释，翻译作一般人能够理解的问题，如何从用户混杂不清的描述中，了解他们产生的真正问题以及他们真正想要的结果呢？

Shell_HAT：
沟通能力确实是做好技术支持的非常重要的一个方面。我根据自己的经验，把项目中遇到的沟通问题归纳为以下三个方面：
(1)客户提供的信息不够。我们要通过各种方式教客户怎样提供有用的信息，报错信息是什么，通过哪些步骤可以重现问题，什么时候开始出现问题的，身边的同事有没有类似的问题，等等。只有当客户学会怎样提问之后，我们解决问题的效率才能大幅提高。
(2)提供的解决方案用户看不懂。我们要时刻谨记站在用户的角度上考虑问题。他们对你维护的系统可能根本不熟悉，甚至连电脑的基础操作都很生疏。我们不能想当然的认为他们应该知道如何如何怎样怎样。如果解决方案里面有需要客户自己完成的操作，请把详细的步骤写清楚，访问哪个链接、点击哪个按钮、运行哪个命令等，关键步骤好有截图供他们参考。
(3)多个团队协作解决同一个问题。有些比较复杂的问题并非是某一个团队能够单独解决的，除了告诉客户我们负责的范围是什么、我们已经帮客户做了什么，还应该积极主动的帮他们联系相关的团队，让客户感觉到你是在 真心的想帮他们解决问题。对于短时间内无法解决的问题，更应该定期的跟进和反馈，让客户感觉到你是一直不停的在帮助他们解决问题。

无风之谷：
对初入技术支持这个职位的同学，在技术能力方面，应该掌握哪些知识？

Shell_HAT：
UNIX、数据库、中间件、语言脚本，每样都会点的话，基本上可以胜任大部分技术支持的职位了。当然了，想进外企，先练英语。

无风之谷：
能否向大家分享下在应聘HP技术支持这个职位面试经验？

Shell_HAT：
因为我当时大四还没毕业，所以也谈不上什么面试经验或技巧。主要是两个方面吧，一是计算机专业的基础课程要学好。另一个就是英语了，虽然当时谈不上流利，但至少能聊几句。
几个月之前的一次招聘会却让我感慨良多。当时并排放着四个HP的桌子，其中两个招开发、一个招测试、一个招技术支持。开发那边人头攒动，一天收了N多简历，那两个MM都搬不动了。我们技术支持这边后只收到可怜的几份简历。应届生基本上不往我们的桌子跟前走，全都跑到开发那边去了。有些工作几年的，技术还行，但是英语一句都不会说。隔壁部门的一个兄弟开玩笑的跟我说：“看这个情况搞的咱不像招技术类的了，而像是招语言类的啦。”其实后来，那几位能坐下来开口说几句英语的应聘者，大部分都通过了后续的面试，加入了HP。
所以说，想进外企做技术支持其实并不是特别难。有点相关经验，能说点英语，基本上没有太大问题。

无风之谷：
HAT兄作为SHELL版块的斑竹，你认为现在Shell版缺少东西的是什么？

Shell_HAT：
缺少切磋。有时候，某人给出答案之后，其他人不再尝试给出不同思路的答案。有时候，某人给出代码之后，其他人很少尝试指出其中的不足和改进的建议。