运维扫盲,捅破窗户纸!
”与人交谈一次,往往比多年闭门劳作更能启发心智。思想必定是在与人交往中产生,而在孤独中进行加工和表达。“ 或许正是因为交流,让我意识到无论在运维行业多久还是会有盲区。所谓的盲区其实就是一层窗户纸,可能你躬身所做的正是其中的一部分,只是咱们不知道其顶层的设计而已。因此今天我们就来通过几个概念来进行运维扫盲!
BCMS
❝参考:
国标《公共安全 业务连续性管理体系要求》GB/T 30146-2013/IS 22301:2012
❞
重要性
建立和管理一个有效的业务连续性管理体系(BCMS)的重要性
-
理解组织的需求以及制定业务连续性管理方针和目标的必要性 -
实施和运行控制措施来管理组织应对中断事件的整体能力 -
监视和评审业务连续性管理体系的绩效和有效性 -
基于客观测量的持续改进
策划一实施一检查一处置(PDCA)模型
采用“策划(Plan)一实(Do)一查(Check)一改进(Act)”PDCA)模型来策建立实施、运行、监视评审保持和改进组织 BCMS 的有效性。
| 策划(建立) | 建立与改进业务连续性管理相关的业务连续性方针、目标指标、控施、过和序,以提供与组织的总方针和总目标相一致的结果 |
|---|---|
| 实施(实施和运行) | 实施和运行业务连续性的方针、控制潜施、过程和程序 |
| 检查(监视和评审) | 对照业务连续性方针和目标,监视和评审业务续性的绩效,并将结果报告管理者以供评审,确定和授权纠正与预防措施 |
| 改进(保持和改进) | 基于管理评审以及重新评审的业务连续性管理体系的范围、方针和目标的结果,采取纠正措施,以持续改进 BCMS |
部分定义
-
业务连续性(business continuity)
在业务中断后,组织在预先确定的可接受的水平上连续交付产品或提供服务的能力。
-
业务连续性管理(business continuity management)
识别对组织的潜在威胁以及这些威胁一旦发生可能对业务运行带来的影响的一整套管理过程。该过程为组织建立有效应对威胁的自我复能力提供了框架,以保护关键相关方的利益、声誉、品牌和创造价值的活动。
-
业务连续性管理体系(business continuity management system;BCMS)
用于建立、实施、运行、监视、评审保持和改进业务连续性,是一个组织整个管理体系的一部分。
-
业务连续性计划(business continuity plan)
用于指导组织在业务中断时进行响应、恢复、重新开始和还原到预先确定的业务运行水平的形成文件的程序。
-
业务连续性方案(business continuity programme)
由最高管理者和适当的资源所支撑的,为实施和保持业务连续性管理所进行的持续不断的管理和治理过程。
-
业务影响分析(business impact analysis)
分析活动和业务中断可能带来的影响的过程。
-
恢复点目标(recovery point objective ;RPO)
为使活动能够恢复进行,而必须将该活动所用的信息恢复到某时间点。
-
恢复时间目标(recovery time objective ;RTO)
事件发生后到下列活动完成之间的时间段。
-
产品或服务必须恢复 -
活动必须恢复 -
资源必须复原
小结
当我们将业务连续性管理体系(BCMS)部分概况讲完后,你是否会恍然大悟?因为我们所作的一切其实都是为BCM服务的,会分布于BCMS的各个层面。另外,PDCA模型不仅可以用在项目管理中,也适用于很多管理体系标准(如 GB/T 19001质管体系GB/T 24001环境管理体系GB/T 22080 信息安全管理体系GB/T 24051信息技服务管理和ISO28000供应链的安全管理体系规范),从而保证了各体系标准的一致性从而支持与相关管理体系整合后的实施与运行。
UIOC
❝参考:
https://www.51cto.com/article/499172.html https://www.jianshu.com/p/42b1e06fc49c
❞
UIOC(紧急事件处理中心)的建立目的是在系统发生异常时能够快速调动相关IT资源,集中资源并发会诊,统一决策以保证系统快速恢复,各处理方可在UIOC中全面了解事件,综合各方情况作为问题解决和决策依据。在这个过程中,开发应该关注应用逻辑、运营关注业务影响、运维关注底层资源、DBA关注数据库、724关注监控告警。
诊断顺序
UIOC是一个联合诊断、积极配合的过程,流程启动后,必须要有统一管理,否则很容易陷入一片混乱,一般需要以下八点次序进行问题分析:
- 「召集相关资源」 , 选用合适有效的沟通渠道和工具,确保这些渠道和工具随时可用,启动UIOC前通过渠道和工具快速召集相关资源。
- 「问题描述与业务影响评估」 ,启动UIOC后,故障处置组需要对问题、异常进行简单描述,并不断记录关键信息,联动7x24提供故障链路全类型告警信息。
- 「应用owner协查」 ,在问题、业务影响描述清楚后,应用负责人应串联异常现象和告警信息对应用整体情况进行说明。
- 「生产变更」 , 依据应用owner的输出信息来判断是否有业务发版、组件版本发布、基础资源变更等。
- 「持续收集信息」 , 开发人员应关注请求量、异常日志;运维人员检查基础资源情况,包括性能数据、日志信息;DBA同学检查数据库性能数据、慢查询等。
- 「专家会诊」 ,根据生产问题严重性,对可能造成P4级以上的生产故障,请求专家协助分析并制定快恢解决方案。
- 「执行快恢方案」 , 各项操作具体到人,如回滚则需应用onwer提供回滚版本、运维人员操作、业务方验证、7x24观察告警情况等。
- 「判断问题是否全面解决」 ,应用onwer关注应用各节点运行情况,确保各节点日志全部正常,业务测试验证正常,上下游系统或基础资源各项指标恢复至故障前数据标准,全链路监控无告警。
响应流程
小结
我看到的网络上关于UIOC文章的参考可追溯至2015年,但是紧急事件处理场景作为运维已经屡见不鲜了。在故障处理中我们是否有完备的流程、应急预案、团队oncall、故障升级、快速恢复等相应的环境和能力,这是我们要考虑的。当然我们还是要根据业务场景、行业特点、团队规模来区分处理,选择合适的方案,而不是盲目的追求UIOC。
IaC+GitOps
IaC
❝参考:
https://mp.weixin.qq.com/s/gkE5fnZ6dtigKPXR2qEpkg
❞
基础架构即代码(IaC)是通过代码(而非手动流程)来管理和置备基础架构的方法。利用IaC,我们可以创建包含基础架构规范的配置文件,从而便于编辑和分发配置。此外,它还可确保每次置备的环境都完全相同。通过对配置规范进行整理和记录,IaC有助于实现配置管理,并避免发生未记录的临时配置更改。IaC可以帮助我们管理IT基础架构需求,同时提高一致性并减少错误和手动配置,其优势为:
-
降低成本 -
加快部署速度 -
减少错误 -
提高基础架构一致性 -
消除配置偏移
当然IaC并不是孤立存在的,其中版本控制是IaC的一个重要组成部分,就像其他任何软件源代码文件一样,配置变更也应该在源代码控制之下。结合版本控制,我们可以确保配置变更可靠执行,部署一旦出错也可以进行快速回滚,有效降低了配置管理的难度。因此我们可以将IaC与GitOps理念更好结合。
GitOps
GitOps的核心理念:将应用的所有环境配置都通过源代码控制系统Git进行管理,并通过自动化的流程进行交付和变更。
-
从应用定义到基础设施环境,所有的配置都以源代码的方式保存在Git中。 -
所有变更、审批记录也记录在Git的历史状态中。 -
Git 成为 “sourceof truth”,我们可以追溯变更历史、可以回滚到指定版本。
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
-
基础架构即代码(Infrastructure-as-Code,IaC)则是一种典型的声明式 API。 -
Docker和Kubernetes容器技术是实现Immutable Infrastructure模式的最佳实践。
GitOps与声明式API、不可变基础设施相结合,保障了应用环境的可复现性,提升了交付与管理效率。
总结
”阻碍成年人进步有一个很关键的因素,就是要面子“。我们运维扫盲,一方面扫的是技术、体系、概念、解决方案的欠缺,另一方面扫的就是面子。作为运维,我们可以不懂,但是不能不知道。因为,当你认为运维工作只是杂事时,你就会萎靡不振;但当你知道你所做的可能是BCMS、UIOC、IaC+GitOps 中的某一环节时,你才会明白运维工作的价值,正是你的一份默默付出,才会收获一片森林。
精彩文章合集
文章推荐 ☞ 【合集】 运维思索系列 ☞ 【 合集 】 运维管理系列 ☞ 【 合集 】 运维监控之路 ☞ 【 合集 】 基础设施自动化之路 ☞ 【 合集 】 CI/CD之路 ☞ 【 合集 】 Ansible之路 ☞ 【合集】 K8S之路
☞ 【合集】 数据库系列
札记:“ 如何快速变强:从麦穗理论里寻找最优解,用38%的时间认真积累经验,剩下50%实践,最后12%的时间复盘总结。” -- 优秀的运维小伙伴