(4)IT运维管理：ITIL先锋论坛—某互联网公司运维平台技术方案.docx

双体系：XX金融运维平台实践

运维平台负责人

1项目背景

目录

目录

CONTENTS

2整体解决方案

统一变更体系

4故障处理体系

5磐石运维未来思考

01项目背景

01

金融与互联网结合对运维的挑战

业务背景和现状

海量实时业务7*24小时永动机

1、业务海量

十万+/秒支付、百万+/秒入账十亿+/天

2、变更频繁

在奔跑的高速上换轮子

用户要求

可用：99.999%

快：200ms

安全：资金有保障

没有什么是确定的

硬件不可靠程序有bug人会犯错误

对运维平台的要求是？

02整体解决方案

02

全方位兜住不确定性，降低未知风险的影响

问题一问题二问题三定义最核心问题

问题一

问题二

问题三

现网频繁变更，如何不人为搞出故障？

故障不可避免，出现故障，如何快速恢复业务？

业务现在没问题，提前解决那些风险隐患导致业务未来有故障的问题？

整体解决方案

故障处理持续运营核心目标：减少故障对业务可用

故障处理

持续运营

核心目标：

减少故障对业务可用的影响时间

核心目标：

持续减少业务可用的隐患

统一变更

核心目标：

确保变更对业务可用的影响可控

一切都是为可用性

整体解决方案

FIT品质坚如磐石

03统一变更体系

03

业务无损变更方案，控制变更时不搞出故障

统一变更：整体方案以及难点

流程化

变更记录统一灰度统一回退一致性

变更记录

统一灰度

统一回退

一致性

难点：

1、确保变更对现网影响可控？

2、和现网一样级别的可用性？

业务2灰度原则能力：业务1城市1台对等城市城市对等10%城市10%对等城市城市对等30%城市30%对等城市城市对等100%城市100%对等城市

业务2

灰度原则能力：

业务1

城市1台

对等城市

城市

对等10%

城市10%

对等城市

城市

对等30%

城市30%

对等城市

城市

对等100%

城市100%

对等城市

1、业务按照优先级

2、流量逐步放量

3、一个步骤内只动单边

变更中兜底能力：

1、流量切换到对端(自动/手动)

2、版本回退

3、版本基线回退(很少用)

灰度1

城市10%

对等城市

城市

对等10%

城市30%

城市

城市

对等30%

城市100%

对等城市

对等100%

版本准备内测环境灰度1灰度1-n全量发布

灰度2

灰度2

灰度3

灰度3

灰度4

灰度4

灰度5

灰度5

灰度6

灰度6

城市

城市

全量

全量

流水线中心实时核对线上版本比较业务生效/异常检查本地合入检查远程合入检查发布中心循环IDC现网目录离线核对30分钟核对现网基线目录↓下一个步骤确保上一个步骤的正确性三方对账确保非正常流程一致性(漏发、机器故障、手动修改、入侵等)发布中心基线库统一变更：发布即生效一致性解决方案

流水线中心

实时核对

线上版本比较

业务生效/异常检查

本地合入检查

远程合入检查

发布中心

循环

IDC现网目录

离线核对

30分钟核对

现网基线目录

↓

下一个步骤确保上一个步骤的正确性

三方对账确保非正常流程一致性(漏发、机器故障、手动修改、

入侵等)

发布中心基线库

版本准备

线上版本比较

推送

本地部署目录覆盖重启业务生效/异

本地部署目录覆盖

重启

本地合入检查合入本地基

本地合入检查

合入本地基线

远程合入检查

远程合入检查

基线库

大域名三域名、全部可用双城路由，本地优先发布...读写分离，读本地，写第三方CC密钥密钥外部依赖本地化、可降级统一变更：双城双活的高可用发布平台

大域名

三域名、全部可用

双城路由，本地优先

发布...

读写分离，读本地，写第三方

CC

密钥

密钥

外部依赖本地化、可降级

前端层

城市 本地小域名

城市

本地小域名

本地小域名

web

web

第三方城市

服务层

无状态server 网关

无状态server

发布...

发布...

无状态server 网关

无状态server

存储层

mysqlDB集群,

mysqlDB集群

,

城市DB2

城市DB2

对等城市DB1

对等城市DB2

城市三db1

城市三db1城市三db2

外部系统

CMDB

CMDB

权限

权限

CMDB

CMDB

权限

权限

CC

CC

统一变更体系小结

统一