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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1056|回复: 0

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

[复制链接]
发表于 2018-9-3 17:24:59 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-3 17:33 编辑 / H& y/ C3 _3 P5 U( `; X
( L! w" D( S; n0 b  n* l
2 @1 @) [. e  f/ O
. y, O6 \4 O$ k& f+ \# p' M
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。
% C' T4 d/ l1 {  J* |

! m7 I2 j# X# @3 N
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:ITILxf.com" target="_blank" class="relatedlink">DevOps。

5 f. C2 G5 d4 a3 n" X1 ^
1.png
DevOps
5 L; G$ {1 n( f" M

1 Z) ~6 i% k; E& @( K" I# H
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。

6 s( h3 `/ }: }4 Z: |

1 r1 ~* s$ W; DDevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

% }' E8 u8 a' f* }, }
* a: k! j$ j3 f3 m( W0 S  G
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。

7 M3 `) v, }0 c0 S9 X7 R
+ g' ^& Z+ k; h7 }' m  X4 o* o8 L
5 [% ?* ^& v* M$ C

一、前言

$ E. `6 G) C* I4 n! C

% p2 T8 I# E* Q& z& ~2 D
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。

+ o' d7 w- _3 o; K, x2 z8 C% x4 A' P

; W. B0 e: U  {' X
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”

% g5 ~) Y8 X' B" \% T9 j* A" P

) G2 g2 Y" Y1 S9 {+ t
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。

3 l( O) }' N  J. H. u& x- i
3 ]+ e7 B2 N( \+ W& V$ N
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。

" n) M4 f6 I4 d" {0 g$ m' t* Z# Z
0 |; y9 }- E6 M0 B( F$ B/ k1 g
本文,我将自己关于这些问题的思考分享给大家。
& c' ?+ V+ I3 ]: k) V

. {1 C5 t1 b3 I  H
  T5 p# b' q5 E) r  B

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

. X" K+ ]7 b7 k  N8 s

" l% o' _: f2 e& |: A/ v/ Z
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?

2 c/ z" ^# x6 P& [

  k& W/ U; _' H3 X
如果让我们来从头设计一个平台,我们应该如何去考量?

5 r7 s/ G9 {0 u: A

; T; w  E1 x3 ?* H" @
1、效率 & 成本的均衡

; H% B; ?3 k( R7 Q  G9 t

* V) _; B! \7 _运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。

8 K) K, v& i) Q7 ?. H. N
- ~' [) Y( i. X7 D$ u2 u2 E& |4 B" x
至于如何量化比较,就因系统而异了。
) m1 E, h' u& a- r# b, c6 t

8 H9 d! `' ^' F5 g6 T( R
2、体验 & 人性化
  E# w7 Q/ V- f" v3 R; v6 M; P

: \' _1 n2 N3 a0 A* F( [为什么我要把体验放在第二位?

7 m8 c1 A. u+ C- m6 q
  p& s* k; b5 r' v8 a" a
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。

5 [6 n* p5 ^; z, r+ G# y/ D
; C: I( K! l9 U# l) j
我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。
; Z7 a3 H% t7 m# V6 H& `
# v! m+ F+ F  W. ?
3、优秀的系统架构
3 j& `6 |( o" U" p5 r
6 l+ g- Y& F4 @
在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:
: @, ]7 l9 u. I  \/ r" n, r7 B

+ F5 u- ?" l) N  D7 d  `
  • 稳定性:负载均衡、多活等。

    7 J+ F$ ?. k' J9 C. q

2 g0 R, R! ^; q3 H
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。
    5 B. W' Q* a, Q. D0 b

+ a; {9 `' K9 s$ _6 z, D
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。
    & w; i* D& @4 L  b7 z# L8 }& R

/ Q  z. D8 ?# y# R7 S1 e7 z$ t
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
    - R+ k5 V8 o; @7 d! M' w3 f

5 R" r  A' r; V( n4 Q) j9 s
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    & }5 C. h) w5 K4 s1 |8 Z
5 ^8 S2 D% _; v1 h: W6 T
6 I! n9 K! M6 s! W$ F

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


! T9 D$ l- |5 g9 F9 t4 A; a

( z$ E- ?2 k) M& \$ c) t& @$ k3 |, `* [
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?

% A" j2 G$ ^5 a+ T  f  {
% ]: p8 {& Q' y6 s) V
运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。

2 h8 A9 {  g8 Q: J: ]$ f' F+ J

. p) S! o) ]1 Z4 s) k用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。

