什么是DevOps?谷歌开展DevOps的SRE方法介绍!

DevOps这个概念已实施多年,但是在业界不同公司的实施程度落差很大,走在前面的公司可以玩的很熟练的,有的还不知道什么叫DevOps。

定义:DevOps是什么?

根据维基百科的定义:DevOps是过程、方法和系统的统称,促进Development、Opeartion和QA部门间的沟通、协作与整合。

什么是DevOps?谷歌开展DevOps的SRE方法介绍!

DevOps示意图,来源:维基百科

为什么要DevOps?

随着公司持续成长,系统的规模、功能、复杂度、事件与更新次数变多,有很多额外的工作,必须要手动处理回应各项事件。

而公司通常在应用程序的发展中,分开发和运维,有些会有测试部门,而开发与运维部门由不同背景、技能、目标和激励措施不同,容易产生冲突。

  • 开发:我做了个超炫的功能,什么时候可以上线?
  • 运维:不要停机,不要更新,不要挂掉

如果程序发生了重大错误时间,就会变成这样:

  • 开发:都是你没上新版,新版已经解决了这个bug
  • 运维:你还敢说,上个月那一版,部署完网站就挂了
  • 开发:可是我在电脑上是好的!

这种情况发生在任何角落,不仅仅在开发和运维上,也就是我们所说的“谷仓效应”

简单说就是各部门之间变成孤岛,发生冲突之后,部门之间互不信任,使用各种措施阻碍对方:

  • 维运:根据以前发生过的错误,准备一连串的 Checklist。
  • 开发:强调这不是改版,是微调,可以直接上。

部门间从合作变成互相角力,拖慢了整个系统开发流程。

同样的事情发生在 Google ,而 Google 又怎麽解决这样的问题呢?

2003年成立 SRE Team (Site Reliability Engineering) ,组成如下:

  • 50%~60% 纯软件工程师。
  • 40%~50% SRE软件工程师(网站可靠性工程师)。

SRE 软件工程师必须要:

  • 运维产品
  • 建一个系统來执行运维的人工操作

Google 规定, SRE 只能花50%的时间做 ticket、on call、人工操作,超过 50% 的部分,指派给开发团队负责。

所以开发团队则是要:

  • 开发产品
  • 如果 SRE 太忙,要帮忙分担工作

所以 SRE 除了做运维,也要写运维的程序,而开发团队除了写产品的程序,也要做运维。==>>产生交叉培训。

也带來了其他好处:

  • 系统变大变复杂,却不需雇佣更多人。
  • 软件更新速度保持不变。
  • 软件不用停机就可以直接进行修改。

什么时候导入DevOps?

那什么时候要导入 DevOps 呢?只要有以下症状,都可以考虑看看:

  • 开发部门无法在开发早期侦测软件缺陷
  • 无法确定问题出现在哪一个部门
  • 人为错误经常发生
  • 只要部署出去, Dev 就认为工作完成
  • 问题发生,相互指责

如何导入DevOps?SRE导入方法

那要如何导入 DevOps 呢?五大原则如下:

  • 接受失败(Failure),视失败为开发周期中的一个元素
  • 减少组织之间的仓谷效应
  • 持续改善
  • 善用工具和自动化
  • 任何事都是可以被量测的

1.接受失败(Failure)

就像我们去考试一样,从90分进步到99分比较容易,还是从99分进步到100分比较容易?

Google 的解释是这样的,为了达到 SLA (Service Level Agreements)100%,中间有太多不可抗力因素,例如从你的应用程序传信息要先到电信商的基地台,中间可能已经是99.9%的 SLA ,再从基地台传到你的手机可能又是99.9的 SLA ,这里都还没算到你开发的应用程序可用性, SLA 就已经是98.9%了,那你要怎麽做到100%?

先买下电信商,再买下那支手机的制造商,然后请超厉害的工程师把APP写到100分?然后呢?你做到 SLA 100%了,客户感受到你0.1%的进步吗?客户愿意为了你0.1%的进步而多付100万吗?

我们回过头来讲错误预算,直白一点的意思是“在没有超过约定好的中断时间之下,我们有多少时间可以拿来做一些创新的尝试”。所以错误预算可以:

  • 培养不究责的文化 Blamelessness => 以利事后调查
  • 允许犯错 => 鼓励创新
  • 用来承担 Launch 的风险 => 做到快速 Launch

