运维系统化

在 上张贴 由 ddy4633

系统化运维

  • 工具化

  • 自动化

  • 智能化

运维工作工具化

工具化：

  • 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天清理删除

发表评论