中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究...

内容来源:DevOps案例深度研究第4期 – 火神山雷神山 DevOps实践研究战队(本文只展示部分PPT及研究成果,全程视频请移步文末)

本案例内容贡献者:赖泽薇、张扬、邓茜芸、韦一、刘德权、候利涛、冯利娟、常相宇、张力、韩丰、陈浩 

IDCF指导老师:王立杰、许舟平、姚冬、徐磊

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第1张图片

(图片来源于网络)

一、中国速度,为瀑布站台

我们看一下火神山雷神山建设的整体过程,它是典型的瀑布模式。主要体现在阶段定义清晰、顺序串行开展,前期规划驱动,交接棒式进行,上一个阶段的输出是下一个阶段的输入。由于前期在时间、范围和成本方面做了强力的约束,那么在进行中不接受变化,因为变更代价巨大。

在上世纪60年代软件危机爆发之后,软件行业继续找到一种科学体系化的方法来进行软件开发,最早的瀑布模型就是来自于工业制造和建筑建造的模式。

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第2张图片

但是为什么在我们的软件领域,要从起初瀑布模式往敏捷模式演进?因为软件开发不确定性更多,需要快速应对变化的需求,业界对研发模式方面也在不断地探索,如何提升效率、提高软件质量。常见的几个模型有瀑布、螺旋、迭代、敏捷。

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第3张图片

其特点主要表现为:

  • 瀑布式开发:顺序开展、文档驱动。要求每一个环节的工作尽可能充分讨论、论证,减少施工风险,减少返工。

  • 螺旋开发:开始将瀑布开发的模式进行粒度的拆分,将整个开发过程划分为一个个阶段,在每个阶段引入风险分析。它是风险驱动的方法体系,在每个阶段之前,都必须进行风险评估,使软件在无法排除重大风险时有机会停止,以减小损失。但螺旋开发更倾向于是增量开发方式,它将整个软件功能的开发拆分为多个可控的阶段,最终的软件交付还是在最后一步。

  • 迭代式开发:在螺旋开发之上出现了先保证能用,再想办法让它好用。不要求每一个阶段的任务做的都是做到尽善尽美,而是根据优先级来交付高价值的功能。以最短的时间构建一个 MVP,交付给客户之后,再通过客户或用户的反馈,逐步进行完善。 

  • Scrum框架:是一个包含增量和迭代的框架。强调固定周期、固定节奏、强调团队协作,强调质量、强调成果可发布,能快速被验证。

那么我们如何选择这些模型和框架?

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第4张图片

其实对于简单域,我们更推荐瀑布模式。因为需求明确、范围清晰、周期确定的情况下,瀑布也可以很快。只需要强有力的执行计划、不断提升技术,自动化一切,有效的沟通,团队赋能就可做到快速交付,而无需反复验证确认。

但是有个问题是,软件开发往往是一个繁杂或者复杂的过程,因为需求是不断变化的。尤其是对于创新型的业务应用,在一开始的时候只是一个商业想法,构建业务应用也是为了快速验证这个想法是否可行,这是一个不断假设和验证的过程。在这样的场景下,敏捷模式是更合适的。

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第5张图片

其实我们很多人都忽略了敏捷宣言的最后一句话,往往最后一句话也是最重要的。这句话是“也就是说,尽管右项有其价值,我们更重视左项的价值。” 它想表达的是尽管瀑布价值有其价值,但是我们更重视敏捷开发的价值,这是一种价值观的取舍。所以很多时候瀑布和敏捷会存在融合。

从火神山雷神山医院的建设来看,在整体上很多项目不得不以瀑布计划的方式进行,核心是减小瀑布模型的粒度,采用敏捷开发的优秀实践方式,提高开发的沟通效率。

二、中国速度,中国质量

从早期丰田的精益生产系统,一直到目前流行的DevOps理论框架,关于项目质量管理的方法论有很多种。在这里,我将这些历史的和现存的各种质量管理的核心思想抽象并概括为“质量内建三部曲”,即:

从“做正确的事”,到“正确地做事”,再到“最小的质量成本”。

从项目生命周期的维度,按照质量内建的原则,分别从设计、实施、验收和运维这四个阶段进行质量管理和控制。

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第6张图片

三、全能运维,召之即来,来之即战

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第7张图片

两座医院的医疗团队组建起来了,是不是就可以按部就班开展救治,就万事大吉了?很显然并不是,等待医疗团队来解决的困难还有一大把呢,我们这里列出了医疗团队在接手救治的过程中面临的四个方面的主要困难。

  • 一是业务非常紧急但是医院的交付却谈不上多么完整。多个支援雷神山的医疗团队在接手病区后发现,等待他们的几乎都是空空如也的病房。医护人员要让病房工作起来,需要自己先动手到各处寻找、搬运、安装和现场调试众多设备。这就相当于既要当好运维,还得帮开发擦屁股收拾残局。

  • 二是业务类型全新但是培训却谈不上多么充分。两家医院的医疗团队成员本职专长业务千差万别,在疫情的紧急要求下,却都需要在极短时间内完成新冠肺炎诊治这项新业务的培训熟悉,然后立即投入到实际运维工作中。

  • 三是团队都是临时组建,投入实际诊治工作之前缺乏必要的磨合。由于各个医疗团队都是来自多个地方的人员临时组建而成,收治工作过程中的所有配合与协作,都是从零开始,这对所有运维人员的业务素养和团队配合能力都提出了极高的要求。

  • 四是疫情严重,医护人员本身处在一线,被传染的风险极高。这就要求全体医护人员在开展收治工作的过程中,必须千方百计做好充分的自身防护。

火神山和雷神山两座医院,在短时间内汇集了来自全国各地的军队和地方医护人员,他们克服重重困难,开足马力收治新冠肺炎患者,快速将两座医院的效能发挥到最大程度,成为了此次重大疫情防控战斗的中流砥柱。这些医护人员面临的任务艰难程度是前所未有的,但是他们的实际表现却足以令我们所有人刮目相看。从这个意义上来说,他们绝对称得上是全能型的运维团队。

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第8张图片

东方红,太阳升,春天就要来到武汉城。当我们在这里坐而论道,侃侃而谈的时候,前方传来好消息,截至目前,火神山和雷神山两座医院的医护团队,全都是0感染!距离战役结束双0感染的目标,我们又近了一步!(注:本文成文时间 2020年3月15日)

拓展阅读

本次案例解读分为四篇,本文为第四篇章,请关注本公众号,持续阅读~

  • 第一篇 坚强的领导核心,“小团队大后台”组织结构(点击查看)

  • 第二篇 完善的项目计划,高效能价值流(点击查看)

  • 第三篇 有力的技术保障,基建世界里的云原生缩影(点击查看)

  • 第四篇 全能运维,召之即来,来之即战

中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究..._第9张图片

你可能感兴趣的:(中国速度之二神山建设(4):全能运维,召之即来,来之即战 | IDCF DevOps案例研究...)