Devops Master轻量级ITSM技术白皮书.docx
- 文档编号:5749402
- 上传时间:2022-12-31
- 格式:DOCX
- 页数:15
- 大小:216.32KB
Devops Master轻量级ITSM技术白皮书.docx
《Devops Master轻量级ITSM技术白皮书.docx》由会员分享,可在线阅读,更多相关《Devops Master轻量级ITSM技术白皮书.docx(15页珍藏版)》请在冰豆网上搜索。
DevopsMaster轻量级ITSM技术白皮书
P2
DevOps轻量级IT服务管理
1、概述
在IT服务管理领域,ITIL®*是以安全性和连续性为目标建立和维护IT基础架构管理的。
但迄今为止,随着敏捷和DevOps理念的不断深入,IT服务管理的环境正在变化,前者需要依据业务用户的需求缩短开发周期,提高发布频率。
若保持原有的ITIL流程化的管理方式,难以满足上述需求。
为了实现敏捷和DevOps的目标,我们需要更轻量级的、更快速的IT服务管理。
这是一个关键的问题。
去年,我们联合ITIL方面的一位专家/教练开始研究这一问题。
我们的挑战是:
如何去除不宜用的部分,以保持敏捷的速度与频率?
我们达成了这样的结论:
IT服务管理应当完全聚焦于业务连续性方面。
为了做好敏捷开发与精益运维,我们重新组织了IT服务管理,这意味着仅需从IT服务管理中提取关键信息来管理业务连续性要素即可。
同时我们定义了以下数据是在哪些流程或活动中发生的,这些数据包括:
业务活动模式(PBA)、服务级别需求(SLR)、服务级别协议(SLA)、服务设计包(SDP)、服务级别包(SLP)、服务验收标准(SAC)及运营级别协议(OLA)。
主要思路是:
在活动进行过程中收
集和记录数据。
P3
从IT服务管理的观点需要这些数据时,则应生成汇总报告,并使用这些信息。
我们称之为轻量级IT
服务管理。
这不是一份文件,只是信息。
P4
需要信息(MRI)以确保业务连续。
服务负责人、可靠性工程师和运营经理识别出与业务连续性相关的每个数据项,因为MRI是由业务环境、业务战略和产品特征或IT服务特征来决定的。
这不会改变敏捷开发的方式。
只会在设计与开发的工作中增加收集数据的内容,以获取MRI。
这基本上无需团队付出额外的时间和精力。
下面将对这个流程进行说明。
2、计划
这一业务用于表述服务需求,由服务负责人设定愿景、目标、预算、项目范围、以及产品或项目章程中的预期收益。
服务负责人和运维人员协商并确定IT服务的运行时基础架构及适当的IT服务可靠性目标。
尤其是在云环境中实施IT服务时,这是特别重要的一个因素。
我们首先设定并配置运行时(Run-time)基础架构,其后开发人员可以轻易地、明确地理解所需性能、安全级别和现有运行时基础架构的可靠性。
开发人员应当为在该环境工作的服务开发正确的代码。
一旦运行时基础架构得以确定,该服务就可获取转换的基础架构,随即是用于测试的基础架构和用于开发的开发基础架构。
另一方面,本阶段定义了可靠性目标后,该服务将有一个清晰的运维故事,用于处理所需系统功能的错误和问题,比如:
备份、记录日志及冗余。
在产品或项目章程中确定的基础架构将驱动架构满足预定义的非功能性需求。
下面是服务级别协议(SLA)检查表的样例。
分类
类别
项目
参考文件
a
授权
签订协议的组织-1
责任人
签名
职位/角色
协议日期
签订协议的组织-2
责任人
签名
职位/角色
协议日期
b
服务描述
服务定义
服务构成
重要业务功能
c
服务范围
商定主题
目标系统/服务
强制的
目标地区/地点
目标组织
目标人群
未覆盖服务
可选的
这些从SLA汇总的数据宜包含在产品或项目章程中。
P5
i
批处理时间
对批处理时间的描述
强制的
完成时间
重要成果描述
输入时间
输出时间
地点
j
服务连续性
对连续性计划的简要描述
投标接受者
强制的
连续性详细计划及对SLA连续性的参考
P6
q
服务报告/审查
服务报告内容
频率
时间选择分配表
强制的
评估会议
频率
会议类型相关人员
相关人员的职位
r
术语表
技术术语描述
强制的
P7
3、需求、设计
包括服务可靠性需求的用户故事用于本阶段。
我们知道,用户故事最初包括“角色(作为某个角色)”、“功能(我/我们可以……)”和“商业价值(为了……)”。
此外,“条件(我需要……)”是有效的。
在编写用户故事后,要按照架构设计的视角进行重构。
确保对以下架构驱动因素进行描述:
功能需求(RF)、质量需求(RQ)、业务需求(BC)和技术需求(TC)。
用户故事一旦固定,运维故事(OperationStory)就将由运维人员创建。
运维故事应当如此表述:
无论运维操作人员是否正在接受新IT服务训练,其结果都不会有任何差别。
这其中也包含现有基础架构中的所有附加或被修正的配置。
而后,测试故事就将由质量保证人员(QA)或可靠性工程师创建,应与用户故事和运维故事保持一
致。
若运维故事不在现有运维能力范围内,则应当在用户故事中重构。
正如大家所了解的,从用户故事、测试故事和运维故事中收集IT服务管理的MRI是有效的。
尤其是用户故事,通过与用户对话,它能够向IT服务管理提供有益信息。
因此,为这一对话准备检查
清单是有益的。
我来举个你可以从以下故事中获取的信息的例子:
P9
1、用户故事:
用户故事中的角色将对用户概况(UP)做出描述。
用户故事中的功能将为服务级别要求(SLR)和服务级别协议(SLA)创建信息。
用户故事中的角色、功能和商业价值将建立有关业务活动模式(PBA)的信息。
用户故事将为服务设计包(SDP)/服务级别包(SLP)和服务验收标准(SAC)生成信息。
2、测试故事:
服务验收标准(SAC)的信息可直接从测试场景和测试用例进入测试故事。
3、运维故事:
运营级别协议(OLA)的信息可直接从环境条件进入运维故事,参考业务活动模式(PBA)。
工作完成后,所有这些信息都将可以取用,并将被记录下来。
此外,当用户故事中的任务被敏捷团队分解后,任务记录对于服务设计包(SDP)而言将构成有用的信息。
同时,服务验收标准(SAC)得以验证,以确保品质。
c
评估
组织就绪状态评估
业务利润
*可选的
以下是一份服务设计包(SDP)清单示例。
这些数据主要来自用户故事。
P10
分类
类别
项目
参考文件
转换计划
界面与弹性计划(根据发布文件生成)
事态
*可选的
事件
问题(problems)
错误
问题(issues)
不合格
最终服务验收(由发布中生成)
*可选的
服务验收标准(由发布中生成)
明确服务生命周期中每个步骤的验收标准,以促进生命周期过程的进步,并将标准投入实践中。
所有相关的基础架构
*可选的
保证期
试运行期及其标准
注:
*参考文件一栏中的“可选”上加星号是表示,当发布包确定其为必需时,该项就是必需的。
服务设计包(SDP)的纸质文档未被创建,相关数据/记录以计费服务(BOS)的形式保存在一个磁盘文件或数据库中。
从应用生命周期管理的角度来看,IT服务的寿命终止(EOL)可从BOS注册的数据中推断出来;其中包括:
一份服务级别协议(SLA)清单、服务设计包(SDP)、服务级别包(SLP)、服务验收标准(SAC)和运营级别协议(OLA)。
P12
4、开发、部署
敏捷中迭代开发的代码将可用于发布。
团队应按服务验收标准(SAC)核实测试的结果,来定义代码是否可以发布。
把关人(Gatekeeper)应参考服务设计包(SDP)来创建发布包。
在自动化部署管道中,每个步骤都应确定一个检查点。
可靠性工程师或把关人可以根据发布包和服务验收标准(SAC)中的信息,检查IT服务的状态,决定是否继续下一步。
分类
类别
项目
参考文件
a
服务启动日期
由所有利益相关者商定
b
保证期
由所有利益相关者商定
c
最终服务验收标准
由所有利益相关者商定
d
部署时间表
向公众开放的文件或信息
强制的
e
服务级别协议(SLA)/服务级别要求
(SLR)
由所有利益相关者审查并商定
强制的
f
服务
对服务进行输入或更新,检验其与其他组件的一致性
服务目录服务组合
强制的
g
客户与利益相关者
在配置管理系统(CMS)中得以识别与记录
h
运行风险
执行了适当的风险减轻措施
强制的
i
符合紧急情况或特别状态
测试完成,记录在阻碍速度测试进度
表中
紧急情况应对行动failover相关行动
强制的
j
用户
由所有用户定义与通过;创建了合适的账户
强制的
下面展示一份服务验收标准(SAC)的清单范例。
服务验收标准(SAC)数据主要来自测试故事。
P13
分类
类别
项目
参考文件
k
负载因素与性能
测量所有项目并纳入容量计划中
在线负载性能与容量
强制的
l
运维完成后审查测试文件,并接受
运维过程的进度过程
m
批处理运行完成,并审查测试文件,验收
批处理作业打印条件
强制的
n
适当执行安全手段
安全检查
强制的
o
安全测试
p
监控与测量
测量工具与流程准备就绪
强制的
q
连续运行
与持续运营相关的工作被定义并批准
持续运营相关成本被
定义并批准
r
运营成本
并入财务流程和成本模式中
s
事故和问题的类别及其流程
审查或修正新服务的已知错误与缺陷
强制的
t
新签约的供应商
强制的
u
由供应商、支持团队、开发团队及其他有关方面审查与修订的支持协议
服务级别协议(SLA)服务级别要求(SLR)运营级别协议(OLA)合约
强制的
v
被事件-、问题-及其他IT支持团队验收的技术支持文件
强制的
w
变更请求(RFC),批准与更新的发布记录
强制的
×
服务、服务级别要求(SLR)、服务级别协议(SLA)、运营级别协议
(OLA)、合同、应用与基础架构组件
配置管理系统(CMS)中记录的细节
P14
分类
类别
项目
参考文件
y
软件许可
被验证与分配
z
硬件组件
记录在配置管理系统(CMS)中,保存在固定媒体库中。
aa
发布与维护相互同意的
计划发布政策,频率机制
bb
用户
完整必要的培训,接收用户文件
cc
可接受服务的相关文件
有关内部系统与外部系统、可靠性与界面的文件准备就绪并得到同意。
强制的
dd
最终批准
业务经理批准新服务的最终验收
强制的
服务验收标准(SAC)的纸质文档未被创建,相关数据/记录以计费服务(BOS)的形式保存在一个文件或数据库中。
P15
5、运营
最终,把关人根据发布包中所登记的充分性情况,决定IT服务可以投入运营。
在发布IT服务后,运营团队或可靠性工程师应当以变更请求(RFC)的方式向开发团队反馈问题
(issues或problems)。
这个变更请求将被加入敏捷团队的产品代办列表(ProductBacklog)中,服务负责人应当像管理其他待办事项一样对其进行管理。
P16
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Devops Master轻量级ITSM技术白皮书 Master 轻量级 ITSM 技术 白皮书