运维与自动化运维发展概括

1、运维自动化发展 运维学习和发展的一个线路： 1.搭建服务（部署并运行起来） 2.用好服务（监控、管理、优化） 3.自动化（服务直接的关联和协同工作） 4.产品设计（如何设计一个运维系统） -----当下云计算的核心竞争力是运维！ 系统架构师（偏管理）：网络 系统 数据库 开发 云计算 自动化 运维管理 服务管理 项目管理 测试 业务 -----专注于某一领域

2、运维自动化发展 运维工作内容分类： 监控运维（7x24运维值班、故障处理） 应用运维（业务熟悉、服务部署、业务部署、版本管理、灰度发布、应用监控）

安全运维（整体的安全方案、规范、漏洞检测、安全防护等）

系统运维（架构层面的分布式缓存、分布式文件系统、日志收集、环境规划（测试、开发、生产）、架构设计、性能优化） 基础服务运维（包含运维开发）（内部dns、负载均衡、系统监控、资产管理、运维平台）

基础设施运维（系统初始化、网络维护、负责设备上下架、巡检、报修、硬件监控）

3、运维自动化发展 标准化： 物理设备层面： 1.服务器标签化、设备负责人、设备采购详情、设备摆放标准 2.网络划分、远程控制卡、网卡端口 3.服务器机型、硬盘、内存统一。根基业务分类 4.资产命名规范、编号规范、类型规范 5.监控标准 操作系统层面： 1.操作系统版本 2.系统初始化（dns、ntp、内核参数调优、rsyslog、主机名规范） 3.基础agent配置（zabbix agent、logstash agent、saltstack minion） 4.系统监控标准（cpu、内存、硬盘、经常） 应用服务层面： 1.web服务选型（apache、nginx） 2.进程启动用户、端口监听规范、日志收集规范（访问日志、错误日志、运行日志） 3.配置管理（配置文件规范、脚本规范） 4.架构规范（nginx+keepalievd、lvs+keeplievd） 5.部署规范（位置、包命名等） 运维操作层面： 1.机房巡检流程（周期、内容、报修流程） 2.业务部署流程（先测试、后生产、回滚） 3.故障处理流程（紧急处理、故障升级、重大故障管理） 4.工作日志标准（如何编写工作日志） 5.业务上线流程（1.项目发起2.系统安装3.部署应用4.解析域名5.测试6.加监控7.备份） 6.业务下线流程（谁发起，数据如何处理） 7.运维安全规范（密码复杂度、更改周期、V**使用规范、服务登录规范） -----目标：文档化

4.运维自动化发展 工具化： 1、shell脚本（功能性（流程）脚本、检查性、报表性） 2、开源工具（zabbix、elkstack、saltstack、cobbler） 目标：1、促进标准化的实施 2、将重复的操作，简单化 3、将多次操作，流程化 4、减少人为操作的低效和降低故障率 工具化和标准化是好基友 痛点： 1、至少要ssh到服务器上执行，可能犯错 2、多个脚本有执行顺序的时候，可能犯错 3、权限不好管理，日志没法统计 4、无法避免手工操作 例子：比如某天我们要对一台数据库从库进行版本停机升级，那么要求进行评估 统计影响：晚上3点有定时任务连接该数据库，做数据报表统计 1、凌晨3点我们所有系统的定时任务有哪些 crontab 2、这些crontab哪些连接我们要停止的从库 3、哪些可以停，哪些不能停（修改到主库），哪些可以后补 4、这些需要后补的脚本哪个业务、谁加的、什么时候加的

5.运维自动化发展 web化

运维平台： 例子： 1、做成web界面 2、权限控制 3、日志记录 4、弱化流程 5、不用ssh到服务器，减少人为操作造成的故障 dns web 管理 bind-DLZ 负载均衡web管理 job管理平台 监控平台 zabbix 操作系统安装平台 6.运维自动化发展 服务化（api化） dns web 管理 bind-DLZ dns-api 负载均衡web管理 slb-api job管理平台 job-api 监控平台 zabbix zabbix-api 操作系统安装平台 cobbler-api 部署平台 deploy-api 配置管理平台 saltstack-api 1、调用cobbler-api安装操作系统 2、调用saltstack-api进行系统初始化 3、调用dns-api 解析主机名 4、调用zabbix-api该新上线机器加上监控 5、再次调用saltstack-api部署软件（nginx-php） 6、调用deploy-api将当前版本代码部署到服务器上 7、调用test-api 测试当前服务运行是否正常 8、调用slb-api将该节点加入集群 7.运维自动化发展 智能化

智能化的自动化扩容、缩容、服务降级、故障自愈 触发机制-》决策系统（决策树）-》 1.zabbix触发Action 触发： 1、当某个集群的访问量超过最大支撑量，比如10000 1.1、cpu使用率达到xx。内存使用率达到xx 2、当持续5分钟 3、不是攻击 4、资源池有可用资源 4.1、当前网络带宽使用率 4.2、如果公有云--钱够不够 5、当前后端服务支撑量是否超过阈值，如果超过应该后端先扩容 6、数据库是否可用支撑当前并发 7、当前自动化扩展队列，是否有正在扩容的节点 8、其他业务相关的 之前：先判断buffer是否有最近x小时，已经移除的之前创建的虚拟机，并查询软件版本是否和当前一致，如果一致跳过2、3、4步骤，如果不一致掉过2、3步骤 2.openstack 创建虚拟机 3.saltstack 配置环境--------》监控 4.部署系统部署当前代码 5.测试服务是否可用（注意间隔和次数） 6.加入集群 7.通知（短信、邮件） 自动化缩容： 1.触发条件和决策 2.从集群中移除节点----》关闭监控--》移除 3.通知 4.移除的节点存放在buffer里面 5.buffer里面超过一天的虚拟机，自动关闭，存放于xx区 6.xx区的虚拟机。每七天清理删除

8. 运维自动化发展 基于ITIL的运维管理体系 成为一名运维经理： 技术： 运维知识体系 除了技术： 1.服务管理 ITIL 2.项目管理 PMP 做人