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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-3 17:24:59 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-3 17:33 编辑
# \* g5 ~* T& i, @( u9 ^& d, w/ {) W

) w1 {) u+ O8 z( \
  w) l, ^% r5 L1 q5 N, d' A
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。
. c1 |- G- u$ J3 I
" L  g! o. X- T; v' ]
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps

2 M' ?8 A3 @- N7 V
1.png
DevOps

; R) @% p& @9 H! V

9 x3 ?* `( k. k0 T, V0 z- a
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。
& u1 X) {9 A; ]$ ?

) k* [/ K  N! y6 Z! s" }, ?DevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

, I# H: C4 d1 f" f0 J

+ E! h% A  Y* F7 p5 B$ P0 B
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。
$ n) N  Z$ D) X$ D/ s3 l/ \9 D

* Y. x0 x, S8 l; X; b% j$ p

/ r- U$ |8 d$ \: {

一、前言


5 ]" _$ h% X2 y: ]4 `5 b' l5 G2 _
5 d' Q1 d. z# u3 Y; U
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
3 E2 J* v6 D  Z1 m' H& i

1 x* H* f. L/ Q5 m3 P8 s7 |
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”

; i/ j9 e8 h( d  b3 z2 P! u" [
9 L' W4 d" A* W4 c" b9 V, A
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。

6 M0 \& S6 N% I6 s. K

5 W3 S5 R  S; c0 e5 p4 j
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。
5 W/ f  i& H" c6 ?4 x. O3 W; O
2 X8 p' I9 g( x2 C
本文,我将自己关于这些问题的思考分享给大家。
9 p% h* N: z  h4 m  V# N" _

: O. e, t6 w2 N+ S, T, z4 l
6 w$ K5 B# `' y& D. [

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

$ ~; [2 f0 }5 g" ?! d
" u% r) d3 ~* L& j
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?
+ r2 W: }- C) C) |0 ?

/ j' A; b5 H9 ?0 C; y0 B
如果让我们来从头设计一个平台,我们应该如何去考量?
7 @# ]; x1 I1 A$ }
& q- }' i7 C/ X. k. C' Z; }+ z, {
1、效率 & 成本的均衡
) a2 u3 V0 b; m+ v# _1 [

0 A, k! S2 g0 e/ q- y9 Y2 p/ }" Y运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。
9 }; h0 T& Q: d9 g% j
' j/ L+ O' A: z
至于如何量化比较,就因系统而异了。
# Q$ A8 [. ^& f; U) Q' e2 q
! `/ O7 c: z. R/ V+ A$ q; r
2、体验 & 人性化

2 _$ P( U" h" G, B$ \
6 F1 z: Z& _, e7 c: q7 ~- ^# |
为什么我要把体验放在第二位?
2 x, A+ h4 ]' ?' I
- R' M2 p% G% r; a4 T  R/ `
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。
6 m/ a1 `6 K1 w, b

  u- S5 I: c; [9 c, u我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。
' t. C, }, W' M/ h2 g

* x$ h4 G; m& i+ r4 G1 ]
3、优秀的系统架构
3 l0 `; s5 c/ T4 y1 |

) z# P, ^' ~3 W  }/ M, Y在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

5 v7 l5 O7 j: e# F: ?

8 F9 h& C5 M8 ?0 d. U7 W8 R8 y5 J
  • 稳定性:负载均衡、多活等。
    ' A/ ]# T2 M$ v8 u' k  O1 s; F$ E  Q
/ i- n' l" w$ B$ @" j: ]
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。

    2 v+ D9 _: T$ C  k5 z

+ k7 |5 ^( W5 g. }+ {* ~
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。
    " y/ c1 K0 d" y3 \

  y- p6 y/ c3 K
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
      `, h6 T) K. J% w$ ~# C( \9 ?

" e- q5 a# \' ]! n
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。

    2 E: @% f0 z  `" z; j/ ]0 U

. F9 `) [+ i6 }* A

" M5 y2 f8 W  T1 l2 o

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

" Z# o5 l6 t& W& o

# y4 {7 D' \( K0 C1 F; t
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?
& x0 |) _6 H; V1 w: W9 J1 Q- y$ D! c

7 d1 k4 E, b0 |运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。
) c2 s4 D& k$ b
/ T) y5 q: {) a6 f# m9 n
用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。

* y7 C6 J. g% c( ^0 W" c

1 g6 Q* Q) {. T- ~
1、架构上的稳定性

9 C5 z: _: u# f- b& E1 Q! D
$ v- t5 F) T+ D$ n1 X& }% m. {& S
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。
) X9 l9 v6 `* M2 K% k( M7 C8 ]
2 d2 ?* y! \: E8 }
2、快速地发现问题

