今天分享专题大纲如图所示，从5个方面跟你们一块儿探讨:html
一、点评运维团队的配置
目前咱们运维分为4个组，相信跟大部分公司同样，运维团队分为：应用运维、系统运维、运维开发和监控运维，固然还有DBA团队和安全团队，这里就不一一罗列了。整个运维团队全算上目前是不到40人规模。java
咱们团队分工是这样的：python
应用运维：负责支持线上业务，各自会负责对应的业务线，主要职能是保证线上业务稳定性和同开发共同支撑对应业务，以及线上服务管理和持续优化。nginx
运维开发：帮助运维提高工做效率，开发方便快捷的工具，实现运维平台化自动化。web
系统运维：负责操做系统定制和优化，IDC管理和机器交付，以及跳板机和帐号信息管理。算法
监控运维：负责发现故障，并第一时间通知相关人员，及时处理简单故障和启动降级方案等。docker
二、点评的总体架构
先看下点评的机房状况。shell
点评目前是双机房结构，A机房主跑线上业务，B机房跑测试环境和大数据处理做业，有hadoop集群、日志备份、灾备降级应用（在建）等。点评目前机房物理机+虚拟机有近万台机器。vim
点评的总体架构，仍是跟多数换联网公司同样，采用多级分层模式，咱们继续来详细看下点评总体架构。后端
上面这幅图基本归纳了点评的总体架构环境：
用户引导层用的是第三方的智能DNS+CDN。
负载均衡首先是F5作的4层负载均衡 以后是dengine作的7层负载均衡（Dengine是在tengine基础上作了二次开发）。再日后是varnish作的页面缓存 以后请求到web端 web端经过内部协议调用service（RPC）。
图片存储用的是mogileFS分布式存储 。
全部业务，所有有高可用方案，应用所有是至少2台以上。
固然，具体业务要复杂不少，这里只是抽象出简单层面，方便各位同窗理解。
目前，点评运维监控是从4个维度来作的：
业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、建立订单等（cat）。
应用层面，每一个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等（cat）。
系统资源层面：如cpu、内存、swap、磁盘、load、主进程存活等 （zabbix）。
网络层面： 如丢包、ping存活、流量、tcp链接数等（zabbix cat）。
三、点评运维系统介绍
点评的运维和平台架构组作了不少实用的工具，这些工具组成了点评的总体运维体系。
目前自动化运维比较热，但自动化运维我的以为是一种指导思想，不必硬造概念和生搬硬套。自动化在不少公司百花齐放，各家有各家的玩法。但无论怎么定义，运维人员都必须从不一样纬度去面对和解决企业所存在的问题。
点评在这方面，也是摸着石头过河，咱们的思路是先造零件，再整合，经过零件的打造和之间的整合，慢慢勾勒出一条适合本身的运维自动化框架。
咱们运维的理念是：
能用程序干活的，坚定程序化、平台化；
能用管理解决的问题，不用技术解决；
同一个错误不能犯三次；
每次故障，都是学习和提高的机会；
每一个人都要有产品化思惟，作平台产品让开发走自助路线；
小的，单一的功能，组合起来完成复杂的操做（任务分解）；
因此，咱们将本身的理念，融入到本身的做品中，作出了不少工具。
首先总体作个说明，点评运维工具系统汇总：
全方位监控系统：覆盖业务、应用、网络、系统等方面，作到任何问题，均可直观反馈。对不一样应用等级，作到不一样监控策略和报警策略。
自动化工具系统：对重复的、容易出错的、繁琐的工做尽量工具化，经过小的策略组合，完成大的任务。
配置和管理系统：对于复杂的配置管理，尽量web化、标准化、简单化，有模板定义，有规范遵循。
记录和分析系统：对发生的问题和数据作记录并分析，不断的总结、完善和提高。
下面就跟你们来一一介绍下:
3.1 全方位监控系统
Zabbix你们应该很是熟悉了，这里就不作介绍，主要介绍下cat监控。
这张是cat的应用监控图表，可直观从业务角度看出问题，可跟基线的对比，发现问题所在。如图所示，此时支付远偏离基线，流量正常，可能后端出了问题。
除了这些，还有建立订单、支付、首页访问、手机访问等业务数据。
这张图是从业务角度来监控的。
这张也是从业务层面来监控的，该图展现的是手机的访问量趋势图，下面包括延迟、成功率、连接类型、运营商等都有明确数据，该监控可全方位覆盖业务。
从业务层面往下，就是应用层面。
应用状态大盘可清晰表示当前业务组件状态，若是某个业务不可用，其下面某个应用大量报错，说明多是该应用致使。
该监控大盘十分清晰明的能展现业务下面的应用状态，可在某业务或者某域名打不开的时候，第一时间找出源头。
下图为应用报错大盘，出问题的应用会实时登榜（每秒都会刷新数据），当出现大故障时，运维人员可一眼看出问题；而当多个不一样业务同时报错时，则多是公共基础服务出了问题。
再看下图的这个功能，是Cat最强大的功能，能完整显示应用之间调用过程，作了什么事情，请求了那些，用了多长时间，成功率是多少，访问量是多大，一览无余。 Cat几乎无死角的覆盖到业务和应用层面的监控，固然还可作网络等层面监控，总之很是强大。这也是点评的鹰眼系统。
Logscan系统，是一套日志扫描工具，可根据你定义的策略，对日志内容进行定时扫描，该工具可覆盖到基于日志内容的检测，结合zabbix和cat，实现无死角覆盖。 好比有一些攻击的请求，一直遍历你的url，经过cat、zabbix等都没法灵活捕获，有了日志扫描，即可轻松发现。
3.2 自动化工做系统
首先介绍下点评的流程系统-workflow系统
顾名思义workflow是一套流程系统，其核心思想是把线上全部的变动以标准化流程的方式，梳理出来。
咱们遵循一个理念，能用程序跑，就不去人操做。
流程有不一样状态的转化，分别为发起、审计、执行、验证等环节。用户可自行发起本身的需求变动，经过运维审核，操做（大部分是自动的），验证。 如扩容、上线、dump内存、封IP等都为自动化流程。
以咱们线上自动化扩容流程为展现，用户使用时，须要填写对应信息，提交后，运维在后台审核事后，就彻底自动化扩容，扩容完成会有邮件通知，全程运维不须要登陆服务器操做。（自动化倒不是太复杂的技术难题，经过小的任务组合，设置好策略便可）. 几十台机器的扩容，运维只需点个审核经过按钮，数分钟而已。
通过长时间的推广，点评如今98%以上变动都是经过工做流平台完成的，全部变动所有有记录，作到出问题时 有法可依，违法可纠。
并且经过流程单的使用频率，可作数据分析，了解哪些操做比较频繁，可否自动化掉，是否还有优化空间。 这才是作平台的意义，以用户为导向。
流程系统就介绍到这里，朋友们可关注下其中核心思想。
下面介绍另外一套重量级核心系统：Button系统
Button是一套代码管理、打包、部署上线系统，开发可彻底自主化进行上传代码，自动化测试，打包，预发，灰度上线，所有上线，问题回滚等操做。 全程运维不用干预，彻底平台自主化。
点评的运维，除了有些无法自动化的手动配置下，其余基本都是开发自助。 这就是自动化的威力！
Go平台系统，是一套运维操做系统，其中包含了不少常规操做、如批量重启、降级、切换、上下线、状态检测等。
该系统主要是解决运维水平良莠不齐，工具又各有各的用法，好比说批量重启操做，有用ssh、有用fabric、有本身写shell脚本的。 干脆直接统一，进行规范，定义出来操做，经过平台化进行标准化。 因为长时间不出问题，偶尔出一下，运维长时间不操做，找个批量重启脚本还要找半天。 哪些不能自动化的，咱们基本都作到go里了，在这里基本都是一键式的傻瓜操做了。
如今，咱们监控团队就能够灵活操做，不须要有多高的技术含量，而且每次操做都有记录，作好审计和受权。
全部后台基本都是python、shell脚本实现，小的脚本组再整合成任务，这也是咱们的重要理念之一。 对于比较复杂的任务，咱们进行分解，而后用小的，单一的功能，组合起来完成复杂的操做（任务分解）。 其实咱们实现自动化也是这个思路，先造零件，再拼装。
尽管有了puppet，go等工具，但对于一些job做业的管理，也显得很是吃力，咱们架构组的同窗作出一套任务调度系统。至关于分布式的crontab，而且有强大的管理端。 彻底自主化管理，只须要定义你须要跑的job，你的策略，就彻底不用管了。会自动去作，而且状态汇报、监控、等等所有都有记录，并实现彻底自助化。
以上这些系统都很是注重体验，都有很是详细的数据统计和分析，每过一段时间，都有人去看，不断改进和优化，真正作到产品自运营。还有一些自动化系统就不一一介绍了。
3.3 配置和管理系统
先介绍下puppet管理系统，相信很多同窗对puppet语法格式深恶痛绝，而且也领教过一旦改错形成的故障严重性。
并且随着多人协同工做后，模板和文件命名千奇百怪，没法识别。
针对这些问题，点评就作了一套管理工具，主要是针对puppet语法进行解析，实现web化管理，并进行规范化约束。
跟go系统同样的想法，将puppet中模块进行组合，组合成模块集（方法集），可方便识别和灵活管理。
下面展现的是咱们的软负载均衡管理页面，该系统是线上SLB的管理系统。 其核心在于把nginx语法经过xml进行解析，实现web化管理，傻瓜式配置，规范化配置，避免误操做，版本控制，故障回滚等。
点评系统不少，基本上遇到个痛点，都会有人想办法把痛点解决。
下面就介绍下点评另外一套强大配置系统，lion。
Lion是一套应用配置管理系统，点评的全部应用用到的配置，不在本地文本文件存储，都在一个单独系统存储，存储以key/value的方式存储。而且也是彻底平台化，运维负责作好权限控制和审计。开发所有自助。
其核心是用了zookeeper的管理机制，将配置信息保存在 Zookeeper 的某个目录节点中，而后将全部须要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，而后从 Zookeeper 获取新的配置信息应用到系统中。
是否是在点评作运维轻松不少？各类操做都工具化，自助化，自动化了。那运维还须要作什么。
3.4 记录和分析系统
此类系统虽然不怎么起眼，但对咱们帮助也是特别大的，咱们经过一些系统的数据记录和分析，发现了很多问题，也解决很多潜在问题，更重要的是，在这个不断完善总结的过程当中，学习到了不少东西。
这个是咱们故障分析系统，全部的故障都会作记录，故障结束后都会case by case的进行深刻分析和总结。其实以上不少系统，都是从这些记录中总结出来的。
该系统为故障记录系统，每一个故障都有发生的原因和改进的方案，按期有人review。
运维起来很轻松吗？也不轻松，只是工做重点有了转移，避开了那些重复繁琐的工做，和开发同窗深度结合，共同注重运营质量和持续优化。
再来看下图所示是点评的DOM系统，即运营质量管理平台，该平台汇总了线上的服务器状态、应用响应质量、资源利用率、业务故障等全方位的数据汇总平台。
并经过同比和环比，以及平均指标等数据，让各开发团队进行平台化PK，性能差的运维会去推进改进。
最后一个须要介绍的是雷达系统，该系统是咱们最近在作的，一个比较高大上的项目。
朋友们也感觉到了，咱们系统之多，出问题查起来也比较费时。 很多同窗生产环节也遇到过相似问题，出了问题究竟是什么鬼？到底哪一块引发的呢？ 结合这个问题，咱们把线上的问题作了个分类，并给了一些策略层面的算法，能快速显示。 可以让故障有个上下文的联系，如：上线时间、请求数降低、错误数增多等，哪一个先出现，哪一个后出现？ 固然，这块功能还在作，目标是实现 出问题的时候，一眼就能从雷达系统定位问题类型和范围。
以上向你们演示的就是点评的运维系统，相信咱们点评的运维思想都在里面体现了。
运维点评这几年的发展，主要目标是实现平台规范化、运维高效化、开发自主化 。
以前也是经过运维root登陆，而后写脚本批量跑命令的低效运维。也经历过CMDB系统信息不许确，上线信息错乱的尴尬局面。也遇到过出了很大问题，运维忙来忙去，找不到rootcase。
好在，经过努力，这些问题如今都有了很大改观，相信朋友们经过展现的系统，能感受出点评运维的进步。
四、运维踩过的坑和改进的地方
我就这些年，点评运维出的一些case案例，跟你们聊一聊咱们作了哪些具体工做:
变动不知道谁作的，没法恢复，变动完也找不到根据，形成重大故障。//以前线上puppet经过vim的管理方式，因为运维同窗失误推了一个错误配置，致使所有业务不可用1个小时，咱们后面经过规范puppet配置修改并作成工具，进行权限控制，还加了流程系统，进行避免。
出了问题，开发说代码没问题，运维说环境没问题，该找谁？//咱们后面作了工具，经过DOM和cat系统，可进行深度诊断，基本很容易定位问题所属。
执行了个错误命令，全线都变动了，致使服务不可用。//咱们经过go系统，进行平常操做梳理，并作成工具，运维90%操做均可经过自动化流程和go平台完成。大大缩减故障产生率，而且以后进行权限回收。
出问题了，各类系统翻来查去，没法快速定位，找不到rootcase。//点评正在作雷达系统，就是将历史存在的问题，进行复盘，将一些故障类型，进行分级，而后经过策略和算法，在雷达系统上进行扫描，出问题环节可快速第一时间优先显示。
运维每天忙成狗，还不出成绩，每天被开发吐槽。//点评这两年彻底扭转了局势，如今是运维吊打开发，由于咱们目前，大部分系统都实现了开发自助化，运维被解放出来，开始不断完善平台和关注业务运营质量，咱们dom系统是可定制的，运维天天都把各业务的核心指标报表发到各位老大那里，哪些服务质量差，响应慢，开发都会当即去改。（固然，须要老大们支持）。
五、将来关注的领域和方向
点评也有些前沿的关注点，好比比较热的Paas技术。
PaaS和云很热，还有docker技术，点评也不能掉队，目前点评有数千个docker的实例在跑线上的业务。
上图java都是跑的docker实例
目前点评Docker这块可作到10秒内快速部署业务并可响应用户请求。30秒内可完成一次实例无缝迁移。 我的感受docker技术不在于底层这块，在于上层管理系统的构造。底层一方面是持续优化，挖掘性能，但更重要的是在策略层和调度层。 如何快速部署、迁移、恢复、降级、扩容等，作好这些还有很多挑战。
点评这两年成长不少，但须要走的路也不少，将来关注的点会在多系统的有机整合和新技术的尝试以及发展，还会更多的关注智能策略层面。
结束语
在最后结束时，感谢各位到场朋友捧场，也感谢点评运维和平台架构的每一位同事，有了大家，点评运维才走到了今天，咱们共同努力，来创造新时代的运维体系。点评不少系统都是第一次拿出跟你们分享，你们可看一下设计理念和思想。文章内容选自51CTO学院讲师马哥博客，Linux运维架构师成长之路：http://edu.51cto.com/course/course_id-3559.html
