DevOps能PPT课件

,Accelerate加速度DevOps能成长模型作坊,1,1,-,加速度,业务如既往等于落西,2,-,Accelerate:TheScienceofLeanSoftwareandDevOps:BuildingandScalingHighPerformingTechnologyOrganizationsLink:http:/a.co/eo5FyQj,3,-,组织效能,个人的认同,软件交付效能,Westrum组织文化,职业满意度,更少的职业倦怠部署痛苦返工,持续交付,软件开发实践,领导力转型愿景激发智力支持型领导鼓舞士气,认同个人,精益管理限制在制品,可视化管理,来自生产环境的反馈,轻量变更管理,精益产品开发小批量工作团队实验收集实施客户反馈,将工作流可视化,测试自动化基于主干的开发,测试数据管理,信患安&前置松耦合的架构,监控部署自动化授权的团队,持续集成版本控制预警式通知,4,-,高效能者是怎样完胜风险和不确定性的？,通过快速的交付能取悦客户的服务和产品，组织能快速的交付价值,型团队（Twopizzateam）,短迭代周期,度量来客户的反馈,5,-,不得不加速度,交付取悦客户的产品和服务通过市场交互理解客户的需求系统顺应合规和监管的变化响应潜在风险：,安全威胁,经济形势变化,6,-,软件技术是核心竞争,JamesBessen：战略性的使技术，于并购公司和业务创新（2017）技术和利润的关联性（2008）软件技术转型和加速度适于所有组织在DevOps运动中，涌现出来,各种实践,各种能,7,-,DevOps教练,10DeploysperdayDev&opscooperationatFlickr,JohnAllspaw&PaulHammondVelocity2009,8,-,DevOps教练,DevOps是技术实践学习的流程和化这些是效能产出的驱动,9,-,DevOps教练,DevOps适于各种类型的组织,10,-,DevOps教练,效能组织能够达到两倍的目标或者高,商业标产率利润率市场份额户数,商业标产品或服务的质量运营效率客户满意度产品或服务的数量达成组织的使命和标,2x三年的市场总值增长于50%,11,-,高效能是怎么炼成的？,成熟度是已经过时的模型,12,-,DevOps教练,2005年，级别上限升70，重新设置职业，增加新专业技能、副本、战场和种族，可以变更2008年，级别上限升80，增加死亡骑职业，开放更多副本和新的装备2010年，级别上限升85，新增两个种族，游戏的内容在改头换的艾泽拉斯陆进，增加新专业技能,书呆专属的成熟度模型,13,-,DevOps教练,2011年，级别上限升902013年，级别上限升100，新增新的陆德拉诺2017年，级别上限升120，部落和联盟接在海上找到了新的盟友,书呆专属的成熟度模型,14,-,成熟度模型告诉我们已经到达某个的地可是整个世界从你身旁正呼啸过,15,-,成熟度模型告诉我们等一旦到达了某个等级之前的专项资源投会即刻停止,DevOps教练,16,-,DevOps教练,成熟度模型告诉我们所有的都是遵循着一模样的成功之旅,17,-,DevOps教练,成熟度模型告诉我们技术只是有待完成的检查清单而不是持续探索和改进的激动旅程,18,-,建议参考和应用DevOps能力成长模型,适于本来能和起点就参差不齐的不同团队符合每个团队的优劣势和业务上下的不同每个团队聚焦在不同的、各的约束点/弱点上,根据业基线设置下步的标,能模型,19,-,软件交付效能,重要的度量向,20,-,度量软件交付效能,同时聚焦产出和全局度量：部署频率（在业务需求被满的前提下）变更的前置时间故障恢复时间（MTTR）变更失败率,吞吐量稳定性,21,-,我们看到更高的吞吐量伴随着稳定性,他们如影随形。并不需要做折中，退求其次的建议也是多余的。,22,-,高效能DevOps团队更敏捷Agile,46x,代码部署更频繁巨的差距在于：天多次部署和每周次，甚更少,440 x代码提交到部署的前置时间更短巨的差距在于：于天和周甚更长,23,-,高效能DevOps团队更可靠Reliable,96x,更快速的恢复时间巨的差距在于：于天和天,1/5x更低的变更失败率巨的差距在于：015%失败率和3145%,24,-,2017DevOps状态调查报告：2017ITPerformancebycluster,问卷调查,25,-,常见错误,产出输出Outcomesoutputs全局/团队局部/个体Global/teamlocale/individual,26,-,常见错误：代码行数Lineofcode,越多越好？,更臃肿的软件,更的维护成本,更的变更成本,越少越好？,妙莫测且法理解的代码,理想的：最有效的代码解决业务问题,27,-,常见错误：速率Velocity,Agile：问题被拆分成故事，评估完成这些作的点数在冲刺结束的时候，由客户签收的点数被记录下来=速率Velocity速率是产能计划具。不是产效率具为什么速率不能作为产效率使？,速率只是个相对的度量，绝对的。因此，很不适合于团队间的较,点数评估被夸，被博弈,聚焦在团队的完成度，通常牺牲了团队间的协作（这是个全局标）,28,-,常见错误：利用率Utilization,利率仅仅在某个点上/程度上是好的利率越越好么？,在利率下，我们失去了于计划作的可配的时段,排队理论：在利率达到100%的时候，前置时间接近于穷,当你们的利率越来越的时候，所有团队将花费越来越长的时间完成任何的作,29,-,技术实践很关键,DevOps是各种技术实践的融合,30,-,度量效能：软件交付效能的影响地图,软件交付效能,商业性效能,组织的效能,利润率,市场份额,产率,使命,提供价值,=IT效能,31,-,度量和改变化：企业化的影响地图,Westrum企业化,软件交付效能,组织的效能,精益产品管,持续交付,32,-,持续交付的驱动力持续交付的影响地图,持续交付,版本控制自动化部署持续集成主干开发自动化测试测试数据管理模式化安全管理松耦合架构赋能团队监控前瞻性预警通知,软件交付效能,Westrum企业文化,组织的效能,个人的认同,更少的返工,33,-,持续交付意味着使作更可持续发展,持续交付,更少的部署痛点,更少的加班加点,34,-,架构很关键,不是技术,35,-,技术堆栈并关键,低效能者们的相似之处：使外包的式开发软件使Mainframe系统但是：使Mainfram系统并不和效能相关联作在绿地应或棕地应也不和效能相关联,36,-,关键的是架构的产出,我们的团队是否能：,变更系统的设计,测试系统,部署系统,不依赖与外部进沟通和协作,37,-,每个开发者，每天的部署次数,开发员数量,部署频率,高等效能随着开发者数急剧提,中等效能维持在个基本恒定的频率低等效能随着开发者数急剧下降,38,-,“任何组织在设计套系统时，所交付的设计案在结构上都与该组织的沟通结构保持致。,-梅尔.康威,39,-,软件管理实践和产品开发很关键,两抓，两都要硬,40,-,精益管理实践的影响地图,精益管理限制在制品（WIP）可视化管理生产环境的反馈轻量的变更管,软件交付效能,更少的加班加点,Westrum企业文化,41,-,实施轻量的变更管理流程,评估变更审批流程对软件交付效能的影响，结果：只针对风险变更进审批与软件交付效能是关的没有变更审批流程，或者仅仅依靠同评审的团队展现出更的软件交付效能需要外部员（CAB）进审批的变更流程导致更低的软件交付效能外部CAB审批对：前置时间、部署频率、恢复时间有负影响；相反CAB对提产系统的稳定性没有相关性建议：应基于同评审（结对编程、团队内代码评审、结合流线）的轻量变更审批流程,42,-,精益产品管理的影响地图,小批量工作使工作流可视化收集和实施客户反馈进行团队实验,精益产品管理,软件交付效能,更少的加班加点,Westrum企业文化,组织的效能,43,-,领导力很关键,组织转型领导,44,-,DevOps教练,领导力转型的5个维度,45,-,转型领导力和效能之间的关系,持续交付,测和部署动化持续集成主开发前置安全管理松耦合架构赋能团队,转型领导力个体认同支持型领导智力激发舞型沟通愿景,精益产品管理团队进行试验小批量工作收集和实施客户反馈,IT效能,商业性效能,组织的效能,更少的部署痛点,2016,46,-,我们一起能将工作做的更好,47,-,总是有更好的方法,聪明的投资在技术和实践上，使我们的作变的更好：作在：减少部署痛点作在：降低精疲尽/