DevOps学习笔记（一）

DevOps学习笔记（一）

一直看到自己关注的公众号列表里有在推送DevOps相关的文章，但文章的受众似乎不是给小白看的，所以很多内容都一知半解。这周找来了赵舜东老师的相关课程，算是对DevOps有了较为系统的学习。

首先声明，我仅是站在一名PM的角度来对DevOps进行相关了解，这也就决定了其技术内容肯定不会过于深入，充其量也就能向同为小白的人做一个科普性介绍。

相关学习来源于赵舜东老师的课程，所以本篇文章会借用一些老师的材料。如侵必删。

---

DevOps是什么？

在互联网或软件公司，一般IT组织架构内会分为开发（Dev）、运维（Ops）等部门。软件开发的流程也严格意义上遵循“计划→开发→构建→测试→释放→部署→运维→监控”顺序流程。

随着‘短平快’要求的发展，不仅项目实施越来越敏捷化，程序开发也越来越急需缩短上线的时间，于是DevOps的需求概念就应运而生。

DevOps就是将“开发”和“运维”合并在了一起。和Scrum一样，DevOps也是一组最佳实践，它其实没有固定的表现和组织形式，只是强调专业人员（开发人员，测试人员，运维人员）在应用和服务生命周期中的协作和沟通强调整个组织的合作以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付。

要想学习DevOps的内容，需要从以下四个方面来入手把握：敏捷管理、精益管理、持续交付、IT服务管理。

此外，还要深刻理会DevOps核心思想：从关注价值开始。

首先解释下，什么是价值。

一个功能的成功诞生，要源自于用户的想法或现实问题亟待解决的需求。从想法变成现实，往往需要一定长度时期的软件开发流程的等待。而DevOps的价值就是缩短此间的前置时间，实现敏捷、持续的交付。

在此举一个坊间流传的关于QQ功能优化6h上线的例子。据说马老板在某天凌晨2点在使用QQ时，发现了一个关于用户体验的问题。随即发了封邮件给对应的产品经理。该产品经理于凌晨3点紧急召开了工程师线上开会，立马开发、测试、部署上线。等早上马老板再上班时，晚上的想法已经得到了应用实现。

虽然不知道QQ内部是不是DevOps的实现运营形式，但是体现了一个功能从计划到发布上线6h的可行性。

DevOps的知识体系——敏捷开发

敏捷相较于传统的瀑布开发模式，它的开发周期更为精短，往往2-4周即为一个迭代周期，而每一个迭代周期都有一个潜在可交付的功能内容输出，不用等到完全开发完成之后用户才得以看到应用实体，所面临的的变更优化风险更为轻微，所以深受大家欢迎。

在此之前也有写过文章简单介绍过敏捷管理。在这里我们再简单回看一下Scrum框架的实施。

Scrum框架是大家比较公认的最佳实践。它包括了三种角色， PO ( Product Order ，一般为项目经理或者产品经理)、 Scrum Master （敏捷教练，一般具有资深的敏捷项目管理经验，甚至开发技术经验）、Scrum Team （敏捷团队，一般包括开发、测试、运维在内的小组）。整个团队基本在7个人左右，一般也不会超过9个人，否则管理协作与一般团队也没有什么差异了。

Scrum的三个工件。Product Backlog ，可理解为产品功能需求清单，它涵盖了整个功能的需求点。Sprint Backlog ，可理解为当下一个迭代阶段内的任务需求清单。燃尽图，可理解为常规项目中的甘特图，随着时间进展，需要解决的问题点会随之减少，直至燃尽。

Scrum的五个活动。Sprint 计划会议、每日站会、Sprint 评审会议、Sprint 回顾会议、产品待办事项列表梳理。这五个活动并非一定是要独立开展的，其实可以将计划会议、评审会议、回顾会议每周集中在某个时间点进行；站会和待办事项则可以化解到每天开展。

这里简单提一下站会。顾名思义，站会其实就是 Scrum 团队每天集中站立在看板前，进行的15min左右的沟通会。每个成员需要汇报自己的相关进展，一般包括三个内容：“我昨天完成了XXX任务；今天计划开展XXX任务；其中XXX事项需要XXX协助解决”。简洁而有效。

DevOps的知识体系——精益管理

提到精益管理，其实思想起源于日本丰田公司的精益KANBAN管理。以下是一个看板的简单示例。

它简单包含了三个部分。处理流程，待决事项→分析→开发→测试→部署，每个阶段隶属一个泳道，其中每个阶段可以拆解为‘正在进行’和‘已经完成’。贴纸卡片，每一个贴纸代表一个用户故事/功能需求，将对应阶段的贴纸贴在相应泳道内，可视化当前程序开发进展。WIP数量标识，所谓WIP就是在制品，对于传统制造业可能要好理解一些，就是正在生产的制品。WIP数量即限制该泳道内最多的贴纸数量。

为什么会有WIP限制呢？一方面，无限的生产和库存非但没有价值，反而可能成为高库存负荷的代价，对于开发而言，一味的增加开发任务量同样对于开发程序的质量是没有任何保障的，甚至可能会给后端测试上线带来更多的问题；另一方面，为满足持续交付而迭代发布的功能来说，限制有限的任务数量，可以集中开发力量办大事，加快上线运转速度。

再来看一稍微复杂的实际案例。

---

以上，篇幅关系，暂先分享‘敏捷开发’、‘精益管理’两个核心内容，‘持续交付’、‘IT服务与管理’就放到后面一篇来整理分享。

希望看完的朋友可以点下【喜欢】和【收藏】，这对我十分重要，谢谢。

微信公众号：ActCrew

一个常态性极度拖延（懒人）+间歇性踌躇满志的矛盾体