作者 | 宋意 阿里巴巴高级技术专家
起源 | 阿里巴巴云原生公众号
导读：不论是什么角色，成长是咱们每个人都必须经验的过程。作为一个技术人，成长不仅是技术上的一直精进，也包含日常工作中的方方面面。本文次要讲述了阿里巴巴高级技术专家在阿里 10 年的成长之路，分享他从一个一般技术人开始，在阿里的三个阶段，以及在降职、转岗、带团队、做事等方面的心得感悟。
自我介绍
宋健，花名宋意，2008 年开始加入工作，至今 12 年多始终专一在运维畛域。2010 年 6 月退出支付宝，做过监控、SRE、资源管理、运维产品等方面的工作，经验并参加了阿里运维从脚本到工具化再到主动智能化的演进过程，在阿里的 10 年依据部门变动有三个阶段：
- 2010.6-2013.1，支付宝（零碎运维部）
- 2013.2-2015.12，技术保障（支付宝、阿里云、淘宝、B2B 等运维部门对立后的新 BU）
- 2016.1- 至今，天基（负责阿里寰球数据中心和运维体系的“数字化、自动化、智能化”建设）
个人经历
1. 支付宝
关键词：开源监控、监控值班、应急响应
入职后退出的团队是运维部的监控组，那个时候团队刚刚开始组建，所有的货色从零开始，好在有 B2B 的兄弟团队能够借鉴教训，利用 nagios 疾速构建了支付宝第一代监控零碎。过了几个月因为 双 11 的起因，咱们的下班地点由华星时代搬到了电信二枢纽机房，因为支付宝过后的外围机房在那里，咱们须要 7*24 小时在现场以便疾速处理紧急事件。过后小组应该是 6 个同学，一白班一晚班一失常班，咱们一边值班一边保护监控零碎。
随着业务的疾速倒退服务器一直减少，很快一台 nagios 已无奈满足需要，调研后引入 centreon 解决了 nagios 的程度扩大问题。监控项的增加和保护以编辑 nagios 配置文件为主，没有方法凋谢所有人员，因而监控项的保护工作也是由监控团队负责，PE 和 DBA 只有整顿好需要收回邮件即可。但新建业务和扩容的频率越来越高，每天要花费大量工夫编辑文件受理监控需要且常常出错，和需求方协商后确定了针对不同业务组件设定监控模板的计划，再想方法主动获取到服务器信息，那个时候还没有专门 CMDB，起初总算实现了新机器上线主动匹配模板增加监控和告警。重要的告警都是通过短信收回，告警短信须要和线上业务的短信辨别开防止相互影响，所以咱们又洽购了几十个短信猫，专门学习了如何通过服务器管制短信猫发送短信，再起初还演进出了利用短信猫接管短信敞开告警的能力。
这样的状况持续一年左右逐步稳定下来，有了教训积淀后咱们开始尝试引入外包值班，而后开始招聘和培训外包同学，制订值班和应急规范，建设相应的流程零碎。外包值班又继续了差不多一年工夫，因为监控能够看到所有业务数据，出于平安思考又进行了去外包化。目前监控值班的角色依然存在，办公地点在西溪的寰球运行指挥核心，有专门的办公室和门禁限度，外面全是各种酷炫大屏，整个经济体的业务由他们 7*24 小时守护着。
这两年就是不停的做事件，不停的遇到问题和解决问题，逢山开路遇水搭桥。
2. 技术保障
关键词：监控对立、OD 拆散、资源管理
2013 年我所在部门由支付宝调整至团体，到团体后参加的第一个我的项目是对立团体监控零碎。原来淘宝、支付宝、阿里云、B2B 等业务都是自建监控团队和零碎，组织层面对立后必然要将零碎进行整合，整合后的新零碎叫 alimonitor。过后我的项目主导方是在运维开发团队，我参加进来时我的项目曾经启动，只有我一个人是在监控团队，这也是我第一次参加较大型的跨团队我的项目。因为刚调整到团体跟其它成员都不相熟，所以跟大家单干起来阻力很大，但我还是积极参与到我的项目中，每天跑到开发团队加入晨会，直到有一次在晨会上被气哭，但神奇的是从那天后单干就变的十分顺畅，再也感触不到壁垒的存在。我的项目继续了差不多一年工夫胜利上线，通过这个我的项目使我和开发团队的同学们建设起了良好的信赖关系，对后续的工作起到了很大帮忙。
开发团队负责着团体所有的运维工具，除 alimonitor 外还有 staragent、armory、aone 等，有段时间这些工具常常产生故障，甚至在双十一、双十二的关键时刻掉链子，起初从业务团队转来一位资深同学负责团队，并发动了运维工具的 OD 拆散我的项目，我作为次要负责人承当所有工具的 PE 职责，也是这时候我开始带团队，最终推动 10 多个产品上百个利用实现 OD 拆散标准化革新，解决了工具的稳定性问题。因为每个工具负责了运维的其中一个环节，所有工具承载的业务加起来形成了团体的工具运维体系，这段经验使我对运维业务有了更全面和深层次的了解。
工具 PE 的事件稳固后我又接到了一个事件，负责整个团体开发测试环境的资源管理，测试环境过后有好几万台服务器，但没有人晓得哪些机器在用以及谁在用，而且每年还有数千台的物理机新增估算，老本节约十分重大。我接手后首先建设了一个资源生命周期管理系统，使所有新资源的申请全副通过零碎，并且对已有资源发动盘点和认领，所有资源设置有效期，到期后能够续租或开释，零碎还会定期巡检资源的应用状况，再配合宕机回收、闲置降配等经营策略，最终将测试资源盘点的清清楚楚，不仅年度预算 0 新增，还将回收的几千台物理机在双十一时声援了生产环境。再起初持续尝试通过混部晋升测试资源使用率，调研多个计划后抉择了跟 jstorm 团队单干，但上线后经常出现 jstorm 工作把测试机资源占满，影响业务的日常测试引发投诉，受限于过后技术限度最终没能持续推动上来。
从参加一个跨团队我的项目到负责一个跨团队我的项目，再到做一个产品解决业务问题，这是我成长最快的两年。
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 的事件全副交接了进来，目前我的主要职责是为业务上云提供一站式监控计划，包含云资源监控、主机监控、业务监控、链路监控等。
埋头做了好几年的产品，然而产品的深度都没有达到本人的预期。次要问题我感觉是过于关注产品技术自身，没有做到以业务价值驱动，导致未能取得继续的资源投入。
这三个阶段我会用三个词概括：做事件 –> 做我的项目 –> 做产品。
做事件和做我的项目的重点是“正确的做事”，区别是我的项目多了一层合作。做产品的重点是“做正确的事”，不仅须要关注当下后果，更重要的是如何继续走到将来。
个人成长
“很傻很天真，又猛又长久。”我感觉这句话能够形容我的待人和做事格调，待人方面我会默认置信每一个人，做事方面因为比拟笨就会比他人下更多功夫。这些年我始终保持在一个畛域，比他人投入更多的工夫和精力，在经验一次又一次失败后，一直的吸取经验和教训使本人成长。期间也有过很屡次想打退堂鼓，最艰巨的时刻总能想到一句充斥力量的阿里土话刺激本人。
1. 对于降职
互联网行业招人时常常会说一句话，岗位对标阿里的 P 几，这一点足以阐明在阿里级别的重要性，所以降职对每个人来讲都很重要。但当咱们把级别看的很重时也带来了问题，级别变成了每个人的第一标签，单干时首先看你的级别而不是负责什么，做事件首先想到的是降职而非价值。往年公司在这方面曾经有所调整包含暗藏职级等，心愿能够让咱们回归到用事件价值和成就感来驱动本人。
10 年前我入职支付宝时级别为 P4，到目前共经验 8 次问难，均匀每 2 次问难胜利 1 次，然而 P7 到 P8 的降职用了 5 年问难 3 次……每次降职失败后最难的是调整心态，感觉本人受到了不偏心待遇，评委不主观、不理解我做的事件、只能看到我的短板等，这样的想法继续太久必然会影响到本人。
如何调整？我的做法是首先摆正心态，置信公司置信评委，公司肯定心愿给每位同学匹配到最合适的评委，评委主观上也肯定是主观的，不会刻意针对某一人。而后从本人身上找起因，评委的反馈是什么？为什么会让评委有这样的感触？没表白分明还是没思考分明？
失败起因能够简略概括为两方面：
- 能力没达到，包含软技能和硬技能。
- 运气不好，跟评委气场没对上。
能力起因集体是能够扭转的，但首先须要认知到本人的有余，技术、业务、表白是哪方面的问题？仔细阅读和了解评委的反馈，有时候反馈可能不那么间接，比方将来瞻望不够意思是看不到你负责这个业务的将来，平时你有想过业务的将来吗？多和主管聊一聊，主管肯定违心帮忙你找到问题所在。把本人做了一年或者几年的事件，在 20 分钟外向几个生疏评委讲清楚，让他们齐全认可和了解我认为一点都不容易。
运气方面集体能做的就是来年再战，多试几次总归运气有不那么差的时候。每个人都有能够晋升的中央，成长是无止境的，只有当切实找不到或不了解的时候，才能够把起因简略的归为运气，使本人心态可能调整过去，当心态温和后真正的问题就会缓缓清晰，在这个期间须要主管给予更多的刺激和激励。
2. 对于转岗
这 10 年我只有一次正式转岗，但转岗的念头还是有过好屡次，其中三次印象比拟粗浅：
- 第一次是入职两年后，大略 2012 年中，第一次感觉遇到了瓶颈，已有事件无奈再让本人冲破，所以就去找主管聊了聊，主管也感觉我须要做些更有挑战的事件，理解想法后也被动帮忙我找团队，就在定下团队筹备走流程时产生了组织调整，支付宝整个运维部被合并至团体新成立的 BU 技术保障，事件也跟着产生了变动，从原来的支付宝监控转变为对立整个团体的监控，对我来讲又有了新的挑战就拥抱变动放弃了转岗。
- 第二次是在 2015 年底，过后团体正在去 PE 化，技术保障大 PE 团队分拆到了各业务线，我负责的工具 & 测试 PE 团队也被拆分调整，但本人对调整后的事件并不太感兴趣。几年的 PE 做下来感觉运维最大挑战还是工具，思考很久决定转岗至负责运维工具的产品技术部，抉择的产品是 StarAgent，BU 没有变动还是在技术保障。
- 第三次是在 2019 年底，SA 做了近四年且间断两次降职失败之后，在我的主导下 SA 从一个纯正的命令通道降级为主机治理平台，成为所有运维零碎和人员治理服务器的第一入口。感觉本人曾经用尽了全力，却依然不晓得怎么冲破，陷入了迷茫。起初在主管帮忙下终于想明确，本人始终想着怎么把事件做好，但很少思考做的是不是正确的事件，导致做的越来越多越来越累。和主管探讨后对职责进行了调整，将精力聚焦在一件事下面，其它事件进行了交接。
转岗的目标还是为了解决问题，无论什么时候有转岗想法后，应该首先找主管聊一聊，必要的话也能够找主管的主管或 HRG 去聊。不要放心聊了会被打“标签”，坦诚的去沟通，主管肯定也很想帮忙你，只是他可能还没意识到问题，问题聊分明了才可能失去解决，没有沟通间接找新团队其实还是在回避。
集体在以后团队成长受限、看不到以后业务的前景，如果沟通后的确是这些方面的问题，那么转岗就是必要的。但除此外遇到如合作或沟通等方面的问题，则须要慎重考虑。换团队的老本十分高，须要工夫来和新主管及成员建设信任感，以后得不到解决的问题换个中央后大概率还会碰到，新团队也会带来新的问题甚至问题更多。
3. 做事件
我也常常看书和听他人分享，要学习的方法论切实太多，但每次看完听完就没有而后了，最初依然是走了很多弯路撞了很屡次墙，才缓缓排汇造成了本人的办法，我的经验总结下来就两句话。
1）一件事件
“让天下没有难做的生意”，是一件事件。
“做技术驱动的世界第一的商业基础设施服务商”，也是一件事件。
“云上云下监控数据采集技术对立”，也是一件事件。
每个人每天都在做事件，为什么有的人做的好有的人做的不好？我认为很重要的一点是做的事件之间有没有产生连贯。做的好的应该是：每天做的事是每个月的一件事的一部分，每个月做的事是该季度一件事的一部分，每个季度做的事是本年度一件事的一部分。当做的所有事件建设起了关系，组成了更大的一件事才有意义。
每天的一件事和每月的一件事的高度是不一样的，复杂度和解决须要的工夫也不一样。每个事件都该做，每个问题都该被解决，但咱们的工夫和精力是无限的，判断事件该不该做的根据就是这个事件是否成为你的月度、季度或年度的一件事的一部分，如果能够则制订打算去做，否则阐明这个事件不该你来做。
2）99% 和 1%
一件事件能够分为 99% 和 1% 两局部，大部分时候咱们做到 99% 就感觉能够了，如某个成功率指标做到 99.99% 之后，可能发现最初 0.01% 要付出的代价比之前的全副还要高，要不要做？我感觉应该尽可能推动，因为越深刻越能体现出竞争力，至于最初做到 5 个 9 还是 6 个 9 取决于和业界拉开的间隔。
99% 是必须做的，1% 是须要冲破的，深度和壁垒往往体现在最初的 1%。每次实现一件事件较之前提高 0.01% 也是冲破，100 次 0.01% 就是 1%。但如果每次做到 99% 就进行了，那么咱们和流水线上的工人没有本质区别，都是在反复做事件只是反复的货色不一样而已。
实现一件一件有关联的事件将本人打造成一个服务，防止实现一件一件无关的事件让本人成为一个资源。一件事件体现的是业务广度，1% 体现的是技术深度，布局时须要业务广度，落地时须要技术深度，二者联合起来能力保障所做事件的正确性和竞争力。
4. 带团队
带团队的目标还是做事件，只是由一个人变成了多集体，多集体做一件一直迫近 100% 的事。对于团队负责人最重要的事件我总结为 3 句话：
1）定义分明团队的一件事
一件事就是团队的指标，团队指标肯定是久远的，最好能先想分明几年后的样子，而后推导出一年的指标，再拆解出实现指标波及的技术畛域，最初确定每个畛域的季度或月度指标及负责人。
我是从 2014 年开始带团队，尽管每年也在做打算，但早些年次要以列举事件为主，每次汇报都被老板批，直到近两年才想明确这一点。当初来看前些年带团队本人更像个 PM，不停地为产品做新性能，但上线后又不足长期演进计划，导致反对工作越来越多，团队同学越来越辛苦，产品没有深度也不足竞争力。在老板和其它团队眼中只把咱们当资源，只有反对好业务的需要就能够，当业务方没有投诉老板也不违心再投入，团队同学看不到心愿就会想转岗，转走后又没有新的人员补充，每个人的事件都越来越多，为了不使大家那么辛苦，本人也去负责答疑做各种日常事务，最终使团队陷入一种恶性循环的状态。
这段经验使我真正了解了一句话：“用战术上的怠惰覆盖策略上的懈怠”。
2）让更多的人退出进来做这一件事
想把事件做的更好必然须要更多优良同学退出，同时每个团队都会存在人员流动状况，所以第二重要的事就是确保团队一直有新鲜血液退出。
刚开始带团队个别都是通过组织调整，最后几年我对招人也是齐全没想法，缺人了就找老板要，起初才缓缓明确我是在实现本人的指标，不是在帮老板带团队，才意识到招聘对团队的重要性。
招聘策略我会偏向于多校招，只有多数业余类人才须要社招。校招最难的是第一年，因为第二年这些同学能够举荐学弟学妹，后续每年根本就不会断档了。第一年怎么招？如果切实找不到更好的渠道，外部的公海池是个不错的抉择，总归能够筛选出一些优良的同学。如果每年都有校招新同学退出，新同学又会变成老同学，人造的就建设起了人才梯队。
随着团队成员越来越多，治理方面的问题就会裸露进去，治理最重要的我感觉还是让每个同学分明本人月度、季度和年度的一件事别离是什么，而后定期与同学沟通交流，理解实现目标过程中遇到的问题并给予帮助和倡议，使同学晓得本人的发力方向。
3）与更多团队单干造成更大的一件事
BU 的一件事是靠 BU 内的多个部门单干实现，部门的一件事又须要部门内多个小组单干实现，重点项目根本都是多个团队协同实现，一个团队的力量始终是无限的。
反观本人这些年大部分时候在单打独斗，负责一块独立的业务，益处是自主空间比拟大、不必依赖他人看人脸色，但这样的业务往往也不在主干道上，做的好或不好影响都无限。这一点我感觉本人当初做的还不够好，还是会有小农意识，须要继续加强与兄弟团队的单干，一起做一件更有价值的事。
总结
最好的 10 年在阿里度过我感觉本人很侥幸，公司的共事们都很有智慧，继续与优良的共事共事，我的认知和行为也受到影响，逐步失去扭转和晋升。这十年我失去了很多共事的帮忙，谢谢帮忙过我的每一位同学，还有历任主管和团队的小伙伴们，因为你们对我的容纳和反对使我走到了明天，对下一个十年我充斥了信念和期待！