一、运维分类
基础运维：IDC、上架服务器、网络
应用运维：Web
运维开发：运维工具开发、系统开发
监控组：服务器监控、网络流量、网站访问量监控
二、运维架构
1）硬件标准化——包括服务器、内存、系统版本等 —》Cobbler
2）软件标准化——应用软件版本 —》Puppet
3）运维自动化——包括监控、发布、CMDB。
三、自动化运维
把运维中大量日常重复性工作使用工具让其自动运行，减少人的参与。
1）监控报警——系统数据，应用指标的监控，和出错时及时报警。
2）发布系统——代码发布，发布后的检查，代码的回滚，灰度发布。
3）服务器标准化——Cobbler装机加上Puppet，可以做到硬件、软件的标准化。
4）CMDB——配置管理数据库，存储了所有运维相关数据，包括服务器硬件信息、域名和服务器的关系、IDC容量等。它是运维的心脏，所有的系统都依赖于它。
四、监控系统的理想化模样（选择zabbix的理由）
1、监控数据收集及可视化
1）监控系统能够自定义监控的内容，可以自己写脚本来收集需要的数据——Zabbix支持任何自定义的监控脚本，只要输出需要的值就可以。
2）数据要保存在数据库中，这样以后需要的时候可以对这些数据进行分析计算——Zabbix在数据库中的表结构虽然有些复杂，但逻辑很清晰。
3）能够方便、快速地将监控加入到服务器上，不需要烦琐的操作——Zabbix的模版可以方便地将一组Item进行统一操作。
4）数据可视化不要很花哨，但要直观好用——Zabbix每一个Item都可以看到其历史，Web界面可拖动，界面友好。
2、异常数据报警
1）可以定义复杂的报警逻辑，可以做到Item之间的关联报警，而不是只能针对一个——Zabbix强大的Trigger定义，几乎可以满足所有规则组合。
2）报警需要被确认，让运维人员知道多少报警已经有人认领并开始处理了——Zabbix对于报警，有ACK机制。
3）报警方式要能够自定义，可以发邮件和短信，如果能够在IM上通知别人就更好了——Zabbix支持邮件，Jabber。
4）报警内容要可以自行设置，在报警邮件中加入一些简单的分析，而不是让运维人员上服务器敲命令来获取基本的信息——Zabbix自定义了一套宏可以在报警邮件中引用，如果要更复杂的功能，可以通过远程调用命令实现。
5）报警后可以自动跑一些命令。这些命令可以是获取需要的信息，也可以是自动修复，比如重启服务等——触发报警后，Zabbix可以远程调用命令实现。
3、和其他系统协同工作
1）有强大的API可以使用，可以让其他系统调用完成工作——Zabbix支持RestAPI，几乎所有的操作都可以通过API实现。
2）监控数据是开放的，数据库中的数据结构不要太复杂，让人无从下手——监控数据就在Zabbix数据库中，可以方便地进行分析。
3）监控可视化的图可以方便地引用，而不是要用一大串JavaScript——Zabbix使用PHP原生的绘图模块，如果要引用Zabbix的图表，只需要引用图表的URL即可，非常方便。
五、Zabbix名词
- Zabbix Server：Zabbix的控制中心，收集数据、写入数据库都是它的工作。
- Zabbix Agent: 部署在被监控服务器上的一个进程，负责和Zabbix Server交互，执行命令。
- Host：广义上的服务器，大多数情况指代的是刀片机这类，在少部分时间会指代包括交换机在内的，被Zabbix监控的实体。
- Item: 对于某一个指标的监控，对应的是Items，比如某台服务器的CPU负载就是一个Item。
- Trigger: 一些逻辑规则的组合，它有三个值：正常、异常、未知。
- Action: 当Trigger符合某个值的时候，Zabbix会进行的操作，比如最常见的发邮件。