4月20日20:00-21:30，一场别开生面的技术大会—— “运维/Devops在线技术峰会”将在线举办。从网络基础架构实践和演进，到同城容灾架构剖析；从如何稳定、安全的使用云数据库，到企业如何在云上安全加固最佳实践；从阿里云专家理解的DevOps，到如何构建一个通用化的智能运维平台……不仅一一告诉你云上的运维重点在哪、运维人应该如何思考，也手把手教你如何做。同时，对于处于转型中的企业，我们也邀请了有代表性的互联网公司来分享他们的亲身体验。
阿里云运维/Devops在线技术峰会官网：
https://yq.aliyun.com/activity/188
峰会统一报名链接：
https://yq.aliyun.com/webinar/join/167
以下为文章正文：
她，从行业软件、共享软件、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命令中率等，并结合云平台的特点及业务数据，优化运维的成本、效率，以及优化业务架构、业务模块的部署架构及对云资源需求。
她还指出，云上的自动化运维在以下四个方面是一定要做到的：
- 自动化：自动化你所能的一切，自动化比手工快得多。工具一旦被配置好，验证也是正确后，之后每次执行任务都不会出错；
- 方便迁移：运维的根本是要保证稳定和安全，但有时也要考虑成本，方便迁移的方案可以灵活选择适合自身业务的最合适的云平台；
- 将IaC进行到底：基础设施的变更也要通过代码维护。很多企业运维面临的两大问题：人员变动频繁、文档更新不及时。将IaC进行到底，不止是创建时自动化，变更、销毁也都通过代码维护，这样就可以将脚本做为基础设施的文档，可以做版本管理，每次的变更也都会有历史记录。
- 永恒的职责：“自动化、基础设施即代码”、“持续集成/测试”、“持续交付/部署”、“持续监控/反馈”。
快的那个，会被慢的拖死
“教主拥有超强的业务前瞻能力和驱动能力。”阿里云高级专家闫长海在一段文字中说到。而在另一面，尹书威也有很多纠结。
她说，前几年部门节奏比较快，可预见一年之后部门人员将呈现头部、中部、尾部较大的差距趋势。“到底是托着尾部的前进、还是头部快速跑？”尹书威踌躇万分。“后来想起小时候玩‘魂斗罗’的游戏，如果是两个人一起玩，快的那个是会被慢的拖死，后来决定是头部的快速前进。”她坦然，这个选择其实比较残酷。
接下来，她又深陷另外一个抉择：业务？还是技术？并在这里徘徊很久。因为前几年的行业软件让她感觉无限的“危机感”，对行业很了解，但却视野很窄。后来钻研了一段时间的技术，同样有“危机感”，因为又离市场很远。对于一个做技术的人来说相信很多人有这样的迷茫，但她最终决定以业务为方向，技术围绕业务做拓展。
现在，她最关注云上自动运维的各种开源工具，包括它们适合的运维场景、功能、如何开发扩展，以及多个工具组合的的最佳实践。比如Jekins2.0和Salt的结合、InfrastractorAsCode与PipelineAsCode的最佳实践等。并通过输入、实践、输出形成的闭环，快速掌握多方面的技术。
结束语：
“人生是一种修行。”尹书威说，她没有任何宗教信仰，但却非常喜欢这句话。
“修行的道路上，没有失败者也没有成功者，只有一段又一段各式各样的人生，无论哪一段，都足够绚丽多彩、苦乐参半。”
不以物喜，不以己悲——也许正是这样的人生态度，才造就了今天自动化运维的大牛。
