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

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

 找回密码
 点击获取邀请码 - 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-3 17:24:59 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-3 17:33 编辑 % U% o5 [" _" t

% B. ^" H4 E  i  F: H
" l& y: l1 [6 h1 v

* |' o" }6 Z; i+ @
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。
4 d6 V, W, d7 `& D, I
7 H+ o. l" T  h* @1 p" j3 s
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps
+ T- r+ @, M3 E3 C
DevOps
3 m: R% }! e9 j$ l+ O

+ x, j4 N% G! [+ f* M$ A+ C
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。

7 D6 ?1 Q7 P: I4 A( H. o
. v3 E7 V' p1 x3 q0 Z
DevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。
4 B4 P. a/ R. ]5 W1 N( q6 G% F
3 W: K1 L+ I. V- v& s; o
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。
6 S, B" `% }& v4 B5 G3 ~
) k# C$ z- q) |

) s" z) b: m* ~0 D; q3 `

一、前言

- c/ x+ F. q+ b3 N$ Y  X
) \9 d( _0 m5 m- L5 N
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。
; o0 m# X& X! d* G+ r
0 A" Q9 g/ E6 R2 C; c. w/ p# y
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”

% Z* ]1 b, ^) l% i. a

# r$ N; S2 U. F2 d( l7 n5 p
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。
5 \$ Q; m: Q$ J: z2 k

5 J& F% ]) D/ i/ y' u! e1 ^# Y
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。
5 p3 V$ h. y& ~
7 X3 v. R( K' o+ @
本文,我将自己关于这些问题的思考分享给大家。

) ]# n& S! {1 ~
- U2 t' M; f/ p7 r, z9 y
6 `4 r- z- u8 ]

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


0 J1 b" W1 @- m+ S+ c: D; P

; n1 u4 H& ~5 A# y$ z6 S
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?

; {: c3 r/ F6 w! X
8 k; O6 ]% U6 q1 k# L" H) M
如果让我们来从头设计一个平台,我们应该如何去考量?

# \/ k* m4 e6 n4 O

, e9 z% Z7 Q# r! [
1、效率 & 成本的均衡
2 v% }" _, d8 X$ Y  O

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

7 G* p9 W0 a; y: P* @$ u
! D, D( O. q$ l) |
至于如何量化比较,就因系统而异了。

/ n/ P, B' f" Y$ ?+ Z& u5 j

1 p; f5 o, ?' ~- v/ @; G* `
2、体验 & 人性化
. d! O  u. w% A

" z/ m2 b0 h; s5 e6 W为什么我要把体验放在第二位?
; s+ F, j( L8 x+ R" S3 D' C
% q, A! `1 n/ d; b' m) x
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。
+ O- m  e! p4 e! u# J& ]# P

4 z2 Q' T) a  s2 j% H我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。
" Z; g0 |* k2 Y6 U* Y$ f
7 ?  J$ j- N9 ^" e7 G+ H1 U
3、优秀的系统架构
0 c2 N- ^8 Z: \  K
4 R* k! c3 f( U$ K0 E# r/ n
在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

) ]0 [; ^: K* \8 D5 J! m' t

/ e* h6 o  u/ W
  • 稳定性:负载均衡、多活等。
    5 c& X  O2 i7 E

  M9 Q/ S" \0 n+ a8 ^
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。
    $ d: |% K4 I0 N% d* h, q
$ m( m/ O6 S! J8 Y+ q
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。

    2 Q$ G) R% g- p& b

2 }; A( J* V& f. @3 C' s; I2 ?
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。

    8 q" c1 s1 t2 T
3 }+ L4 S! M; X9 {
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    2 ?1 m5 S% f- p* c# E
5 i# T" `! K' ?6 J5 c
! J# {' H3 k9 Y2 t! k  N

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


6 A) E' ~9 ?) G+ _3 d- y. f2 s
9 z) X" e( q$ T5 _4 e
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?

7 x1 L$ F8 O2 y6 x( k

) ]5 y4 Y4 \1 @* L运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。

