6.5 过程要素管理
本文最后更新于86 天前,其中的信息可能已经过时,如有错误请发送邮件到big_fw@foxmail.com

内容:三星

file

可以和第四章服务规划设计做对比,八个服务管理+两个新增(容量管理,可用性和连续性)

过程串联:二星

file

  • 监控:当没有客户的请求的时候,我们做的是监控;出现事件以后及时去响应;事后分析与问题管理;进入知识库
  • 容量管理:当前对业务系统的一些监控以及业务流量的分析,随着时间的推移,得到完善与增强
  • 配置管理:配置让各种组件更标准化,清晰化,上线轻量化,更安全
  • 安全管理:让持续部署更安全
  • 变更管理:让持续部署更频繁
  • 连续性和可用性管理:实现业务高可用,更可靠

过程总结:二星

file

服务级别管理:

  • 第四章是做协议签订——第六章主要对它做一些监控和更新

服务报告管理过程:

  • 主要是甲方和乙方的一个载体,保障双方及时准确的传递

事件管理过程:

  • 服务质量下降,中断的都是事件;强调快速解决

问题管理过程:

  • 找原因,预防重复发生,纳入知识库

配置管理过程:

  • 对配置项的管理,对整个过程做必要的记录

file

变更管理过程:

  • 让变更更有序的实施

发布管理过程:

  • 变更的实施的过程,有序且成功的进行

信息安全管理:

  • 保证信息的可用性、机密性、完整性

可用性连续性管理:

  • 保证在任何条件下都可以可用连续性

容量管理过程

  • 包括当前,满足未来,要有容量的意识

服务级别:三星级

file

服务协议在运营过程中相当于一个标杆,要按照标杆去走

在运营过程中更注重与 更新 服务目录以及 监控 服务级别协议的执行情况

服务报告:三星

file

主要为甲乙双方提供有效的 信息沟通。为高层提供 决策支持

建立:在规划的时候,由乙方的团队进行设计,规定好频率,内容,模板等等

审批:由甲方领导去确认

分发:给相关的干系人

归档:自己留一份,公司一份,甲方一份

更新服务报告模板,不是一成不变的

过程要完整,及时、准确

事件管理:三星

file

故障发现:

  1. 由人发现(使用过程中)

  2. 大部分是由监控发现的

  3. 监控也是自上而下,上层是业务监控,下层是基础设施监控;

  4. 实际生产环境中,大概是90% 基础设施的监控能发现30% 的问题;10%的业务监控能发现70% 的问题

故障定位——故障恢复——故障改进

file

最主要的目的就是:尽快解决事件。

  • 受理与处理
  • 监控与跟踪
  • 升级:自己搞不定,事件超时或者能力不足时;求助能力更高或者权限过高的人来处理
  • 满意度调查
  • 事件报告:量化分析
  • 考核机制:完整性,有效性

事件管理和问题管理的区别:

file

问题管理:三星

file

主要侧重是找原因,预防同类事情发生(和知识库关联)

  • 受理
  • 找原因
  • 更新知识库
  • 完成报告
  • 过程的完整性,评估机制的有效性

配置管理:三星

file

不仅仅指软件的配置

对运维对象(和项目相关的产物:包括源代码,测试代码,部署脚本,数据库脚本,文档等等,这些都是配置项)进行记录管理,保证可靠性与时效性;关联支持其他服务过程(跟变更,发布版本相关,都要记录)。

  • 配置项的识别、记录与更新
  • 对配置数据库(存放配置项的仓库)进行管理与维护
  • 审计:名字对不对,变化对不对等等
  • 配置管理过程的完整性,数据的准确、完整、有效、可用、可追溯;审计机制的有效性

配置中心示例

file

变更管理:三星

file

保证变更有规范性和流程化

当有需求的时候并不是马上就去变更,而是去评估和分析,然后进行审核,审核通过再实施、确认、生成报告

  • 任何人都可以提请求与变更,口头或者书面
  • 一般是项目经理PM和一线工程师受理
  • 评估分析(范围是否蔓延,有没有违背服务级别协议,对进度成本质量资源有没有影响)—— CCB审核(一般是甲方的成员组成)
  • 实施——确认——回顾
  • 生成变更报告,发布
  • 变更管理过程的完整性,变更记录的完整性

