导语：无论什么角色，成长都是每个人都必须经历的过程。作为一名技术人员，成长不仅仅是技术上的不断提升，还包括日常工作中的方方面面。本文分享了一位阿里巴巴资深技术专家在阿里十年来的成长历程，分享了他从一名普通技术人员到阿里的经历，在阿里的三个阶段，以及他对晋升、转岗、团队领导、工作等方面的感悟。

关于我

宋健，昵称宋毅，2008年参加工作，专注运维领域12年多，2010年6月加入支付宝，从事过监控、SRE、资源管理、运维产品等工作，经历和参与了阿里巴巴运维从脚本化到工具化再到自动化智能化的演变。他在阿里巴巴的10年，按照部门变动可以分为三个阶段：

二、我的经验 1 支付宝

关键词：开源监测 监测职责 应急响应

入职后，我进入了运维部监控组。当时团队刚刚开始组建，一切从零开始。幸好有B2B的兄弟团队学习他们的经验，很快搭建了第一代支付宝监控系统。几个月后，因为双11，我们的工作地点从华星时代搬到了电信第二枢纽机房，因为当时支付宝的核心机房在那里，需要我们7*24小时在现场，快速处理突发事件。当时团队应该有6个同学，一个白班，一个夜班，一个平班，我们一边值班，一边维护监控系统。

随着业务的快速发展，服务器数量不断增加，很快一台服务器已经不能满足需求，经过排查，引入了水平扩展问题并解决了。监控项的添加和维护主要靠编辑配置文件，没有办法打通到所有人员，所以监控项的维护也是监控团队的职责，PE和DBA只需要整理需求，发邮件就可以了。但是新增业务和扩展的频率越来越高，每天编辑文件接受监控需求需要花费大量的时间，而且经常出错。经过和需求方的协商，我们确定了方案，对不同的业务组件设置监控模板，然后想办法自动获取服务器信息。当时也没有专门的CMDB，后来终于实现了新机器上线时自动匹配模板添加监控和告警。重要的告警通过短信发送，告警短信需要和上线业务的短信区分开来，避免互相影响，所以我们购买了几十台短信猫，并学会了如何控制短信猫通过服务器发送短信。后来我们还进化出了利用短信猫接收短信来关闭闹钟的功能。

这种情况持续了大概一年，逐渐稳定下来。积累了经验之后，我们开始尝试引入外包值班，随后开始招募、培训外包生，制定值班、应急标准，搭建相应的流程体系。外包值班又持续了差不多一年。由于监控可以看到所有的业务数据，所以出于安全考虑，还是外包了。目前监控值班的角色还在，办公室在西溪的全球运营指挥中心，有专门的办公室，有门禁限制，里面全是各种炫酷的大屏幕，整个经济体的业务，24小时都由他们守护着。

这两年来，我马不停蹄地工作，马不停蹄地遇到问题、解决问题，修一条条翻山越岭的路、架一座座跨河的桥。

2 技术支持

关键词：统一监控 OD分离 资源管理

2013年，我所在的部门从支付宝调到了集团，到集团后我参与的第一个项目是统一集团的监控系统。原来淘宝、支付宝、阿里云、B2B等业务都建了自己的监控团队和系统，组织层级统一之后，就要把系统整合起来，整合后的新系统就叫这个系统。当时项目负责人在运维开发团队，我介入的时候项目已经启动，监控团队就我一个人。这也是我第一次参与比较大的跨团队项目。因为刚到集团，跟其他成员不熟悉，跟大家合作的阻力很大，但我还是很积极的参与项目，每天都到开发团队参加晨会。直到有一次在晨会上气得哭了，但神奇的是，从那天开始合作就变得很顺利，我再也感觉不到隔阂的存在。项目历时近一年，顺利上线，通过这个项目我和开发团队的同学建立了良好的信任关系，对后续的工作有很大的帮助。

开发团队负责集团所有的运维工具，另外还有，，aone等。有一段时间，这些工具经常出问题，甚至在双十一，双十二的关键时刻出问题。后来，一个业务团队的学长同学调过来带队，发起了运维工具OD分离的项目。我作为主要负责人，承担了所有工具的PE职责。也是在这个时候，我开始带领团队，最终推动十多个产品、几百个应用完成了OD分离标准化改造，解决了工具的稳定性问题。由于每个工具负责运维的其中一个环节，所以所有工具所承载的业务共同构成了集团工具运维体系。这段经历让我对运维业务有了更全面、更深入的理解。

工具PE项目稳定后，我又被分配了一项任务，就是管理整个集团的开发测试环境的资源。当时测试环境有几万台服务器，但没人知道哪些机器在用、谁在用，再加上每年还要额外增加几千台物理机的预算，成本浪费严重。接手后，我先搭建了资源生命周期管理系统，让所有新增资源申请都经过系统，并对已有资源进行盘点和认领。所有资源都设置了有效期，到期后可以续费或者释放。系统还会定期巡检资源使用情况，再配合宕机恢复、闲置降级等运营策略，最终测试资源盘点一清二楚。不仅每年的预算没有增加，回收的几千台物理机还支撑了双十一的生产环境。后来我继续尝试通过主机托管的方式提高测试资源的利用率。调研了多种方案后，我选择了与团队合作。但上线之后，任务经常占用测试机资源，影响业务的日常测试，还引发投诉，受限于当时技术限制，最终无法推进。

