运维人员需要产品观

时间:2021-04-10 21:52:13
 在很多“外人”的眼中,运维工程师的工作不过是搬机器、调网络、装软件、处理故障、7×24小时值班,简单而又枯燥至极。但事实并非如此,运维工作涵盖很多技术领域,运维工程师要掌握硬件、软件、操作系统、开发等多方面的知识,核心目标是为亿万用户使用的产品保驾护航。

当今互联网行业的发展日新月异,新技术层出不穷。为了适应发展趋势,运维工程师只有提升技术能力才能更好地完成艰巨的运维任务,必须要对传统运维发出自我挑战。

在360,运维团队由基础运维团队、网络运维团队和应用运维团队三部分组成。我们将运维从技术支持领域升级,进行产品化改进,核心目标是为了降低运维成本、 缩短研发周期、让产品试错更廉价。理想很丰满,现实很骨感,从最初服务少量项目、几十台服务器,发展到大量具有数亿用户的项目,我们也在不断摸索,在试错中成长。在这个过程中,我们经历了两次重要的升级。

第一次升级:运维工具化

运维工作中有很多琐碎的、重复的事情,初期我们只有两个IDC,服务器数量有限,项目数量也较少,靠纯手工劳作还可以应付。但随着时间的推移,项目暴增,随之IDC和服务器的数量也成倍增长,同时360各项目都是小团队在做, 开发风格不同、习惯各异,但极致要求响应速度,如果运维工作按照之前方式进行,很难满足需求。大势所趋,我们必须进行工具化升级,将重复的事情自动化。

在工具化过程中,我们秉着低成本、拿来即用的原则,借鉴业界成型的方案,同时将精力用在对开源软件的研究中,有开源工具就绝不自己凭空创造。初期,我们只围绕开源软件做周边脚本开发,不动核心代码,在实践中总结经验。例如,在最基础的部署软件环境中,我们基于YUM搭建了自己的包管理系统,将常用软件打包, 同时根据项目做成模板,这样无论是初始安装还是扩容都能在分分钟完成。配置文件管理利用Puppet完成,服务器批量操控依赖SaltStack。就这样 我们的运维兵器谱在不断地丰富。

另外,运维工作离不开监控报警,这是一件让无数运维人苦不堪言的事情。而会休息才会工作,监控体系必须优化。

我们的监控大概分为系统级、应用级、项目逻辑和用户体验四部分。系统级主要监控硬件和网络等;应用级主要监控常用软件的健康状况;项目逻辑监控主要模拟用户行为探测项目功能点是否运行正常;用户体验监控主要联动博睿和基调等第三方监控一起优化用户体验。我们用过的工具很多,开源工具有Nagios、 Cacti、Ganglia、Zabbix等,同时自己也开发了一些针对项目场景的监控工具,但万变不离其宗,都是围绕上述几个维度进行监控,然后再进行分级预警和报警。

为了减少报警骚扰,我们分级处理,将报警分为邮件预警、短信报警和疯狂短信报警。以磁盘空间监控为例:每天下午6点,统计 磁盘使用率超过80%的机器,发出邮件预警,下班前解决;在预警的基础上,超过85%触发短信报警;超过90%就要持续报警,避免事故的发生。此外,随着 服务器数量的增多,硬件故障在所难免,架构设计需要考虑高可用方案,冗余范围内的服务器故障会以邮件预警的方式发出,避免对运维工程师的骚扰。

有了监控工具和分级机制,还需要有好的制度。为了大部分人可以安心休息,我们每天有专人负责处理常规报警,遇到无法解决的问题才要求他人协助。第二天的负责 人要针对第一天的报警找出根本原因,并尽力解决,因为如果无法根治,困扰将持续发生。所谓线上无小事,实际工作中复杂场景引发的问题数不胜数,所以可以宽 容第一次错误,但不能接受同样问题发生第二次,要不断地总结和完善。

工具化是运维的必经之路,是向更高层发展的基础,面对运维这样复杂的学科,这样一个极其磨炼人意志的工种,运维工程师需要用聪明的方式解决复杂的问题,节省时间,去做更有意义的事情。

第二次升级:运维产品化

我刚提出运维产品化时,有朋友开玩笑说,你做后端运维吃苦受罪这么多年,看着产品经理吃香的喝辣的,羡慕嫉妒也想转行做产品吧。也有人说,你是在偷换概念,不就是做自动化运维平台嘛。其实提出这个概念,一方面是源于有了足够的工具化积累;另一方面是想换一种思路做运维,培养产品观,站在用户的角度思考问题, 让处于后端的运维工程师主动挖掘需求,围绕运维做更多的探索,提升团队技术能力,解决海量用户带来的问题。

有了这个想法,就需要将无形的技术转变为有形的产品形态,同时要赋予它好的寓意。我们的产品取名为HULK——绿巨人,意在让小伙伴们借助巨人的肩膀成长,轻点鼠标,运筹帷幄。

想到做这个平台,源于对实际工作需求的观察。产品经理有了创新点之后,开发工程师就想以最快的速度上线,但又会很痛苦,因为产品就好比宝塔明珠,塔基需要一 层层地盖。而开发工程师是与运维工程师合作最紧密的兄弟,“兄弟有难得拔刀相助”,因此我们明确了开发工程师就是运维平台的用户,运维工程师在平台的建设 中扮演了多重角色,是建设者也是使用者,但目标是为用户解决问题,让我们的用户有极致的用户体验。

