基于AWS的公有云运维体系构建

  从去年起接触AWS，开始接触运维行业。别人都是从运维转软件开发，我这也算是不走寻常路。 介绍下我们项目的北京，我们是从无到有的构建自己公有云环境。在这之前团队成员都没有运维相关经验。开始摸索之路后，主要基于以下几点构建运维能力：

  1、系统监控防护能力

   亚马逊的天然优势就是集成众多服务，在监控方面亚马逊的服务是cloudwatch。通过cloudwatch监控EC2、RDS、Redis等服务基础指标，然后根据业务需要，定制个微服务节点的监控指标。实现全方位运维监控。这部分的业务监控指标，值得说明，本身就是个devops的过程。通过不断记录，逐步完善。

  2、用户体验分析

   这部分刚开始起步做的比较简单。作为云服务运维，这部分也一直被推崇为运维行业的增值点。让运维从幕后走向台前。这部分基础使用的工具大家也都比较熟悉——ELK。这个基本概念就不用给大家介绍了。由于整个团队运维人力有限，当时做了一个最基础版本。没有数据采集，数据都是导入到ELK上做结构化，然后进行分析。最基础的就是分析服务请求，分析上线用户数，最活跃租户，最活跃服务。今年部署了全新版本，基于filebeat采集数据，实现了用户数据的实时分析。这部分本身对故障定界也有关键意义。日志数据本身就有很多方面的价值。

  3、故障定界

    定界定位，这也算是和传统运维的一大差异。接触了互联网才知道，我们原有的运维团队更像是开发团队内修复BUG的一群人。其实和互联网概念的运维完全不是一回事。可传统一个BUG的修复，这群人要做什么呢。需要看日志，取dump，打堆栈无非就这几种方法。新模式下，我们引进了APM工具，dynatrace。通过dynatrace可以看到每一个请求的调用路径。说白了故障其实无非有三种：1）调用耗时长 2）调用频率高 3）调用出错了。这些通过APM可以简单看到具体代码，就可以直接发给开发进行修改了。当然这个里面也有很多坑，我会单独写个篇章介绍APM；

   4、自动化部署与灰度发布

   讲到运维， 现在要不说点自动化。给人感觉就一个字 low.所以我们这个肯定要做一部分。首要解决的问题就是安装部署。一个集群提供服务，几十台主机。测试、准生产、生产各个环节一套下来，恐怖运维就不用干别的了。对于我们这些开发出身的人员，太浪费。所以我们基于亚马逊的opswork实现了一套自动化升级框架。也以此构建了灰度发布的能力。

     5、弹性伸缩

     这个意义就在于在业务需要的时候长节点出来，业务不需要的时候减节点下去。亚马逊有提供的天然机制。opswork和autoscaleing。不过现在想来其实别的云平台做一套这玩意应该也不难。