|
DevOps 和 SREalswl* x9 j9 d7 s2 P; {# H. U
- X* ?; k8 b( r2 L8 A3 B" |; Z
6 n+ }* G* a8 @* w `1 o7 o
E7 J [/ G5 z+ X$ z5 Q% \6 i T% S! B* ~: O) p0 ~
最近有一位朋友和我聊职业发展方向问题,聊了不少 DevOps 和 SRE 话题。 我几年前刚接触这两个概念时也常常将之混淆,可惜当时没有人来解答我困惑。 现在这虽然已经极为流行,但是我发现我这位朋友对这两个职位还存在一些误区。 于是我给了一些见解并整理成文章以饕大众。
3 i, b( j, {8 \$ k" q% h最常见的误区:$ E7 T1 o. e* |& @* A; [; m% C4 ?- J
- DevOps 新概念,好高级哦
- SRE 是高级版 DevOps
- 运维可以轻松转身 DevOps 工程师, X' \- Y% o# f# _6 D' Y9 W
让我一一给你讲解吧。
: I; g, P _% n9 c
% f* G/ b; Q0 X4 H# t
) U8 n/ a$ _2 l6 Y: H7 G. g# L
4 F4 g% m+ K$ r1 ^) i/ i7 I7 W; w9 w; t6 d5 ~, R# f" j
sre-and-devops.png+ u1 I: l* z- k( g1 s3 @9 k
' p5 t8 {3 u( ]! j* Q <small>image via YouTube</small>
& I8 N7 T" x1 S9 x% Q( }0 C& eDevOps 和 SRE 定义DevOps 是字面上 Dev 开发 / Ops 运维两者组合, 严格意义上 DevOps 如下(via DevOps - Wikipedia):
* B9 @, ?+ H3 I* Q! W& n: \! TDevOps(Development 和 Operations 的组合词)是一种重视“软件开发人员(Dev) ”和“IT 运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。% X8 i4 t! h5 V" j$ p
SRE 全称是 Site Reliability Engineering,最早是由 Google 提出,并且在其工程实践中发扬光大。 他们还出了一本同名书籍「Site Reliability Engineering」, 让这个理念在互联网工程师圈子里广泛传播。
# r; f- r6 R( H7 u4 _0 a4 ~Google 对 SRE 解释是(via Site Reliability Engineering - Wikipedia):+ E- I% i: \9 G2 a; B& p$ I
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.
2 [" `& ^* x9 F& Z 我将其翻译翻译为中文:: h- }7 j# }, `9 g; H- \( H
网站稳定性工程师是致力于打造「高扩展、高可用系统」,并将其贯彻为原则的软件工程师。' X% h' d# d4 D' c5 C- x- r
从定义来看,DevOps 是文化、运动和惯例,而 SRE 是有严格任职要求的职位。 文化是软性定义,文化有更多概念可以捏造,而 SRE 定义精准,就少了想象空间(也可能 SRE 门槛高 😄)。 按 Google 给出的说法是,SRE 工程师实践了 DevOps 文化。这个观点没错,但是国内的 DevOps 逐步独立出 DevOps 工程师, 所以在本文,我着重讨论的是 DevOps 工程师和 SRE 工程师两种职位对比。- }( d* u0 s% D$ f+ ^9 b
两者产生背景和历史互联网需求催生了 DevOps 。在最传统软件企业中,是只有 Dev 没有 Ops, 那时 Ops 可能还是只是技术支持人员。开发按照瀑布流:需求分析、系统设计、开发、测试、交付、运行, 传统软件发布是一个重量级操作。一旦发布,Dev 几乎不再直接操作。 80 后可能会记得 QQ 每年都会有一个大版本发布吧,QQ 2000 / 2003 / 2004 等等。 此时 Ops 不用和 Dev 直接高频接触,甚至针对一些纯离线业务,压根没有设立 Ops 这个岗位。
5 }$ x+ W) s6 ?* T# s5 g7 L1 k! d- I: O) | l) i

