运维工作内容分类：个人理解级别从低到高
1).机房运维（负责服务器上下架、IP配置与划分、服务器打标签、机房定期巡检、服务器故障报修、服务器硬件监控)
2).基础设施运维（系统安装初始化、网络维护）
3).监控运维（7×24运维值班、简单故障处理、通知相关业务负责人）
4).基础服务运维（包含运维开发）（内部DNS管理、负载均衡配置、系统监控报警、硬件资产管理平台、监控平台搭建、代码发布平台）
5).应用运维（精通公司业务、各种服务系统部署、业务系统部署、版本管理、灰度发布、应用监控）
6).系统运维（架构层面的分布式缓存、分布式文件系统、日志收集与分析、业务环境规划（测试、开发、生产）、业务架构设计与规划实施、服务器系统性能调优）
7).安全运维（关键程序包更新、整体的安全方案、规范、漏洞监测、安全防护、漏洞扫描与修补等）
二：运维的发展线路：
1).搭建服务–可以安装服务并运行，由于是参加工作没有相关服务安装和部署经验，所以此阶段的主要目的是可以把服务安装并可以运行起来。
2).用好服务–适当对服务优化，工作一两年后可以根据业务的实际需求对服务做适当的优化，比如可以对nginx做调优和监控。
3).自动化–自动化服务的部署或监控，工作三到五年后可以结合自动化部署工具或编写脚本实现业务的自动化部署。
4).产品设计（如何设计一个监控系统），可以根据需要设计和部署大型业务系统，现在很多公司都在用云服务，比如阿里云、Amazon的AWS，微软的Azure，以及腾讯云、青云等等各种云计算，但是 云
计算的核心竞争力是运维，其始终离不开运维对业务的技术支撑，比如搭建云服务时的服务器选型、网络规划、物理机系统部署与优化、监控系统的安装等等。
三：自动化运维之运维标准化
1.物理设备层面：
1).服务器标签化（IP地址/与交换机接口/当前服务/）、设备负责人（管理人）、设备采购详情（保修日期）、设备摆放标准（服务器之间间隔1U通风）。
2).网络划分、远程控制卡、网卡端口。
3).服务器厂商机型号同一、硬盘大小转速同一、内存统型号大小频率一、服务器课根据业务分类，有的要求IO高（存储服务器），有的要求内存大（缓存服务器），有的要求CPU块（代理服务器），有 的对CPU和IO要求CPU和内存都高（数据库服务器）。
4).资产命名规范、编号规范、类型规范。
5).监控标准（统一阈值和监控类型）。
2.操作系统层面：
1).操作系统版本（不要混合使用linux和windows,linux发行版尽量统一）
2).系统初始化（IP、网关、掩码、DNS、NTP、内核参数调优、rsyslog、主机名规范、任务计划）
3).基础Agent配备（Zabbix Agent、Logstash Agent、Saltstack minion）
4).系统监控标准（CPU使用率、内存使用率、硬盘使用率、IO延时、网络状况、进程数与僵尸进程、运行时间等）
3.应用服务层面：
1).Web服务器选型（LNMP/LAMP/Tomcat/MySQL）
2).进程启动用户身份及目录、端口监听规范、日志收集规范（访问日志、错误日志、运行日志、系统日志）
3).配置管理（配置文件规范、脚本规范）
4).架构规范（Nginx+Keepalived、LVS+Keepalived等等）
5).部署规范（位置、包命名等）
4.运维操作层面：
1).机房巡检流程（巡检周期、巡检内容、硬件报修流程）
2).业务部署流程（先在开发环境和测试环境测试、最后后在生产环境部署、如出现问题立即回滚、出现问题先回滚再修复）
3).故障处理流程（紧急故障处理、故障升级流程及时间、重大故障管理、责任分配）
4).工作日志标准（如何编写工作日志周报、月报）
5).业务上线流程（1.项目发起人 2.系统安装部署优化 3.部署Nginx及相关访问 4.备案及解析域名 5.上线测试 6.对服务和主机加监控 7.数据定期备份）
6).业务下线流程（谁发起，下线时间，服务器和数据如何处理。）
7).运维安全规范（密码复杂度、更改周期、VPN使用规范、服务登录规范、命令使用规范、备份还原规范）
运维标准化实现业务规范化和流出啊，最终达到文档化的目的，即所有和业务相关的都有文档可查，包括技术文档、故障文档等，也不会导致因为某员工离职而导致业务无法继续。
四：自动化运维之工具化：通过相关运维工具，替代需要人工需要多次执行单一的工作内容，如：
1).Shell或Python脚本（简单功能配置或修改的脚本，如自动修改配置文件、流程执行的脚本，如需要先修改完配置文件才能重启服务、检查性，如检查配置文件是否修改，日志是否生成、报表性的脚本，如生成自定义数据的文本文档并自动发送到邮箱）
2).开源监控工具：Zabbix ELKStack SaltStack Cobbler
3).开源部署工具：cobbler等
运维工具化带来的好处：
1).促进标准化的实施
2).将重复的操作，简单化
3).将多次操作，流程化
4).减少人为操作的低效和降低故障率
运维工具化遇到的问题：
1).你至少要ssh到服务器执行。可能犯错
2).多个脚本有执行顺序的时候，可能犯错。
3).权限不好管理，日志没法统计。
4).无法避免手工操作。
例子：比如某天某台Web服务器磁盘可能发生问题，要在访问量较低的凌晨要将服务器的数据导出来放在其他服务器替代，那么需要考虑的是：
1).是否有由其他服务器连接此服务器取数据或此服务器是否到其他服务器取数据。
2).此服务器是否有定时任务计划到其他服务器执行或有其他服务器连接到此服务器执行。
3).任务计划索要涉及的内容，以及停服务是否影响其他服务器。
4).后续的代码更新问题。
五：自动化运维之web化
公司基于php等语言自己开发的可以在web通过鼠标点击就能实现代码发布和回滚等功能的web界面的操作平台。
1).招聘开发运维做成Web界面。
2).web界面的登录权限控制。
3).操作日志记录。
4).一键部署所有指定服务器，弱化操作流程。
5).不用ssh到每台后端服务器，减少人为误操作的故障率。
例如：
1).DNS Web管理 bind-DLZ
2).负载均衡Web管理
3).Job管理平台
4).监控平台 Zabbix
5).操作系统安装平台
六：自动化运维之服务化（API化）
1).DNS Web管理 ———->bind-DLZ dns-api（bind）
2).负载均衡Web管理——>slb-api（haproxy、LVS、Nginx）
3).Job管理平台————->job-api（php自主开发）
4).监控平台 Zabbix ——->zabbix-api（zabbix、nagios、cacti）
5).操作系统安装平台——>cobbler-api（cobbler、kickstack）
6).部署平台——————>deploy-api（安装服务软件nginx+php）
7).配置管理平台————>saltstack-api（saltstack、ansible）
8).自动化测试平台———>test-api（自主开发测试）
通过调用相关api实现服务器从系统安装到上线完全自动化：
1).调用cobbler-api自动安装指定的操作系统
2).调用saltstack-api进行系统初始化和配置
3).调用dns-api 解析域名和主机名
4).调用zabbix-api 讲该新上线机器加上监控
5).再次调用saltstack-api 部署访问软件（安装Nginx+PHP,Tomcat,Mysql）
6).调用deploy-api 将当前最新稳定版本的代码部署到服务器上的指定目录。
7).调用test-api 测试当前服务运行十分正常，如有异常，则执行报警等操作
8).调用slb-api 将该节点加入集群
七：自动化运维之智能化：
能根据一定的策略或条件，智能化的自动化扩容、缩容、（服务降级、故障自修复），包括自动发布代码加进负载集群等一些列操作
触发:指的是触发事先定义的一个阈值，可能是CPU使用率80%，也可能是并发超过100000，也可能是web访问响应时间超过5s，这是一个触发机制，然后要定义要做的决策，如：
1).当某个集群的访问量超过最大支撑量，比如10000
1.1 CPU使用率达到xx% 内存使用率达到xx% 响应时间> x秒
2).此状态已经持续5分钟。
3).判断不是攻击
4).扩张资源池有可用资源
4.1).当前网络带宽使用率
4.2).如果是公有云——钱够不够
5).当前后端服务支撑量是否超过阈值 如果超过应该后端先扩容
6).数据库是否可以支撑当前并发
7).当前自动化扩展队列，是否有正在扩容的节点
8).其它业务相关的。
自动化扩容机制：
1).扩容之前：先判断Buffer区域是否有最近x小时，已经移除的之前创建的虚拟机，并查询软件版本是否和当前一致，如果一致，跳过 2 3 4步骤，如果不一致，跳过2 3。
2). OpenStack 创建虚拟机
3). Saltstack 配置环境—-监控
4). 部署系统部署当前代码
5). 测试服务是否可用（注意间隔和次数）
6). 加入集群
7). 通知（短信、邮件）
自动化缩容机制：
1).触发条件和决策
2).从集群中移除节点-关闭监控-移除
3).通知
4).移除的节点存放于Buffer里面。
5).Buffer里面超过1天的虚拟机，自动关闭，存放于xx区
6).Buffer区的虚拟机，每7天清理删除。
转自：http://blogs.studylinux.net/?p=151