自动化体系构建

方案概述

方案初衷涉及到一些工作,略过

整体方案解决体系分为三步:

  • 方案拟定、方案定型、搭建一套和目前生产环境一致的系统架构体系,用于生产测试环境,根据业务的需求进行优化配置,对测试环境进行大并发高可用性能进行测试,满足业务运营需求。
  • 复制一套体系做为生产环境,纳入上线管理,安全防护,针对管理权限进行细化,完整的生产应急响应机制,对该阶段暴露的体系问题,记录分析。
  • 对系统体系架构暴露出的问题进行分析解决,对现有的架构体系进行优化整改,完成稳定版系统架构体系定型,在此基础上实现横向扩张,自动伸缩。

目录


1.1        整体方案架构场景… 2

1.1.1         架构方案初期建设… 2

1.1.2         生产环境服务器部署配置需求… 5

1.1.3         服务器标准化版本规范… 5

1.2生产环境业务架构体系部署… 6

2.1.1 生产环境自动化测试平台构建… 6

2.1.2 生产业务服务器监控系统… 7

2.1.3 备份机制、容灾机制、业务快速恢复… 9

3.1针对不同业务进行不同的数据备份… 10

3.1.1 Web集群备份方案与负载均衡备份机制:… 10

3.1.2 MySQL集群备份机制… 11

3.1.3 Redis集群备份机制… 12

3.1.4监控系统备份机制… 13

3.1.5管理系统备份机制… 13

3.1.6 ELK备份机制… 14

 1.1       整体方案架构场景

整体方案架构图:

 

1.1.1  架构方案初期建设

  • 亚马逊云服务商解决方案建设,负责选型可用的服务方案建设,对云服务商提供的解决方案解析筛选,成本控制预算、相关费用透明化;亚马逊方案云服务提供解决方案定型,实现业务快速部署。
  • 安全防御体系建设,制定相应的解决方案,应对网络攻击采用亚马逊云提供商提供的服务方案,采用AWS waf 和 Aws shield,应对来自网络攻击,利用Amazon CloudWatch 对来自网络攻击进行实施监控,实现攻击实时告警,实时响应。
  • 亚马逊安全体系建设架构图:

 

  • 完成系统标准化规范方案,为后期自动化建设体系做基础性工作后期自动化方案架构图:

 

  • 初期环境部署系统架构解决方案图:

注:为也生产业务稳定运行,满足业务7X24小时高可用机制,所有关键性节点采用双节点方案,避免单节点故障,边缘化业务采用低配置实现双节点服务,采用高可用主从方式,为后期做自动伸缩扩张做预留方案。

整体架构图如下:

1.1.2 服务器标准化版本规范

  • 为了业务稳定运行,采用官方统一稳定版本进行部署,采用版本如下:

操作系统及应用版本:

  • CentOs CentOS 6.8
  • 数据库版本:       MySQL 5.6.36
  • Redis版本:       Redis 3.2.0
  • Nginx版本: Nginx-1.9.12
  • PHP 版本:           PHP 5.6.31
  • Tomcat版本:       5
  • Java JD版本:       Version 1.8

操作系统及应用版本

  • Zabbix 版本: zabbix 3.0
  • ELK 版本: 根据官方选择最新稳定版
  • Salt stack 版本: 根据官方选择最新稳定版

2.1 生产环境业务架构体系部署

2.1.1 生产环境自动化测试平台构建

  • 版本发布、新版本上线达到测试性能标准、输出相应的测试数据报告,针对不同的关键性指标,需要指定相应的测试机制。
  • 自动化测试环境框架筹备工作,建立初步自动化测试工具平台。
  • 自动化平台架构图:

  • 版本更新需要经过测试环境,测试完毕后,放入生产预热测试环境测试,进行相应的测试,满足相应的测试指标及周期,然后进入生产发布版本。
  • 规划测试体系投入比例:按照相应的比重进行划分单元测试、集成测试、接口测试、UI测试、自动化测试。

