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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 424|回复: 0

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-3 17:24:59 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-3 17:33 编辑
/ R+ K) X6 x6 \
9 T/ R# K: [8 s. v/ Q$ k3 a6 g7 C

: B! m# S4 D" o$ S, ]

% `. B  j4 Y) \  G* c; s1 L
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。

8 d$ L& K' D+ @: |  R3 X# D( M

5 Q! T2 Y& E" i3 M, k, G7 s
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps

7 {. {- n- g. Y, k4 Y, H
1.png
DevOps

- J+ P' S5 V8 q

1 x6 P1 J. M6 @. I# b
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。
" ]' U( V+ K5 T
4 i7 v9 R% W0 |. m
DevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

9 I' p7 O9 f, I4 F

% m6 z9 t) d' H# i* [
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。

, I) ?& x' F8 |7 V

% Y' w5 v; z" j) j
$ S: d4 @% q/ l

一、前言

* W, @5 v* `& u; @6 u2 e2 V
4 U. v0 }. y4 D% X% L2 a& e; t9 g( G
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
8 V, M& ]0 H% C* D  f, x% h

6 F3 A) O2 |' B" @+ u$ H* z: q' U/ Q
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”

" q* M! q0 F  D9 c: Y
# P) H. |! k2 a' Q
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。
$ L9 l* n4 }: W  l( Z* i" s: S, r

7 W0 _0 V# W. U  H! j
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。
1 o' Y& ~3 C8 g, P: r

# [- s/ ]( q: V7 S
本文,我将自己关于这些问题的思考分享给大家。
* c" k! w2 R1 l8 g

4 [- ]% k6 l) f% Q" m

, X3 I9 @  _3 u& G! u3 M3 x

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