: X  J) ^5 I+ I0 B3 p4 g4 J

) W* [( E" N6 d8 e0 H
1、架构上的稳定性
. Y) D. m3 B8 z

' o, h6 m% n( x  w
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。
% A' `* r4 X+ o# T

+ b! }$ K" J% V8 s3 f, u7 _+ t
2、快速地发现问题
  V- ^: s- l9 C- t. K4 t" d4 h

3 x9 `  s" c# c% o# T
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。
; R% R6 L# A/ j5 n7 J3 H

; y7 s  W* Q' p; P5 }$ G3 d" {还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。
, @) o; ^) K, M1 N- q2 z
, {9 j4 d1 }8 q" B
3、应急预案&演练

+ b6 e& m  ^& i# E. w
2 n0 C+ O1 Y- D. ]; T! b& e; {7 I
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。
9 U* p" D. L" c

0 B5 B7 Q+ f; Y8 T3 Z" n因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。

+ ~: v" E; {( i$ E

/ V* e* _9 i" K
4、自我保护
' |6 N6 Y! x7 P9 \0 f0 a- ~# ?

! O$ b% R8 o* {: }; f
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:

) _- O! D: K- G. C  a  b. z
3 E$ u8 d, O( y2 N
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。

    - B) M; Y& f0 g- Z

- q+ }/ H6 ~. p+ {: @
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。
    2 @+ Z" t. a2 G# H& ?* c
& B* g' ?: E+ g  ]
7 g" `( f: i3 b1 ~
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。

    ( K, R( X7 B# s5 G6 }$ M* W
* B0 ]4 |# k3 e# v4 ]4 F9 q
5、容量规划
( d- v. e+ I8 A: o% d1 h' [

/ B; ?$ N8 \/ b$ }& o& E
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。
$ v  k1 r' L$ I  H9 x+ T5 [
& S6 T+ I. F' p" v
笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。

6 l2 P3 B3 V0 y# v" w2 v# \
% E1 n7 d2 D0 q
6、变更管理
2 }: u  P. U0 f( y5 ], _1 Z/ f5 `* a7 D. b1 }
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

% h7 \% v, U$ \5 z% I
0 B! y6 e% ~+ C8 o8 p7 f% g4 J
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。

    0 E4 w" x3 N" @2 w( U  N; K
1 e- \3 Z" L6 S0 U' o

! g' `' g! w7 n3 @4 Y- E
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。

    / d) }; V% y& I
& B8 J$ K/ Q- F3 n. J
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。
    6 g1 b% Z, z5 T7 F  g: T

8 Q) O) I2 O3 K4 Q! v
& g: M: \7 I0 N- Y- X

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


