敏捷运维的实操 -- 迭代内工作量

好了，现在我们做好准备，即将进入敏捷运维的世界了。

运维是否敏捷不代表是否先进，我这里只是说了我怎么通过敏捷运维的方式来实现一个目标，那就是工作量的透明化。

运维的一个很明显的特色就是我们需要随时根据实际的需求变化来调整运维工作的内容。常规情况下，我们可能是制定好计划，开始按照计划工作。如果遇到突发性任务，就会优先处理高优先级的突发性任务，同时将计划好的工作向后延期。即使我们采用敏捷运维，遇到的情况也是一样的，我们也要面临顺眼问题。但是，对于敏捷管理来说，一个迭代里需要做的事情是需要预先计划好的。那么怎么处理呢？

这个时候，计划好迭代内工作量就显得十分重要。在前面的章节里，我们说过，敏捷运维的过程中，我们将日常工作分为三大类：

重复性任务 -- 确定性的重复性工作，例如数据备份，定期系统安全检查，固定的系统运维报告
可计划任务 -- 根据各类要求对系统进行操作，例如计划性补丁，系统增强
突发性任务 -- 突然发生的系统故障，临时提交的系统变更请求

这种区分的目的是为了解决迭代内工作量的规划问题。前两类问题在处理上有相似之处。我在下边分类描述一下工作量的处理

重复性任务 --这部分通常工作量是相对固定，而且可以计算的，我们要做的就是计算好总的工作量，然后合理的分配到每个迭代当中，通常可以比较容易的确定每个迭代周期内的此类工作量。这里有一个要说明的事情，就是这类工作如果可能的话，尽量通过自动化工具来完成。
可计划任务 -- 这类工作从性质上说每台服务器上只发生一次，但是对整个被服务的服务器集群来说，是多次发生的，需要在一定时间段内完成。这类工作虽然有相当一部分可能可以通过自动化工具来完成，但是各个不同的系统环境往往会带来个性化问题，仍然需要较多的人工干预。可以相对粗略的估算、计划处每个迭代周期内的工作量。
突发性任务 -- 这类工作的不确定性决定了在工作量的估算上，很难准确，这种不确定性会严重影响整个迭代的任务进度，在极端情况下，这类突发性任务会占据整个迭代资源池，阻碍其他任务的完成。我曾经遇到过一次公司内部的严重的事故。大量的服务器收到影响，我所在部门，全球所有时区的员工都被要求参与到系统的恢复当中。基本上我们的日常工作都受到了极大的影响。不得不把上两类工作推后。我会在后边慢慢解释面对这种情况，我们是怎么应对的。

根据上面的划分，在实际操作过程中，我们将为每个迭代的工作量用这样一个方式来分解

根据这个工作量划分，我们将各类工作在每个迭代周期内的工作量用下表中的字母代替

	最乐观迭代期内可完成工作量
重复性工作	E-r
可计划工作	E-p
突发性工作	UE

在上边的工作量估计中，我们假定UE可以预测，因此制定了E-r和E-p。

所以一个迭代周期的总工作量=E-r + E-p + UE。

但是就像刚刚说过的，突发性任务的不确定性为迭代进度带来了非常恐怖的影响。为了处理这个问题，我们引入了活动任务池的概念。对于前两类工作，可以作为每个迭代周期内的工作量的固定组成部分，我们会对他们有一个预期，就是那个“最乐观迭代期内可完成工作量”，同时，在规划的过程中针对每类工作，制定一个活动任务池。以重复性任务为例，所谓的活动任务池就是将原本最乐观的情况下，能完成的该类的任务的最大任务量-Er进行进一步分划分，其中一部分作为最基本的工作量（除非发生及特殊情况下不能进一步缩减）- Br，另外一部分作为活动任务池的内容 - Vr。

由于突发性工作的不确定性，我们可以根据历史经验进行估计，但是无法准确计划。实际情况中，UE是不定的，小组的速度（每个迭代内的总工作量）是固定的，所以E-r和E-p是不能提前预知的。所以需要对上边的各个不同类型的工作量如下表：

	最乐观迭代期内可完成工作量	最基础工作量	活动任务池
重复性工作	E-r	B-r	V-r
可计划工作	E-p	B-p	V-p
突发性工作	UE

这个时候，迭代内工作量的公式变成了

所以一个迭代周期的总工作量=B-r + V-r + B-p + V-p + UE。

请注意，在我们的新模式下，E-r <> B-r + V-r。

为什么？

