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

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

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 191|回复: 0

资深老司机如何兼顾DevOps运维与开发?(附脑图)

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-3 17:24:59 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-3 17:33 编辑
" L+ b" Y) c# i; e4 z. B
* I7 Y6 q4 P% n/ ]# {

3 l. I& Y8 f7 s) x3 b8 X

: [7 p& q  e% Y% ^/ y; b% o$ i
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。

# P4 z; `/ h, O! u3 U1 F7 V
; N' g0 ?' _' o" G# h( q/ A
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps

' K5 N2 G3 R3 X" J  H6 l2 e
1.png
DevOps

3 g" k) w7 Q+ m; M& D4 `6 [3 }

. i1 f2 `+ H: R; i/ y( f: w
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。
5 `* @, t4 C5 G7 k* i  W

7 j5 H/ h0 e. ODevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

2 }) m* m3 D# y

$ o$ ]1 d+ k, B! ~% Z# z( n1 N
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。
& d' X( P: v+ K
6 k7 {# ~: U, E) ^

, r+ v$ D" C2 N( ~1 z7 ~

一、前言

1 X4 a* w& t, m* d; G

3 J  a: r7 j: f+ e1 j5 Q/ p1 H
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
7 e2 r9 E0 A- ]/ O% k
3 w  `8 ]" l" K! v8 O
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”
  d  {/ m# c$ g- G& T

; K5 Q4 d: J& O* `! \3 q& v1 o
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。

4 y% `# i2 ?3 W  I  b0 F! y

' e0 Q% @% {. v3 U9 k. Y4 j+ v
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。
* ~9 q: L9 O* w/ Q# Y+ n5 E* K

$ Y$ F7 {" w7 j5 P. h1 A
本文,我将自己关于这些问题的思考分享给大家。
6 N2 q: s9 ]9 B4 J3 [
7 `4 Y/ E; S3 n+ [
. _7 q% h; Q$ ]4 H+ L' a* s

二、什么样的平台是好的运维平台?

; \8 M4 s$ D8 X# S% x" f
: F1 ?! W/ @& W, q% G" ^* \
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?
: @7 y: U; e0 P  X" g
# h  c+ _1 d. V4 c* g- n' ~
如果让我们来从头设计一个平台,我们应该如何去考量?

% ^; t/ V: Y) L5 k* j

0 k1 k" y0 Q9 d
1、效率 & 成本的均衡
- k  Q: X* b: j7 g; Q

1 ~1 R$ E, k2 [% J8 n8 ]6 l运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。

- s7 u  R4 O9 p

* C" N3 |) d, b0 d; B至于如何量化比较,就因系统而异了。
7 `! W3 z" ^" j, h

9 M6 s' V2 q: J  u3 r
2、体验 & 人性化
2 _; _$ z7 [0 k9 @

- [3 A( }% J+ k% I为什么我要把体验放在第二位?

* [% F7 A# A. @4 U. x$ n/ e* h6 e
7 b! I" G6 b! I& g# ]9 Z3 P! t) A5 }
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。

6 c1 L! _1 l( ]7 S9 }3 W! R" u- l
; \/ H1 ^' J& @$ t; i6 V# a8 q
我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。

% W7 [3 g9 ]: l( C2 X
, R- k5 S) O/ _$ b% q
3、优秀的系统架构
5 Q8 `; q! s0 R/ g' K! W8 j
7 a: c5 q6 ?8 u: o2 W
在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

- j8 ]0 e9 _/ {7 ~
# S2 f5 f) q% g
  • 稳定性:负载均衡、多活等。

    , n0 U. Z3 N3 b! D/ d

0 X3 Q: ~% @5 W) v$ O
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。

    7 _: p) ~0 T' x( [, U6 X* ^

$ ^- H5 c4 U  ]
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。

    ) i4 v8 \' K2 Q/ x: D
' R3 k/ M+ b% f, [2 q% s1 z& B
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。

    5 M, E- P- d' o4 G. y( D
