阿里高级技术专家宋意：平凡人在阿里十年的成长之旅

宋意

读完需要

14

速读仅需 5 分钟

阿里妹导读：不管是什么角色，成长是我们每个人都必须经历的过程。作为一个技术人，成长不仅是技术上的不断精进，也包括日常工作中的方方面面。
本文分享阿里巴巴高级技术专家在阿里 10 年的成长之路，分享他从一个普通技术人开始，在阿里的三个阶段，以及在晋升、转岗、带团队、做事等方面的心得感悟。

2020年12月杭州初冬美景，拍摄者：右军

1

关于我

宋健，花名宋意，2008 年开始参加工作，至今 12 年多一直专注在运维领域。2010 年 6 月加入支付宝，做过监控、SRE、资源管理、运维产品等方面的工作，经历并参与了阿里运维从脚本到工具化再到自动智能化的演进过程，在阿里的 10 年根据部门变化有三个阶段：

1. 2010.6-2013.1，支付宝（系统运维部）

2. 2013.2-2015.12，技术保障（支付宝、阿里云、淘宝、B2B 等运维部门统一后的新 BU）

3. 2016.1-至今，天基（负责阿里全球数据中心和运维体系的“数字化、自动化、智能化”建设）

2

我的经历

2.1

支付宝

关键词：开源监控、监控值班、应急响应

入职后加入的团队是运维部的监控组，那个时候团队刚刚开始组建，所有的东西从零开始，好在有 B2B 的兄弟团队可以借鉴经验，利用 nagios 快速构建了支付宝第一代监控系统。过了几个月由于双 11 的原因，我们的上班地点由华星时代搬到了电信二枢纽机房，因为支付宝当时的核心机房在那里，我们需要 7*24 在现场以便快速处置紧急事件。当时小组应该是 6 个同学，一白班一晚班一正常班，我们一边值班一边维护监控系统。

随着业务的快速发展服务器不断增加，很快一台 nagios 已无法满足需求，调研后引入 centreon 解决了 nagios 的水平扩展问题。监控项的添加和维护以编辑 nagios 配置文件为主，没有办法开放所有人员，因此监控项的维护工作也是由监控团队负责，PE 和 DBA 只要整理好需求发出邮件即可。但新建业务和扩容的频率越来越高，每天要花费大量时间编辑文件受理监控需求且经常出错，和需求方协商后确定了针对不同业务组件设定监控模板的方案，再想办法自动获取到服务器信息，那个时候还没有专门 CMDB，后来总算实现了新机器上线自动匹配模板添加监控和告警。重要的告警都是通过短信发出，告警短信需要和线上业务的短信区分开避免相互影响，所以我们又采购了几十个短信猫，专门学习了如何通过服务器控制短信猫发送短信，再后来还演进出了利用短信猫接收短信关闭告警的能力。

这样的情况持续一年左右逐渐稳定下来，有了经验沉淀后我们开始尝试引入外包值班，然后开始招聘和培训外包同学，制定值班和应急标准，建设相应的流程系统。外包值班又持续了差不多一年时间，由于监控可以看到所有业务数据，出于安全考虑又进行了去外包化。目前监控值班的角色仍然存在，办公地点在西溪的全球运行指挥中心，有专门的办公室和门禁限制，里面全是各种酷炫大屏，整个经济体的业务由他们 7*24 小时守护着。

这两年就是不停的做事情，不停的遇到问题和解决问题，逢山开路遇水搭桥。

2.2

技术保障

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

2013 年我所在部门由支付宝调整至集团，到集团后参与的第一个项目是统一集团监控系统。原来淘宝、支付宝、阿里云、B2B 等业务都是自建监控团队和系统，组织层面统一后必然要将系统进行整合，整合后的新系统叫 alimonitor。当时项目主导方是在运维开发团队，我参与进来时项目已经启动，只有我一个人是在监控团队，这也是我第一次参与较大型的跨团队项目。因为刚调整到集团跟其它成员都不熟悉，所以跟大家合作起来阻力很大，但我还是积极参与到项目中，每天跑到开发团队参加晨会，直到有一次在晨会上被气哭，但神奇的是从那天后合作就变的非常顺畅，再也感受不到壁垒的存在。项目持续了差不多一年时间成功上线，通过这个项目使我和开发团队的同学们建立起了良好的信任关系，对后续的工作起到了很大帮助。

