进入到IT这个圈子，很多人是从工程师开始做起的，那么如何成长为一名成功的工程师呢？或者是如何成功地转换为下一个角色呢？你需要做哪些准备呢？作为MDE（Market Development Engineering）的工程师和产品开发的工程师，还是有些不同的，我下面重点想说的是比较通用的，关于MDE的工程师，或者类似的做技术支持的工程师，我想后面再单独写一篇。

让我们先来看看成功的工程师是什么样子。在Sun公司里，工程师分为4个级别，从低到高依次是工程师（Engineer），高级工程师（Staff Engineer），杰出工程师（Distinguish Engineer），科学家（Fellow）。在工程师这个级别里又分为MTS1-4，也是依次从低到高的。Fellow，SUN公司总共没有几个，James Gosling是其中的一个，Bill

那么这些不同的级别的定义是什么样子呢？要求是什么样子呢？我们分别来看看。一名MTS3的工程师应该可以独立地设计和实现一个解决复杂问题的解决方案，制订项目计划，并确定短期战略目标。对于MDE的工程师，应该可以独立地支持一个ISV，从技术评估，技术培训，移植的技术支持，性能调优，选型测试等。当然，并不是说MDE的工程师可以自己把所有这些全部完成，但是他/她在遇到阻碍的时候知道通过什么渠道来解决问题。MTS4的工程师，可以解决更复杂的问题，通过领导一个团队，独立地设计和实现一个复杂的项目，这样的一个项目通常都需要和其他的团队进行协调和沟通，并利用或组合其他团队的工作。一个MTS4工程师要有能力给其他低级别的工程师提供技术建议和指导。从MTS4到Staff Engineer是一个大的台阶，作为Staff Engineer，应该是在组内和组外都公认的专家，拥有解决复杂问题所必须的技术知识和商务知识。Staff Engineer和Engineering Manager是在同一个级别上的。

从一个MTS1或MTS2工程师做起，怎么准备自己走到下一步呢？一个很重要的概念就是管理自己：管理自己的目标，管理自己的时间，管理自己与其他人的沟通。

第一，要给自己设定一个目标，可以和自己的经理聊聊，自己的下一步在哪里，自己的优势在什么地方，通常他们会给出比较诚恳的建议的。我建议在制订这个长期的目标的时候也不要太长，比如说10年，那就太长了，说老实话，在20-30岁的这个阶段，3年后发生什么事情我们很难预测。所以我建议这个目标可以订的短些，比如2-3年。

第二，结合长期目标，给自己制定短期目标，比如说一年的，半年的，一个季度的，等等。制订目标的时候，有个SMART方法，想必大家都知道：s（specific，具体的，不能说空话，要用数据和时间说话）、m（measurable，可衡量的）、a（agreed，双方都同意的）、r（realistic，可实现的，可以达到的）、t（timebonded，有时间性的，可以考核）。

第三，在设定的时间，回顾自己的目标，检查完成的情况，如果没有完成，要总结是什么原因，并适当调整目标。

第四，管理好自己的时间，检查自己的大部分时间都在做什么，是不是在做最重要的事情，是不是大部分时间做了些不重要的事情，可是最重要的时间却没有时间做。管理时间需要对自己的工作进行优先级的评估，优先处理最重要的工作。发现了问题之后就要调整自己的习惯或方式，节约时间。随着你的级别越来越高，你会发现你的时间越来越少。可是你的加班不能无限延长，你还需要时间陪伴你的家人，你也需要时间休息。

第五，积极地学习。活到老，学到老，这句话没有错。有的工程师发现了一个正在进行BETA测试的新产品，认为对自己以后的工作有帮助，就马上拿来装上使用一番。有的工程师经常阅读和自己工作相关的各种标准和规范，对提高自己起了很大的作用。学习的范围要逐渐的宽一些，不要总是局限在纯粹的技术上，可以适当地学习些软技巧或商务等方面的知识。

第六，能够做决定。一个级别高的工程师，有责任做相应的决定。你的老板不会为你做所有的决定，你需要和你的老板商量，哪些是你应该做决定的，自己要把这些责任承担起来。最重要的决定是决定要做什么，如果这个决定没有做，那么尽管工作得再漂亮，到最后可能发现原来根本就是浪费时间。为了做正确的决定，你需要搜集相关的信息，没有足够的相关信息，可能做出的决定也是错误的。

第七，积极地沟通。谁是你最重要的客户？或者最重要的stakeholder？你的工作对谁影响最大？不要被动地等他们来找你，而是主动地去找他们，询问他们最关心的是什么，利用你的知识和经验，向他们建议哪些对他们最重要，提前和他们沟通项目计划，等等。工作展开后，要有定期的状态更新，碰到计划为的状况的时候，要立即和相关人员进行沟通。另外，找机会多和一些比你级别高的人或更有经验的人聊聊，有时候他们给你的一个建议，或无意中说的一句话，都会给你很大的启发。和他们的聊天，也经常能够给你些激励。