+ z( L3 |( J/ K; `# D6 ^& w* u
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    ' A. E  F- f6 h6 R6 l

7 l* [! z! M8 i* `7 j! k  [
/ {' w0 r  B4 ?9 Z

三、如何运维自己开发的平台?


. H' _" W) ]5 s4 R' I
3 O3 M4 n' G  ~' w/ ~
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?
5 D7 a" ?; e3 \) Z

. z! p6 E! W. W' {0 \' F运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。

$ S) M* X5 p2 K( Z. Q. U/ O, f
( i. ~" ]; c& z; y
用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。

! R1 N7 F  m) W* @" ~' s' X) B
& n8 ?7 m; `8 T- h6 L
1、架构上的稳定性
# }% R" t, U2 \7 o  [
% R6 k5 n" V. E& u" I& k
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。
/ q3 K$ H6 m' d) m8 @' Q% a4 i- k

$ G" G$ c* k+ M9 L) Z0 ]) o
2、快速地发现问题
; b$ Q* H7 |) J1 d! D( W) E: f

3 B; y: ]' a1 L5 J- c4 o* `) A. ^
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。

7 Z- Z, K# g2 ?

6 J2 Z/ v& L% N" W还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。

; O2 G# V" L8 X! r

0 F2 V7 _4 M: X+ t( _8 N5 w1 G# w
3、应急预案&演练
" ~, r. Q. B/ @

: j* t6 Y8 R9 ?( q
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。
% g& ]4 ~0 T8 Q% Z# Q) u" t/ m
/ G9 N. r. Q: y2 W: m
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。
: j0 h1 O  V) r0 @" S
/ V% k+ w2 z. m" D
4、自我保护
6 g; _) y1 w7 u  v) W- u
6 f7 t4 [& n: O$ B: R
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:
% U) k4 j8 [/ H# t  k7 j& Y

8 z) P% F. I, w2 L) r& V
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。

    5 n% i, p3 t9 u( ?
0 {$ i# ]& @* V: F* L0 d; n+ i
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。
    # `1 c/ [! H, l- E# a
: t. V+ V9 r" T7 A/ N& q
2 N' R1 f: ?& S* E
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。
    - J8 v* V- T3 {  ]8 B  q" M8 [1 y9 q
; m9 E6 \) `  C3 G, p8 M8 M. N
5、容量规划
- d+ k5 `/ H5 a; ~: I/ O+ J* B) U

1 `+ E( m" x9 X( R  M
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。
. G; r/ f1 G; R8 S  J

% a  n& p: |  H% {5 Z0 B笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。
8 h$ A# f8 G2 \. A
: l8 g' |/ c( X' L# d
6、变更管理
8 B% K4 d1 }7 q& I& p. k1 K+ K% L. r# ]& R; v* z
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

! M/ _' w# o: W; q" ^" ~( a. x2 d- {% M+ |+ i1 `) Z; r0 B% Z+ g9 K
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。

    9 \. p/ R# r8 g0 C6 [  ^
/ d  ?+ Y" x! R0 H) U- H
! J9 v6 D; B0 `+ |4 D- [0 h* G3 s
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。
    ' ^5 {5 \; M% t0 c' `
9 W6 C' h, k+ y9 ~4 `1 u
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。
    , K$ R; w& o5 i1 `4 r- C
: `* V0 H3 f( V
. k* d# b& G1 p9 u9 \

四、除了开发与运维,我们还要做什么?

* T' m$ y; i9 f* ~$ q3 A& h" e
5 Y/ J/ f: q% d! h7 c2 v) M& f( b
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。
% g! ~; P0 V+ e6 A5 {

+ P9 M) |4 r0 o因此,我们要考量的,还有产品和需求层面的东西:
) ]- R! N8 Y8 ]9 \9 ~, q. u) r$ T
7 b" m0 U; ?; p0 `
1、需求管理

$ M! p6 p3 ^( U/ }) t

+ c# c# b" B. M; C, ~8 d. ~: q
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。

6 C. B& r: C- @: Q  }2 f; e& E

! M  z9 O, d# w$ E+ J5 ^. Z5 h
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。
    % }6 ?5 ], Z( `5 `' t

' n# K1 z2 h& f# a" @( }
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。

    ; w- `+ d1 W# f5 {5 m4 E, h
    对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。

    , q. _- s! ]6 E( H. B0 b% n

# @; G* T' ^$ o3 k5 k9 Y! e, W

( _3 p% V$ R" P6 g, \. V8 n
8 A3 i! i1 O* D; T: u$ X: J3 W! w4 `. ?' v2 _
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。
    % @3 F7 ]- s% Q
    - j. b6 |; E; E
    因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。

    6 v8 P" O5 G, e. o, ]
    / k# A! i7 [- t1 u
. K4 O" N8 q+ D
0 V% t5 e) W) Y: Z
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。

    0 m  R8 V7 x$ Y- o& S3 V4 n

