DevOps:软件架构师行动指南3.4 持续服务改进

3.4 持续服务改进


每一个被组织采用的流程都应该从这个视角来考虑:这个流程到底多有效?还可以怎样改进?这个流程如何适应公司整体流程框架?

我们讨论的所有运维服务(硬件和软件的供给、IT支持功能、服务级别协议的规格说明和监控、容量规划、业务连续性和信息安全)都是组织层面的流程。需要从我们提出来的几个问题的视角来进行监控和评估。

从组织层面来说,每一个服务都应该有一个负责人,并且这个服务的负责人需要负责检查监控、评估和改进。

持续服务改进的主要焦点是要在IT服务和业务需求之间达成一致——不管这些需求是否已发生变化还是维持不变。如果这些需求已经发生变化,则对IT服务的期望变化可以关注范围、功能或者服务级别协议。如果业务需求相同,则可以扩展IT服务来更好地支持它们,但对它们的改进也可以专注在提升效率上。DevOps关注更快、更可靠地把这些变化引入实践中。

图3-3描绘了ITIL建议的7步骤改进流程。这个数据驱动的流程开始于一个明确的愿景、策略和目标,这些能够驱动当前的改进周期。基于此,第1步定义应该度量什么,以便理解应该改进什么,并且当改进完成后,是否达到了期待的目标。指标可以粗略地分成3类:技术、流程和服务。

 

图3-3 服务持续改进流程(改编自ITIL)

实际的数据收集是在第3步发生的。这对于建立基线是非常重要的(如果它们已经不存在了)用于以后的比较。而且,数据的收集(谁收集和如何收集、什么时间、什么频率收集)需要明确定义。第4步,处理数据(例如,将不同数据源的数据进行聚合或按照指定的时间间隔进行)。分析数据是在第5步进行。在第6步,演示分析中得出的信息,并决定改进措施。而第7步将已制定好的改进措施付诸实施。这些行动将影响服务的整个生命周期的所有阶段——策略、设计、移交或运维。

时间: 2024-08-25 02:12:00

DevOps:软件架构师行动指南3.4 持续服务改进的相关文章

DevOps:软件架构师行动指南3.3 服务运维功能

3.3 服务运维功能 监控是运维过程中最重要的核心,因为它收集事件.检测事故和度量以判断是否符合服务级别协议.它提供了服务改善的基础.服务级别协议也可以定义和监控运维活动,例如,发生事故后的响应时间. 监控可以和其他控制结合在一起,例如,对云资源的自动伸缩,即在一个Web服务器池中,当平均CPU负载达到70%时就触发一个规则来启动新的Web服务器.控制可以是开环或者闭环.开环控制(即不考虑监控反馈)可以用于在预定的时间进行常规备份.在闭环控制中,在决定采取行动时考虑监控信息,例如在自动伸缩的例子

DevOps:软件架构师行动指南3.2 运维服务

3.2 运维服务 运维服务包括供给硬件.供给软件,或者支持各种不同的IT功能.由运维提供的服务,还包含服务级别协议(Service Level Agreement,SLA)的规格说明和监控.容量规划.业务连续性以及信息安全. 3.2.1 供给硬件 硬件可以是组织拥有的物理硬件,也可以是由第三方或云供应商管理的虚拟硬件,也可以是由个人.项目,或者大型组织中的一部分所使用的硬件.表3-1展示了这些可能性. 表3-1 个人.项目和组织使用的硬件类型 使用者 物理硬件 虚拟硬件 个人 笔记本电脑.台式机

《DevOps:软件架构师行动指南.》导读

本节书摘来自华章出版社<DevOps:软件架构师行动指南.>一书中作者伦恩·拜斯(Len Bass) [澳]   英戈·韦伯(Ingo Weber)    著 朱黎明(Liming Zhu)   前言   多年以来,我们一直在探索研究运维中的问题.自然而然地,我们也一直在追踪DevOps运动.它正在沿着Gartner成熟度曲线向上发展.这种现象有着坚实的业务原因.我们能够找到从信息技术经理视角对DevOps的探讨(例如小说<凤凰项目:一个IT运维的传奇故事>),也能找到从项目经理视