这看起来有没有像我们学生时代,老师对我们的教诲,不要怕犯错,Try and Error?

现在呢?多做多错,少做少错,不做不错。欢迎来到大人的世界。大人讲的都是对的吗?官越大,越正确,你不知道吗?(怨念好深……)

是的,现在是团队合作的社会,为了不造成别人麻烦,或怕被惩罚,或是怕犯错变成别人攻击的对象,我们总是避免犯错。为了避免犯错,我们就不再创新了。枪打出头鸟啊~ DevOps 第一条原则就把我们的脸打得好肿。

2.减少仓谷效应-infrastructure as a code

就是尽可能让环境,用统一规管的格式或设定档(例如 yaml 档)来部署,而不是人为去设定网络和服务器等:

  • 让开发/测试/生产环境长得几乎一模一样,提早发现错误
  • 可以被版本控制工具所管理 (如 git),这代表任何的改变都有迹可寻
  • 减少人工所产生的错误
  • 达成自动化

这样如果一套程序在开发环境run不起来,在测试或生产环境一样run不起来,要发现错误容易的多,大家一起来看 yaml 档就好了。而且谁做错全部的人都知道,不用推责任给别人,也不用故意放大检视他人,大家心里知道就好,犯错的人也会默默检讨,毋需指责。

3.持续改善 – 使用 CI/CD

什么意思?谁不会持续改善,每个人都会不是吗?听起来好像废话。

这里讲的持续可以用“渐进”来解释,以前系统要改进,可能是收集完使用者回馈的100项缺点,一口气全部改完再给使用者,就跟瀑布模式的系统开发流程一样,常常要交付给使用者时才发现跟原始的需求不一样。

所以这里强调的是,只要修正一个点,就交付给用户测试看看,测试OK再改下一个。这里用到的具体做法就是 CI/CD,注意CD有两种:

  • 持续整合 Continuous Integration

持续验证开发结果 ,小部分小部分地尽早确认,期望产出符合需求,或依据产出进行快速修正。

  1. 建置 (build)
  2. 测试 (test)
  3. 程序码分析 (source code analysis)
  • 持续交付 Continuous Delivery
  1. 发行到测试环境,确保软体持续保持在随时可以释出的状况。
  • 持续部署 Continuous Deployment
  1. 自动部署到生产环境。

自动化 – 减少手动

什么是手动呢?手动的特征如下:

  • 手动执行 script、开关机、上新版程序
  • 对每个新客户进行的重复性工作
  • 没有永久的价值(长期的改善)

因为这些工作是不断重复的,因为重复就会感到单调,因为单调做起来就觉得很没劲,甚至厌烦,久了甚至会忽视,不专心地做这些事情,这样出错的机率反而就会提高。

我曾经在以前的某个公司,也做过某件明明对公司就非常重要,却没有人重视也没有人关心的手动,刚好有一次工作太忙,又觉得自己做很多次自以为熟悉,就忽略了一两个检查步骤,然后好死不死就刚好系统有问题没检查到,造成最后一条龙的流程全部受到影响,并且要全部重来,最后在检讨会议上给别人盯着看~

所以自动化说有多重要就有多重要,并且搭配渐进式部署 (Progressive Rollout)

  • 一次发布一点点变动,并且针对少量使用者发布,每次的变动都可以密切地监控效能是否有什么影响。
  • 快速准确地发现问题。
  • 出现问题时安全地回滚更改。
  • 只要错误减少,产品交付就会加快。

任何事都是可以被量测的

这一点是跟 CI/CD 最大的差异之处,它强调的重点如下:

  • 监控是追踪系统健康和可用性最好的方法
  • 如果必须要有人阅读电子邮件, 并判断是否需要采取行动的系统,从根本上是有缺陷的。
  • 只有一定要采取行动的时候,系统才发出通知。

什么是DevOps?谷歌开展DevOps的SRE方法介绍!

透明监控达成资讯透明

跟之前「减少谷仓效应」的概念类似,就是要让所有事情都透明化,所以才需要监控这个关键步骤,这样发生任何事,都能快速找到原因,而不是浪费时间在那边跟别人吵架。

以上提到的实施方法,就是 Google 提出的 SRE (Site Reliability Engineering) 概念。

{{o.name}}


{{m.name}}

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/103390.html

(0)
上一篇 2021年8月25日 10:08
下一篇 2021年8月25日 10:12

相关推荐

发表回复

登录后才能评论