关注
HarmonyOS技术社区
，回复
【鸿蒙】
送
价值
399元
的鸿蒙
开发板套件
（数量不多，先到先得）
，还可以
免费下载
鸿蒙
入门资料
！
👇
扫码
立刻关注
👇
专注开源技术，共建鸿蒙生态
不管是什么角色，成长是我们每个人都必须经历的过程。作为一个技术人，成长不仅是技术上的不断精进，也包括日常工作中的方方面面。
图片来自 Pexels
本文分享阿里巴巴高级技术专家在阿里 10 年的成长之路，分享他从一个普通技术人开始，在阿里的三个阶段，以及在晋升、转岗、带团队、做事等方面的心得感悟。
宋健，花名宋意，2008 年开始参加工作，至今 12 年多一直专注在运维领域。
2010 年 6 月加入支付宝，做过监控、SRE、资源管理、运维产品等方面的工作，经历并参与了阿里运维从脚本到工具化再到自动智能化的演进过程。
在阿里的 10 年根据部门变化有三个阶段：
-
2010.6-2013.1，
支付宝（系统运维部）
-
2013.2-2015.12，
技术保障（支付宝、阿里云、淘宝、B2B 等运维部门统一后的新 BU）
-
2016.1-至今，
天基（负责阿里全球数据中心和运维体系的“数字化、自动化、智能化”建设）
①支付宝
关键词：
开源监控、监控值班、应急响应
入职后加入的团队是运维部的监控组，那个时候团队刚刚开始组建，所有的东西从零开始，好在有 B2B 的兄弟团队可以借鉴经验，利用 nagios 快速构建了支付宝第一代监控系统。
过了几个月由于双 11 的原因，我们的上班地点由华星时代搬到了电信二枢纽机房，因为支付宝当时的核心机房在那里，我们需要 7*24 在现场以便快速处置紧急事件。
当时小组应该是 6 个同学，一白班一晚班一正常班，我们一边值班一边维护监控系统。
随着业务的快速发展服务器不断增加，很快一台 nagios 已无法满足需求，调研后引入 centreon 解决了 nagios 的水平扩展问题。
监控项的添加和维护以编辑 nagios 配置文件为主，没有办法开放所有人员，因此监控项的维护工作也是由监控团队负责，PE 和 DBA 只要整理好需求发出邮件即可。
但新建业务和扩容的频率越来越高，每天要花费大量时间编辑文件受理监控需求且经常出错，和需求方协商后确定了针对不同业务组件设定监控模板的方案，再想办法自动获取到服务器信息。
那个时候还没有专门 CMDB，后来总算实现了新机器上线自动匹配模板添加监控和告警。
重要的告警都是通过短信发出，告警短信需要和线上业务的短信区分开避免相互影响，所以我们又采购了几十个短信猫，专门学习了如何通过服务器控制短信猫发送短信，再后来还演进出了利用短信猫接收短信关闭告警的能力。
这样的情况持续一年左右逐渐稳定下来，有了经验沉淀后我们开始尝试引入外包值班，然后开始招聘和培训外包同学，制定值班和应急标准，建设相应的流程系统。
外包值班又持续了差不多一年时间，由于监控可以看到所有业务数据，出于安全考虑又进行了去外包化。
目前监控值班的角色仍然存在，办公地点在西溪的全球运行指挥中心，有专门的办公室和门禁限制，里面全是各种酷炫大屏，整个经济体的业务由他们 7*24 小时守护着。
这两年就是不停的做事情，不停的遇到问题和解决问题，逢山开路遇水搭桥。
②技术保障
关键词：
监控统一、OD 分离、资源管理
2013 年我所在部门由支付宝调整至集团，到集团后参与的第一个项目是统一集团监控系统。
原来淘宝、支付宝、阿里云、B2B 等业务都是自建监控团队和系统，组织层面统一后必然要将系统进行整合，整合后的新系统叫 alimonitor。
当时项目主导方是在运维开发团队，我参与进来时项目已经启动，只有我一个人是在监控团队，这也是我第一次参与较大型的跨团队项目。
因为刚调整到集团跟其它成员都不熟悉，所以跟大家合作起来阻力很大，但我还是积极参与到项目中，每天跑到开发团队参加晨会，直到有一次在晨会上被气哭，但神奇的是从那天后合作就变的非常顺畅，再也感受不到壁垒的存在。
项目持续了差不多一年时间成功上线，通过这个项目使我和开发团队的同学们建立起了良好的信任关系，对后续的工作起到了很大帮助。
开发团队负责着集团所有的运维工具，除 alimonitor 外还有 staragent、armory、aone 等。
有段时间这些工具经常发生故障，甚至在双十一双十二的关键时刻掉链子，后来从业务团队转来一位资深同学负责团队，并发起了运维工具的 OD 分离项目。
我做为主要负责人承担所有工具的 PE 职责，也是这时候我开始带团队，最终推动 10 多个产品上百个应用完成 OD 分离标准化改造，解决了工具的稳定性问题。
由于每个工具负责了运维的其中一个环节，所有工具承载的业务加起来构成了集团的工具运维体系，这段经历使我对运维业务有了更全面和深层次的理解。
工具 PE 的事情稳定后我又接到了一个事情，负责整个集团开发测试环境的资源管理，测试环境当时有好几万台服务器。
但没有人知道哪些机器在用以及谁在用，而且每年还有数千台的物理机新增预算，成本浪费非常严重。
我接手后首先建设了一个资源生命周期管理系统，使所有新资源的申请全部经过系统。
并且对已有资源发起盘点和认领，所有资源设置有效期，到期后可以续租或释放，系统还会定期巡检资源的使用情况，再配合宕机回收、闲置降配等运营策略，最终将测试资源盘点的清清楚楚。
不仅年度预算 0 新增，还将回收的几千台物理机在双十一时支援了生产环境。
再后来继续尝试通过混部提升测试资源使用率，调研多个方案后选择了跟 jstorm 团队合作，但上线后经常出现 jstorm 任务把测试机资源占满，影响业务的日常测试引发投诉，受限于当时技术限制最终没能继续推进下去。
从参与一个跨团队项目到负责一个跨团队项目，再到做一个产品解决业务问题，这是我成长最快的两年。
③天基
关键词：
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 对接的上游是配置下游是通道，将配置、采集、通道三部分组合起来就是标准的数据采集。