( o6 Q; q, v1 @0 e% |$ P$ I
' g3 c  }5 a& e# i, q5 G
用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。

5 B8 z: j" C6 }- E7 P
+ `% G6 @0 _% e/ o) H3 G
1、架构上的稳定性

4 ?; Y/ {6 u2 R- ~
, i$ K' V. h" \
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。
% D8 {3 d$ r6 k/ H1 x, B! U/ |

2 i( f. E- e5 u- _; _
2、快速地发现问题

( f" z0 \) M+ ]3 I

7 ^4 ]" g1 u# g8 z& \8 M+ g
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。
( v; T% d" Y( p) E3 a8 G/ W
1 [1 b+ e7 ?( A& F& p% @0 m
还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。
  [0 |: ~% J$ M

1 Q2 c* q5 V7 Q, T
3、应急预案&演练
0 `% W3 J0 ^9 t) ], W2 U

3 e% G1 s0 e" }
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。
* @  {* k: `' f  F7 _- n' w
( w: r# e7 a  \9 D( l' }2 L
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。
/ I0 k* V0 x. y( B8 F) N

' n) p) d, J9 t! A  ~' \7 [+ [: G! s- O
4、自我保护

. S- W" q% u; T/ [' t8 t

, l% Y* M# D8 Y2 j# M
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:

" F& f$ Z, C$ {+ k7 U: Y# S6 y# b
# i- R  _" ~- o. r1 D! ]7 l5 u
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。

    3 L2 g3 J) e# M

( V: \& O9 c8 ~+ d, a7 Q
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。

    4 G; o$ w3 L: _  {8 J# q6 q8 L

$ i% u0 g8 o. S- W" B3 U

1 u5 |( w; S, R
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。

    3 b, O9 L5 q9 A8 d* L
+ k7 b+ t( j8 f
5、容量规划

* {8 H, V, D, u4 g: S+ e9 t
5 T0 A4 T- h1 B4 l3 s9 z- {/ F
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。

, h# S* s8 g! n2 y
' l) F5 K/ Q2 K" N
笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。

  u6 D* x! o$ ~! z

8 `0 f1 w* O: _; `
6、变更管理
! g4 V2 t2 K5 Q& j! Q* m2 m" D' [6 s; x' r7 D
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:
  w& L2 ?; I; o
7 p, i) _) i/ J2 S
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。
    " [5 w; w9 Z/ @* A* i% v* h

7 A/ l, u1 |) K$ _
! N9 m- S# S+ {, O  S! w8 n5 M
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。
    . Z1 g8 _6 ~+ |: c2 Z2 F! a
# ~! S/ d! }- Z& ?8 {/ n
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。

    3 ?" }3 t8 T+ `5 w

' n7 C' M4 [3 n# ]2 q! S

- _5 ?$ c; y. q; @2 V

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

! [! Q9 P9 {- I; Y

+ n+ m) s$ x1 Q$ U$ U9 l# m
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。

9 `' h( ?; S4 f& h6 U; ?5 t
5 P4 K6 u& o5 q; w, L0 r( a' y
因此,我们要考量的,还有产品和需求层面的东西:

1 c# t" g2 R) i
+ i. t2 e% k+ G5 {4 A9 A: u
1、需求管理
. Z% R& s6 J( U! N  R: M# W! A! ?
3 H- i( r8 f4 y. i  _% Y
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。
0 ?3 i! W% Y, X1 `# f
" m; t$ j0 M6 P7 a( k7 O: G
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。
    / C, t) \8 C6 P+ [% g* o6 v
% `. W6 U4 q, T( d8 A* @; D3 T
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。

    & u( B4 k9 M+ C3 |& }4 e% }3 G
    对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。

      ?6 i- ^( G9 d3 ]: ?1 @
; p' c* J9 `( X$ V: x
5 z2 ]* l+ Q6 E5 a, @+ t1 z" X0 J
2 H" g! Y: B/ F# }3 f
4 n, F" C( Z9 k# z+ J
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。
    + N4 Z, a5 y- E, b& p3 p$ F) Q

    2 {6 o8 A# f* e9 u' k& J5 U
    因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。

    4 e( {, G* l- |4 u
    " Z, [  I% y5 K$ g6 L# G
+ ^# R7 H& o) y: u1 ^' J2 V: L
" u' z" a1 T4 b8 K, N
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。
    % p' V- S/ {  Q5 ?' @
9 x; {7 ?. s& \) }/ T5 J' p9 S

- U% @: G, L# z0 V' @" B4 S& n$ E
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。

    7 W( `* g; k6 w5 Q- S

7 h2 {# a5 r! F9 I4 K5 t" F; `$ y
2、量化
  ^. q  P- V' B- J- L& k# Y

2 |# ?( }' B1 }! i  SIf You Can’t Measure It,You Can’t Improve It。量化是优化的前提。
5 x$ D- z. c: K4 h+ A; E  A% ^' N( i& V

2 v5 P* r7 a- k6 T% r5 \量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。
' H1 O) D( t9 O" Q1 _. d

1 a' \7 O- ^1 s2 z$ h7 b% s! R6 l2 T
3、制定SLA

: i& n, K+ d5 K; P8 V' |

' k+ y7 W; u% @. @6 g6 ^简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
. n  [0 b6 R: u+ V3 N" J& ?2 d
3 L' ?: M$ N+ x- ^' _
一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。
  A. f7 x& |8 K& H( O

' N3 m2 b- [6 u% \
$ o+ x/ A0 ?$ G  k- P

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


7 n, b7 E/ o% E( m/ R  C

1 V* t5 P: @$ ~6 g) Q
1、制定规范,并让规范在平台落地

2 h7 |9 _$ v' t% A; o# b1 G* J
+ q2 D2 ?$ Z% U& s
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。

% c3 ~& M- D8 W+ j9 X, _* h

/ y: z% N' o0 y* p规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。

! M0 i8 ^( l/ ^, \

! U9 a! E  h4 V4 c我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。
% G$ K* r" ^- i5 y1 {

! ^/ J$ _& K4 R8 g6 f5 _' p具体的实施方式可以考虑限制和引导两种手段:

" `5 i3 {7 M7 a) p* z# B
1 z1 I3 S2 F4 y( d8 P
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。

    / @. c2 u% N1 R: D. t
. L; G$ C( c/ E+ z; \( B/ B4 T
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。
    0 n8 ~" @; r: z3 Z/ u3 p
* _6 R' @' w# e
2、协调开发与答疑
- A0 h: Q3 w+ s1 a5 j
6 k; _1 ]! A3 D+ y/ G
运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。
# o! f. ~8 u9 H8 d' s' V
: \2 Q8 \$ M$ @6 D
日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。

7 G' y* l! ?6 R& k6 \% C
- J" I( X; T8 `. X) i' V
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。
# U+ ~4 W$ j2 }* D7 r7 N, W! f
0 L% J/ s9 G5 J& Q; J7 @
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:
, H+ u6 A# n9 ^+ H7 e
4 u, l8 T: G/ n. e  w) v  F4 F$ M
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;

    6 z6 Y5 I8 {% O5 l8 G' d( a
$ e# t% X  w9 T& R

9 C8 b& i9 g4 k+ }9 M. l
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。

    # C* f) D* z7 i& @, _

9 G0 G7 I4 ]7 F% H  _( g& ?
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
. s6 }( O1 N3 @+ O$ p
( S4 S9 s. w1 C( T  q
因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
, m" a3 C5 ~( e; I! B

: ]  X3 E( o! L! V

: H! ?0 G% c1 k% x% W+ _* Z

六、后记

5 m( l0 j5 J% x/ S- k% i. Q

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

1 Y' v* u, i' L& g4 z3 ?
5 ^; K  n6 x- J1 I/ H* F
最后附上笔者思考本文时的脑图:

1 M6 q* p; E" _
) K7 i% D3 ~, o' M! k1 A
* D" ]: X" m4 J2 G. O

4 w: H3 t  E( k4 k4 N( B1 |
作者介绍

. H9 f- K- G, |  }  j9 H/ z2 C  |

2 z) k; a  p% A4 T; j' N6 |, [. W
高家升,现任职于滴滴运维部,曾负责滴滴登录系统的建设、监控系统存储与报警链路的重构。曾任职于小米,参与小米自动化运维平台的建设,负责服务树、权限、堡垒机等模块。专注于运维自动化与稳定性建设,代码熟手、Open-Falcon Commiter。
" R# t- G; d+ h6 S! G" i. `% L6 ^

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?点击获取邀请码 - 立即注册

x

本版积分规则

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

QQ|小黑屋|手机版|Archiver|ITIL先锋论坛五万运维人社区 ( 粤ICP备17056641号|网站地图

Baidu

GMT+8, 2018-9-21 00:46 , Processed in 0.324446 second(s), 34 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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