【沉淀】“快的那个,会被慢的拖死”,记不断奔跑、看着阿里云产品管控慢慢长大的那个人——尹书威

【沉淀】“快的那个,会被慢的拖死”,记不断奔跑、看着阿里云产品管控慢慢长大的那个人——尹书威
《沉淀》是云栖社区展示专家风采的人物栏目。它呈现每个专家独一无二的人生经历、认识和感悟的同时,也能帮助你沉淀技术,收获对技术和人生的判断。我们的想法是:“若你想精进为一个很厉害的人,不妨细细品味这些技术牛人背后的沉淀。”如果你想了解这些云栖专家更多分享时,请点击云栖专家频道,当然我们也欢迎你往前走一步,成为我们的云栖专家(https://yq.aliyun.com/expert),与技术大牛一起“煮酒论英雄”。


以下为文章正文:

她,从行业软件、共享软件、OA系统到联想网盘,再到阿里云,并扎在云计算领域一干就是七年。

她,看着云产品管控慢慢长大,并先后经历过管控系统的服务化改造、开源DevOps工具与阿里云的集成等。

“开源生态对阿里云是一块全新的领域,教主制定了国际包围国内的方针,拟定了开源社区引导企业用户的战略,为阿里云开源社区、开发者服务奠定了稳定的基础。” 阿里云高级专家闫长海说到。

但她却认为只是迈出了第一步,运维自动化后面还有很长的路要走,并持续寻求改变。“我们在做一件伟大的事情,也许现在的效果还不明显,但一两年后我们会感谢曾经努力的自己。”她坚信成功迟早会来。

她认为未来运维将分为两个领域:应用运维和业务运维,而传统运维人要想转型,就要做到:从Ops走向DevOps,从项目走向产品,从资源走向应用。

她,就是本文的主人公、自动化运维领域牛人尹书威。

进入云计算领域看似跨度很大,但有着千丝万缕的关系

【沉淀】“快的那个,会被慢的拖死”,记不断奔跑、看着阿里云产品管控慢慢长大的那个人——尹书威
尹书威认为,未来云上的运维一定要做到四方面:自动化、方便迁移、将IaC进行到底和“永恒的职责”

尹书威,阿里云高级专家,就职于阿里云云应用服务部门,负责开源的自动化运维工具与阿里云的集成,致力于通过主流开源高效的自动化工具提高云上运维/开发的便利性。

她的花名——“黎山”,出处来自西游记中《四圣试禅心》中几个菩萨的妈妈——黎山老母。谈到这个花名,尹书威说:“其实没啥寓意。”相较之下,她更喜欢另一个因扮演年会小品角色,而得的别名“教主”。

IT行业中,女性程序员非常少,能成为大牛的女性更少,那尹书威是如何一步步进入这个行业,并成为大牛的?

“这个受我父亲的影响比较大。”她说,父亲是属于那个年代少有的知识分子,从小就灌输给她长大要做技术,“所以这个思想一直深深感染着我。”上世纪90年代,计算机还比较奢侈,家里就给她买了一台386的电脑,因此她早早便开始接触计算机。

毕业后,尹书威一直从事软件开发的相关工作,先后做过行业软件、共享软件、OA系统,以及联想网盘。

共享软件是物业管理系统,属于行业类软件,但是以共享软件的形式存在的——用户在软件园下载,购买后会发放注册码。尹书威说,那时微软刚刚提出SaaS概念,这算是第一批SaaS系统了。有单机版和网络版,网络版即是“租户”形式的,用户只需要注册便可使用。“但那时大家还不能接受把‘数据’放到网上,所以单机版的下载量相对较多,并一度持续数周在共享行业软件排行第一。”尹书威说,她当时还注册了专利,只不过后来随源码卖了。

接着,她来到阿里云,并一直跟着云计算的成长而成长。对于这步,她不觉得跨界:“看似跨度很大,但有着千丝万缕的关系。” 

看着云产品管控慢慢长大

尹书威是2010年加入阿里云的,那时阿里云刚刚起步,云产品不多,“只有几个云管控系统,我记得最开始只有ECS。” 由几个发展为现在的上百个,她算是看着云产品管控慢慢长大的。

这样的时间点来到阿里云,也让她亲身经历过很多重要开发,比如阿里云的管控系统服务化改造,这是一个将阿里云底层的功能提供可操作的UI方式供用户使用的系统。

为什么要进行服务化改造?她称,云计算是2010前后才开始大火特火,阿里云尽管在云计算上布局比较早,但也是摸着石头过河。随着用户量和ISV的增加,大家发现一个较严重的问题,用户只能调用OpenAPI,不能调用阿里云的内部接口,云产品提供的一些重要功能OpenAPI不齐全,有些也并不稳定,这使得用户无法使用云产品对外提供OpenAPI做管控或与他们的自有系统集成。

阿里云合作伙伴们的一致诉求都是帐号独立、结算独立,而管控系统的功能几乎一致。尹书威思量:“如果为‘虚商’单独开发管控系统,工作量非常大,同时功能的同步性、Bug修改的同步性都是严重的问题,所以一定要一套代码支撑阿里云自身以及虚商的管控系统。”所以,她将基于OpenAPI的管控系统服务化改造分为两部分:一部分是阿里云的管控系统基于云产品的OpenApi提供功能,另一部分是阿里云的管控系统能够轻量的输出给“虚拟云商”使用。

“用那时比较流行的一句话就叫‘Dog Food’,自己吃自己的狗粮,打磨OpenAPI的健壮性和丰富性。”

也正是这样的改造,使得一套代码完美的支撑了各个虚商,并且可以轻量化的输出。增加虚商时,管控系统的代码几乎不感知,只需要业务人员在管控系统的管控系统中做配置即可。

一步一艰难

3月底,圈内有一篇很火的文章《深度解析国内公有云大厂基础实力》,文中有对开源生态覆盖度的描述:“同时Azure和阿里云都在开发基于Terraform的模板部署项目...”这句话,肯定了阿里云去年在市场上的布局。阿里云资深专家汤子楠,就此也给予了阶段性的肯定:“单骑救主,让阿里云在新的‘战场’也能保持领先。”

一切看似风淡云轻,但对尹书威而言,却是职业生涯挑战最大的一次,“可谓一步一艰难。”在采访中,她一字一顿说到。

她这次参与的是研发与阿里云集成的开源DevOps工具。然而开始开源生态集成工作时,她发现DevOps工具玲琅满目,但是一个也不支持阿里云,也就是说不能用任何一个自动化工具管理阿里云的资源。

面对众多的工具,大家集成开发的优先级是什么,功能范围是什么,都无从所知。为了理清头绪,尹书威开始研究主流DevOps工具在运维流程中的角色。随着研究的深入,她头脑里也逐渐形成一张大图,串起一张从基础设施管理→持续集成→持续交付→持续监控的主线。基于此,她决定每个主线挑选一个工具由自己团队开发,其他由合作伙伴来。“我们负责架构设计和代码Review,这样当主线工具集成后,可以在其上长出一个产品,实现针对于阿里云DevOps的闭环。”尹书威解释。

然而理想很丰满,现实很骨感,开发开源DevOps工具一波三折,最典型的两个问题是:各个开源DevOps工具的开发语言不同;另外一个是国内自动化观念的问题。

开发语言上的不同,体现在:Terraform和Packer是Golang,Ansible是Python,Chef是Ruby。挑战,不仅仅是要在短时间内掌握这些语言,也要掌握各个社区的编程规范、文档规范、TestCase规范。尹书威说,后者不能随心所欲,“因为回馈给社区是一定要符合他们的章法和套路。”

用户教育的问题是什么?是当这些工具与阿里云逐步集成后,尹书威想提供更多真实的Sample给用户使用,但在调研中发现虽然大家都知道“基础设施即代码”的词,但真正这样做的并不多。“有很大一部分用户是用了一些DevOps工具,但也只是解决临时性的问题,大家还是习惯性的用UI操作。”尹书威指出,这样就违背了IaC的原则,使基础设施的变动不可追溯、不可做版本管理、不可测试。

“比如想要修改资源Tag和Name,如果用IaC的理念,只需要修改两行代码,执行变更就可以自动更新这些资源,但用户却用了传统的手工方式:导出到Excel→在Excel上修改→再导回到列表中……这个过程需要更多的时间,不仅无法追溯更改之前的值是什么、也无法回滚。再举一个例子:想要在已有实例上挂载数据盘,如果用IaC的理念,只需要把磁盘的那个资源加上,执行下变更,可以快速自动的执行挂载数据盘。而很多用户的做法是做个临时的小工具,把所有要挂载的实例取出来,然后再执行挂载。虽然达到了效果,比纯手工操作要快,但已经违背了‘基础设施即代码’的理念,使基础设施和代码不对等,已经破坏了他们的完整性和一致性。”

我们在做一件伟大的事情

目前这个工具已经研发好,并且Terraform的代码已经纳入官方社区。由于“Alicloud”的字母优势,还排在Terraform官方文档和代码仓库的第一个位置。

尹书威的同事闫长海说:“以阿里云四大件产品为先导,迅速的覆盖了Packer、Terraform、Ansible三款工具的实施落地。得到了开源社区、开发者的一致认可。”这位同样也是阿里云高级专家的还指出,尹书威积极推进的Terraform跟阿里云商业合作,也进一步提升了阿里云在国际市场的占有率和在社区的影响力。”

但尹书威认为这只是迈出第一步,后面还有很长的路要走。对比海外的自动化程度:网络的搭建(VPC+Nat网关)全套代码搭建,以及SLB的监听也是用代码实现。她感叹到:“国内自动化教育任重而道远。”

但她并不气馁,觉得这也是机遇,并持续寻求改变:“通过海外的需求完善工具,再不断的反哺国内用户。”就此,她也呼吁到:“希望有更多的开发者一起加入到工具集成的开发中,使中国的自动化运维步伐再快些,加快国内自动化的Sense,使企业有更多的时间去创新。”

“我和团队都认为我们在做一件伟大的事情,也许现在的效果还不明显,但一两年后自动化的理念被接受,并加以实施时,我们会感谢曾经努力的自己,也感谢在路上踩过坑的用户们。”尹书威坚信成功的那一天很快就会到来。

据悉,尹书威团队会在4月份持续将主流工具对阿里云的集成回馈到社区,包括Packer、Ansible、Chef、Jenkins等,造褔更多的运维/开发者。

传统运维人转型的最佳姿势

云计算给企业带来了便利,有无限可用的资源、基础设施硬件不用维护、负载均衡/网络/备份等都有成熟的方案,随时可扩容等。因此,在云计算领域浸淫七年之久的尹书威认为,未来运维将分为两个领域:应用运维和业务运维。

这对运维人员,也提出了更高的要求。除了需要了解各个云服务平台采用的不同技术、提供的不同云服务、不同的专业术语,运维人员也要知道怎样构建各个云计算平台的基础设施、部署、运维、监控等,以及各个应用对于云计算平台的最佳选择。

那传统运维人,该如何转型呢?尹书威的答案是“三从”。传统运维人要从Ops走向DevOps,从项目走向产品,从资源走向应用。

具体则落到两方面,一方面应该快速掌握各个云平台的自动化工具及云平台的能力,利用Dev手段管理云上的基础设施和应用,将开发、测试、预发、生产各个环境的自动化打通;另一方面则是理解和应用业务运维的能力,比如业务架构是什么样子、业务压力情况、用户访问规律、读写情况、Cache命令中率等,并结合云平台的特点及业务数据,优化运维的成本、效率,以及优化业务架构、业务模块的部署架构及对云资源需求。

她还指出,云上的自动化运维在以下四个方面是一定要做到的:

  1. 自动化:自动化你所能的一切,自动化比手工快得多。工具一旦被配置好,验证也是正确后,之后每次执行任务都不会出错;
  2. 方便迁移:运维的根本是要保证稳定和安全,但有时也要考虑成本,方便迁移的方案可以灵活选择适合自身业务的最合适的云平台;
  3. 将IaC进行到底:基础设施的变更也要通过代码维护。很多企业运维面临的两大问题:人员变动频繁、文档更新不及时。将IaC进行到底,不止是创建时自动化,变更、销毁也都通过代码维护,这样就可以将脚本做为基础设施的文档,可以做版本管理,每次的变更也都会有历史记录。
  4. 永恒的职责:“自动化、基础设施即代码”、“持续集成/测试”、“持续交付/部署”、“持续监控/反馈”。

快的那个,会被慢的拖死

“教主拥有超强的业务前瞻能力和驱动能力。”阿里云高级专家闫长海在一段文字中说到。而在另一面,尹书威也有很多纠结。

她说,前几年部门节奏比较快,可预见一年之后部门人员将呈现头部、中部、尾部较大的差距趋势。“到底是托着尾部的前进、还是头部快速跑?”尹书威踌躇万分。“后来想起小时候玩‘魂斗罗’的游戏,如果是两个人一起玩,快的那个是会被慢的拖死,后来决定是头部的快速前进。”她坦然,这个选择其实比较残酷。

接下来,她又深陷另外一个抉择:业务?还是技术?并在这里徘徊很久。因为前几年的行业软件让她感觉无限的“危机感”,对行业很了解,但却视野很窄。后来钻研了一段时间的技术,同样有“危机感”,因为又离市场很远。对于一个做技术的人来说相信很多人有这样的迷茫,但她最终决定以业务为方向,技术围绕业务做拓展。

现在,她最关注云上自动运维的各种开源工具,包括它们适合的运维场景、功能、如何开发扩展,以及多个工具组合的的最佳实践。比如Jekins2.0和Salt的结合、InfrastractorAsCode与PipelineAsCode的最佳实践等。并通过输入、实践、输出形成的闭环,快速掌握多方面的技术。

结束语:

“人生是一种修行。”尹书威说,她没有任何宗教信仰,但却非常喜欢这句话。

“修行的道路上,没有失败者也没有成功者,只有一段又一段各式各样的人生,无论哪一段,都足够绚丽多彩、苦乐参半。”

不以物喜,不以己悲——也许正是这样的人生态度,才造就了今天自动化运维的大牛。
上一篇:中国移动:巨型传统客服中心智能化转型之路


下一篇:一张图看懂“2018杭州.云栖大会”企业应用专场