开发团队负责着集团所有的运维工具，除 alimonitor 外还有 staragent、armory、aone 等，有段时间这些工具经常发生故障，甚至在双十一双十二的关键时刻掉链子，后来从业务团队转来一位资深同学负责团队，并发起了运维工具的 OD 分离项目，我做为主要负责人承担所有工具的 PE 职责，也是这时候我开始带团队，最终推动 10 多个产品上百个应用完成 OD 分离标准化改造，解决了工具的稳定性问题。由于每个工具负责了运维的其中一个环节，所有工具承载的业务加起来构成了集团的工具运维体系，这段经历使我对运维业务有了更全面和深层次的理解。

工具 PE 的事情稳定后我又接到了一个事情，负责整个集团开发测试环境的资源管理，测试环境当时有好几万台服务器，但没有人知道哪些机器在用以及谁在用，而且每年还有数千台的物理机新增预算，成本浪费非常严重。我接手后首先建设了一个资源生命周期管理系统，使所有新资源的申请全部经过系统，并且对已有资源发起盘点和认领，所有资源设置有效期，到期后可以续租或释放，系统还会定期巡检资源的使用情况，再配合宕机回收、闲置降配等运营策略，最终将测试资源盘点的清清楚楚，不仅年度预算 0 新增，还将回收的几千台物理机在双十一时支援了生产环境。再后来继续尝试通过混部提升测试资源使用率，调研多个方案后选择了跟 jstorm 团队合作，但上线后经常出现 jstorm 任务把测试机资源占满，影响业务的日常测试引发投诉，受限于当时技术限制最终没能继续推进下去。

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

2.3

天基

关键词：StarAgent、Argus、云监控

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

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

插件平台统一全网类变更入口后，我们也看到全网类 Agent 越来越多，每台服务器都有 N 个运维类 Agent，进一步梳理后发现监控类 Agent 是最多的，因此又发起监控 Agent 融合的项目，统一后的新 Agent 叫 Argus，完成集团内的 agent 融合后继续走向公有云，目前公共云外部客户和阿里内部使用的监控 Agent 都是同一套代码。

在 Argus 完成集团内多套监控系统的 Agent 统一后，进一步分析会发现所有监控系统的采集实现都有类似性，Argus 对接的上游是配置下游是通道，将配置、采集、通道三部分组合起来就是标准的数据采集，因此又与 alimonitor 团队合作，复用已有的配置和通道能力建设了一个覆盖全网的通用数据采集平台。随着在监控领域做的越来越深入，后来干脆专注于监控场景，将 SA 的事情全部交接了出去，目前我的主要职责是为业务上云提供一站式监控方案，包括云资源监控、主机监控、业务监控、链路监控等。

埋头做了好几年的产品，但是产品的深度都没有达到自己的预期。主要问题我觉得是过于关注产品技术本身，没有做到以业务价值驱动，导致未能获得持续的资源投入。

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

做事情和做项目的重点是“正确的做事”，区别是项目多了一层协作。做产品的重点是“做正确的事”，不仅需要关注当下结果，更重要的是如何持续走到未来。

3

我的成长

“很傻很天真，又猛又持久。”我觉得这句话可以形容我的待人和做事风格，待人方面我会默认相信每一个人，做事方面因为比较笨就会比别人下更多功夫。这些年我始终坚持在一个领域，比别人投入更多的时间和精力，在经历一次又一次失败后，不断的吸取经验和教训使自己成长。期间也有过很多次想打退堂鼓，最艰难的时刻总能想到一句充满力量的阿里土话安慰自己。

