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. 产品、研发部门的数据支持、支援加强。