基于这些想法,我们勾画出了宏伟蓝图,提供一个塔基,第一层提供核心基础服务,如Web、RDB、NoSQL等;第二层提供通用基础服务,构造一个完美的平台,让开发工程师受益。但勾画的平台功 能大而全,需求都是我们替用户假想的,这样做的后果就是进展缓慢,但做出的功能没人用。我们在失败中反思,意识到需求还得从日常工作中去挖掘,平台上每个功能模块都必须解决用户的痛点。互联网精神唯快不破,要围绕“快”找痛点。早期开发和运维的合作中,更多的是邮件、IM及当面沟通,跨团队的沟通成本是第 一个痛点。初期平台建设中,我们从加速流程开始进行摸索,以“需求任务流”为核心,将通用需求规范流程,统一需求提交页面,同时尽量为用户提供选项,而不是随意填写,尽量减少沟通成本,同时为完全自动化打好基础。由于完整的自动化流程开发成本比较高,初期我们还“投机取巧”,用户提交需求以后,只是把格式 化的邮件发送给运维工程师。运维工程师使用半自动化工具干活,完成后再通过平台任务流告知用户结果,手工操作的部分是隐藏在平台后面的,用户不得而知。就 用这种方式,我们的平台积累了不少用户和口碑。之后我们将日常需求分层、分类:主机类包括主机申请、账号授权、软件部署等;Web类包括配置文件管理、域名管理等;DB类包括建库、建表、SQL审核、授权等。再攻克技术难点将一个个需求实现完全自动化,点点鼠标解决问题。

关于需求任务流,还有个小插曲,标准的任务流由提交、审核、驳回/通过组成。但这个流程太死板,例如用户提交的一个需求,在审核的过程中有待商榷,运维工程师会和开发工程师 沟通,最终达成一致意见即可,而如果按标准流程需要驳回再提交。为了让用户少一次操作,我们增加了管理员可编译功能。有些同事反对这样做,觉得不符合常 理。不过有时候常理是需要结合实际场景打破的,就为了让用户使用更简单。

近期为了进一步提升项目试错阶段的速度,我们在平台上推出了一个新功能:“项目孵化器”。以典型的Web业务为例,以往,申请Web Server、账号、数据库实例、负载均衡等是提给运维最基本的需求,每一步都是时间成本。使用“项目孵化器”可以最大限度解决这个痛点,只需在平台上进 行两个步骤:第一步填写业务名称,预估峰值QPS;第二步选用MySQL、MongoDB、Redis等相关数据库资源。两步之后,Web Server、数据库实例等所需资源会瞬间展示在用户面前,同时包管理、配置文件管理、代码发布系统、监控系统等配套辅助功能随之开通。

与之前的模式相比,效率和规范化都有明显提高。说起来很神奇,但实现理念很简单,我们提炼日常项目中的通用方案,构建资源池,在项目发展初期最小量匹配资源。在孵化器的设计阶段,我们听到了很多不同的声音。例如,让用户填信息不够全面,架构太简单不满足全部需求,诸如此类问题,让人头痛欲裂。经过过往项目 分析及用户调研,发现项目尚处于试错阶段,快速试错是首要需求。至于项目发展中衍生出来的需求,可以再用平台扩展功能去解决。

当利用孵化器建立一个试错项目之后,用户进入平台想看见什么?展现形式如何?还能做什么?这些问题随之而来。

众所周知,项目中的关联关系是个复杂的问题,解决不好,就像一盘散沙无法联动。为了解决此问题,首先我们确定平台各功能模块以项目名为主键,将项目的域名、负载均衡、Web Server、数据库、通用基础服务等相关联。项目后期各功能模块的扩容可以借助关联关系自动化完成。例如增加一台Web Server,即可自动部署软件环境,完成相关节点授权、上传代码、测试上线。

展现形式上我们借鉴社交网站的实现方案,以“我的项目”为中心,用户进入平台以后默认页展示项目在平台中用到的各功能模块信息,例如域名、主机数量、数据库实例和监控指标等。做到信息清晰可见,操控简单易用。

在平台建设中,我们一直遵循两个准则:第一,把事情由复杂变简单;第二,给用户极致的用户体验。所谓极致,就是要超出用户的预期,但只有挖掘用户潜在的需求,才能做出超出预期的功能。传统的运维模式,大多是开发工程师提需求,运维工程师满足需求,运维工程师主动推进的意识不够。360的文化中有很重要的一点是Ownership,一个项目的成功与失败,运维工程师是有责任的,因此需要在日常工作中时刻提醒自己“这个项目是我的,为了让项目变得更好,我们需要主动思考,为开发工程师提供更多的增值服务”。例如一个项目上线前,会默认部署日志收集模块,收集汇总后进行访问日志自动化分析,以时间维度展示访问量走势,同时辅以IP地址分析模块展示地域及运营商分布。同时基于访问日志状态码做进一步的页面分析,然后以日、周、月维度生成一份体检报告,以及应对方案推送给开发工程师。这些增值服务是超出预期的,拉近了开发工程师和我们的距离,一起去探讨、改进,做出更多有利于项目发展的功能。

结束语

运维工作在一家公司中至关重要,但传统的运维模式一定程度上限制了运维工程师的技术发展,更抑制了创新思维,我们需要利用运维“宽泛技术”定位的优势开拓思路。例如运维工作需要和很多开发团队合作,协助架构设计,在这个过程中会接触到很多开发团队的技术积累,可以把各家之所长进行聚合,将一些基础服务进行平台化改造,资源共享。也可以根据项目的需要,主动做技术研究,将基础服务做成一个个小产品,提供给开发团队使用,帮助项目缩短研发周期,稳定发展。在当今技术背景下,运维工程师应该在红海中寻找蓝海的思维模式,培养产品观,由外至内地思考,突破传统运维的壁垒,开拓创新。