第八，认真地写报告。很多人不重视写报告或技术文档，这不利于工程师的成长。写报告是沟通的重要的环节。写报告的时候，首先要确定你的报告是写给谁的，谁在关心这个报告，关心的内容是什么。可以把自己想象成看报告的人，最想通过这个报告了解什么。报告也不仅仅是给你的老板看的，对于MTS4或者更高级别的晋升，是需要跨部门的讨论的。在一个10-20人的团队里，大家可以容易互相了解，在一个100人的团队里呢？就无法做到这点了。怎么让其他的团队里的人了解你的优点和技术专长呢？如果他们看到过你的报告，是很容易判断的。

总而言之，首先要定义自己的目标，然后学习和实践，通过证明自己的能力，最后的成功是水到渠成的。

我在MDE这个团队做了4年了，基于过去的经验，谈谈做MDE工作的感受吧。做MDE的工程师，和售前，售后，服务的工程师的工作有一定的相似性。MDE的全名是Market Development Engineering，所做的工作是帮助ISV在Sun的平台上进行开发，为他们进行移植，性能调优，测试提供技术支持，目标就是让ISV的产品在Sun的平台上运行得最好。MDE的工程师和服务部门的工程师是有区别的，服务部门的工程师按照合同为客户提供所需要的服务，比如帮助客户进行架构设计，进行系统开发等等，是工程项目的主体，而MDE的工程师是在项目中提供支持，支持客户（ISV）的工程师完成工作。MDE的工程师和做产品研发的工程师更是有区别了，不说大家也都明白。

MDE的工作需要我们积极主动地开展，而不是被动地等待。如何能作到积极主动呢？态度非常关键，我们需要用积极主动的态度，来驱动我们制订目标和计划，用目标和计划来保证积极主动的行动。我们每个财年都要做制订目标，这个目标里其实包括了三部分内容：为部门的目标所做的贡献；个人的目标；还有就是我们的客户计划。为部门的目标做贡献，很容易理解，但是怎么和个人的目标结合在一起呢？自己的兴趣在什么地方？自己需要在什么地方得到发展？能达到什么样的水平？举个例子，我们今年的重点是推动Solaris，我的强项是Java，我就希望自己今年在Solaris方面的技术水平得到提高，这就是我今年的目标。具体些，我会希望自己参加一个有深度的培训，学习1-2本经典的书，比如Solaris Internal；研究并掌握一项关键技术，比如Dtrace；发表一篇技术文章，比如如何使用Dtrace分析和解决I/O瓶径。客户的计划也是很重要的，我们的ISV最需要什么样的支持？困扰他们的是什么？他们今年的产品计划是什么样子？比如我有个ISV，他们打算把应用从某平台转到UNIX平台，我会了解他们计划在什么时候开始做移植工作，他们的应用是用C开发的还是Java，他们的客户对性能的要求是什么样子，他们要测试的硬件需求是什么样子，需要多少颗CPU的机器，多大的存贮等等。这些内容都是客户计划中的重要内容。

有的时候目标和计划的制订比较容易，但是完成计划会碰到困难。有人制订了发表3篇文章的计划，可是到Q3的时候还没有一个出来，问问情况，肯定会有很多理由，仔细分析，有些是真正的理由，有些则似乎是找的理由。我和一个同事聊过，我问他还有四个月，文章还没写，也没有具体的实施计划，所以说这个3篇文章的计划，倒象是一个愿望。这里有个关键的问题是行动没有和目标结合起来，也就是说没有具体行动的计划。怎么样才能够有具体的行动计划呢？可以给大家举两个人写文章的例子。一个是王昱，他在工作中感觉到很多人对J2EE的集群特性并不了解，于是就计划写这样的一篇文章，先是阅读一些文章，包括J2EE的规范等，然后把自己的思路写成幻灯片，感觉可以把幻灯片讲给听众了，再把内容填进去，写成最后的文章，最后发给相关的编辑进行审核，很快就发表了（链接）。另外的一个例子是张欢，她帮一个ISV解决了设置应用服务器SSL的问题，感觉这个问题很可能也会被其他的用户碰到，于是就把自己所碰到的问题，解决的方法，理出一个思路，然后整理成文章，最后是和编辑联系审核，发表得也很快（链接）。

管理时间的概念里很重要的一点是，对于承诺的事情，要在规定的时间里提交结果。很多人都有这样的体会，原本计划做一件事情，在查资料的时候，发现里面有很多自己不熟悉的，于是顺着线索一路搜索下去，又是查资料，又是写测试程序，结果到了规定的时间，被问到为什么该提交的报告还没出来的时候，才发现自己在研究一个离原来的目标很远的题目，而且这个题目和自己原本的任务的关联性并不是很大。