从参与一个跨团队的项目，到负责一个跨团队的项目，再到做一个产品解决业务问题，这是我成长最快的两年。

3 天基

关键词：，，云监控

2016年初，我转入了产品技术团队。SA是一个很重要的基础产品，它的核心功能就是命令通道，几乎所有操作服务器的场景都严重依赖它。但是SA过去做得并不好，很长一段时间，只有一半的人兼职支持。我当时的想法比较简单，就是想改变这种现状。我觉得这个产品不被重视的原因就是命令功能太单一，业务价值需要结合场景才能体现出来。所以首先要做的就是把SA从后台推到前台。第一个功能就是插件平台，为全网提供一个发布能力，发布对象可以是各种运维脚本，也可以是新扩展的服务器也会自动安装。这样做的目的是把SA最大的优势，全网覆盖的能力开放出来，让上层系统把更多的执行逻辑委托给机器，而不是全部转换成命令去频繁调用SA。

插件平台主要的用户群体是各类业务运维系统，但一线开发人员和运维人员也经常需要登录服务器执行命令。为了覆盖这部分用户，推出了第二个功能——WEB 端。人执行命令的场景可以分为单机交互操作和多机批量操作，所以WEB 端又分为交互端和批量端两个子功能。WEB 端在保证安全性的同时解决了人为操作服务器的效率问题。

插件平台统一了所有网络类的变更入口之后，我们也看到所有网络类都增加了，每台服务器都有N个运维类，进一步梳理之后发现监控类是最多的，所以我们发起了一个监控整合的项目，统一的新项目叫“监控整合”。集团内部整合完成后，我们继续向公有云迈进，目前外部公有云客户和阿里内部使用的监控都是用同一套代码。

在将集团内多个监控系统统一之后，进一步分析发现，所有监控系统的采集实现都大同小异，连接的上行是配置，下行是通道，配置、采集、通道三者结合起来就是标准化的数据采集。因此我和团队一起复用了现有的配置和通道能力，搭建了一个覆盖全网的通用数据采集平台。随着我越来越深入监控领域，我干脆专注于监控场景，把 SA 的事情全部交给了他们。目前我的主要职责是提供云服务的一站式监控解决方案，包括云资源监控、主机监控​​、业务监控、链路监控等。

我做产品已经几年了，但产品的深度一直没有达到我的预期，我觉得主要问题是太注重产品技术本身，没能驱动商业价值，导致没能获得持续的资源投入。

我可以用三个词来概括这三个阶段：做事情-->做项目-->做产品。

做事情和做项目的关键点都是“把事情做对”，区别在于项目多一层协作。做产品的关键点是“做正确的事”，不仅要关注当下的成果，更重要的是如何持续走向未来。

我的成长

“很傻很天真，但也很凶悍很执着。”我觉得这句话很能形容我待人处事的风格。待人处事，我会默认信任所有人。做事，我会比别人更努力，因为我比较笨。这些年来，我一直坚持在一个领域，投入比别人更多的时间和精力。在经历了一次又一次的失败后，我不断从经验和教训中汲取教训，让自己成长。这期间，有很多次我想退缩。在最艰难的时刻，我总是想起一句有力的阿里方言来安慰自己。

1 关于促销

互联网行业招人的时候，经常有人说职位相当于阿里巴巴的P级岗位，这足以说明阿里巴巴对级别的重要性，所以晋升对大家都很重要。但是当我们非常重视级别的时候，也带来了问题。级别成为大家的第一标签，合作的时候他们首先看你的级别而不是你的职责，做事情的时候他们首先想到的是晋升而不是价值。今年公司在这方面做了一些调整，包括隐藏职位级别等等，希望让我们回归到用事情的价值和成就感来驱动自己。

10年前我加入支付宝的时候，级别是P4，至今参加了8次答辩，平均2次成功一次。但从P7晋升到P8，用了5年时间，3次答辩……每次晋升失败后，最难的就是心态的调整。总觉得受到了不公平的对待，觉得评委不客观，不了解我做的事情，只看到我的缺点等等。如果长期这样想，必然会对自己造成影响。

如何调整？我的做法是，首先调整心态，相信公司，相信评委。公司一定想为每一个学生匹配最合适的评委。评委要客观，不会刻意针对某一个人。然后在自己身上找原因。评委的反馈是什么？评委为什么会有这种感觉？是我没有表达清楚，还是我没有想清楚？

失败的原因可以简单概括为两个方面：

我没有具备所需的能力，无论是软技能还是硬技能。我运气不好，在评委面前也没有合适的气质。

