本帖最后由 FYIRH 于 2021-12-27 18:03 编辑 / T, M7 E" ?) [# C
3 `+ Q, {3 Q. X* m5 O& @
最近有一位朋友和我聊职业发展方向问题，聊了不少 DevOps 和 SRE 话题。 我几年前刚接触这两个概念时也常常将之混淆，可惜当时没有人来解答我困惑。 现在这虽然已经极为流行，但是我发现我这位朋友对这两个职位还存在一些误区。 于是我给了一些见解并整理成文章以饕大众。 , J& I. I3 |0 a4 v- o
最常见的误区： 0 f2 i8 A8 w8 h. ?: Z' N
DevOps 新概念，好高级 SRE 是高级版 DevOps 运维可以轻松转身 DevOps 工程师
: P7 E1 m5 X8 [. k! ^
' ^3 w$ A+ M% n; K/ i3 S
让我一一给你讲解吧。 2 e. X4 u8 N4 K, [. V5 M; u5 b ]
7 {6 d) i L' Z1 |' S6 m8 v
DevOps 和 SRE 定义& E$ Y9 s* A4 k( _. w
DevOps 是字面上 Dev 开发 / Ops 运维两者组合， 严格意义上 DevOps 如下（via(DevOps - Wikipedia)(via)）： 8 ` B* j( g4 p+ O* C1 S: B
DevOps（Development 和 Operations 的组合词）是一种重视“软件开发人员（Dev） ”和“IT 运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。 2 ], w: D6 d) _# x" Z0 y
SRE 全称是 Site Reliability Engineering，最早是由 Google 提出，并且在其工程实践中发扬光大。 他们还出了一本同名书籍(Site Reliability Engineering)(via)」， 让这个理念在互联网工程师圈子里广泛传播。 3 y3 h* _) V1 m, P2 `. l1 v
Google 对 SRE 解释是（via(Site Reliability Engineering - Wikipedia)(via)）： - ^# K. }8 L' f
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. 3 P2 Z/ F5 [; S4 D3 n
我将其翻译翻译为中文：
0 m' c! q1 X; j
网站稳定性工程师是致力于打造「高扩展、高可用系统」，并将其贯彻为原则的软件工程师。
) s O' J# r, I8 q
从定义来看，DevOps 是文化、运动和惯例，而 SRE 是有严格任职要求的职位。 文化是软性定义，文化有更多概念可以捏造，而 SRE 定义精准，就少了想象空间（也可能 SRE 门槛高 😄）。 按 Google 给出的说法是，SRE 工程师实践了 DevOps 文化。这个观点没错，但是国内的 DevOps 逐步独立出 DevOps 工程师， 所以在本文，我着重讨论的是 DevOps 工程师和 SRE 工程师两种职位对比。 : G2 l) P \. Y
两者产生背景和历史
) ?& v [3 I9 E: h$ d互联网需求催生了 DevOps 。在最传统软件企业中，是只有 Dev 没有 Ops， 那时 Ops 可能还是只是技术支持人员。开发按照瀑布流：需求分析、系统设计、开发、测试、交付、运行， 传统软件发布是一个重量级操作。一旦发布，Dev 几乎不再直接操作。 80 后可能会记得 QQ 每年都会有一个大版本发布吧，QQ 2000 / 2003 / 2004 等等。 此时 Ops 不用和 Dev 直接高频接触，甚至针对一些纯离线业务，压根没有设立 Ops 这个岗位。
, [( K! ]4 U) M4 F* d
5 h3 o, Z; o& m0 G+ l, p- U
* ~1 T# w+ k+ T, Z' `, G) U互联网浪潮之后，软件由传统意义上桌面软件演变为面向网站、手机应用。 这时候业务核心逻辑，比如交易，社交行为都不在用户桌面完成，而是在服务器后端完成。 这给互联网企业给予了极大操作空间：随时可以改变业务逻辑，这促进了业务快速迭代变更。 但即便这样，Dev 和 Ops 是极其分裂的两个环节。Ops 不关心代码是如何运作的，Dev 不知道代码如何运行在服务器上。 当业界还沉浸在可以每周发布版本喜悦中时，2009 年，Flicker 提出了每天发布 10+ 次概念，大大震撼了业界。
% \ O5 y. H4 y9 ^& o1 o' x
Flicker 提出了几个核心理念： 2 N8 Y$ f+ k( ^7 g
业务快速发展，需要拥抱变更，小步快跑 Ops 目标不是为了网站稳定和快速，而是推动业务快速发展 基于自动化工具提高 Dev / Ops 联接：代码版本管理、监控 高效沟通：IRC / IM Robot（现在那些 ChatBot 套路，10 年前就被 Flicker 玩过了） 信任、透明、高效、互助的沟通文化
% E5 H i0 @& o
. G1 H. j, Q$ u" [& |) S/ [9 S+ r: n9 c1 p' |, h2 i
真是让人难以想象，今天各种培训公司和一些知名大 V 在呼唤这些 DevOps 理念， 竟然在 2009 年一份幻灯片中就展现淋漓尽致。经典总是不过时，在尘封下闪耀着智慧光芒。 有些人将 DevOps 和运维自动化等同，这是只看到表象。 DevOps 目标是提高业务系统交付速度，并为之提供相关工具、制度和服务。 一些个人或培训机构添油加醋和衍生含义，都是围绕这 DevOps 本质而发散。 : k: m6 i) g& B) b) n# y% T2 P
接下来聊聊 SRE 历史， SRE 出现要晚一些。在 2003 年时候 Google 的 Ben Treynor 招募了几个软件工程师，这个团队设立目的是帮助 Google 生产环境服务运行更稳定、健壮、可靠。 不同于中小型规模公司，Google 服务于十几亿用户服务，短暂服务不可用会带来致命后果。 因此 Google 走在了时代最前面，SRE 产生了。
6 \0 W6 a, z$ ^$ n/ O( o
这个职位为大规模集群服务，小型团队不需要这样职位设定（可能也招不起真正 SRE 😊）。 Google 在探索若干年之后，SRE 团队开始将自己心得体会写在线上，并在 2016 年将此书出版。
; b j* f! Z8 b
两者的职能不同DevOps 文化，那么就没有一个具象职能要求。现在不少公司将 DevOps 职能单独抽取出来，称之为 DevOps 工程师。 那让我们看看 DevOps 工程师关心什么：DevOps 文化目的是提交交付速度， DevOps 工程师就自然会关心软件 / 服务的整个生命周期。 # i! p7 Z( [4 H6 s9 ]4 J, E t
一个简单的公式： 速度=总量/时间，添上工程行业术语，即 交付速度=（（功能特性*工程质量）/交付时间）*交付风险。 - ?3 l3 P5 D) k
功能特性交给产品经理和项目经理管理，DevOps 工程师需要关心剩下几个因素：工程质量 / 交付时间 / 交付风险。 DevOps 工程师职能如下： ; u0 P. I+ k" ?
管理应用全生命周期（需求、设计、开发、QA、发布、运行） 关注全流程效率提升，挖掘瓶颈点并将其解决 自动化运维平台设计和研发工作（标准化、自动化、平台化） 支持运维系统，包括 虚拟化技术、资源管理技术、监控技术、网络技术 # i! d+ o8 E5 b: X
) u; V! v) ~6 G. t* t/ C; d
SRE 关键词是「高扩展性」「高可用性」。高扩展性是指当服务用户数量暴增时， 应用系统以及支撑其服务（服务器资源、网络系统、数据库资源）可以在不调整系统结构，不强化机器本身性能 ，仅仅增加实例数量方式进行扩容。高可用性是指，应用架构中任何环节出现不可用时，比如应用服务、网关、数据库 等系统挂掉，整个系统可以在可预见时间内恢复并重新提供服务。当然，既然是「高」可用， 那么这个时间一般期望在分钟级别。SRE 职能可以概括为以下：
$ B( i( i+ U( U6 v' F* M9 L! p
工作内容不同$ N! e1 k" N P1 }9 _8 z4 `5 V3 T
职责不同导致两个职位工作内容也不尽相同，我将 DevOps 工程师和 SRE 工程师职能列举如下：
2 P% i, v1 S$ M- D
DevOps
/ o6 l. g: n( z+ h/ J, n% S4 Q# ?0 XSRE
8 Y1 x2 F. R1 P8 ~6 @: u
很有趣的对比，DevOps 和 SRE 都会关心应用生命周期，特别是生命周期里面中变更和故障。 但是 DevOps 工作内容是主要为开发链路服务，一个 DevOps Team 通常会提供一串工具链， 这其中会包括：开发工具、版本管理工具、CI 持续交付工具、CD 持续发布工具、报警工具、故障处理。 而 SRE Team 则关注更为关注变更、故障、性能、容量相关问题，会涉及具体业务，产出工具链会有： 容量测量工具、Logging 日志工具、Tracing 调用链路跟踪工具、Metrics 性能度量工具、监控报警工具等。
* M* D* B% [1 {: i. X
DevOps 和 SRE 关系
# K4 M I$ ~ ^2 h7 e& O0 }DevOps 首先是一种文化，后期逐渐独立成一个职位；SRE 一开始就明确是一个职位； 不少同学把 DevOps 和 SRE 搞混，是被两者表象锁迷惑，看上去这两者都有的工具属性、自动化要求也相似。 甚至有一些开发同学把这类运维工作都统一理解为：服务器 + 工具 + 自动化。这是盲人摸象，管中窥豹。 0 Z" G& ~+ X9 K! Q9 P% G) E! F
从技能上来说，两者都需要较强的运维技能。 在职业发展天花板上，DevOps 可能缺乏 SRE 在一些专业领域的技能： 计算机体系结构能力；高吞吐高并发优化能力；可扩展系统设计能力；复杂系统设计能力；业务系统排查能力。 两者都需要软实力，但是 SRE 面临复杂度更高，挑战更大，要求也更高： 分析问题、解决问题能力 战胜困难决心 面对挑战热情 自驱学习 3 T8 V' W* D$ J* d0 {& Y
DevOps 具有普遍意义，现代互联网公司都需要 DevOps，但是并非所有团队对高可用性、高扩展性存在需求，它们不需要 SRE。 DevOps 工程师掌握相关技能之后，也有机会可以发展为 SRE 工程师。 而一位合格 SRE 工程师，在有选择情况下面，我相信不会去转型为 DevOps 工程师。 3 f5 R# Z5 |8 m. d1 ?
从专业背景来看，无论是 DevOps 还是 SRE 工程师，都需要研发背景，前者需要开发工具链，后者需要有较强架构设计经验。 如果有运维工程师想转型成为 DevOps 或者 SRE，那么需要补上相关技术知识。 毕竟，不是会搭建一套 Jenkins + Kubernetes 就可以自称为 DevOps / SRE 工程师。
. i) G+ [; D [! X, E0 S
怎么样，有没有解开这几个常见误区呢？希望你看到这里可以豁然开朗，最后附上两个工程师的技能点， 期望有志成为这两种工程师的同学，加油努力。
3 j8 a" H! `/ F S8 L# Q4 \) ^
附录：技能点6 K8 J) D) o. P D
DevOps： Operator 技能
1 f# W% E, m" uZabbix / Nagios / Cacti
" w* ? j7 k9 e3 i7 X
Bash / Python - H1 O1 V! p' b# ?' w
Linux Basis 脚本 基础服务 自动化工具 基础监控工具 虚拟化 服务
( |$ y4 W, C: @9 j4 c5 n
9 Y: I! r) u4 O6 ]# n
Dev ; c5 U' _. o! n
Git Repo / Gitlab / Github Logstash / Flume 日志收集 配置文件管理（应用、中间件等） Nexus / JFrog / Pypi 包依赖管理 面向 开发 / QA 开发环境管理系统 线上权限分配系统 监控报警系统 基于 Fabric / Saltstack / Chef / Ansible 自动化工具开发 3 m: X7 J; E5 U% q; D
Pytho Go（可选） Java（了解部署）
. ?1 T5 {. W% C" w4 g, J! ~/ l
语言 流程和理论 基础设施 8 b1 a0 Q# G% @* ~* ?. ^$ W
9 Y( l6 Z' N/ _0 Q: I
SRE： 语言和工程实现 8 b9 w6 _- w5 f( _) a2 ?
问题定位工具
) X" Y% G* \: t% D2 {" M. g容量管理 Tracing 链路追踪 Metrics 度量工具 Logging 日志系统 ) @8 \( k5 H& I; ]
, A) v, k" y( ^) O3 z' k( l
运维架构能力
6 ]. @6 R5 z% \+ `/ o0 nLinux 精通，理解 Linux 负载模型，资源模型 熟悉常规中间件（MySQL Nginx Redis Mongo ZooKeeper 等），能够调优 Linux 网络调优，网络 IO 模型以及在语言里面实现 资源编排系统（Mesos / Kubernetes） # I+ ? ^1 W, G, e8 l
; b8 w/ Q2 a* U' b* z1 U A
理论
5 ?" ?! G! |% r; j6 p容量规划方案 熟悉分布式理论（Paxos / Raft / BigTable / MapReduce / Spanner 等），能够为场景决策合适方案 性能模型（比如 Pxx 理解、Metrics、Dapper） 资源模型（比如 Queuing Theory、负载方案、雪崩问题） 资源编排系统（Mesos / Kurbernetes）(转自狄敬超.alswl）
/ q' @7 U8 y2 i( m$ J/ G/ ^
8 Z9 o& z/ I& D* t8 o8 }) i: P
6 @! d( g( P/ _6 o0 e- J$ m9 \* L
! T9 L1 g1 X1 a | 
|ITIL
( 粤ICP备11099876号 )|appname
窥视卡
雷达卡
发表于 2021-12-27 17:56:15
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
显身卡