另外一点是读邮件，相信大多数人都订阅了很多邮件列表，每天早上来的时候，会收到几十甚至是上百封邮件，怎么去看？如果按顺序从头看到尾，每封邮件都看，可能这一天都看不完邮件，那就什么都别做了。我也曾经有过这样的阶段，感觉自己一天都是邮件的奴隶了。我现在的做法是，针对技术邮件列表做过滤器，把和技术相关的放在一个特别的目录里，这样在看的时候，已经有很多都被过滤了，那些邮件基本上都不是紧急的，是作为信息来使用的，如果有时间我就会去看，如果没有就算了。处理收件夹中的邮件时，可以快速扫描标题和发件人，首先看紧急的，然后看其它的。对于能够在1分钟内就可以回的，马上回掉。如果需要等的时间比较长，比如几天，可以先给对放回个邮件，告知已经收到邮件，正在处理，可能会在几天后有结果。

做为MDE的工程师，每个人都是需要独立地和ISV工作的，每天都和ISV接触，可能做许多决定。那么怎么做这些决定呢？是不是都需要请示上级呢？如果没有规定好的流程或策略，我们自己怎么来做决定呢？首先要清楚自己能做决定的范围，以及规定好的流程和策略。如果是在自己的范围内，但是没有可依据的流程和策略，怎么办？playbook是一个帮助我们做决策的很好的工具。很多公司有会设置这样的playbook，而且还会逐级向下，在各个部门也建立playbook，playbook里会简明扼要地阐明公司或部门的发展目标或者优先级等。例如我们公司的playbook里确定了FY06的优先级(链接)是：

 本周主要针对问题管理的概念、目标和范围、主要活动等内容进行分享。

问题管理负责预测、监控、发现并及时解决IT服务和IT基础设施中存在的问题和错误，将这些问题和错误对客户和业务的负面影响降至最低，并防止由其引发的事件再次发生。

问题是指未查明根源的一次或多次事件的原因。问题定义有两个途径。一是由一系列显示共同特征的事件导致的，二是由某个原因不明的重要事件导致的。

 问题管理是指负责积极IT服务运营过程中遇到的所有问题的流程。问题管理包括问题处理和问题控制，其目标在于将由于IT基础架构的错误而导致的问题和事件对业务产生的负面影响减小到最低，并防止与这些错误有关的事件再次发生。为了实现这个目标，问题管理调查分析事件的根本原因，然后采取有关行动改进或纠正这种情形。

（3）问题管理与事件管理的区别

问题管理的主要目标是要查明事件发生的潜在原因，并找到解决此事件的方法或防止其再次发生的措施，而事件管理的主要目标是在事件发生后尽可能地恢复客户服务，即便采取的是一些应急措施而不是永久性的解决方案。事件管理强调速度，而问题管理强调质量，把速度放到第二位。为了发现事件原因和防止事件再次发生，问题管理可能需要花费更多的时间解决事件，切可能推迟恢复服务。

通过对当前事件情况进行分析，查找引起该事件的根源，找出针对该根源的解决方案，从根本上解决事件。

    在事件尚未发生（复发）时，通过对历史事件记录的回顾及趋势分析，主动识别潜在的问题，查找出导致问题的根源，设计针对根源的解决方案或预防措施，从根本上解决问题，并防止该问题导致的同性质的事件再次发生。

已知错误是指问题经过诊断分析后找到事件发生的根本原因，并制订出可能的解决方案时所处的状态。在这种状态下，一种临时性的权宜措施或永久性的解决方案已经得到解决。如果一个问题转化成了一个知名错误，则应当提出一个变更请求。但是，在通过一项变更将此知名错误永久性的修复之前，它仍将作为一个知名错误。

    问题控制是指对发现的问题进行归类、调查和分析，从而提出解决方案或应急措施的流程。问题控制的根本目的是要查明事件产生的根本原因，一旦查明事件产生的根本原因，问题就升级为知名错误。知名错误将由错误控制流程解决。

错误控制是指对知名错误进行处理和控制的流程。在问题控制将知名错误转交给错误控制之后，错误控制需要向变更管理提交变更请求，再由变更管理实施变更后，最终消除知名错误。

问题管理流程负责预测、监控、发现并及时解决IT服务和IT基础设施汇总存在的问题和错误，将这些问题和错误对客户和业务的负面影响降至最低，并防止由其引发的事件再次发生。具体的目标细化为：

将IT基础架构中的错误引起的事故和问题对业务的影响减少到最低程度。

