运维人员须要有产品观

摘要

        运维工程师要掌握硬件、软件、操做系统、开发等多方面的知识，核心目标是为亿万用户使用的产品保驾护航。运维工程师应该在红海中寻找蓝海的思惟模式，培养产品观，由外至内地思考，突破传统运维的壁垒，开拓创新。

 

       在不少“外人”的眼中，运维工程师的工做不过是搬机器、调网络、装软件、处理故障、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地址分析模块展现地域及运营商分布。同时基于访问日志状态码作进一步的页面分析，而后以日、周、月维度生成一份体检报告，以及应对方案推送给开发工程师。这些增值服务是超出预期的，拉近了开发工程师和咱们的距离，一块儿去探讨、改进，作出更多有利于项目发展的功能。

 

结束语

       运维工做在一家公司中相当重要，但传统的运维模式必定程度上限制了运维工程师的技术发展，更抑制了创新思惟，咱们须要利用运维“宽泛技术”定位的优点开拓思路。

      例如运维工做须要和不少开发团队合做，协助架构设计，在这个过程当中会接触到不少开发团队的技术积累，能够把各家之所长进行聚合，将一些基础服务进行平台化改造，资源共享。也能够根据项目的须要，主动作技术研究，将基础服务作成一个个小产品，提供给开发团队使用，帮助项目缩短研发周期，稳定发展。在当今技术背景下，运维工程师应该在红海中寻找蓝海的思惟模式，培养产品观，由外至内地思考，突破传统运维的壁垒，开拓创新。