3.1

关于晋升

互联网行业招人时经常会说一句话，岗位对标阿里的 P 几，这一点足以说明在阿里级别的重要性，所以晋升对每个人来讲都很重要。但当我们把级别看的很重时也带来了问题，级别变成了每个人的第一标签，合作时首先看你的级别而不是负责什么，做事情首先想到的是晋升而非价值。今年公司在这方面已经有所调整包括隐藏职级等，希望可以让我们回归到用事情价值和成就感来驱动自己。

10 年前我入职支付宝时级别为 P4，到目前共经历 8 次答辩，平均每 2 次答辩成功 1 次，但是 P7 到 P8 的晋升用了 5 年答辩 3 次……每次晋升失败后最难的是调整心态，感觉自己受到了不公平待遇，评委不客观、不了解我做的事情、只能看到我的短板等，这样的想法持续太久必然会影响到自己。

如何调整？我的做法是首先摆正心态，相信公司相信评委，公司一定希望给每位同学匹配到最合适的评委，评委主观上也一定是客观的，不会刻意针对某一人。然后从自己身上找原因，评委的反馈是什么？为什么会让评委有这样的感受？没表达清楚还是没思考清楚？

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

1. 能力没达到，包括软技能和硬技能。

2. 运气不好，跟评委气场没对上。

能力原因个人是可以改变的，但首先需要认知到自己的不足，技术、业务、表达是哪方面的问题？仔细阅读和理解评委的反馈，有时候反馈可能不那么直接，比如未来展望不够意思是看不到你负责这个业务的未来，平时你有想过业务的未来吗？多和主管聊一聊，主管一定愿意帮助你找到问题所在。把自己做了一年或者几年的事情，在 20 分钟内向几个陌生评委讲清楚，让他们完全认可和理解我认为一点都不容易。

运气方面个人能做的就是来年再战，多试几次总归运气有不那么差的时候。每个人都有可以提升的地方，成长是无止境的，只有当实在找不到或不理解的时候，才可以把原因简单的归为运气，使自己心态能够调整过来，当心态平和后真正的问题就会慢慢清晰，在这个期间需要主管给予更多的安慰和鼓励。

3.2

关于转岗

这 10 年我只有一次正式转岗，但转岗的念头还是有过好多次，其中三次印象比较深刻：

第一次是入职两年后，大概 2012 年中，第一次觉得遇到了瓶颈，已有事情无法再让自己突破，所以就去找主管聊了聊，主管也觉得我需要做些更有挑战的事情，了解想法后也主动帮助我找团队，就在定下团队准备走流程时发生了组织调整，支付宝整个运维部被合并至集团新成立的 BU 技术保障，事情也跟着发生了变化，从原来的支付宝监控转变为统一整个集团的监控，对我来讲又有了新的挑战就拥抱变化放弃了转岗。

第二次是在 2015 年底，当时集团正在去 PE 化，技术保障大 PE 团队分拆到了各业务线，我负责的工具&测试 PE 团队也被拆分调整，但自己对调整后的事情并不太感兴趣。几年的 PE 做下来感觉运维最大挑战还是工具，思考很久决定转岗至负责运维工具的产品技术部，选择的产品是 StarAgent，BU 没有变化还是在技术保障。

第三次是在 2019 年底，SA 做了近四年且连续两次晋升失败之后，在我的主导下 SA 从一个纯粹的命令通道升级为主机管理平台，成为所有运维系统和人员管理服务器的第一入口。感觉自己已经用尽了全力，却仍然不知道怎么突破，陷入了迷茫。后来在主管帮助下终于想明白，自己一直想着怎么把事情做好，但很少思考做的是不是正确的事情，导致做的越来越多越来越累。和主管讨论后对职责进行了调整，将精力聚焦在一件事上面，其它事情进行了交接。