2.1.2 生产业务服务器监控系统

  • 制定完善的业务监控体系统,实现短信告警功能,整体监控体系架构图:

  • 根据业务制定相应的监控指标,对监控指标进行一段时间的评估期。
  • 对异常告警处理完毕后,输出相应的处理报告,对报告进行分析、评估、最后纳入公司技术文档FQA库
  • 监控告警机制及响应及处理,设定预警机制、设定报警机制、设定告警机制、故障划分、故障响应、故障分级等
  • 架构图如下:

 

2.1.3 备份机制、容灾机制、业务快速恢复

  • 针对不同业务进行不同的数据备份
  • Web集群备份机制
  • MySQL集群备份机制
  • Redis集群备份机制
  • 监控系统备份机制
  • 负载均衡集群备份机制
  • 管理系统备份机制
  • ELK系统备份机制
  • 容灾机制、数据恢复演练机制
  • 业务系统备份架构图:

3.1针对不同业务进行不同的数据备份

3.1.1 Web集群备份方案与负载均衡备份机制:

  • 规范所有服务安装目录:比如创建专用的目录用于存放安装对应的软件服务
  • 备份对应的配置文件,实现本地压缩打包,同步到备份服务器进行数据备份及MD5值校验,防止被篡改。
  • 备份机制实现每天凌晨1点全量备份,如手动更改配置文件时,需要首先做手动备份,然后开始修改配置文件。
  • 备份回滚机制,定期恢复数据,进行演练机制,自动删除90天前的配置文件备份数据。
  • 备份命名机制:“业务名+年月日周+IP”

3.1.2 MySQL集群备份机制

  • MySQL采用一三五增量备份,二四六全量备份,数据保存三个月,备份命名机制“业务数据库名+年月日周+IP”,脚本自动删除3个月以前的备份数据,定期进行数据恢复演练。

3.1.3 Redis集群备份机制

  • 每小时备份一次 RDB 文件,并且在每个月的每一天,也备份一个 RDB 文件。 这样的话,即使遇上问题,也可以随时将数据集还原到不同的版本。

 

  • 每秒钟一次 fsync ,每秒备份一次数据、或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次,在这种配置下,Redis 仍然可以保持良好的性能,并且就算发生故障停机,也最多只会丢失一秒钟的数据( fsync 会在后台线程执行,所以主线程可以继续努力地处理命令请求)。

 

  • 暂定每秒fsync,每秒备份一次数据,备份命名机制采用:“业务名称+Redis+IP+年月日时分秒”

 

3.1.4监控系统备份机制

  • 监控系统备份,采用每日凌晨1点进行备份,数据保存周期为一年,备份命名机制采用:“zabbix+IP+年月日”。

3.1.5管理系统备份机制

  • 管理系统备份机制,根据业务不同来划分具体的备目录,统一采用saltstack进行批量管理文件,根据业务分类,对配置文件进行分类备份,备份命名机制采用:“实例名+IP+年月日”,备份机制增量备份,如有新的改动或大面积的调整,调整前后都需要手动进行备份,以保证误操作可以实现秒级回滚机制,实际环境执行,必须加上测试条件,待返回结果正常才能去掉测试条件,例如:salt ‘master_agent’ state.highstate test=Ture

 3.1.6 ELK备份机制

  • ELK备份机制,针对不同的索引进行不同分分类备份,针对不同的应用日志,ELK配置日志规则,按照业务的不同进行分类分目录进行备份,便于管理及查找、针对ELK日志集中事件展示分析做相应的日志分类,对日志保存周期为6个月,备份机制采用每天全量备份、对关键性的业务及文件日志采用实时备份,采用MD5校验的方式来实现,命名规则采用:“索引值+日志类型+IP+年月日时分秒”。
打赏作者

Leave a Reply

Your email address will not be published.