$ b, K, h6 t! A9 `; N H2 h3 I' m' u- x+ y
qq-2004.png
" c" b- s) h* }/ C8 L! W0 E 7 f e$ Z) w" g, X
互联网浪潮之后,软件由传统意义上桌面软件演变为面向网站、手机应用。 这时候业务核心逻辑,比如交易,社交行为都不在用户桌面完成,而是在服务器后端完成。 这给互联网企业给予了极大操作空间:随时可以改变业务逻辑,这促进了业务快速迭代变更。 但即便这样,Dev 和 Ops 是极其分裂的两个环节。Ops 不关心代码是如何运作的,Dev 不知道代码如何运行在服务器上。( T4 S, m) m2 e3 v+ F8 s7 \
当业界还沉浸在可以每周发布版本喜悦中时,2009 年,Flicker 提出了每天发布 10+ 次概念,大大震撼了业界。 Flicker 提出了几个核心理念:* Z2 x* R9 l5 N( q1 Z3 i) [
- 业务快速发展,需要拥抱变更,小步快跑
- Ops 目标不是为了网站稳定和快速,而是推动业务快速发展
- 基于自动化工具提高 Dev / Ops 联接:代码版本管理、监控
- 高效沟通:IRC / IM Robot(现在那些 ChatBot 套路,10 年前就被 Flicker 玩过了)
- 信任、透明、高效、互助的沟通文化% z! j" a0 V5 J2 W9 t5 s
. @0 I* i! P* m/ g/ g - c$ h, E& E. Z2 i$ l
! ?6 i. k! i! z* N) {( D+ h( a3 Kflicker.png
9 l( G8 \/ R; Y: s- k
; x( X) _( \9 Y; y" P原文 SlideShare 在这 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr- a, X% U7 r. J4 k5 y6 z
真是让人难以想象,今天各种培训公司和一些知名大 V 在呼唤这些 DevOps 理念, 竟然在 2009 年一份幻灯片中就展现淋漓尽致。经典总是不过时,在尘封下闪耀着智慧光芒。 有些人将 DevOps 和运维自动化等同,这是只看到表象。 DevOps 目标是提高业务系统交付速度,并为之提供相关工具、制度和服务。 一些个人或培训机构添油加醋和衍生含义,都是围绕这 DevOps 本质而发散。
3 L) o' l, p x& I1 i. E接下来聊聊 SRE 历史, SRE 出现要晚一些。在 2003 年时候 Google 的 Ben Treynor 招募了几个软件工程师,这个团队设立目的是帮助 Google 生产环境服务运行更稳定、健壮、可靠。 不同于中小型规模公司,Google 服务于十几亿用户服务,短暂服务不可用会带来致命后果。 因此 Google 走在了时代最前面,SRE 产生了。+ W3 G& h3 k8 R$ m) W, y
这个职位为大规模集群服务,小型团队不需要这样职位设定(可能也招不起真正 SRE 😊)。 Google 在探索若干年之后,SRE 团队开始将自己心得体会写在线上,并在 2016 年将此书出版。& Y, ^6 S+ A" I7 ]0 u
两者的职能不同DevOps 文化,那么就没有一个具象职能要求。现在不少公司将 DevOps 职能单独抽取出来,称之为 DevOps 工程师。 那让我们看看 DevOps 工程师关心什么:DevOps 文化目的是提交交付速度, DevOps 工程师就自然会关心软件 / 服务的整个生命周期。
0 K3 j$ T! \' Z5 U9 |! E+ @* {! ]; \一个简单的公式:速度 = 总量 / 时间,添上工程行业术语,即 交付速度 = ((功能特性 * 工程质量) / 交付时间) * 交付风险。4 g$ v: m: m S; w2 _9 S4 Z
功能特性交给产品经理和项目经理管理,DevOps 工程师需要关心剩下几个因素:工程质量 / 交付时间 / 交付风险。 DevOps 工程师职能如下:1 {. F8 i' j8 C! H5 Y- O' T9 `
- 管理应用全生命周期(需求、设计、开发、QA、发布、运行)
- 关注全流程效率提升,挖掘瓶颈点并将其解决
- 自动化运维平台设计和研发工作(标准化、自动化、平台化)
- 支持运维系统,包括 虚拟化技术、资源管理技术、监控技术、网络技术6 N) H; L. W; e9 G
SRE 关键词是「高扩展性」「高可用性」。高扩展性是指当服务用户数量暴增时, 应用系统以及支撑其服务(服务器资源、网络系统、数据库资源)可以在不调整系统结构,不强化机器本身性能 ,仅仅增加实例数量方式进行扩容。高可用性是指,应用架构中任何环节出现不可用时,比如应用服务、网关、数据库 等系统挂掉,整个系统可以在可预见时间内恢复并重新提供服务。当然,既然是「高」可用, 那么这个时间一般期望在分钟级别。SRE 职能可以概括为以下:6 u9 a' W9 C7 ^0 I: H3 K
- 为 应用、中间件、基础设施等提供 选型、设计、开发、容量规划、调优、故障处理
- 为业务系统提供基于可用性、可扩展性考虑决策,参与业务系统设计和实施
- 定位、处理、管理故障,优化导致故障发生相关部件
- 提高各部件资源利用率
( |4 C! B& ^5 p0 D/ h; r. @0 R 工作内容不同职责不同导致两个职位工作内容也不尽相同,我将 DevOps 工程师和 SRE 工程师职能列举如下:+ S8 f; j4 k, F: S! [0 D4 h
- DevOps
0 W* ~8 i5 U f6 Y v- 设定应用生命管理周期制度,扭转流程
- 开发、管理 开发工程师 /QA 工程师使用 开发平台系统
- 开发、管理 发布系统
- 开发、选型、管理 监控、报警系统
- 开发、管理 权限系统
- 开发、选型、管理 CMBD
- 管理变更
- 管理故障
% y. c. R \; B/ x
- SRE7 r7 g# K' t8 s3 w0 Y
- 管理变更
- 管理故障
- 制定 SLA 服务标准
- 开发、选型、管理 各类中间件
- 开发、管理 分布式监控系统
- 开发、管理 分布式追踪系统
- 开发、管理 性能监控、探测系统(dtrace、火焰图)
- 开发、选型、培训 性能调优工具
. ~: g9 I0 G" I
很有趣的对比,DevOps 和 SRE 都会关心应用生命周期,特别是生命周期里面中变更和故障。 但是 DevOps 工作内容是主要为开发链路服务,一个 DevOps Team 通常会提供一串工具链, 这其中会包括:开发工具、版本管理工具、CI 持续交付工具、CD 持续发布工具、报警工具、故障处理。 而 SRE Team 则关注更为关注变更、故障、性能、容量相关问题,会涉及具体业务,产出工具链会有: 容量测量工具、Logging 日志工具、Tracing 调用链路跟踪工具、Metrics 性能度量工具、监控报警工具等。6 v. F# L& H8 Q6 U+ w+ x
DevOps 和 SRE 关系DevOps 首先是一种文化,后期逐渐独立成一个职位;SRE 一开始就明确是一个职位; 不少同学把 DevOps 和 SRE 搞混,是被两者表象锁迷惑,看上去这两者都有的工具属性、自动化要求也相似。 甚至有一些开发同学把这类运维工作都统一理解为:服务器 + 工具 + 自动化。这是盲人摸象,管中窥豹。 s/ R- V) R4 [) G0 B% D! o
从技能上来说,两者都需要较强的运维技能。 在职业发展天花板上,DevOps 可能缺乏 SRE 在一些专业领域的技能: 计算机体系结构能力;高吞吐高并发优化能力;可扩展系统设计能力;复杂系统设计能力;业务系统排查能力。 两者都需要软实力,但是 SRE 面临复杂度更高,挑战更大,要求也更高:6 ~' l8 L1 h/ n* l. w& s- N
- 分析问题、解决问题能力
- 战胜困难决心
- 面对挑战热情
- 自驱学习1 v. {7 }4 b" Z
DevOps 具有普遍意义,现代互联网公司都需要 DevOps,但是并非所有团队对高可用性、高扩展性存在需求,它们不需要 SRE。 DevOps 工程师掌握相关技能之后,也有机会可以发展为 SRE 工程师。 而一位合格 SRE 工程师,在有选择情况下面,我相信不会去转型为 DevOps 工程师。
; ?2 N5 m' u0 ]1 b- z, R" k1 L2 U从专业背景来看,无论是 DevOps 还是 SRE 工程师,都需要研发背景,前者需要开发工具链,后者需要有较强架构设计经验。 如果有运维工程师想转型成为 DevOps 或者 SRE,那么需要补上相关技术知识。 毕竟,不是会搭建一套 Jenkins + Kubernetes 就可以自称为 DevOps / SRE 工程师。% E; o7 x* X/ t5 t& h
怎么样,有没有解开这几个常见误区呢?希望你看到这里可以豁然开朗,最后附上两个工程师的技能点, 期望有志成为这两种工程师的同学,加油努力。
a4 b$ T, x- c附录:技能点DevOps:0 L) T9 @ U4 @" c
- Operator 技能* f+ d' J1 V8 c# J
- Linux Basis
. K' e' t; H- d/ P% C; f8 D- 基本命令操作
- Linux FHS(Filesystem Hierarchy Standard 文件系统层次结构标准)
- Linux 系统(差异、历史、标准、发展) V8 S- {; M3 s- }
- 脚本
+ s- o+ {9 L- k$ c- [- Bash / Python f. Z1 ]3 w0 |
- 基础服务
3 v/ J2 h8 @7 _- DHCP / NTP / DNS / SSH / iptables / LDAP / CMDB, x+ d+ `5 m4 t/ r) Z
- 自动化工具
0 R+ H& G' u. Z/ F" n; W- Fabric / Saltstack / Chef / Ansible, m2 |5 S9 p2 ~" p
- 基础监控工具
! @/ H$ _" _; k. F, ]6 q. T# v# i - 虚拟化
; ^" d- |7 n6 r T- KVM 管理 / XEN 管理 / vSphere 管理 / Docker
- 容器编排 / Mesos / Kubernetes
" m; u b0 Q: V
- 服务/ k" G5 Y& u) Y7 I8 X
- Nginx / F5 / HAProxy / LVS 负载均衡
- 常见中间件 Operate(启动、关闭、重启、扩容)4 O, u& [$ [ h. k9 \% ^0 t6 w* w
- Dev
# E$ M8 n) J# y# J- 语言
, r, D& p/ r- E6 m8 _/ L( `" E- Python
- Go(可选)
- Java(了解部署)6 R2 I, l, U" m
- 流程和理论
% L+ |- [6 i% o) q) Y- Application Life Cycle
- 12 Factor
- 微服务概念、部署、生命周期
- CI 持续集成 / Jenkins / Pipeline / Git Repo Web Hook
- CD 持续发布系统
$ [% ~; U+ |! y9 _; f% R6 N
- 基础设施
" p0 O* W. I& y- Git Repo / Gitlab / Github
- Logstash / Flume 日志收集
- 配置文件管理(应用、中间件等)
- Nexus / JFrog / Pypi 包依赖管理
- 面向 开发 / QA 开发环境管理系统
- 线上权限分配系统
- 监控报警系统
- 基于 Fabric / Saltstack / Chef / Ansible 自动化工具开发
/ t/ C5 S/ r' Q4 \! v0 }1 e
SRE:2 V o/ m4 K1 {- X( ?$ N
- 语言和工程实现
Q: l* ~7 P. A' t& U6 G' m- 深入理解开发语言(假设是 Java)
?* h7 `( k( K, L9 R, ]- 业务部门使用开发框架
- 并发、多线程和锁
- 资源模型理解:网络、内存、CPU
- 故障处理能力(分析瓶颈、熟悉相关工具、还原现场、提供方案)
! u/ _ B1 a) t1 D! N2 h( W
- 常见业务设计方案和陷阱(比如 Business Modeling,N+1、远程调用、不合理 DB 结构)
- MySQL / Mongo OLTP 类型查询优化
- 多种并发模型,以及相关 Scalable 设计
$ [ V, u& o! M7 f, p: N; _: O A
- 问题定位工具& h( e% d6 Z5 B3 A! O" N5 c
- 容量管理
- Tracing 链路追踪
- Metrics 度量工具
- Logging 日志系统! s! F! Y9 Y0 z8 f
- 运维架构能力
j/ d/ b; i( K6 B0 p" M* g- Linux 精通,理解 Linux 负载模型,资源模型
- 熟悉常规中间件(MySQL Nginx Redis Mongo ZooKeeper 等),能够调优
- Linux 网络调优,网络 IO 模型以及在语言里面实现
- 资源编排系统(Mesos / Kubernetes)8 U2 }0 ?3 n! p. ?
- 理论
4 c/ Y+ w% L- n3 w- 容量规划方案
- 熟悉分布式理论(Paxos / Raft / BigTable / MapReduce / Spanner 等),能够为场景决策合适方案
- 性能模型(比如 Pxx 理解、Metrics、Dapper)
- 资源模型(比如 Queuing Theory、负载方案、雪崩问题)
- 资源编排系统(Mesos / Kurbernetes)
* p. U# L3 F. Z8 ^# `1 _8 m1 c- A
- @, W) P8 e; }# W
|
上一篇: 迄今为止最精辟的SRE工作内容描述下一篇: SRE工程师一般需要掌握什么技能?
|