转岗的目的还是为了解决问题，无论什么时候有转岗想法后，应该首先找主管聊一聊，必要的话也可以找主管的主管或 HRG 去聊。不要担心聊了会被打“标签”，坦诚的去沟通，主管一定也很想帮助你，只是他可能还没意识到问题，问题聊清楚了才可能得到解决，没有沟通直接找新团队其实还是在回避。

个人在当前团队成长受限、看不到当前业务的前景，如果沟通后确实是这些方面的问题，那么转岗就是必要的。但除此外遇到如协作或沟通等方面的问题，则需要慎重考虑。换团队的成本非常高，需要时间来和新主管及成员建立信任感，当前得不到解决的问题换个地方后大概率还会碰到，新团队也会带来新的问题甚至问题更多。

3.3

做事情

我也经常的看书和听别人分享，要学习的方法论实在太多，但每次看完听完就没有然后了，最后仍然是走了很多弯路撞了很多次墙，才慢慢吸收形成了自己的方法，我的经验总结下来就两句话。

一件事情

“让天下没有难做的生意”，是一件事情。

“做技术驱动的世界第一的商业基础设施服务商”，也是一件事情。

“云上云下监控数据采集技术统一”，也是一件事情。

每个人每天都在做事情，为什么有的人做的好有的人做的不好？我认为很重要的一点是做的事情之间有没有产生连接。做的好的应该是：每天做的事是每个月的一件事的一部分，每个月做的事是该季度一件事的一部分，每个季度做的事是本年度一件事的一部分。当做的所有事情建立起了关系，组成了更大的一件事才有意义。

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

99%和 1%

一件事情可以分为 99%和 1%两部分，大部分时候我们做到 99%就觉得可以了，如某个成功率指标做到 99.99%之后，可能发现最后 0.01%要付出的代价比之前的全部还要高，要不要做？我觉得应该尽可能推进，因为越深入越能体现出竞争力，至于最后做到 5 个 9 还是 6 个 9 取决于和业界拉开的距离。

99%是必须做的，1%是需要突破的，深度和壁垒往往体现在最后的 1%。每次完成一件事情较之前进步 0.01%也是突破，100 次 0.01%就是 1%。但如果每次做到 99%就停止了，那么我们和流水线上的工人没有本质区别，都是在重复做事情只是重复的东西不一样而已。

完成一件一件有关联的事情将自己打造成一个服务，避免完成一件一件无关的事情让自己成为一个资源。一件事情体现的是业务广度，1%体现的是技术深度，规划时需要业务广度，落地时需要技术深度，二者结合起来才能保证所做事情的正确性和竞争力。

3.4

带团队

带团队的目的还是做事情，只是由一个人变成了多个人，多个人做一件不断逼近 100%的事。对于团队负责人最重要的事情我总结为 3 句话：

定义清楚团队的一件事

一件事就是团队的目标，团队目标一定是长远的，最好能先想清楚几年后的样子，然后推导出一年的目标，再拆解出完成目标涉及的技术领域，最后确定每个领域的季度或月度目标及负责人。

我是从 2014 年开始带团队，虽然每年也在做计划，但早些年主要以罗列事情为主，每次汇报都被老板批，直到近两年才想明白这一点。现在来看前些年带团队自己更像个 PM，不停地为产品做新功能，但上线后又缺乏长期演进方案，导致支持工作越来越多，团队同学越来越辛苦，产品没有深度也缺乏竞争力。在老板和其它团队眼中只把我们当资源，只要支持好业务的需求就可以，当业务方没有投诉老板也不愿意再投入，团队同学看不到希望就会想转岗，转走后又没有新的人员补充，每个人的事情都越来越多，为了不使大家那么辛苦，自己也去负责答疑做各种日常事务，最终使团队陷入一种恶性循环的状态。

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

让更多的人加入进来做这一件事

想把事情做的更好必然需要更多优秀同学加入，同时每个团队都会存在人员流动情况，所以第二重要的事就是确保团队不断有新鲜血液加入。