要注意E-r的定义，这个是最乐观的迭代期内的可完成工作量，这里边的最乐观是指我们根据历史经验预测出UE之后估算的一个平均值。在引入活动任务池的概念之后，在UE非常小的时候，V-r可以很大，甚至完全挤占我们预估时为UE留下的工作量空间；在UE很大的时候，V-r很小，整个迭代周期内，基本上都是在完成突发性任务。

所以我们的迭代内工作量的划分变成了以下的样子。

这么划分有什么用？

请注意，这种划分的一个重要的作用是让团队人员知道他们这个周期内要完成的工作池。而且这个迭代周期内的工作池是从巨大的任务海总划分出来的，成员可以清楚的知道他们被期待要做的事情，在发生变化的时候，他们很容易的就可以自行决定本迭代周期内需要做的取舍。而且，每个迭代的可管理性大大提高。

由于突发性任务引起的活动任务池里的工作被舍弃，这种情况下被舍弃的工作会自动进入的下个迭代，重新处理；另一方面，如果突发性任务很少，活动任务池里的工作可以保证团队会尽早地完成未来需要执行的任务。并以此不断地高效的清理总任务池。

这里边有几个关键：

制定好最基础工作量，活动任务池
做好一个大周期的计划-例如4个迭代
好好激励成员
不断提高成员能力

敏捷运维的实操 -- 迭代内工作量相关推荐

福利 | 2022全球敏捷运维峰会：跟技术老将畅聊时下数据库、运维、金融科技应“云”而生的技术创新...
文末有数据派THU福利哦 2022年度Gdevops全球敏捷运维峰会,将于5月13日以广州为起点正式开启! 与大家携手走过的第7个年头,Gdevops始终坚持输出技术干货.传播前沿理念与实战经验.本次 ...
数据中心的敏捷运维之路
随着数据中心的建设规模越来越大,出现了很多大型,特大型的数据中心.这些数据中心往往拥有数万台的服务器规模,再加上互联的网络设备.防火墙.负载均衡等设备,一个大型数据中心需要管理同时运行的几万台设备,并 ...
Gdevops精彩不落幕，敏捷运维盛会圆满收官！(附PPT)
继杭州首站的盛大起航,北京.广州两站的持续升温,贯穿全年的"2016年全球敏捷运维峰会"于11月18日在上海圆满收官!这场意义非凡的收官盛会,特别设置了一个主会场和两个分会场,在总 ...
TEG Cheers | 腾讯技术工程运维技术沙龙精彩回顾(内置现场视频)
7月28日,腾讯技术工程运维技术沙龙-深圳站在腾讯大厦2楼多功能厅举行.现场集结了数十家知名企业的技术开发和运维小伙伴,通过5个小时的思维碰撞,运维人员和导师们一起打造了一场运维人的知识盛宴. 这次, ...
参加“全球敏捷运维峰会（北京站）”有感
峰会介绍: DevOps作为打破开发和运维之间壁垒的方法论,在打通应用全生命周期工具链路的过程中,扮演着极为重要的角色!如何高效实现敏捷运维,如何让运维更加敏捷化,俨然成为当下所有企业的必答题目. 全 ...
Gdevops 2017全球敏捷运维峰会即将登陆北京！
Introduction 全球敏捷运维峰会打造敏捷与运维领域标杆峰会! 2017年全球敏捷运维峰会(Gdevops, Global Devops Summit)将于2017年在成都.上海.北京.广州 ...
Gdevops全球敏捷运维峰会起航成都！
带着一众IT人的期许与寄望,今年的Gdevops峰会将于5月13日在成都拉开序幕!本次峰会由上海市经济和信息化委员会指导,上海市云计算产业促进中心.DBAplus社群主办,中生代技术.新炬网络.Lin ...
PPT下载丨2021 Gdevops全球敏捷运维峰会-广州站精华回放
重磅开篇!大量干货PPT开放下载方式1:登录以下链接并输入提取码1015 https://pan.baidu.com/s/1Hd1v9qPm04dyfOI6oWaGVw 方式2:点击文末[阅读原文] ...
数据库的运维策略脚本篇（内附脚本，无私分享）
数据库运维中盛传一个小段子,我误删除了数据库,改怎么办?有备份还原备份,没有备份就准备简历!听起来有趣但发生在谁身上,谁都笑不起来.接触了很多的客户发现90%客户的运维策略都不是很完善.本篇就分享一些 ...

敏捷运维的实操 -- 迭代内工作量

敏捷运维的实操 -- 迭代内工作量相关推荐

最新文章

热门文章