DevOps:软件架构师行动指南3.5 运维和DevOps

3.5 运维和DevOps 讨论完ITIL的核心概念和阶段后,现在我们强调将来传统IT运维和DevOps之间将形成什么样的交互.我们想要传达的信息是,如果认为ITIL是过于"重量级"而不适合DevOps过程,那么这个观点是短视的,并且这个观点将导致要再走过那些ITIL框架中所试图解决的"坑". 运维的职责是供给硬件和软件.拥有特殊技能的人员.服务级别协议的规格说明和监控.容量规划.业务连续性和信息安全.这些职责的大部分包含在DevOps过程中和过程外.任何关于运维的

DevOps:软件架构师行动指南1.5 团队结构

1.5 团队结构 本节讨论在承担DevOps职责的开发团队中,团队一般是多大规模,包含哪些角色. 1.5.1 团队规模 虽然不同的方法论推荐的准确团队规模是不一样的,但是大家都认为团队的规模应该相对较小.亚马逊(Amazon)有一个"两个比萨饼的规则".即,团队规模应该是两个比萨饼就够吃.虽然这个规则本身有一点模糊(比萨饼有多大,团队成员有多饿),但是这个规则的意图很明确. 小团队的优势在于: 可以快速做出决定.在每次会议上参会者都希望表达自己的意见.参会者越少,表达的意见就越少,用来

DevOps:软件架构师行动指南1.7 障碍

1.7 障碍 如果DevOps解决了开发中长期存在的问题并有如此明显的好处,为什么不是所有的组织都采用DevOps实践呢?本节将探讨采用DevOps时遇到的障碍. 1.7.1 文化及组织类型 在讨论DevOps时,文化很重要.在跨组织以及同一个组织中的不同群体之间,与DevOps相关的文化问题都会影响它的形式与采用.文化不仅取决于你的角色,而且取决于你所在组织的类型. DevOps的目标之一是缩短新功能或新产品投向市场的时间.在采用DevOps实践时,组织要考虑的一个问题是缩短面市时间所带来的收

DevOps:软件架构师行动指南1.1 概述

第一部分 背 景 这一部分为本书的后续章节提供了必要的背景知识.DevOps是一项运动,它设想在开发组和运维组之间没有冲突.DevOps的出现与云发展成为大小型组织的基本平台是同时发生的.第一部分有3章. 在第1章中,我们将定义DevOps,并且讨论DevOps的各种驱动力.DevOps是一个包罗万象的术语,它可以涵盖多个含义,包括让开发人员和运维人员互相沟通:允许开发团队自动化地部署到生产环境:当在生产环境中发现错误时,让开发团队成为第一个响应者.在这一章中,我们将梳理出各种关注点,并且关于D

DevOps:软件架构师行动指南1.2 为什么是DevOps

1.2 为什么是DevOps 从很多方面来讲,DevOps是对缓慢发布的问题做出的响应.发布投放到市场的时间越长,从中获得的功能或质量提升的收益就越低.理想情况下,我们希望持续发布.常常用术语持续交付或持续部署来表示.我们在第5章和第6章讨论这两个术语的细微差别.在本书中,我们使用术语持续部署,或部署.我们开始时先描述一个正式发布过程,然后深入探讨缓慢发布的一些原因. 1.2.1 发布过程 向客户发布新系统或现存系统的新版本是软件开发周期中最敏感的步骤.不论系统或版本是对外发布.直接由客户使用还

DevOps:软件架构师行动指南3.6 小结

3.6 小结 ITIL为运维活动提供通用的指导.这些活动包含供给硬件和软件:提供诸如服务台运维和特殊技能专家的功能:提供日常的IT服务.与这么多流程规格说明标准一样,ITIL对这些活动如何实施提供通用指导而不是具体指导.例如,ITIL不会说"用X的目标度量A",而是说"为了目标X,选择一个可以让你达到X的度量方法". 组织的活动应该满足组织的某些战略目标,并且需要设计.实施.监控和改进.DevOps实践有降低从开发人员提交到生产环境并且快速修复已发现问题的目标,这影