: ?: N9 _  [$ A, P

/ V2 J7 ]& }7 F' d2 O$ m; U
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。
0 x9 f% z, Q0 M4 V9 ]0 J( o
% _) o( F7 H( `1 s6 r
因此,我们要考量的,还有产品和需求层面的东西:

3 H- Y+ w3 U& B

) q# {% B6 ^) c' W
1、需求管理
( _# a9 w9 M* Z; ^9 O# L

! ^* D# D% d4 n( X- k% D: C1 y
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。
8 j0 R0 M6 {. s; @) y* V

4 j4 ?: V6 t7 g7 k, q5 V
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。

    # Z$ W3 I( X% n1 z# W1 A7 O

) I' J/ Z* }. d1 `$ a: I) l' A0 y
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。
    : [% @1 ]* w! L: o, g7 O
    对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。

    7 k2 R' \; `3 n0 h9 U

6 t# t( E3 H- a; }
* @* R: o3 ]* S5 b6 _9 `" T  ?2 F
6 X) S8 g, d" B

/ `: u0 @4 V1 Z
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。
    8 z& {, w  [( C$ `" ^( p5 C
    " o  ]; e1 X, s3 u; @9 l& b6 ]% F
    因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。
    ( n6 Y7 X0 n+ C, s

    9 }; S- _: z3 T4 j0 [

4 d4 Z; T* b9 m7 Q$ t1 _

& M+ {4 U8 @+ `/ f+ N4 `- e! K4 c
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。
    % s9 _) D7 c. E4 v6 l/ i8 o4 w
0 a" @( B* n6 t

! T2 m  b# ^; V" s
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。

      q/ r4 W# j) g3 T

  s  W. D: \; o5 A# n! k& e, O
2、量化

- f5 ?% m' ^) B! A' P8 {8 n$ O: r

; ?+ n' R0 g7 [! L1 _If You Can’t Measure It,You Can’t Improve It。量化是优化的前提。

, Z$ n5 {! Y) J+ l/ L

& |# D1 g. |: ^9 V0 a量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。

* H- W* b9 d" ^, k

2 M0 p$ ?# O* D. [5 N+ C
3、制定SLA
. b- ~  e+ E+ f9 Y9 w8 Q

: C& ]7 i( M8 {( w简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
* a6 s. M2 y3 [4 X: }

; O( w" I5 z0 _一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。

3 U$ I8 t8 H% y. [0 g% e$ c
7 _( X9 \2 d* z+ S" B+ ?1 C+ @

4 ?1 @7 I* M, d' O' c' N* |

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

7 s/ E, Q' P  d/ w' _
' N' ^) t+ e$ \1 Q( R5 s8 _
1、制定规范,并让规范在平台落地

& H( z4 T  ?& A7 U' D: L4 D2 W

  @- g% n2 Y4 W5 v: z' J' I
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。
" C& Z( N- f6 X7 d2 b

3 O# {' r. V7 [: N7 v4 Z规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。

8 Q5 F: Y4 |% C1 n. j: z6 S
+ f( p! e- h( k, K8 W
我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

' @9 z" \- n- C
+ Z9 c8 m% J+ ?, u' W, L# p$ r2 {
具体的实施方式可以考虑限制和引导两种手段:

4 f  F3 s& X& i( K
: t9 ]- k# J% g2 H
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。
    " Y+ V+ ~" p' @6 @  O5 c

8 w2 @  E9 U# ?
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。

    * Y' U2 I5 V- y

3 ~- O+ L3 g0 r7 @9 O
2、协调开发与答疑

  U3 J1 k! I7 Y( B6 M' C

4 z- b) y2 \& W: N, p运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。

3 ^* k0 t$ t1 Q# c

- H* l. j& s/ l, v: H2 ~日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。
9 k6 \4 X- r! d7 M" Z

, |' E- E$ h. q  J  F+ K5 E
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。

2 k5 T5 n( O1 \3 U1 s& p
, i6 X& A. N1 Q- F. C# J6 \8 }& X
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:

% g) G  Q. u" d* P- J
- C. M0 j; }( M  `5 c
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;

    7 b- T/ M$ ^$ B8 @$ y$ {, A* Q, U

7 w0 h& @9 C" M0 T! r, n

! U9 g+ o; L; ]$ [! m" L8 W" H
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。
      X$ s1 ?. o4 W  z5 ^
* H7 o& c8 E( x2 d' h7 H6 {6 ]) E
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
: {, Y# Q3 U7 n- t
& z/ g. D- c# r. X0 H
因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。

8 V# O0 N4 `% U' H4 U( Q/ k9 `) e

( S2 X9 ~4 D6 |; }+ \' D5 B

: ]1 [6 o& i5 Q6 w

六、后记

5 D, c; v2 {" E5 l' B! l
+ s3 [/ K/ i0 v3 {
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。

! ~1 k/ b' d) E2 T; b+ p1 J/ @

, P: ~: ?' k& o& Z6 Q0 G最后附上笔者思考本文时的脑图:
2 {$ s; C  y6 M( d
1.png
$ w5 k; m8 W, Z
2 J+ [# ?+ G+ [: P0 Z: Y

# G; Z  j5 Q  f
作者介绍

0 y) F% s$ Q( \+ I, ?

, ]; N2 y7 S9 }1 R( X6 t+ c" C7 F6 n
高家升,现任职于滴滴运维部,曾负责滴滴登录系统的建设、监控系统存储与报警链路的重构。曾任职于小米,参与小米自动化运维平台的建设,负责服务树、权限、堡垒机等模块。专注于运维自动化与稳定性建设,代码熟手、Open-Falcon Commiter。
: ~6 u5 [+ [% S, V




上一篇:DevOps转型 - 误区、实践和实施路径的成功之路
下一篇:DevOps三步工作法第一步之建立全生命周期管理能力
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、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-5-23 04:38 , Processed in 0.126371 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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