1. 故障管理在运维中的重要性及处理流程 2. 标准化和自动化的运维规划：BCM、BCP和DRP的应用

最编程 2024-02-13 07:14:46

...

运维管理：

ITIL：

人：服务请求一线服务台，二线架构，三线应用

变更管理，通知与checklist

配置管理

事件管理

故障管理：

BCM-BCP-DRP-运维管理之故障管理——故障的分类与处理流程

问题管理

落地实施：

运维规划之标准化与自动化

DEVOPS

cicd，代码开发

SRE

事
盘点大盘cmdb，备份，高可用(限流，降级，熔断，混沌工程)，回滚，灰度，故障解决，监控报警，日志，trace，可观测性，容量规划，容量预测，发布变更cicd，
安装，业务监控，指标定义，系统架构，中间件,压力测试，工具，包

标准化(约定化)，自动化，智能化，数据化，可视化，sre，sla

管理
服务目录
服务请求
变更管理，配置管理
事件管理，故障管理，问题管理

人:
一线(客服服务台，服务请求)，二线(中级工程师)，三线(具体应用的深入)

目标:满足商业逻辑的持续增长迭代运行。高效，稳定，低成本

沟通，协调，信息同步，拿结果

定位问题，是什么问题。分解问题，解决问题

目标：

支撑业务

高可用

可扩展

降本增效

高性能

人，事，关系，结构，流程，管控，验收，节点

事：

1，cmdb资产配置管理

2，LDAP内网服务系统统一登陆,SSO，openldap

3，邮箱

4，内网,VPN,跳板机，堡垒机

5，DNS

6，桌面，打印机，投影仪，会议室，office，window，桌面软件

7，wiki

8，jira 项目管理，bug管理

9，服务树

10，统一监控报警平台，统一日志平台

11，工单平台

12，OA平台

13，备份恢复

14，机器设备采购

15，代码托管

16，防火墙

17，中间件，ng，redis，数据库，lb

18，发布平台，devops，ci，cd

19，云平台，iaas，paas，saas，容器，k8s

push通知平台（短信，邮箱，飞书，钉钉，微信）
自动化测试平台
压测平台
混沌工程平台
网关
dbms
配置管理平台
mq，datalink，es，hbase，Hadoop 等
定时任务
服务注册中心
maven仓库
npm仓库
flutter仓库
镜像仓库
数仓系统  BI 平台  报表平台
产品原型系统

密码管理  keepass

可用性：几个9

在系统的高可靠性（也称为可用性，英文描述为HA，High Available）里有个衡量其可靠性的标准——X个9，这个X是代表数字3~5。X个9表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，我们通过下面的计算来感受下X个9在不同级别的可靠性差异。

3个9：(1-99.9%)*365*24=8.76小时，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
4个9：(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
5个9：(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

那么X个9里的X只代表数字3~5，为什么没有1~2，也没有大于6的呢？我们接着往下计算：

1个9：(1-90%)*365=36.5天
2个9：(1-99%)*365=3.65天
6个9：(1-99.9999%)*365*24*60*60=31秒

可以看到1个9和、2个9分别表示一年时间内业务可能中断的时间是36.5天、3.65天，这种级别的可靠性或许还不配使用“可靠性”这个词；而6个9则表示一年内业务中断时间最多是31秒，那么这个级别的可靠性并非实现不了，而是要做到从“5个9” 到“6个9”的可靠性提升的话，后者需要付出比前者几倍的成本。

可用度A	9的个数	年停机时间（分钟）	适用产品
0.999	三个9	500	电脑或服务器
0.9999	四个9	50	企业级设备
0.99999	五个9	5	一般电信级设备
0.999999	六个9	0.5	更高要求电信级设备

商业，
产品
技术模型
架构(静态推理)
技术环境(资产管理，账号密码管理，cmdb，及资产间拓扑关系)

以下: 动态运维
安装(标准化)，最佳实践(计数器，计时器，容量，度量，压测，规范)
监控，可观测性
高可用性(切换，副本，限流，降级，熔断，混动工程，回滚)
备份
恢复演练
故障处理
发布(devops，流水线，灰度，小流量)
巡检

服务请求(流程化，ldap单点登录，jira，Wiki，网络安全与安全管理，
邮箱，内网，VPN，桌面运维，堡垒机)
变更管理（工单与周知审核范围）
配置管理
事件管理
故障管理
问题管理

一线(简单有直接结果的处理)
二线(综合)
三线(特定领域)

标准化，流程化，自动化，平台化，智能化，可视化，数据化（智能监测与运营分析）

文档
服务间关系及调用关系(业务侧及对应到技术系统，业务模型及之间的调用关系)，和文档，这些是需要历史积累的沉淀。

sli
slo
sla


项目摸排：

项目摸底

在接手系统后，先要确保能日常维护，对整套系统做一个摸底，一般包括以下几项：

项目简介
账号密码表
项目资源管理配置清单
各种结构流程图
部署维护文档
项目监控策略汇总表
项目应急操作手册

项目简介
我们可以从当前项目的业务范围，即项目的功能是什么？以及项目负责人及相关人员是谁，方便我们后面更好的项目对接。
账号密码表
账号密码表中应详细记载各服务器、平台、系统的登录用户名及密码，另外还应该有权限记录表，记录给谁开过权限，登录账号又是什么，以上种种，此处仅是距离，需要记录的东西很多，切记一定要准确清晰。
项目资源管理配置清单
这里面我觉得至少包含但不限于4个sheet表：服务器清单，项目域名信息，项目服务信息，第三方服务资源清单，每种信息都应该列出项目所有环境的信息，例如正式和测试环境等。
各种结构项目流程图
例如此项目的网络拓扑图，系统架构图，从这个拓扑图中我们可以看到此架构使用了多少台服务器，整个逻辑流程是怎样的。例如我们可以从域名开始摸，域名对应的Ddos防护，下面是负载均衡，再下面是每个模块的服务。每个服务需要连接哪个库，又需要和哪个服务进行交互。
部署维护文档
此文档可包含详细的安装步骤，配置文件中的数据库等地址指向都要写清楚，那么如何检验此文档的实用性呢？将此文档交接给另外的同事，可以达到迁移恢复，复制项目的目的。
项目监控策略汇总表
主要包含目前的监控策略，可分为基础监控和业务监控。基础监控为CPU、内存、网络带宽等服务器基础资源监控；业务监控则是针对服务本身的监控，此监控可暴露出当前的项目问题。此表可方便与项目负责人对接项目监控问题，或方便以后查询监控是否有遗漏等。
项目应急操作手册
项目已知的问题，经常发生的问题的处理方法，解决方案等。
可能很多小伙伴认为上面部分内容是业务上的东西了，觉得运维没必要去学，开发让扩展部署几个服务，部署就是了，反正这块是开发要负责的，出了业务问题开发排查即可。