写在前面的话
如今很多人认为devops将彻底取代传统运维，我不这么认为，在我看来devops只是很大程度上的代替了传统运维的手工操作，运维人员只需写好自动化运维脚本，利用自动化工具（zabbix，elk，ansible等）就可以实现自动发布和监控，省去了很多人力。因此Devops能否顺利落地，运维平台的建设将会很重要。本文主要简单介绍下我司的三大运维平台。
运维职责
运维平台
当前我司运维平台主要有3个：
持续集成和交付
①基于Jenkins持续构建
②支持容器化打包和部署
③发布平台，支持灰度发布，异常快速回滚
监控告警平台
①完善的监控体系：覆盖机器、网络、服务和客户设备维度
②快速的异常发现和告警
③灵活的告警通知方式：LCP、邮件、微信、电话
问题定位平台
①基于ELK实现日志采集、上报、告警
②采集软件平台所有组件的运行日志
③通过调用链分析和定位设备问题
持续集成和交付
持续集成(CI)，微服务组件全部改造成容器化部署，并通过K8S实现编排。
持续交付(CD)，做一个版本发布平台：支持灰度、蓝绿发布、版本回滚。
监控平台
公司之前一直使用的是zabbix+grafana的监控方式，随着我们的微服务推行容器化后，k8s应用的监控需求增加，Prometheus会更适合容器的监控。另外，Prometheus用的就是自研的 TSDB，Zabbix 则用的是 MySQL 或 PostgreSQL，在高并发的情况下，时序型数据库读写性能是远高于关系型数据库的，同时还提供了很多内置的基于时间的处理函数，简化数据聚合的难度。因此我们现在也逐步将Zabbix迁移到Prometheus。目前监控平台采集覆盖基础资源38项，102个组件、9项业务监控。
问题定位平台
背景：线上用户反馈设备使用异常，研发或QA介入排查，经常出现问题定位时间太长，问题反馈不及时，客户体验较差。因此需要开发一个问题定位平台，聚合一些设备日志和监控数据进行分析，缩短研发定位时间。
模块涉及到主要概念
•Flow：表示处理问题的流程
•Action：表示Flow中需要执行的操作，是有序的，是在程序中封装好的对数据源的小粒度操作
•Situation：用户定义的问题场景，用于描述该问题场景下日志的分析规则
situation由用户创建，在查询时需要指定该参数，会根据situation中的规则分析出请求日志之间的顺序。
平台演示
后记
这三大运维平台用的都是开源系统，总共有12个系统，Sonar、Jenkins、Ranche、Consul、ELK、Admin-Service、Zabbix、Prometheus、Smokeping、Grafana、Skywalking、Jumpserver。后续会基于Jenkins开发一个Devops集成平台，将这些系统进行整合，以便更好地支持前端业务交付。
