Skip to content

2017 01 08 年终总结 运维技术实践篇

1570 字
   

2016年,运维在云计算的辟护下,捡了一波漏。对技术雷达应用,可以简单看下图,在现有知识领域内,吸取大量的成熟系统、方法与实践方案,称之为地上捡苹果的大丰收

上云的最大优势,就是能在短时期内快速实现外部成熟方案的吸收、改造并沿用与适合企业运营需求的实践。可以说运维今年业务的完成,除了员工出色与高质量的需求达成度,就是对现有成熟技术的吸纳。

捡苹果

可预见的缺陷

挂在树上的果子,仅靠运维的推动,无法获得。

最明显的表现就是数据分析

每个游戏项目,都会产生日志。打个比方,就像迪斯尼乐园一样,拥有各个游乐设施项目。每个项目虽然玩法不同,有的作大死寻求刺激,有的视觉刺激,也有的和英雄拍照,这些不同的游乐项目,在某些地方存在着共性,或者分析的指标。

比如,每个项目每日的游客数量,设施的活动开启了多少次,游客是否满意,设施日常运营开销,项目更新改进后,游客满意度是否出现变化等。

这一系列行为,转化为一条条日志,以一定形式记录在文件中,运维已经实现将所有日志入库,但后一步的分析与挖掘,出现断层。也就是架在苹果树上的梯子之一。

数据分析是个比较综合和的领域,目前公司在这方面的建设与积累可以说非常薄弱。甚至有时候,还需要求助项目部门,才能勉勉强强的需求查出来,还不一定准。

有时候我会和同事们说个梗:一群牛在产奶,奶农把牛奶运到加工厂,做奶酪、奶粉等各种奶制品,最后工厂里发现这批奶制品有问题,就去问奶农,奶农搞不定,就去问奶牛,奶牛也很绝望啊,“我产奶本来想的是喂小崽子,也没想到你们拿去搞这些东西”

正常来说,整个环节,数据分析应该是运营主动发起,并将分析数据在最快的时间:

  1. 反馈给项目组,便于项目参考数据并做出改进方案。
  2. 反馈给营销,便于营销评估渠道的投资回报。
  3. 产品自身消化,决策产品的运营节奏。

好在,今年已经把数据的种子埋下

实践分享

能很明显感受到,运维明年如果想继续成功,把自己剥掉几层皮是不可少的。毕竟今年的结果,也就是明年的日常。运维人员评估的100分里面,默认先扣掉20分,其中10分衰减是新技术成熟应用后,常态化运作的结果;还有10分衰减是探索中的技术,暂时还没有看到效果的原因,毕竟想见效,不会那么快;剩下的80分,想保住其实也挺难的,学艺不精,还需持续努力。

未成功的项目

  • DRDS 分布式关系型数据库 计划用于解决关系型数据库分析查询老大难的问题。实践3个月后放弃,根据公司发展的阶段,建议直接跳过,拥抱已经成熟的大数据分析框架。
  • 阿里云 简单日志服务 陆续上线下线多次,一直在尝试,但暂时没有找到适合的应用场景和机会,17年依旧会投入时间进行分析和可行性验证。
  • 阿里云 数加 大数据开发套件,因长期缺乏相关人员,探索一直搁置,于17年初重启测试与可行性评估。
  • CI 持续集成 Jenkins 评估测试近2个月,暂时梳理出实践与pipeline工作流,还未进行应用,但可用性和潜力大。

成功的项目

  • Git平台 Gogs 利用Gogs搭建与整合公司项目的GIT管理平台,同时打通研发、运维之间的版本交付通道。虽然某些环节用起来有点邪道,比如利用GIT来管理二进制文件,数量还不少,但总体结果来说,非常好用……对应githook和webhook的后期延展功能异常强大。
  • Ansible 运维自动化工具,批量处理服务器操作时效果好,未来将进行与Jenkins的集成,以及运维工具的整合以及运维平台的重构。
  • DataX 工具的应用 阿里的东西怎么说呢……确实很好用,处理离线数据导入或者不同DB之间数据转储神器。

2017年规划

如果说公司是个体,运维应该充当的角色是神经系统(信息通常)、血管(数据流动保障)、白细胞(避免和排除掉在公司内外部搞事情的因素)。17年主要计划是协助BI部门保障血液畅通,同时日常事务的稳定保障与服务质量提升,当然成本也要控制住。

方法和思路

  1. 抄google SRE https://book.douban.com/subject/26875239/ 学习和实践一部分内容。
  2. 产品、研发部门的数据支持、支援加强。