如今很多人认为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集成平台，将这些系统进行整合，以便更好地支持前端业务交付。