5 i2 ?0 Z+ Z( `% z+ @
" p  Y7 N7 f3 z1 F/ s
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。

    : F% |6 ^: ?# k: H. Z5 j8 z

' }& k2 R" L* q& T
2、量化

7 m4 Y2 E, ]' ]: q
: G' g0 ~7 s1 X" Y! L
If You Can’t Measure It,You Can’t Improve It。量化是优化的前提。
+ P$ m5 _) N( @3 y
0 s1 l, O, a" g1 {+ ]
量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。

1 m2 w% ~. `$ {# R& V/ d  `

+ L, Y5 _! Y+ Q$ j4 I
3、制定SLA
/ q2 V9 e. ^8 v" j( b9 k( e

' i8 p. w! @4 \9 k! I) k/ s简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
( h+ @, z, R/ x; c
0 ]' o4 t; O! s! ]
一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。

$ Q( {* _+ w5 w4 I# E

7 i( W+ D6 l: [! ?1 z( e

% L8 w, E& T6 z* V- H1 {

五、除了做这些,我们还要思考什么?

( w0 R- D0 e1 z1 {; g
( S8 d/ m% |, U, U* }/ N" A
1、制定规范,并让规范在平台落地

6 z! Y# r8 `4 s5 l* o6 r7 S
% P( L) j- e0 Y( G5 t
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。

# _' |- I5 ~3 F1 e. u( i1 N4 [

! y  D( Y; b0 S" _8 E: V/ S( z规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。
6 E% \% f4 P' G7 u$ {8 `) o

$ F5 s7 U9 S+ D) U+ L1 R0 Q  e我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

/ h, c8 k* p( r& r* j- C+ {4 ?

: g( O, Z) y: \* V4 }: d具体的实施方式可以考虑限制和引导两种手段:
3 [, ?# J: }5 C2 g% E2 y* ^

4 u5 V0 q2 K, G+ t
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。

    / q9 u6 Q3 a8 A5 t; F

( [* \. M$ ?/ I" O, F4 `
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。
    0 D% g/ S& x* m

/ D" H8 V+ k6 A& Z$ G; }
2、协调开发与答疑
/ s. I0 l( X  `0 f5 a: A6 Y7 A
/ L0 D+ D  k: P! P1 e4 I3 g
运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。
% Y! V! O# g; g0 K

5 h5 r- v6 k( l7 D5 U4 q. _$ ~日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。
0 j1 ^8 l$ q: ^, u3 j! y- y( c

2 C3 t! F! ?- C! C) z5 u" g
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。

  P9 G  _6 q7 e

6 R: z& e6 n& V; U! @/ B
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:
$ j( n# f( H7 C6 L
5 T% ?) T1 v: e4 c) z
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;
    8 S& e* k4 b9 O8 N& E# C" @! ?3 H

( Q( c+ g! |, ~6 F" n1 e" Z2 H

; v4 K5 I6 L7 C- J
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。
    8 h4 _! G- {0 O% N+ I8 m" I

6 |0 ]8 F8 ~& l% j+ I5 {
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
0 q8 [4 w, S- b/ Y" K
5 J1 D0 l; N/ O* }" j* T0 H
因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
( V, [% {5 ]6 n+ }- z

, y  w  h4 y3 K/ ?0 F  q+ M( X( l0 }( A

, o" e( n! h1 T8 @5 h

六、后记

( L& o* D& k3 \5 @& z

+ N1 M2 g" E! ~
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。
# s& R+ n, \  e
+ r6 L0 k+ {) H! n; _
最后附上笔者思考本文时的脑图:
. B- d& D8 }3 O$ K" G# g/ {
1.png

+ D9 l' w( @3 C9 z% B; e$ B* r

! ^* i3 v6 d8 n: u+ [; k
8 ~- b& k3 A9 L5 `. u" r  S
作者介绍

4 J% u9 l4 V3 G, F

5 z9 W& l  T; I/ A5 _
高家升,现任职于滴滴运维部,曾负责滴滴登录系统的建设、监控系统存储与报警链路的重构。曾任职于小米,参与小米自动化运维平台的建设,负责服务树、权限、堡垒机等模块。专注于运维自动化与稳定性建设,代码熟手、Open-Falcon Commiter。

! Q. |5 B) B3 C- t% W1 p* \1 }

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1|网站地图

Baidu

GMT+8, 2018-11-14 13:07 , Processed in 0.233528 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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