当前课程知识点:软件工程与软件自动化 > 第六章 CI/CD与DevOps > 6.3 DevOps > DevOps授课视频
嗨,大家好
今天我们来讨论DevOps
首先我们来看一个典型的产品部署时发生的故事
开发部门使用最新最炫的技术
没日没夜地加班熬夜,终于如期完成了任务
当他们把自己的杰作一股脑地甩给了运维部门之
后
就已经迫不及待地开始了庆功会
祝贺自己又给公司挣到了一大笔钱
但是,从接到产品的那一刻起
运维部门的每个人心中都充满了恐惧
他们为什么害怕呢?
可能是用户的生产环境太老了
根本支持不了这么新的技术
也可能是这款产品的体系结构跟用户的环境模型
根本不匹配
还可能是这款产品的技术他们根本搞不懂
在一片抱怨声中,运维部门终于把这款产品安装
好了
但是由于做了很多蹩脚的修改和不合理的强迫运
行
用户拒绝接受这款产品
于是运维部门就开始把责任推到开发部门头上
而开发部门的回应总是那么理直气壮
这不是我们的错
我们的代码非常完美
在我们的机器上跑没问题
是你们运维部门的部署做得太差劲了
是你们运维部门太笨,不懂新技术
最后已经不需要确定是谁的责任了
因为公司和客户都蒙受了巨大的损失
无论开发人员和运维人员之间的这种指责
多么的有道理或者是没有道理
这种不同工种之间的隔阂存在已久
这种隔阂来源于软件开发企业的组织架构
开发企业一般是按照软件的开发流程来划分不同
的部门
开发部门的驱动力往往是“频繁的交付新特性”
而运维部门的驱动力往往是客户
他们追求的是系统的稳定性和其他的非功能性需
求
这种目标的不匹配造成了开发与运维部门之间的
鸿沟
这进一步减慢了产品交付的速度
运维是IT公司的服务庞大到一定程度,必须出现
的服务人员
他们对用户负责,通过监控,架构优化
自动部署等等,来保证服务的及时变更和稳定
对于大部分软件开发人员来说,由于缺乏运维的
工作经历
他们在工作的时候很难从运维的角度来
来考虑代码的优化和约束
也就是说,开发人员在设计和开发的时候
面对的是无限的资源和技术
而运维人员在部署的时候却面对着
有限的资源和各种各样的约束
正是开发部门和运维部门之间的隔阂越来越大
最终导致了一场名为DevOps的运动
DevOps可以看作是一组过程、方法和系统的统称
当企业希望将原本笨重的开发和运维之间的
工作移交这种过程变得更加流畅的时候
就可以借助DevOps来完成
DevOps的出现是由于软件行业日益清晰地认识到
为了按时地交付软件的产品和服务
开发和运维工作必须紧密合作
DevOps中的Development就是以运维需求为目标
它与系统本身那种纯粹的为了满足业务需求的开
发
并不完全相同
有的同学会问了,为什么会选择开发和运维
这两个部门进行合并呢?
这是因为软件开发活动中典型的价值
就存在于业务和客户之间
业务定义了需求,客户体现了交付价值
虽然大家在讨论DevOps的时候
主要关注开发和运维之间的融合
但是在DevOps的权威资料中却给予了QA同等重
要的地位
我们知道,DevOps是基于持续集成和持续部署的
它的高部署的频率通常会给QA和信息安全
带来很大的压力
比如开发活动可以做到每天部署10次
但是信息安全通常需要4个月的时间来评估应用的
安全性
很显然,在代码开发和代码安全审计方面
很显然,在代码开发和代码安全审计方面
存在着频率不匹配的这种现象
但是从另外一个角度来看
开发会通过持续集成和好的发布惯例
来维持这种高频率的部署
一旦代码被提交,自动化测试便开始运行
而且一旦发现问题,马上解决
通过把单元测试、集成测试、信息安全测试
和质量保证都加入到持续集成和持续部署流程当
中
我们可以更快地发现问题,更快地解决问题
从而更好地保证产品的质量
在传统的开发和部署过程当中
软件开发的各个角色通常只关注自己本身的工作
虽然大家都处在一个项目当中
但各自划分了领地
产品经理就应该将市场需求文档
我们叫MRD,写得清清楚楚
如果开发人员认为你写得不清楚,那就拿回去修
改
开发人员只管按照MRD上的内容进行开发
很少考虑可测性和易测性问题
测试人员只管按照MRD中的内容来进行测试
有问题通过内部工作流平台提交问题单
运维人员只管根据开发人员提交的上线操作单进
行操作
似乎各个角色之间的沟通介质只有各自的提交物
现在,各种角色都能够共同合作
以项目的最终交付作为目标
积极地讨论需求,优化实现
因为角色之间的这种紧密合作让所有人
对不同的角色都有了更深入的了解
开发人员耐心地为产品经理解释技术的实现
说明计划安排
测试人员与开发人员共同讨论验收条件
避免遗漏需求
开发人员让运维人员了解架构设计
细心听取运维人员的建议,进行技术改造
使部署工作更加快捷有效
大家可以看的出来
DevOps与敏捷开发方法存在着密切的关系
敏捷开发过程的一个基本原则就是以更快的频率
交付最小化可用的软件
在敏捷的目标里,最明显的就是在每个迭代周期
的末尾
在敏捷的目标里,最明显的就是在每个迭代周期
的末尾
都给出了一个可交付的软件
敏捷的这种高频率的交付能力
经常会导致大量的部署工作都堆积在运维人员面
前
经常会导致大量的部署工作都堆积在运维人员面
前
这种堆积导致了客户眼睁睁地看着
近在咫尺的软件产品却无法使用
无法得到任何商业价值
而DevOps的目的就是希望能够把运维
也纳入到敏捷开发和敏捷运维过程当中去
让敏捷开发和运维的每个迭代周期
都能够直接完成自动化的部署,完成整个流水线
从而使得软件开发企业作为一个整体
重新获得客户的信任
根据2013年的一份DevOps现状调查报告
采用DevOps的企业的交付速率是竞争对手的30倍
发布失败率也低于50%
毫无疑问,DevOps活动可以帮助企业
更快、更多、更简单地完成价值交付
比如,通过亚马逊的记录显示
他们在保持目前每周部署1000次的情况下
还能够保证99.999%的成功率
在一般的团队中,总是存在选择稳定性
还是新功能的矛盾
开发团队和运维团队的目标是冲突的
开发团队的KPI就是向用户发布新功能
运维团队的KPI就是系统的稳定性
矛盾是必然的
在采用DevOps的团队中
一个跨职能的团队负责所有的工作
包括交付新特性和系统稳定性
团队采用很多实践,比如共享的代码库
持续集成、测试驱动、自动化部署等等
不管是代码的问题还是基础设施的问题
还是配置的问题
都可以很快的暴露出来并得到修复
因为软件不再是开发完了就扔给运维
问题的修复周期变得更短了
因为团队无需等待外部团队来分析和修复问题
当人们清除掉工作的浪费之后
可以有更多的时间为企业、为用户创造更多的价
值
自动化部署和环境的标准化是DevOps的核心元素
可预测的发布和避免重复工作
可以提高团队的效率
从前面我们可以了解到
引入DevOps活动的时机正在变得更加成熟
越来越多的开发团队采用敏捷
或者其他轻型的软件开发方法
开发工作的自动化程度也越来越高
无论是客户还是业务负责人
也越来越重视商业价值的体现
要求加快产品交付的频率
虚拟化和云计算的基础设施日益普遍
使得传统的运维工作所必须面对的
那种简单枯燥、低技术含量的工作不复存在
实体机器和机房进一步集中
大部分企业不需要购买机器和维护机房
只需要购买所需的云计算设施就可以了
计算中心,数据中心的自动化技术和配置管理工
具的普及
也进一步减轻了运维人员的工作强度
开发与运维之间的鸿沟日益严重
这个鸿沟可以用DevOps来消除
同时DevOps还可以改善团队协作关系
提高团队效率,降低生产环境的风险
那么软件公司如何引入Devops呢
一般可以通过三步走的方式来完成引入工作
第一步要弄清楚“为什么”,也就是要统一思想
要让团队中的每个人都明白团队的职责是创造服
务
第二步要实现组织合作
就是让所有人基于统一的规则来完成一个共同的
目标
这一点可以通过遵循下面的步骤来实现
首先要教导团队成员一些基本的概念
尤其是团队可以使用的自动化软件开发工具
其次是要让所有人的目标一致
这可以借助价值流程图、时间线分析
和浪费分析等一些分析工具和分析的方法
比如时间线分析可以帮助团队成员发现
时间花费在哪里,瓶颈在哪里
然后是发现度量链
就是对价值交付链中的各个活动进行度量
发现各个活动相互之间的影响
然后针对基线识别项目
识别哪些项目或者活动偏离了基线
并且采取纠正措施
这些步骤要形成迭代
从而形成一个可以持续改进的流程
第三步就是持续改进循环
这些循环的目的是通过制定计划、实现计划
测量输出和决定如何持续地改善流程
通过持续地,渐进地推进团队建设
推动持续集成和持续部署,优化软件开发过程
最后才能达到DevOps所要求的程度
我们一般把DevOps看做是一种能够
改进开发人员和运维人员之间协作关系
简化软件开发过程的工作方式
但目前DevOps的根本定义已经变得有些混乱了
现在DevOps已经拥有十几种不同的定义
有些定义所强调的内容会给企业和工作人员带来
伤害
比如,并不是每家公司都是新兴企业
但在DevOps的影响下
他们似乎都希望假装自己属于新兴企业
有的企业强迫开发人员承担运维人员和其他人员
的角色
的确,在一个创业公司的开发者可能同时承担
开发,QA,运维人员,系统管理员,DBA
甚至其他任何的形形色色的职位
但反过来却是行不通的
比如,QA 就不能凑合着当开发人员使用
构建工程师也做不了DBA 的工作
他们不具备担任这些角色所必须的专业知识
每个组织里都有这种层级的关系
而成员的能力层次、技术水平也是不同的
如果你让开发去做其他的工作
但没有人能来替他做开发的工作
之前那些职位由不同能力层次的人来分别担任
而全能的开发工程师使得这些职位没有必要存在
了
大公司非常喜欢这一点
因为这意味着它们可以大量的缩减员工数量
来完成同样的工作量
然而,在这个过程中
真正的开发在开发者的工作中所占的比例越来越
小
正是看到了这种情况
有人发出了这样的呼声
看在上帝的面上,让开发人员写代码吧!
好,今天的内容就讨论到这里,谢谢大家
-1.1 软件工程的前生今世
--开篇阅读
--授课视频
-第一章 软件工程基础--1.1 软件工程的前生今世
-1.2 万变不离其宗
--授课视频1/3
--授课视频2/3
--授课视频3/3
-第一章 软件工程基础--1.2 万变不离其宗
-1.3 唯一不变的是变化
--授课视频1/3
--授课视频2/3
--授课视频3/3
--外部链接
-第一章 软件工程基础--1.3 唯一不变的是变化
-1.4 亡羊补牢为时不晚
--授课视频1/2
--授课视频2/2
-第一章 软件工程基础--1.4 亡羊补牢为时不晚
-扩展阅读与话题讨论
--扩展阅读
--话题讨论
-2.1 方法论来源于恐惧
--授课视频
-第二章 敏捷开发--2.1 方法论来源于恐惧
-2.2 敏捷是什么
--授课视频
-第二章 敏捷开发--2.2 敏捷是什么
-2.3 典型敏捷开发方法
--XP敏捷开发方法
-第二章 敏捷开发--2.3 典型敏捷开发方法
-2.4 敏捷不是万能药
--授课视频
-第二章 敏捷开发--2.4 敏捷不是万能药
-专家谈敏捷
-扩展阅读与话题讨论
--外部链接
--话题讨论
-3.1 面向对象核心概念和基本特性
-第三章 OO与UML--3.1 面向对象核心概念和基本特性
-3.2 面向对象设计基本原则
-第三章 OO与UML--3.2 面向对象设计基本原则
-3.3 通用职责分配模式(GRASP)
--通用职责分配模式
-3.3 通用职责分配模式(GRASP)--作业
-3.4 从重构到模式
--模式和设计模式
-第三章 OO与UML--3.4 从重构到模式
-3.5 使用UML设计面向对象系统
--UML综述
-第三章 OO与UML--3.5 使用UML设计面向对象系统
-3.6 主要UML模型图绘制技巧
--UML用例图
--UML类图
-第三章 OO与UML--3.6 主要UML模型图绘制技巧
-扩展阅读与话题讨论
--设计模式有毒么?
--话题讨论
-4.1 案例简介
--书籍参考
--案例说明
-4.2 对象模型之一
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.2 对象模型之一
-4.3 对象模型之二
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.3 对象模型之二
-4.4 对象模型之交互
--授课视频
-第四章 对象模型分析--4.4 对象模型之交互
-扩展阅读与话题讨论
--图书推荐
--话题讨论
-5.1 软件自动化概述
--软件自动化概述
-第五章 软件自动化技术--5.1 软件自动化概述
-5.2 典型自动化方法和工具
-第五章 软件自动化技术--5.2 典型自动化方法和工具
-5.3 文档自动化
--文档自动化视频
-第五章 软件自动化技术--5.3 文档自动化
-5.4 测试自动化
--测试自动化视频
-第五章 软件自动化技术--5.4 测试自动化
-专家访谈
-扩展阅读与话题讨论
--话题讨论
-6.1 持续集成
-第六章 CI/CD与DevOps--6.1 持续集成
-6.2 持续交付和部署
-第六章 CI/CD与DevOps--6.2 持续交付和部署
-6.3 DevOps
-第六章 CI/CD与DevOps--6.3 DevOps
-专家访谈
-扩展阅读与话题讨论
--DevOps专题
--话题讨论
-7.1 质量和质量保证
--授课视频
-第七章 软件质量保证--7.1 质量和质量保证
-7.2 软件质量模型
--授课视频
-第七章 软件质量保证--7.2 软件质量模型
-7.3 SQA组织与职责
--授课视频
-第七章 软件质量保证--7.3 SQA组织与职责
-7.4 全面软件质量管理
--授课视频
-第七章 软件质量保证--7.4 全面软件质量管理
-专家访谈
--专家访谈
-扩展阅读与话题讨论
--外部链接
--话题讨论
-8.1 软件过程综述
--授课视频
-第八章 软件过程改进--8.1 软件过程综述
-8.2 软件过程改进
--授课视频
-第八章 软件过程改进--8.2 软件过程改进
-8.3 能力成熟度模型
--授课视频
-第八章 软件过程改进--8.3 能力成熟度模型
-8.4 过程改进标准框架
--授课视频
-第八章 软件过程改进--8.4 过程改进标准框架
-扩展阅读与话题讨论
--话题讨论
-9.1软件复用综述
--授课视频
-第九章 软件复用--9.1软件复用综述
-9.2 软件构件技术
--授课视频
-第九章 软件复用--9.2 软件构件技术
-9.3 软件复用实施
--授课视频
-第九章 软件复用--9.3 软件复用实施
-9.4 微服务架构
--授课视频
-第九章 软件复用--9.4 微服务架构
-扩展阅读与话题讨论
--微服务扩展
--话题讨论
-文档提交处--文档提交