个人可以改变自己的能力，但首先要认识到自己的不足。技术、业务、表达方面的问题是什么？仔细阅读理解评委的反馈，有时候反馈可能不是那么直接，比如说没有未来展望，就是他们看不到你负责的业务的未来。你有没有想过业务的未来？多跟你的主管聊聊，主管一定愿意帮你找问题。我觉得要用20分钟向几个不熟悉的评委解释清楚自己做了一年、几年的事情，让他们充分认可和理解，并不容易。

至于运气，你能做的就是明年再试一次，多试几次，运气就不会那么差了。每个人都有进步的空间，成长是无止境的。只有当你真的找不到或不明白原因的时候，才能简单地归结为运气，调整好心态。当你的心态平静下来，真正的问题就会慢慢明朗起来。这段时间，你需要更多的来自主管的安慰和鼓励。

2 关于工作调动

过去10年，我只换过一次工作，却想过多次换工作，其中有三件事给我留下了深刻的印象：

调职的目的是为了解决问题。每当你有调职的想法时，你应该先和你的主管谈谈。如果有必要，你也可以和你主管的主管或HRG谈谈。不要担心谈话后被“贴标签”。坦诚沟通。你的主管肯定想帮助你，但他可能还没有意识到问题所在。问题只有在讨论清楚后才能得到解决。没有沟通就去新团队其实是在逃避问题。

如果个人在目前团队的成长空间有限，目前业务前景不明朗，那么如果沟通表明这些确实是问题所在，那么转岗是必要的。但如果存在协作或沟通等其他问题，那么就需要慎重考虑。换团队的成本很高，与新主管和成员建立信任需要时间。一时无法解决的问题，很有可能在换岗后再次遇到，新团队也会带来新的问题甚至更多的问题。

3. 做事

我也经常看书，听别人的分享。方法论要学的真的很多，但每次看完或者听完就没了下文。最后还是走了不少弯路，碰了不少墙才慢慢吸收，形成自己的方法。我的经历可以用两句话来概括。

一件事

“让在世界任何地方都能轻松经商”是一回事。

“成为全球领先的科技驱动的商业基础设施服务商”也是一回事。

“云端与云端下监控数据采集技术的统一”也是一个事情。

每个人每天都在做事情，为什么有的人做得很好，有的人做得不好呢？我觉得看你做的事情之间有没有联系，这个很重要。最好的做事方法是：你每天做的事情是每个月一件事的一部分，你每个月做的事情是每个季度一件事的一部分，你每个季度做的事情是今年一件事的一部分。你做的所有事情只有联系在一起，形成一件更大的事情，才有意义。

一天一件事和一个月一件事的级别不一样，复杂程度和需要解决的时间也不一样。每件事都应该做，每个问题都应该解决，但我们的时间和精力是有限的。判断一件事情是否应该做的依据，是它能否成为你月度、季度或年度任务的一部分。如果可以，就制定计划去做，否则就说明这件事不应该由你来做。

99% 和 1%

一个任务可以分为两个部分，99%和1%。很多时候，我们认为99%就够了。比如某个成功率指标做到99.99%之后，可能发现最后0.01%的成本比前面所有成本都高，要不要做？我觉得还是尽量往前推进，因为越往深，竞争力就越强。至于最后能做到5个9还是6个9，要看跟行业的差距。

99%一定要做，1%需要突破。深度和壁垒往往体现在最后的1%。每完成一项任务，比上一项进步0.01%就是一次突破。0.01%做100次就是1%。但如果我们每次都止步于99%，那我们和流水线上的工人就没有本质区别了。我们都在重复做事，只是重复的事情不一样。

把相关的任务一个一个地完成，把自己打造成服务，避免完成不相关的任务把自己打造成资源。1%体现业务广度，1%体现技术深度。规划需要业务广度，实施需要技术深度。两者结合，才能保证所做事情的正确性和竞争力。

4 领导团队

带团队的目的还是为了把事情做好，只是从一个人变成多个人，多个人做一件越来越接近100%的事情。我用三句话总结团队领导者最重要的事情：

明确定义团队

一个是团队的目标，团队的目标一定要长远，最好想清楚几年后是什么样子，然后推导出当年的目标，再把实现目标涉及的技术领域分解出来，最后确定每个领域的季度或月度目标和负责人。

我从2014年开始带团队，虽然每年也会做计划，但早些年主要都是列清单，每次汇报都会被老板批评，直到近两年我才想通了这一点。现在回想起来，前几年带团队的时候我更像一个PM，不断给产品增加新功能，但上线后没有长期演进计划，导致支撑工作越来越多，团队成员也越来越累，产品缺乏深度和竞争力。在老板和其他团队眼里，我们只是被当成资源，只要支撑业务的需求就行。当业务方没有抱怨的时候，老板不愿意再投入更多，团队成员看不到希望，都想调岗，调岗之后又没有新人补充，大家的事情越来越多，为了不让大家这么辛苦，我还负责解答问题，做各种日常事务，最终让团队陷入了恶性循环。

这次经历让我真正理解了一句话：“用战术上的勤奋来掩盖战略上的懒惰”。