刚开始带团队一般都是通过组织调整，最初几年我对招人也是完全没想法，缺人了就找老板要，后来才慢慢明白我是在完成自己的目标，不是在帮老板带团队，才意识到招聘对团队的重要性。

招聘策略我会倾向于多校招，只有少数专业类人才需要社招。校招最难的是第一年，因为第二年这些同学可以推荐学弟学妹，后续每年基本就不会断档了。第一年怎么招？如果实在找不到更好的渠道，内部的公海池是个不错的选择，总归可以筛选出一些优秀的同学。如果每年都有校招新同学加入，新同学又会变成老同学，天然的就建立起了人才梯队。

随着团队成员越来越多，管理方面的问题就会暴露出来，管理最重要的我觉得还是让每个同学清楚自己月度、季度和年度的一件事分别是什么，然后定期与同学沟通交流，了解实现目标过程中遇到的问题并给予帮助和建议，使同学知道自己的发力方向。

与更多团队合作形成更大的一件事

BU 的一件事是靠 BU 内的多个部门合作实现，部门的一件事又需要部门内多个小组合作完成，重点项目基本都是多个团队协同完成，一个团队的力量始终是有限的。

反观自己这些年大部分时候在单打独斗，负责一块独立的业务，好处是自主空间比较大、不用依赖别人看人脸色，但这样的业务往往也不在主干道上，做的好或不好影响都有限。这一点我觉得自己现在做的还不够好，还是会有小农意识，需要继续加强与兄弟团队的合作，一起做一件更有价值的事。

4

总结

最好的 10 年在阿里度过我觉得自己很幸运，公司的同事们都很有智慧，持续与优秀的同事共事，我的认知和行为也受到影响，逐渐得到改变和提升。这十年我得到了很多同事的帮助，谢谢帮助过我的每一位同学，还有历任主管和团队的小伙伴们，因为你们对我的包容和支持使我走到了今天，对下一个十年我充满了信心和期待！

- EOF -

想要加入中生代架构群的小伙伴，请添加群合伙人大白的微信

申请备注（姓名+公司+技术方向）才能通过哦！

阿里技术精彩文章推荐

往期推荐

深度：揭秘阿里巴巴的客群画像

多隆：从工程师到阿里巴巴合伙人

阿里技术专家楚衡：架构制图的工具与方法论

蚂蚁集团技术专家山丘：性能优化常见压测模型及优缺点

阿里文娱技术专家战獒: 领域驱动设计详解之What, Why, How?

阿里专家马飞翔：一文读懂架构整洁之道

阿里专家常昊：新人如何上手项目管理？

蚂蚁集团沈凋墨：Kubernetes-微内核的分布式操作系统

阿里合伙人范禹：常挂在阿里技术人嘴边的四句土话

阿里技术专家都铎：一文搞懂技术债

支付宝研究员兼OceanBase总架构师杨传辉：我在数据库梦之队的十年成长路

阿里技术专家麒烨：修炼测试基本功

阿里计算平台掌门人贾扬清：我对人工智能方向的一点浅见

蚂蚁资深算法专家周俊：从原理到落地，支付宝如何打造保护隐私的共享智能？

阿里高级技术专家箫逸：如何画好一张架构图？

阿里高级技术专家张建飞：应用架构分离业务逻辑和技术细节之道

蚂蚁科技 Service Mesh 落地实践与挑战 | GIAC 实录

阿里6年，我的技术蜕变之路！

蚂蚁集团涵畅：再启程，Service Mesh 前路虽长，尤可期许

阿里P9专家右军：大话软件质量稳定性

阿里合伙人程立：阿里15年，我撕掉了身上两个标签

阿里高工流生 | 云原生时代的 DevOps 之道

阿里高级技术专家邱小侠：微服务架构的理论基础 - 康威定律

阿里P9专家右军：以终为始的架构设计

阿里P8架构师：淘宝技术架构从1.0到4.0的架构变迁！12页PPT详解

阿里技术：如何画出一张合格的技术架构图？

   END     
#架构师必备#

点分享点点赞点在看