5 V( h* M5 X( b# h+ F2 q

  D* c) G" G1 A/ d8 v+ t8 V, U3 H5 e' K
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。
# Q7 o8 ]) _* }
! P# }3 {! k; N! C7 f- M
还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。

1 |  A9 ?. Y3 L% f4 ^
. p' Y, ?' ~7 A3 y! Y
3、应急预案&演练
6 f6 a( E8 q" O1 Q# c

. u7 J  _+ s# w; b6 A  T7 p
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。
% a& T- X. C7 }# H5 m
- L/ w8 d  A& m( @# D2 W9 r
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。

& r/ P/ A# f0 d0 W  E: I
" k; S1 h: t" f8 c8 Y: _) v
4、自我保护
" p! \. h' U  F! ^4 A
6 f) G8 c9 a% T* B) E3 R# s
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:

  n0 C% V( G5 l2 z$ U$ V, g9 E

# G& A) d) b0 V. P2 n+ H
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。

    ; i' Y  a, v8 d) l% I# s

7 @7 F2 p3 z+ t4 l8 R8 q
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。

    ' V9 V) |: ^  g9 C4 Y$ S
* _/ F. ^; C7 s6 Z* i0 Q
: E$ C* m& t5 ?: N  U& D: k
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。
    # Q3 e: A5 `! Q2 y$ l
6 Y5 E# h8 p6 q6 }4 D3 b* W
5、容量规划

- I0 E7 s0 p( Y/ N$ G. o$ D
0 F% E, x, w: {' h* S
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。

! a9 Y4 G& n9 M* D0 T+ X7 `
1 j5 _. h2 l+ L  j
笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。
( a- l0 g6 K# E# l* u
* E$ u/ i( ~& J9 W: {1 s$ t
6、变更管理
$ D1 J  u3 P$ d. y- ~" g( I: c' u( [& _- l# f
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

1 P  x4 T" Y" G/ |, C) y/ Q  R- ~' D, Q! O( L  m: o* w, l
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。
    3 m5 ~2 \+ q8 U$ G6 Q. b4 C6 \& g
' P; s: ^2 k4 B
; p/ H& Q" i7 B& Y! {) }
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。

    * s! A6 G: R4 k  G4 i
0 @& C1 M$ P; k
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。

    # B* m6 q& o# c; f$ K9 K

# G+ E$ K, K7 m$ k

2 d  K- Y# @  h* i& [: x

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

3 p8 N' V$ y+ o$ m6 P6 b
" `3 N6 m( R$ R" O% C  G
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。
) k$ S+ o% f; i( |

; K2 K  N% s' Z8 a因此,我们要考量的,还有产品和需求层面的东西:
! m" H6 d0 t( _7 O3 I, `- D
8 Z6 w* A; E/ S4 F
1、需求管理

1 I, S4 I& B, O% O+ I: C% d

; P% Q* o! w+ F1 n) X2 @) u
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。
  h/ r, K9 h& Y2 Q' f4 a7 q0 P' Z
6 O' V1 O- J0 j, ~% p' g/ I
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。
    . M2 u. J" h; C8 S5 n7 g- ^
/ H( O! p5 I5 a' K* E; t) K4 E
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。

    / ~/ G! O( x! M" b* X6 |$ h1 k
    对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。

    4 l( R. T, _7 {/ M9 Q6 q1 y
* g* s% \! v$ C2 @0 l& @
1 h* C- p+ y$ L8 g) g
5 V: g& ^, Y5 _8 u' t" X  Z3 D8 e
: a$ Y+ q4 Z& t7 r; s' J
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。

    9 c3 |" H2 W/ I3 f8 ]# i/ X; y% E+ l% |' p! `
    因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。

    ; N, h( m+ x4 U& u

    4 b1 Q3 m' k; U! }4 ~2 z

8 }4 X+ J$ ~7 q0 j  o

2 }# j4 a0 f% z+ B9 w! D' ^$ n$ g
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。

    0 f- g* X; K" t- r0 i* z! R# m
" ~( _7 U$ A# X! k; G; @2 t6 b
5 g8 Y, g' E9 @1 Z
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。

    " j3 H. U' v: ]6 S( o$ U
" z6 m. _, n$ S# u& ?$ r5 d
2、量化
2 ]1 Q5 u3 B3 p0 |* }

! b2 A" p8 {) q% l# z2 GIf You Can’t Measure It,You Can’t Improve It。量化是优化的前提。
! J9 B3 L8 H8 p/ P( X
& a% ^9 `$ L7 A5 x; d. p
量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。

7 D: A3 F! Y9 B/ c0 [
; w' y' ^- K3 W1 f% i6 K- G
3、制定SLA
9 O+ L( m: x% M- \4 }" N; f' m

* V. y9 i) \. h9 W" w; W* ^简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
& K( O- H. _' t# N& Z8 B2 g0 ?

. g  P# x& F0 m  J  y2 }4 L一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。
, @6 A! h2 c& _" ^2 ^

" X& d! h; B4 x

, J/ J0 Y- d, M+ {3 q  B

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

# B1 R% e, `: f. `
2 e5 n8 L# Z+ ^6 [
1、制定规范,并让规范在平台落地

' c: S0 w: h- S2 c- ]0 P" W/ T
4 A8 U9 N2 r1 C" U* B( z
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。
6 i  \  N. h8 B/ U( n" V

- _- U6 Y0 T" M) P8 N7 f规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。

+ {0 u" Y' k0 u. n  b

2 e! k  ^; ], B# c: F) X我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。
2 d5 k% R% G' M) I# s
8 M5 S' f; \* g& N
具体的实施方式可以考虑限制和引导两种手段:
, ]  `( W# G6 q% G4 N( x8 ]

( [6 ?# ?1 @; E- a' \) b4 r) g
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。

    3 r* O$ c" T# m

3 p- ~, P& z% P/ g+ w3 Q
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。

    5 P* q# G  ^" G+ B# n+ q( |

( X; h8 p' ]. H* x( p# b1 o  }
2、协调开发与答疑
6 P# L4 {" H. e* C9 u- d5 A( l, M

9 T; U; K) S! r- J: Z! Y9 m/ x运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。
0 u/ a5 J7 k# t$ ]
' H8 C" N" O/ e( u' F) W/ N( @/ `
日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。

- ]+ w0 M1 l) k3 w
7 I3 t! N& J* R2 r
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。

0 Y, A5 e+ U% n! N, `( e! q; W- E
' r- ^& e5 N7 d0 j2 J
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:

0 u' G, E' h( n5 u% V

7 _1 J! V& k. z% t' `, J) m3 `
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;
    * {" \5 b3 P' y, I5 _: Z

6 X! @) M% k) X0 K/ v2 o/ w
& I1 p7 w  Z5 ^
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。
    ; i8 ^0 W! ^! e# z
6 a" E1 r9 ^) ~
我们也要同时思考如何与这类用户说明,提高小白用户的体验。

1 {' T3 _( ?3 W) i

% m& I" \" g6 m( |因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
0 U& w  y+ V. h: X
. F2 ~/ v, A: ~% W! q
3 r% Q# j* i3 U# V7 `

六、后记


* f5 D& j/ E7 I& e  j

( ?; x( K- R5 F) y- w
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。

% X' M& Q4 l. Z+ Z

  r: Z7 o% O# G. e5 E最后附上笔者思考本文时的脑图:

4 v0 O% v3 C1 \' F" j7 q4 ?/ Y7 q
1.png

) _$ |& F9 B' z  l0 }# R% v. [. C

" c# E5 x* Y9 o: a

2 B4 l& y0 Z3 _3 q  |& y
作者介绍
- ~4 b6 \: Z( E/ M
; c/ P2 }" `+ }
高家升,现任职于滴滴运维部,曾负责滴滴登录系统的建设、监控系统存储与报警链路的重构。曾任职于小米,参与小米自动化运维平台的建设,负责服务树、权限、堡垒机等模块。专注于运维自动化与稳定性建设,代码熟手、Open-Falcon Commiter。
# t! r! }1 s& ]/ x

本版积分规则

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

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

Baidu

GMT+8, 2019-1-23 22:18 , Processed in 0.266213 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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