小扩展

file

发布管理:三星

file

侧重的点是变更的实施过程

file

  • 计划性:什么人,什么时间进行发布
  • 测试:先在测试环境发布
  • 回退方案:发布失败时执行回退方案
  • 发布记录(变化什么内容),更新配置数据库(V8版本升级至V9)
  • 生成报告,定期发布
  • 发布过程的完整性,发布记录的完整性,准确性

确保一个或者多个变更的成功导入!

安全管理:三星

file

提供符合信息安全要求的服务

  • 执行安全策略:安全管理最主要的就是安全策略,下面为示例
  • 对违反事件进行和监控与追踪
  • 保密性,可用性,完整性

小扩展

file

可用性与连续性管理:三星+++++

file

思想:

业务场景:订单成交额

连续性:可用性,连续性,SLA,MTTR等等

管理:运营,实时运营等等

管理内容这里总考!!!

file

可用性、连续性 在任何环境下,都能满足!

  • 至少每年开发,检查
  • 业务环境发生重大变更是,可用性和连续性必须重新测试(这里考的比较细,小的变更不需要重新测试,重大变更才需要)
  • 变更管理流程评估的时候要评估对可用性与连续性的影响
  • 可用性必须被测量和记录 (运行时间/总时间)
  • 连续性计划、联系列表和配置管理数据库,正常办公被禁止时必须一直可以使用
  • 连续性计划必须被测试(业务是连续性,系统是可用性)要和业务的需求一直
  • 所有的连续性计划必须被记录,对测试失败的必须产生行动计划

业务不连续的情况:

  • 业务中断
  • 迁移

容量管理:三星

file

确保服务提供者在任何时间都有足够的能力,满足当前和未来的客户业务需求

比如当前是五千万访问量的架构,以后要是有几个亿的访问量,那么要用什么架构,什么方法,什么技术,要有足够的计划

  • 必须产生、维护一个能力计划
    • 比如访问量翻倍,采用负载均衡/ CDN /上云 / 数据库读写分离、主从复制 / 微服务架构,限流,降级 / 反向代理,NOSQL等等
  • 容量管理要满足业务需求
  • 对服务能力做一些监控,调整,提供足够的方法,步骤,技术

过程要素总结:三星

file

事件管理:尽快解决问题

问题管理:找原因

变更管理:走流程

发布管理:变更的实施过程

配置管理:变更和发布会触发配置管理记录

典型习题

关于过程要素管理的表述不正确( )

A.发布可以导入变更,确保发布的顺利,

B.当业务环境发生重大变更时,可用性和连续计划必须被重新测试

C.变更管理的流程必须评估变更对可用性和连续性计划的影响

D.问题管理是预防同类事件的发生

关于容量管理、连续性和可用性管理的描述,不正确的是( )

A.连续性计划必须包括对正常工作的恢复

B.当业务环境发生重大变更时,可用性和连续性计划应被重新测试

C.变更管理流程必须评估变更对可用性和连续性计划的影响

D.容量管理关注当前的业务需求,连续性管理关注未来的业务需求

关于连续性和可用性管理工作的描述,正确的个数有( )。

①可用性和连续性计划必须至少每年开发、检查,计划必须被维护来反映协议下的业务要求变更

②业务环境发生任何变更时,可用性和连续性计划都应被重新测试.

③变更管理流程必须评估变更对可用性和连续性计划的影响

④计划之外发生的不可用情况,必须被调查并采取合适的行动

⑤连续性计划、联系列表和配置管理数据库在正常办公室访问被禁止时必须仍可使用

⑥连续性计划必须被测试,以保证与业务的需求一致

⑦所有的连续性计划的测试必须被记录,对测试失败3次以上的必须产生行动计划

A.2个 B.3个 C.4个 D.5个

针对服务报告管理的描述,不正确的是( )。

A.为保证服务的规范性,针对不同的服务对象,尽可能统一服务报告模版

B.将分发过的服务报告进行归档,按照不同时段、对象分类,以备查找

C.在服务报告提供时,因服务需求发生变化,应该及时更新服务报告模板

D.服务报告关键指标包括服务报告过程的完整性、服务报告的及时性等

男孩子都是香香软软的小猪
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