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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-3 17:24:59 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-3 17:33 编辑
, H+ |: \  V) S, `- ^- N# c9 E5 o2 ^3 L& m# ^1 s& B# S8 J" s

7 k+ ^; ^! x* n% }

" L/ g( ?! R6 @' }; v  h; p# y) t4 I
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。
0 {- s0 P- _. i- i/ {3 ]
1 J# q* |& O! p; U* R
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps
) ], t% r) g4 q1 s* s
1.png
DevOps
+ A+ R4 A6 W2 s
4 ^. u& \/ c6 \
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。

  Q: K0 k& P9 m; S2 r

- B1 V8 T6 Y5 v( cDevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。
6 L! S6 d" I9 o: ]: q& U9 F+ @; n
1 v+ }- i: ~& q6 v% Q1 |( ^8 i
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。

: U4 Y2 l2 m, X$ X4 O7 Y) T2 H

! \$ P1 V* d& o5 r/ ]

: I+ m7 R: x6 u- g5 q

一、前言


  B# F" `! W5 S- c8 H6 |. ~: N
! y4 |0 b( V3 n% c" l! E
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
$ y4 `" j7 L, Z8 i" u
& z9 e! w1 v8 P" C2 F0 Y: k9 _8 I( ?
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”

9 @+ m$ E6 k7 q, y6 _
) P& }; u5 |7 h" s, l
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。

6 |! d& \+ |2 {1 [; q0 [( u
. I, }8 a' @# i6 ?0 `
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。

% A9 d3 ~2 l! [; o! h" ^  H1 M

8 i1 K, I1 C0 x7 U
本文,我将自己关于这些问题的思考分享给大家。

8 s9 O: b( |9 ]& h% L) E
' t7 D0 F$ l. J0 t" `7 L8 A
6 T" z% j  d7 `

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


& \2 P. Y7 B, t9 V
( a! P+ T/ B& v  S% r: f/ ^
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?

" F7 G6 [  m) p1 |+ t. X' m8 D" H
. j' w9 }8 i6 g) a
如果让我们来从头设计一个平台,我们应该如何去考量?
- `% M. a3 L; {% W
+ ~% g9 }" T" N3 r/ ?% }$ m
1、效率 & 成本的均衡

4 `4 x& S0 A" y0 k" G* {, d

; z" `! r& l" t+ l  j2 l运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。
( F" N4 @1 W! }2 C; R, O/ r" J: z
4 Q3 [& H( u! N( A/ ~( q- \
至于如何量化比较,就因系统而异了。

2 v* k* w. X; Y- f) Z

& Y0 v) l$ A8 I" A) @* z
2、体验 & 人性化

: [1 g# \8 M- j) d) q

/ m4 H: P, x1 i8 D为什么我要把体验放在第二位?

6 s6 _4 _4 w, x# H7 \! i

2 C: R  R5 g- G) Y. ^  @8 _$ t
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。
: n) y) {6 r% r$ g; Q* |; N
/ c( B$ J% Q4 H" F" U$ k
我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。

) l+ j0 i7 P5 X5 P+ y. J1 I

5 G4 E! ]/ P2 s; F0 o8 d
3、优秀的系统架构
6 f+ W( N2 j4 W4 g
7 B5 q* {8 {7 ?/ P1 ~
在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

: \3 f0 t$ |5 c- J* u7 J0 L. x% x8 ~

+ ^+ d" _, `  i2 H+ d
  • 稳定性:负载均衡、多活等。
    % Y% {4 t8 K7 @  y0 u

$ O# W* x6 l" f& Y
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。
    # [$ E8 e8 _. t0 o

4 \$ L5 w2 H4 {/ {; ~
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。
    + [, l/ g( _% L! ~! R1 b- o
* H1 ^' n* F7 y
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
    / e; L5 U8 o; V2 a

; C6 W. T( J! o
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。

    3 U$ y& W/ p/ R: [9 v, B# q
6 T, s! E+ ?- Y, J. ?. m

' d% c* H1 \6 @6 I6 ]6 y" V

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

9 P3 \# h- |" b( P4 j$ k) L! [

8 ~( a" P1 W; A9 j
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?
% o- l, W1 e9 ^6 O9 q: o( z9 Q+ D
- @2 D5 B3 \8 E8 N+ ?. O5 f2 c
运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。
: q  z' z! T- g5 z! j

  Y* h3 H6 o  Q* [0 j用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。

  G+ S9 I/ J2 i+ {# f% s0 U

; Y# q0 m7 f7 r+ e) G1 P* |* C" m
1、架构上的稳定性
9 a1 r* `# Y+ A
/ }) J, f5 e( I: a( S" @: p
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。

. F& S- r# C- S! D8 t* v& G
. t8 B, I: c% N0 O+ ^2 m3 {& I6 _; W
2、快速地发现问题
7 H. [' C" A0 D0 }% r

. K: {3 U, j( n! n: c" G
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。

# L& ?& d* d5 c1 V# P/ v
7 Q% O8 L  @+ i" y3 ?4 w
还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。

4 @3 C, F1 X' D- q  X0 o
" d6 l& V9 T: l9 S+ x/ H4 \
3、应急预案&演练

6 ?3 G  D$ b2 R+ N
' _- I( o( B# ^6 Z9 P) K/ f  Y
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。

# N. {' o* v7 _( _9 B1 P
9 h! S% E- u" C5 L  `$ y
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。
' Q) e/ q8 H& v; g  n

* q8 k0 ~$ X+ W- G* m
4、自我保护
# X: ~1 H8 ?6 K( o4 |- q
0 c- N0 Y& r6 L' J6 e
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:
3 h6 M4 g( L0 I+ P2 E

3 g+ [) h: P- `
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。

    * R) f" X5 Z& I$ R5 f* ^! L5 i1 {
; B2 Y$ }0 e" Q4 {; ]- X, @# r
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。

    ! q5 A' }) \  _- p: z
* ^- x3 O7 D; F4 t- b) d
1 ^# m( L. J4 j0 l
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。
    6 ]& p3 w6 B7 `" F! B

% p- K3 E9 m1 \3 ^
5、容量规划

$ G7 m3 _( A' m& _
; c3 m1 Y) `( f
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。

% A' s/ N, U" _1 C5 q" E" X
- I7 e) J" G7 p3 Y2 O
笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。

2 `( E1 C+ C( i4 @- b

8 j6 t* z8 O  S% ?
6、变更管理
4 a% j" J% r8 a3 a! j, B
1 @# J9 f4 ?7 G2 \! R5 v
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:
/ O! W8 p! Z: ^3 Q  [
8 n% [1 n4 r& F+ C4 A
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。
    - w+ D, U0 ~  [: T
( L8 B: O! z- b

2 d" E( X+ s1 |* z- Q) U" U3 S1 Q7 |+ z
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。

    $ U  W1 L  z% J
7 b1 G9 F5 T4 j! k. }! ~
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。

    + y$ n  U9 S0 `8 k

% g. S- x$ N5 P& Y
. m7 @7 i& \  O0 q! F

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

3 P, B4 c! @# r2 F; W1 g
: p( j& }6 ^) l+ G
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。

5 K8 y" E. C; x# O/ {- t
9 h" G$ b( _1 L) ?
因此,我们要考量的,还有产品和需求层面的东西:
7 b) s! ?8 m8 w6 F( Q

% _$ Y8 F6 W* Y1 n
1、需求管理

1 [+ [% {% }) o0 v  z' Y  ?. v
. D, ^3 X: s5 U: T9 x8 d4 }
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。
4 J2 h8 H* m6 N9 ?0 b
( S+ v3 A' |/ d
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。

    ; u- [" w1 @/ W
  F" U* v/ \( a8 i. Y; K3 s
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。
    2 K' E& k3 U  D+ b4 L
    对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。

    " J8 \; j% `3 |" g4 ]
- B* {1 C% l+ L9 \' C
- c. t- B: g/ j# _9 a$ W; x
1 W1 ]3 c7 s+ R8 K  u8 t
/ ]7 x, v' Y  |2 P. B$ e* h4 L9 U
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。
    & v9 g; M5 n; [* ?/ }" w( B% ]1 a
    " Q) _6 f; v/ x* A
    因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。
    8 [, J; ^+ i+ E) T

    6 `" y* q" C" S9 q. h: N$ K7 y. x

. B- f3 `- L/ R4 g6 q6 P7 f# k. p

4 z' Z% j8 `) ^$ c6 I3 }
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。

    ; @( {! q' f* z- A1 a, ?5 f
. i; C: X- ?3 X9 e1 f

3 i" r* \9 n  p& K- l3 v* Y0 I( @( Z
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。
      k4 C% T% _. q

) `! P6 R4 n- r3 E% P" i3 [' w
2、量化

9 d) `$ y6 a+ F) N8 o7 L# r+ R
0 S% H5 Y1 {7 \8 ~2 c( G0 E
If You Can’t Measure It,You Can’t Improve It。量化是优化的前提。

' }* v) H* t; D; H

& T8 v) |$ {4 t3 x; a量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。
9 I( K1 g% L9 G2 G) `
: D/ A) R) B4 j9 K* j0 B5 v* G
3、制定SLA
; Z4 y# e6 _0 k# u

0 }6 I1 G3 k* r% \% s简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。

4 Q, J6 ~4 |6 ]1 X* u8 S
( a! }# h  d$ M; E, o/ n
一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。

  ?( v1 H4 ]6 s/ K- @/ ^' p! e

5 M/ |( E( j4 h% `+ V+ e

; y# y0 j, i( K; ?

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

4 S! G. I: M* I9 q% U) q# `
5 r# I/ I5 T7 E+ T( m7 U2 g4 M
1、制定规范,并让规范在平台落地

2 t+ o& `7 n: w' E% u4 M
9 y! E5 I% Z& U# {' M  e* }( A! A
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。

2 m. S5 Q1 D+ [) e% |' `1 @

& l6 n, @' A% o8 L  q+ E, H7 X/ J规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。
# Q: y  B$ Z  _; e# O. g0 T
1 t* T* g, j6 {
我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

: D5 e- T5 T' o; `2 F
' V) p" W$ O% u) ^2 |/ R
具体的实施方式可以考虑限制和引导两种手段:
% M" G( V2 ^4 t5 o3 ^/ h, V. r- d
" J1 k  y8 R' f/ e7 W
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。
    # ^# E( _! \5 Q- A) a( `
( Q+ f3 c) [: E
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。

    ' M( \1 l3 H: v; s, T  ]  @
( r1 L- ~& H, u, S3 K
2、协调开发与答疑
7 u( A8 F2 I5 x- G0 e/ u( }  a

# l2 c& N; X! H: n/ C/ Q运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。

0 f! p- c# ^# ?( U8 K5 `

. M0 Y5 k6 v# w- W3 r( v, S- v日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。

8 K& j  v: k/ J" u1 A$ m2 u1 @& F( W
) c! D4 B( a+ h3 F0 Y
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。

. N. T0 p, ?! p4 S5 P# I% i
% o/ ^5 Y+ ^7 E: ?
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:
1 ]! D- D# n3 l9 g
* I2 `& W& w% q
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;

    7 b1 o4 g' G& i% m7 X7 Y; b

" Z2 Z3 e9 {5 B5 Y
, ^" x! a& f4 b5 I
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。
    / S5 i) l) E$ O2 R8 K1 c

# N  Z4 ?5 ]1 c' X2 D* [8 |) k1 p0 Y. C
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
) t3 V9 a" \8 Z, a5 ^& J1 ~+ Z# Q8 V

" g0 X' @) N# ^# z8 @; [4 D因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
2 T0 t7 \: |" H

' u5 c, Z% ^. a5 E% L3 H1 Z7 X
/ f+ G! [/ _/ L; E+ X( q; J

六、后记


1 ?0 o& a' b, |

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

6 b" Q' `. x4 {$ O/ l
3 A/ K: q( |. ]- e5 m$ [( l
最后附上笔者思考本文时的脑图:
4 b6 V6 ?9 V2 Q( |7 L5 c
1.png

& M: G" s0 G; T* q% a9 O
) N( Z4 M8 Z: W6 v- ?3 o
& |* g0 Q4 e7 [8 J- t' v
作者介绍
8 ]/ S4 G6 R' s- C+ N

6 T( q" }9 d. i6 U4 i1 ~, `
高家升,现任职于滴滴运维部,曾负责滴滴登录系统的建设、监控系统存储与报警链路的重构。曾任职于小米,参与小米自动化运维平台的建设,负责服务树、权限、堡垒机等模块。专注于运维自动化与稳定性建设,代码熟手、Open-Falcon Commiter。

( P: `4 @) T0 L1 h+ ~& `2 f! Z: M

本版积分规则

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

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

Baidu

GMT+8, 2019-5-24 13:25 , Processed in 0.249319 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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