查明事故或问题产生的根本原因，制定解决方案和防止事故再次发生的预防措施。

实施主动问题管理，在事故发生之前发现和解决可能导致事故产生的问题。

问题管理的范围包括问题控制、错误控制和主动问题管理。

问题管理识别并管理引发服务事件的根本原因，最小化甚至阻止一切客户损失发生。问题管理与解决流程中的被动部分——事件管理紧密联系，它更为主动，会主动阻止事件和已知错误的重复发生。

问题管理的主动活动分为主动管理和被动管理两大方面。被动方面是指问题管理流程对某一个或某一些事件进行分析后确定问题根源并加以解决；主动方面是指问题管理流程分析事件和问题的发展趋势，在问题暴露之前采取相应的对策。因此，问题管理流程的管理范围包括问题控制、已知错误控制和主动问题管理。

问题控制是对发现的问题进行归类、调查和分析，从而提出解决方案或应急措施的流程。问题控制的根本目的是要查明事件产生的根本原因，一旦查明事件产生的根本原因，问题就升级为知名错误。知名错误将由错误控制流程解决。

下面对问题控制流程中涉及的主动活动进行简单介绍。

问题控制的第一步是发现和记录问题。理论上，所有导致事件产生的未知原因都可以称为问题，但我们通常只将那些重复发生的或非常严重的事件归类为问题。问题记录与事件记录类似，但不完全相同。事件记录强调的是受影响的用户数量、影响程度等信息，而问题记录更侧重于事件的症状、与事件相关的基础架构和运行情况等方面的信息。问题记录应该关联到与其相关的事件，事件的解决方案和应急措施也要记录在相应的问题记录中。

在查明和记录问题后，为了评估问题可能对服务级别产生的影响，应首先对问题进行归类。问题归类应该根据问题涉及的领域、影响度、紧迫性和优先级等因素综合确定。问题归类不是静态的，它在问题声明周期的不同阶段可能会发生调整，如应急措施可以降低问题的紧迫性，而新出现的事件却可能提高问题的影响度。

问题调查与事件调查的目标不同。事件调查的目标在于找出快速恢复事件的应急措施，而问题调查是要找出问题存在的根源。因此，问题调查与事件调查要更加全面深入，甚至包括对事件管理所制订的解决方案和应急措施的调查。在对导致事件的未知原因开展调查后，需要对这些原因进行分析和测试，以确认其是问题产生的最主要和最根本的原因。

在确认产生问题的根本原因后，问题就转化成为知名错误，问题管理也就进入错误控制阶段。如果未最终确认问题产生的根本原因，则应向事件管理人员建议实施应急

     错误控制是对知名错误进行处理和控制的流程。在问题控制将知名错误转交给错误控制之后，错误控制需要向变更管理提交变更请求，再由变更管理实施变更后最终消除知名错误。

错误控制流程主要包括以下几个方面的内容：

在问题控制流程查明了问题产生的根本原因后，问题就转化为一项错误，如果同时针对这些错误提出了相关的应急措施，则错误进一步升级为知名错误。发现和记录错误或知名错误是错误控制流程的开始。问题管理人员需要将有关知名错误的信息存放在问题数据库中。

问题控制和错误控制都是在问题出现后才做出响应，因而是一种被动的问题管理。事实上，根据对IT基础架构进行分析，问题管理可以找到可能出现问题的薄弱环节，在事件发生前发现和解决有关问题与知名错误，以尽量减少问题和知名错误对业务的影响。这就是下面要介绍的主动性问题管理。

主动问题管理主要包括两项活动：趋势分析和制定预防措施。

趋势分析需要根据事件和问题分析报告提供的信息预测IT服务运作的趋势，找出IT基础架构中的薄弱环节，并估计薄弱环节和可能产生的组件故障对业务运作的影响。通过趋势分析，问题管理人员可以制订积极的预防措施，从而维持IT服务的持续运作，改进服务质量。一般来说，趋势分析可以从以下几方面进行：

找出IT基础架构中不稳定的组件，分析其原因，以便采取措施降低配置项故障对业务的影响。

分析已发生的事件和问题，研究其变化趋势。

通过其他方式和途径分析，比如：系统管理工具，用户反馈，与客户和用户的座谈会，客户和用户调查。

通过趋势分析，问题管理人员一般可以确定IT基础架构中存在的薄弱环节，从而可以帮助服务支持人员明确哪些问题是应当重点关注的。然后，问题管理人员应针对这些薄弱环节制订积极的预防措施，以避免事件的发生。这些预防措施通常包括：

提交变更请求（RFC）

提交有关测试、规程、培训和文档方面的反馈信息

对服务支持人员进行教育和培训

确保遵守问题管理和时间管理的规程

改进相关的流程和程序。