请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 70|回复: 0

DevOps 和 SRE

[复制链接]
发表于 2021-12-27 17:56:15 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-27 18:03 编辑 6 G% E$ V( _4 q  v/ e  b9 R% |) C

5 [& W. _1 Q( N3 ~) E
最近有一位朋友和我聊职业发展方向问题,聊了不少 DevOps 和 SRE 话题。 我几年前刚接触这两个概念时也常常将之混淆,可惜当时没有人来解答我困惑。 现在这虽然已经极为流行,但是我发现我这位朋友对这两个职位还存在一些误区。 于是我给了一些见解并整理成文章以饕大众。
2 O3 h' E7 Z5 N' f! n
最常见的误区:
+ U! y2 I0 ?- z- N3 \7 R" k
  • DevOps 新概念,好高级
  • SRE 是高级版 DevOps
  • 运维可以轻松转身 DevOps 工程师

    + ]3 p% }* o$ |- \9 F9 X

; M* S9 r! A2 D# S8 o: P) Z9 M! \
让我一一给你讲解吧。
! C. ]: k: J! h; v2 X
粘贴上传202112271756599426..png
, z$ |7 \, k4 T) q) h, P
DevOps 和 SRE 定义) X% [( l7 C% p6 x$ k! \
DevOps 是字面上 Dev 开发 / Ops 运维两者组合, 严格意义上 DevOps 如下(via(DevOps - Wikipedia)(via)):

' w& ?3 X% ?: c1 S' l3 y
DevOps(Development 和 Operations 的组合词)是一种重视“软件开发人员(Dev) ”和“IT 运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。

, ~! v2 S( b# B1 U
SRE 全称是 Site Reliability Engineering,最早是由 Google 提出,并且在其工程实践中发扬光大。 他们还出了一本同名书籍(Site Reliability Engineering)(via)」, 让这个理念在互联网工程师圈子里广泛传播。
& |7 e) Q' O7 A
Google 对 SRE 解释是(via(Site Reliability Engineering - Wikipedia)(via)):

( J7 l" ~6 A- E
Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations whose goals are to create ultra-scalable and highly reliable software systems.
! @7 ]- @& r; X" b+ s* k" g, t
我将其翻译翻译为中文:
) z( a9 ?- O. U5 h
网站稳定性工程师是致力于打造「高扩展、高可用系统」,并将其贯彻为原则的软件工程师。
1 M0 [8 F" o: n$ s, }
从定义来看,DevOps 是文化、运动和惯例,而 SRE 是有严格任职要求的职位。 文化是软性定义,文化有更多概念可以捏造,而 SRE 定义精准,就少了想象空间(也可能 SRE 门槛高 😄)。 按 Google 给出的说法是,SRE 工程师实践了 DevOps 文化。这个观点没错,但是国内的 DevOps 逐步独立出 DevOps 工程师, 所以在本文,我着重讨论的是 DevOps 工程师和 SRE 工程师两种职位对比。
. @" G& \2 o* {) X
两者产生背景和历史
; |8 f. O6 s& P9 B
互联网需求催生了 DevOps 。在最传统软件企业中,是只有 Dev 没有 Ops, 那时 Ops 可能还是只是技术支持人员。开发按照瀑布流:需求分析、系统设计、开发、测试、交付、运行, 传统软件发布是一个重量级操作。一旦发布,Dev 几乎不再直接操作。 80 后可能会记得 QQ 每年都会有一个大版本发布吧,QQ 2000 / 2003 / 2004 等等。 此时 Ops 不用和 Dev 直接高频接触,甚至针对一些纯离线业务,压根没有设立 Ops 这个岗位。
/ L7 b2 I  I3 ?8 S7 i; b" o0 T( h( Q- t
粘贴上传202112271758353426..png

9 H8 b& Z+ P& G# C* D$ W, U8 y8 a9 E3 |; [3 D
互联网浪潮之后,软件由传统意义上桌面软件演变为面向网站、手机应用。 这时候业务核心逻辑,比如交易,社交行为都不在用户桌面完成,而是在服务器后端完成。 这给互联网企业给予了极大操作空间:随时可以改变业务逻辑,这促进了业务快速迭代变更。 但即便这样,Dev 和 Ops 是极其分裂的两个环节。Ops 不关心代码是如何运作的,Dev 不知道代码如何运行在服务器上。
当业界还沉浸在可以每周发布版本喜悦中时,2009 年,Flicker 提出了每天发布 10+ 次概念,大大震撼了业界。

* \  S0 m& X8 X' d: f: Z7 E; D# C( W
Flicker 提出了几个核心理念:
5 m- E+ F# \) B. _
  • 业务快速发展,需要拥抱变更,小步快跑
  • Ops 目标不是为了网站稳定和快速,而是推动业务快速发展
  • 基于自动化工具提高 Dev / Ops 联接:代码版本管理、监控
  • 高效沟通:IRC / IM Robot(现在那些 ChatBot 套路,10 年前就被 Flicker 玩过了)
  • 信任、透明、高效、互助的沟通文化

    # k- |; |8 u$ h
! ^  A/ a7 C1 L( L" {; |+ V

, i; m8 p5 C& \) h; A( U
真是让人难以想象,今天各种培训公司和一些知名大 V 在呼唤这些 DevOps 理念, 竟然在 2009 年一份幻灯片中就展现淋漓尽致。经典总是不过时,在尘封下闪耀着智慧光芒。 有些人将 DevOps 和运维自动化等同,这是只看到表象。 DevOps 目标是提高业务系统交付速度,并为之提供相关工具、制度和服务。 一些个人或培训机构添油加醋和衍生含义,都是围绕这 DevOps 本质而发散。
8 j9 p  }. i5 Q5 J9 \" O( ~
接下来聊聊 SRE 历史, SRE 出现要晚一些。在 2003 年时候 Google 的 Ben Treynor 招募了几个软件工程师,这个团队设立目的是帮助 Google 生产环境服务运行更稳定、健壮、可靠。 不同于中小型规模公司,Google 服务于十几亿用户服务,短暂服务不可用会带来致命后果。 因此 Google 走在了时代最前面,SRE 产生了。

3 W- P1 C3 j3 [: j, m; P8 A
这个职位为大规模集群服务,小型团队不需要这样职位设定(可能也招不起真正 SRE 😊)。 Google 在探索若干年之后,SRE 团队开始将自己心得体会写在线上,并在 2016 年将此书出版。

8 X* e- M6 {) V+ ?7 F8 K4 }7 q' N2 E
两者的职能不同
DevOps 文化,那么就没有一个具象职能要求。现在不少公司将 DevOps 职能单独抽取出来,称之为 DevOps 工程师。 那让我们看看 DevOps 工程师关心什么:DevOps 文化目的是提交交付速度, DevOps 工程师就自然会关心软件 / 服务的整个生命周期。
+ C* M' }% n4 e' [- V) [
一个简单的公式: 速度=总量/时间,添上工程行业术语,即 交付速度=((功能特性*工程质量)/交付时间)*交付风险。
$ _4 y4 X0 T$ A1 }3 B  w
功能特性交给产品经理和项目经理管理,DevOps 工程师需要关心剩下几个因素:工程质量 / 交付时间 / 交付风险。 DevOps 工程师职能如下:

7 \( N0 Z$ I# V: T, I
  • 管理应用全生命周期(需求、设计、开发、QA、发布、运行)
  • 关注全流程效率提升,挖掘瓶颈点并将其解决
  • 自动化运维平台设计和研发工作(标准化、自动化、平台化)
  • 支持运维系统,包括 虚拟化技术、资源管理技术、监控技术、网络技术

    , b- x4 L9 a% z9 N5 o% b
    # m! w+ n8 B8 _$ g
SRE 关键词是「高扩展性」「高可用性」。高扩展性是指当服务用户数量暴增时, 应用系统以及支撑其服务(服务器资源、网络系统、数据库资源)可以在不调整系统结构,不强化机器本身性能 ,仅仅增加实例数量方式进行扩容。高可用性是指,应用架构中任何环节出现不可用时,比如应用服务、网关、数据库 等系统挂掉,整个系统可以在可预见时间内恢复并重新提供服务。当然,既然是「高」可用, 那么这个时间一般期望在分钟级别。SRE 职能可以概括为以下:

4 w& F: C6 H/ x+ {2 [
  • 为 应用、中间件、基础设施等提供 选型、设计、开发、容量规划、调优、故障处理
  • 为业务系统提供基于可用性、可扩展性考虑决策,参与业务系统设计和实施
  • 定位、处理、管理故障,优化导致故障发生相关部件
  • 提高各部件资源利用率
    / z0 C& E2 x9 I* u2 ~

    # `2 W5 m6 P3 \6 \) k) p
工作内容不同
; V- _. D0 ]( s& H0 R6 N' f0 Z
职责不同导致两个职位工作内容也不尽相同,我将 DevOps 工程师和 SRE 工程师职能列举如下:

. n2 o7 ^5 [" t3 y+ g4 m7 e* ?
  • DevOps
    * E3 n3 `* Y, D1 z2 h% Q
    • 设定应用生命管理周期制度,扭转流程
    • 开发、管理 开发工程师 /QA 工程师使用 开发平台系统
    • 开发、管理 发布系统
    • 开发、选型、管理 监控、报警系统
    • 开发、管理 权限系统
    • 开发、选型、管理 CMBD
    • 管理变更
    • 管理故障

      1 V& r) w6 J, R: H6 p- L
  • SRE
    2 D$ Z" h( `; |' ?
    • 管理变更
    • 管理故障
    • 制定 SLA 服务标准
    • 开发、选型、管理 各类中间件
    • 开发、管理 分布式监控系统
    • 开发、管理 分布式追踪系统
    • 开发、管理 性能监控、探测系统(dtrace、火焰图)
    • 开发、选型、培训 性能调优工具
      ) ?  h9 X/ o7 S$ G7 \- @( D$ Q
很有趣的对比,DevOps 和 SRE 都会关心应用生命周期,特别是生命周期里面中变更和故障。 但是 DevOps 工作内容是主要为开发链路服务,一个 DevOps Team 通常会提供一串工具链, 这其中会包括:开发工具、版本管理工具、CI 持续交付工具、CD 持续发布工具、报警工具、故障处理。 而 SRE Team 则关注更为关注变更、故障、性能、容量相关问题,会涉及具体业务,产出工具链会有: 容量测量工具、Logging 日志工具、Tracing 调用链路跟踪工具、Metrics 性能度量工具、监控报警工具等。
3 X0 S+ }8 ?" P3 M) }3 H( y3 T
DevOps 和 SRE 关系# x1 e8 u. U3 I% X( j. E
DevOps 首先是一种文化,后期逐渐独立成一个职位;SRE 一开始就明确是一个职位; 不少同学把 DevOps 和 SRE 搞混,是被两者表象锁迷惑,看上去这两者都有的工具属性、自动化要求也相似。 甚至有一些开发同学把这类运维工作都统一理解为:服务器 + 工具 + 自动化。这是盲人摸象,管中窥豹。
" W5 Z' J: E) F! I% c
从技能上来说,两者都需要较强的运维技能。 在职业发展天花板上,DevOps 可能缺乏 SRE 在一些专业领域的技能: 计算机体系结构能力;高吞吐高并发优化能力;可扩展系统设计能力;复杂系统设计能力;业务系统排查能力。 两者都需要软实力,但是 SRE 面临复杂度更高,挑战更大,要求也更高:
  • 分析问题、解决问题能力
  • 战胜困难决心
  • 面对挑战热情
  • 自驱学习
    - Z" A1 [) e9 Z+ ^+ B8 h2 {
DevOps 具有普遍意义,现代互联网公司都需要 DevOps,但是并非所有团队对高可用性、高扩展性存在需求,它们不需要 SRE。 DevOps 工程师掌握相关技能之后,也有机会可以发展为 SRE 工程师。 而一位合格 SRE 工程师,在有选择情况下面,我相信不会去转型为 DevOps 工程师。
: l8 b3 `5 c- [6 \9 ?: k% z1 C
从专业背景来看,无论是 DevOps 还是 SRE 工程师,都需要研发背景,前者需要开发工具链,后者需要有较强架构设计经验。 如果有运维工程师想转型成为 DevOps 或者 SRE,那么需要补上相关技术知识。 毕竟,不是会搭建一套 Jenkins + Kubernetes 就可以自称为 DevOps / SRE 工程师。

) D0 K# g% y* W( a
怎么样,有没有解开这几个常见误区呢?希望你看到这里可以豁然开朗,最后附上两个工程师的技能点, 期望有志成为这两种工程师的同学,加油努力。
( a( e  n0 G- h- N$ w+ W
附录:技能点
" j- t, @- O& H: |, N4 n3 `
DevOps:
  • Operator 技能
    $ q  z) E4 F$ b
    • Nginx / F5 / HAProxy / LVS 负载均衡
    • 常见中间件 Operate(启动、关闭、重启、扩容)

      : Y9 a' M, T* K! {: Y) R
    • KVM 管理 / XEN 管理 / vSphere 管理 / Docker
    • 容器编排 / Mesos / Kubernetes
      2 ~8 l% H9 H6 B; Q5 w+ |7 }: r
    • zabbix / nagios / Cacti

      + X8 `; r' B! k4 z# y& `( t/ i/ ]7 r6 C
    • Fabric / Saltstack / Chef / Ansible
      " z' Y% h  W* f% ]
    • DHCP / NTP / DNS / SSH / iptables / LDAP / CMDB

      7 C; \# u$ U5 m
    • Bash / Python
      2 l3 F0 H; j. I% J; F+ i
    • 基本命令操作
    • Linux FHS(Filesystem Hierarchy Standard 文件系统层次结构标准)
    • Linux 系统(差异、历史、标准、发展)

      % M% o- H# l" f: m
    • Linux Basis
    • 脚本
    • 基础服务
    • 自动化工具
    • 基础监控工具
    • 虚拟化
    • 服务

      * j1 {! D* y* g7 s  E
      * C. [1 v9 R: y  \, b$ G4 V
  • Dev
    & {7 I* V$ q! @/ [* g+ k
    • Git Repo / Gitlab / Github
    • Logstash / Flume 日志收集
    • 配置文件管理(应用、中间件等)
    • Nexus / JFrog / Pypi 包依赖管理
    • 面向 开发 / QA 开发环境管理系统
    • 线上权限分配系统
    • 监控报警系统
    • 基于 Fabric / Saltstack / Chef / Ansible 自动化工具开发
      # s+ I3 ]+ P% K" h& ^
    • Application Life Cycle
    • 12 Factor
    • 微服务概念、部署、生命周期
    • CI 持续集成 / Jenkins / Pipeline / Git Repo Web Hook
    • CD 持续发布系统
      1 z: C' c+ H* A' r
    • Pytho
    • Go(可选)
    • Java(了解部署)
      % X- }$ O7 M6 I; L9 a" o' s( O
    • 语言
    • 流程和理论
    • 基础设施

      , @) w3 d+ V  f3 E

      - c4 |& z  ]" T, |& i1 Z9 [$ `
SRE:
  • 语言和工程实现
    , ~, n% |* B3 D3 H/ e1 D
    • 业务部门使用开发框架
    • 并发、多线程和锁
    • 资源模型理解:网络、内存、CPU
    • 故障处理能力(分析瓶颈、熟悉相关工具、还原现场、提供方案)
      . b" L, u9 _! d- Q6 r
    • 深入理解开发语言(假设是 Java)
    • 常见业务设计方案和陷阱(比如 Business Modeling,N+1、远程调用、不合理 DB 结构)
    • MySQL / Mongo OLTP 类型查询优化
    • 多种并发模型,以及相关 Scalable 设计
      + U/ J; C& B6 O  s" Y4 k# p7 e+ x
      ) h, }8 G) B/ h
  • 问题定位工具
    + ?- L6 B2 Y' p- w+ t
    • 容量管理
    • Tracing 链路追踪
    • Metrics 度量工具
    • Logging 日志系统

      % T8 a; ?$ E6 O
      ! ~0 R3 w, \. }) H" S: |/ \1 O
  • 运维架构能力

    # l/ y7 A1 m/ X. o
    • Linux 精通,理解 Linux 负载模型,资源模型
    • 熟悉常规中间件(MySQL Nginx Redis Mongo ZooKeeper 等),能够调优
    • Linux 网络调优,网络 IO 模型以及在语言里面实现
    • 资源编排系统(Mesos / Kubernetes)

      # l" W$ U0 c4 ]. u4 Y* `
      1 B& q) `# G2 m8 X- o/ H. @  c
  • 理论

    6 M( D* b( N1 z) z
    • 容量规划方案
    • 熟悉分布式理论(Paxos / Raft / BigTable / MapReduce / Spanner 等),能够为场景决策合适方案
    • 性能模型(比如 Pxx 理解、Metrics、Dapper)
    • 资源模型(比如 Queuing Theory、负载方案、雪崩问题)
    • 资源编排系统(Mesos / Kurbernetes)(转自狄敬超.alswl)
      8 c" V6 h1 v% W/ {! L
      % L6 @" g. L% c9 G

8 ?* c2 d) ^; o4 ~
3 \3 z3 _4 m+ V) A. D' H$ @+ {# ]1 b' v; a




上一篇:速记:Devops必备Linux命令
下一篇:人工智能正在接管 DevOps 吗?
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-1-20 19:15 , Processed in 0.189174 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表