系统化运维
- 工具化
-
自动化
-
智能化
运维工作工具化
工具化:
- 1.Shell脚本(功能性【流程】脚本、检查性、报表性)
-
2.开源工具:Zabbix、Elkstack、Saltstack、Cobbler
** 目标:**
- 1.促进标准化的实施
-
2.将重复的操作 –> 简单化
-
3.将多次操作 –> 流程化
-
4.减少人为操作低效和有可能造成的故障 –> 降低故障率
总结:工具化和标准化支撑了运维的日常生活
工具化的痛点
1.至少需要SSH到服务器执行 --> 可能犯错
2.多个脚本有执行顺序的时候 --> 可能犯错
3.权限不好管理,日志没法统计
4.无法避免手工操作
例子:比如某天我们要对一台数据库从库进行版本升级,要求进行评估!
停机影响:
晚上有定时任务连接数据库,做数据报表统计
考虑问题:
- 1.凌晨3:00 我们所有的系统的定时任务有哪些 crontab
-
2.这些crontab那些连接我们要停止的从库
-
3.那些可以停止,那些不能停止(修改到主库),那些可以后补
-
4.这些需要后补的脚本那个业务,谁加的,什么时候加的
运维标准化
物理设备层面:
- 1.服务器标签化、设备负责人、设备采购详情、设备摆放标准
-
2.网络划分、远程控制卡、网卡端口
-
3.服务器机型、硬盘、内存统一。根据业务分类
-
4.资产命名规范、编号规范、类型规范
-
5.监控标准
操作系统层面:
- 1.操作系统版本
-
2.系统初始化(DNS、NTP、内核参数调优、rsyslog、主机名规范)
-
3.基础Agent配备(Zabbix Agent、logstash Agent、saltstack minion)
-
4.系统监控标准(CPU、内存、硬盘、网卡、进程)
应用服务层面:
- 1.web服务器选型(Aapache、nginx)
-
2.进程启动用户、端口监听规范、日志监听规范、日志收集规范(访问日志、错误日志、运行日志)
-
3.配置管理(配置文件规范、脚本规范)
-
4.架构规范(Nginx+Keppalived、Lvs+Keepalived)
-
5.部署规范(位置、包命名)
运维操作层面:
- 1.机房巡检流程(周期、内容、保修流程)
-
2.业务部署流程(先测试后生产,回滚)
-
3.故障处理流程(紧急处理、故障升级、重大故障管理)
-
4.工作日志标准(如何编写工作日志)
-
5.业务上线流程(项目发起->系统安装->部署Nginx->解析域名->测试->加监控->备份->调试运行)
-
6.业务下线流程(谁发起,数据如何处理)
-
7.运维安全规范(密码复杂度、更改周期、VPN使用规范、服务登入规范)
-
目最终的标:文档化
- 总结:标准化->规范化->流程化->文档化
运维操作平台
大公司Job管理平台
- 1.做成web界面 (清晰可视化管理)
-
2.权限控制 (自定义权限级别)
-
3.日志记录 (每次日志操作的记录,录像)
-
4.弱化流程 (全部写成下一步,弱化流程)
-
5.不用ssh到服务器,减少人为操作造成的故障 (提高容错率) – 堡垒机实现
功能:
DNS Web管理 bind-DLZ 插入数据库
负载均衡Web管理
Job管理平台
监控Web管理 Zabbix
操作系统安装平台
部署平台
配置管理平台
痛点:需要操作多个Web界面,略微繁琐
服务化(API)
dns-api
slb-api
job-api
zabbix-api
cobbler-api
deploy-api
1.调用cobbler-api --> 安装操作系统
2.调用saltsatack-api --> 进行系统初始化
3.调用dns-api --> 解析主机名
4.调用zabbix-api --> 将该新上线的机器加上监控
5.再次调用saltstack-api --> 部署软件(例:安装Nginx+PHP)
6.调用deploy-api --> 将当前版本的代码部署到服务器上
7.调用test-api --> 测试当前服务器运行情况
8.调用slb-api --> 将该节点加入集群
总结:集成大成为一体实现运维自动化
智能化
严格的意义上来说智能化才是自动化运维的终极目标
功能:
- 自动化扩容、缩容
-
服务降级(紧急情况下,壮士断腕)
-
故障自愈
自动化扩容
- 规划:
- 触发机制 –> 决策系统(决策树) –> 实现自动扩容
-
简单的设计:
zabbix-action --> OpenStack(私有云) --> saltstack(环境配置) --> 监控 --> 部署--> 测试(注意间隔和次数) --> 加入集群 --> 通知
实现:
触发:
1.当某个集群的访问量超过最大支撑量
(1)当前的CPU使用率达到多少,内存使用率达到多少
2.并且持续超出持续5分钟
3.不是攻击造成的
4.资源池有可用的资源
(1).当前网络宽带使用率
(2).如果是公有云--考虑钱够不够
5.当前后端服务支撑量是否超过阈值,如果超过应该后端先扩容
6.数据库是否可以支撑并发
7.当前自动化扩展队列,是否有正在扩容的节点
8.其他相关的业务
自动化缩容:
规划:
触发条件和决策 -> 集群中移除节点 -> 移除监控 -> 通知 -> 移除的节点存放于回收区 -> 超过一天关闭并存放在删除区中,每7天清理删除