: V, ]+ [& S: T  a

: @; n" D+ E* H% W- ~! m7 N" R% w
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?

( Z9 N) S, I4 S

3 q" [4 g! I% o! ]. d3 \/ G
如果让我们来从头设计一个平台,我们应该如何去考量?

- U3 `; P6 a* e

) S7 W" Z! {; g4 f) a  {" e5 |1 y
1、效率 & 成本的均衡

% C8 t2 u! S1 _1 O+ y
  }9 u! c3 K0 B3 y0 c
运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。
$ z: a0 x: T- `1 l$ i$ p

5 a! O+ |  Q& k6 z- C" S至于如何量化比较,就因系统而异了。
7 l1 I- z- i" d
6 N4 Z. x: |6 N* n3 S/ e8 E
2、体验 & 人性化

, o0 \( _% ^0 P* b: q% O( |7 E
0 m9 g% R  v: i; j+ O  _4 ^
为什么我要把体验放在第二位?
" D0 p* ]9 c* z* w

: Q* b5 S' Z& x2 ?/ L
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。
. K3 V8 y; K# \  a

$ b6 y% a2 p, p& n( D9 k6 F我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。

8 [2 ^$ e5 b; T; U0 S+ M; b

* _+ z7 {; o3 K- F1 n" ~
3、优秀的系统架构

1 R1 n/ \. j0 o( c: u

5 U9 E: }, f2 X4 A4 x在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:
. H( C( d  _% O3 W
- l# |3 F$ b# D( T# A
  • 稳定性:负载均衡、多活等。

    + a2 h, u* K; i0 d; [" w

& x2 y' W7 N% b" F+ l& o
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。

    0 R% M: J  a5 B  I

9 D, ?8 q& ^2 }4 d5 _
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。

    4 A0 S# W6 Y, p: Q9 h  G

9 X) H" `1 \& ~+ k# e* J9 h
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
      u% l! U: Y8 p5 ~2 Y- A7 G

) T, X) }( F0 r& }
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    % _% k( H: P( E! `3 h: ^% _

! u% U8 |% C, o% i5 k% Y

" v' @# V7 A7 w; T1 I

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


# q- ^6 L# F7 s6 b2 E6 N. [8 Y
2 x/ Z2 `" f! d) K2 O
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?
7 v/ q5 p0 {% S4 F
5 g9 B7 L: q9 c5 Z$ g& M- ~/ a- d
运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。

! Z. ~7 L" ?8 L- }3 f" u
5 s/ g1 {/ h. k0 w( K& V' h2 H
用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。

# r' W9 Q5 R1 _0 q
+ M$ N4 q/ ~' j6 Z$ [, i5 b$ I
1、架构上的稳定性

7 W% h* ~2 o& `$ U% L
; [  H0 y* J9 {6 A5 w/ N3 S1 i7 z
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。
; W/ ?3 f+ K7 h9 g- [* }
4 U, y9 O4 j: m% ?6 H2 t" a
2、快速地发现问题
  l$ z4 x" b. S" ^8 F

( {! d' l8 H3 |: k: ?2 f( |) a; Z
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。
: D  D% X1 D3 s6 Y; H+ E

* p' n5 _: @2 N( l( N4 c4 h1 @3 `. A5 o还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。

- ]) g& m! E' f1 s, s! R
( b# S5 o/ D, W0 G- ~2 f. {
3、应急预案&演练
3 b$ q: Z; D& L, ?' t  H

8 W& D/ U9 |7 Q
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。

; |: @- e0 ?1 K- i+ U
$ d  ~' T/ }7 c  u, U8 b# q7 E! x
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。

. G+ h  `) W# C, g5 \7 q: ]
+ A0 D% P! Q" _; i- q
4、自我保护
! D  j# n- R8 s& T
# C$ L% ^" |. ^, K8 k
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:

7 d- D1 s: v( ?" R& n

4 ^3 M$ [* {7 {+ Z! C' m: V9 p9 b+ u
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。

    ( ]1 Z+ n0 @* g. A! V5 B
% p6 G7 u, ]7 n) y
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。

    8 R, U; W0 }8 C
9 s: S9 }) G) ^% Z
' u5 i! h: T1 e4 y
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。

    ' j4 c8 H8 t- o/ d% H* m

9 M- e2 S/ O; g: \4 C
5、容量规划

1 Q9 q! m: W5 [4 @% i& v. p# q' m9 Z

2 e5 ~: ?- H9 u, O, j  w/ G
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。

  D" N1 ^! L( w4 I( ^6 a. L' o

/ N& ?' T2 Z6 y笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。

6 q' ]0 [* q3 J* H6 r' K$ Q4 R

/ P* t2 `' |9 f3 n) C# r
6、变更管理
5 u, p, E: ^# V" j
% _0 f9 F7 Z& U3 W& J+ t. i/ D4 h
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

! L- o4 ]0 c3 D5 N: W( B
$ L; A+ c3 w& F# Q+ m- Q: }$ x# k6 b
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。
    ' n# ]1 E5 o4 w) X" W

+ q# U3 H' L( Q9 \7 g% f; Z
* s# w5 o% [4 }5 A4 B* C- v6 n
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。

    8 z$ l' R9 n& l3 g6 m9 r

6 S. E$ k0 U; K! x; ?" q7 i; b8 G
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。

    4 X8 p% ~* ]7 K8 f6 {4 C' {

, b; S" j; K) M* k& B, F, @

) y: b; v9 L7 X& {7 Q

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

" |. Q8 {# d& l, t/ R* U

- W7 {* i' I! n* ^  Z4 m
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。

: q7 P% {' l, P/ c& Q8 X# e

% y3 ~8 \. k; |8 m- w; g* x因此,我们要考量的,还有产品和需求层面的东西:

6 b0 s9 {5 y0 W$ ^* O

- i) x+ F8 }% F8 l7 ^4 ]
1、需求管理
7 e0 ~. z6 [# E, L3 m- [8 }

, ]6 D: ?3 a. I+ H6 i8 K0 F  m# `
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。

1 m9 h% g. `' _' q

. M8 k. R4 G2 `7 c
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。
    4 s8 Z4 C' J8 A' F$ R' e
/ ]& g2 g4 k$ a+ E: t
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。

    5 P  P6 _7 i9 W  f8 f- Y$ b! C
    对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。

    % F: l+ E2 @' \3 R  h

+ c5 A7 r0 b0 m) [7 K6 l0 h' P% ~5 r

& ]) o" z" \5 v8 p# X- {- G" K1 l& U7 b% T, `

1 s5 p3 ?# I. |( L/ p, X5 b
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。

    / J1 a1 Z( d: Q. e" {2 a
    " G, f* e! _7 W; ]# B; x
    因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。

    $ I, I8 U+ `8 k! [2 Q4 a
    0 r/ t, U! n$ ?) s

4 T1 m/ u" s2 j8 ^5 @

# w( c: P4 U/ y' [6 m- N  M
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。
    " P  ^+ b! x6 Y8 B

$ d5 `# a7 q2 t( Q, y* I$ c! b

/ v& u6 F/ H9 X! {) K
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。
    0 L3 }% N% ^7 B

4 n# Z. ?. H# g5 o! {
2、量化
" M, Y- k6 Q9 `3 g
) o: r: u6 C4 S& U
If You Can’t Measure It,You Can’t Improve It。量化是优化的前提。

: q# p/ V2 y$ y6 d. ]; _

4 ]) L( t& d# l7 T; Q) |量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。
) \* d1 s9 O  Y' N
* W+ R; j$ o% m8 X
3、制定SLA
! V* ~* f' @/ ?; A+ C5 `
3 x5 j6 k3 u2 j0 j* p+ \& X$ D; |
简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
! y- y8 l* M2 b8 A9 ~

, J3 ?; e* x2 j/ [一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。
8 I' R/ n7 f8 \$ `. ~6 W

; o: A% ?# n! a
" z) d8 c8 g& E) g0 c, U9 A$ r

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

9 m5 f2 ~* V: T8 d4 a% @) y+ W5 V

- m* ~& p4 k1 P, J3 e
1、制定规范,并让规范在平台落地
2 E( [$ J$ x$ e5 l. f1 }0 k* k
- y+ {  `3 y! V, F8 j7 Y
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。
" l# _, a! ?1 u+ \6 X. b2 V5 |
& Q* ^) h6 Z# g6 m& d
规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。

# N6 z, [, `+ j/ \5 B% N

$ X* J9 `7 T6 ^& A1 k# `我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

+ v6 C  m# T& f/ H
) C6 j% I! E8 x! V$ ]1 ?' p0 b5 D
具体的实施方式可以考虑限制和引导两种手段:
& p$ U4 j# f6 U4 a3 z
' R$ p# L& z5 J+ V. a
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。
    + [8 B5 T4 g- ]+ @. d( Y' P/ c
4 w: Q% X0 I) o# Z) T
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。

    : z! t( a4 H: c9 o/ L
5 B- k5 [5 z  ?9 S
2、协调开发与答疑

7 x/ J- X" m8 N! L+ p" y+ B9 Y

! y  B. T, B( Q9 K; s运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。

" t! L2 \# }& Q0 G2 x
& N4 F+ F! G4 |$ L4 O
日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。
3 [& ^- E/ @' A; r6 M

9 g# q" n# _& O+ n, h4 w& T: j
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。

# Y' i; Q' X) i) N, g; K4 J7 h

& ^9 [  E! z! d' g
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:

5 m- i. q0 p% j! j; K+ F9 \
( \  L: l7 E5 H' d% X4 N
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;

    / m" \0 R' t% K5 X! g
' F; m4 D6 C5 T* R

' o2 }( ^1 v' i
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。

    ! k8 n! b6 z: W2 @) w8 _
- c& e- Y' v5 _; L$ M
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
" E7 I8 A+ Q$ l' j$ z$ L
3 X3 A- {, A! N& W! D2 @
因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
. o, G6 f! E% a2 ?4 l' }8 e8 e
" F* e. z- K0 u( A" T

/ |( H, L* O8 u' Q& O

六、后记


) Y% \4 \4 e' v! t* ~! a6 S$ v' s8 j
$ [8 B5 U; E3 N; {5 B3 v
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。
0 b: |6 F7 h3 H; Z% q* S

, c5 G: o' C; P4 C  X! h8 V最后附上笔者思考本文时的脑图:

. G) p- q( Z& [& g$ h
1.png
" A6 z1 j4 v& I9 c; [
, E- J- ^9 B* b  t, g
, w! s2 K. @* o
作者介绍

5 g& d+ F2 U: J' o5 i- I6 s3 U% U' n

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

6 b6 H" \% o1 p) z' K& K3 H" O

本版积分规则

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

Baidu

GMT+8, 2019-8-17 21:11 , Processed in 0.229263 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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