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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

DevOps老手如何同时抓好运维与开发?

[复制链接]
来自- 广东广州

参加活动:0

组织活动:12

发表于 2018-8-27 15:35:54 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 monicazhang 于 2018-8-27 15:53 编辑 ; |" T/ ?  o3 K, N) B2 {, R

* H" g# e  w& ?" K* o8 n' U
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。
6 p4 f8 |* v; Q7 [+ |3 P
+ W2 k, }* b: N5 D- s  M+ z! ~  L
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps

- t1 y. r" m9 G/ }! @8 U! ^
+ y& S- |! l$ B/ o5 H) a
DevOps

. V' j) q' n/ A3 H

  y8 @2 l5 y+ e
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。
4 a% g, P. w2 g; G/ c! @4 m

4 I+ c5 n& j& F+ Z/ WDevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

  y9 y$ i' _5 o+ H
9 U7 }: a) m  \% \
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。

0 g2 w1 \' {. E

& N" C) W/ l7 I" i7 U

一、前言

  ^" a+ R# b2 ], o% \- @# H+ l
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。

# }) d) w9 U9 u/ f$ m. H" H, ~, L
6 g" \+ ]6 X+ k6 L$ X
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”

7 Y4 d* E  @; O9 _9 |$ s+ v; t

9 w% d6 \+ ?3 f* V1 \
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。
7 u  v- K3 i  `7 c

2 q# g& b. z9 K8 x. [0 ^' g2 \
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。

0 t3 I; `) Z1 y& P/ x6 P

1 ~! P8 T, m  n2 ?+ b
本文,我将自己关于这些问题的思考分享给大家。
: k# D1 m% v" {1 s8 Y/ \

* [- p' ^/ k- t4 R  O

; R' H1 N$ t! L7 `

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

& U7 L  |5 v9 n3 q
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?

0 Y5 @0 }$ y! I/ j

- @, r: ?! S  C
如果让我们来从头设计一个平台,我们应该如何去考量?

: S/ d4 d. H" j  P' M4 t
. S; S" i3 z3 T* n1 v0 @
1、效率 & 成本的均衡
, S" t$ T7 e% |) e+ A$ w/ g& t2 ^3 B3 p3 V
) f2 W! J( r9 q( A
运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。
8 o. d& N% M9 ]& V  |, O

* J# h* K7 L) U4 X至于如何量化比较,就因系统而异了。
$ N3 `  @+ X) K. o1 U, r

" \& I1 N. f7 ~
2、体验 & 人性化) V, X1 D2 Y: I& w; C

( b# X: _; y) ~% |! V
0 j- E& a; y$ I* H; d# o/ Y
为什么我要把体验放在第二位?
+ r" n- T) v8 o$ ^* k$ z! E. |
0 n7 G+ q5 C' J0 {
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。

+ ?" h& I( w  F8 U# |6 s7 T
! i$ q2 m8 [9 d0 I: H) J# u
我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。

% ]8 o6 X6 S2 }6 ]

% J3 F2 e8 [% q9 ?$ \
3、优秀的系统架构

6 X) }! w  X7 p$ M) n

; W8 z1 V" d$ w$ O5 t在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:
' [+ I% v* _, R6 h" k* q8 a- D
- N/ d% K# |( ~1 }- _
  • 稳定性:负载均衡、多活等。! P! U1 s  g9 I

    , X3 G0 ~" A" r2 D; j& A
- E* q" G' b8 z! ^( J" J- a5 y
# a  L* T0 j2 u. ~( O' u
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。
    3 f. j" Y+ D5 V1 O
0 t+ q. F+ R8 f
; T; g2 q0 q" K4 {0 y
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。
    - ~3 A- i/ e, S
$ ~$ V& X! {  j% s# q4 c
0 V& m$ E2 B+ Z( L
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。
    $ r9 u3 |. N! h6 `' U+ Y

6 M0 {! x% ], f, R9 i9 h
! |! L9 J7 y0 D4 s
9 L) V7 n) A. `
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。
    : F* |4 c& q2 R1 @) H

. C- Q  a' V. g2 f; x) U; l0 I
3 r- A' I3 T  P; d8 A9 L+ k9 r0 D0 l3 h; M
( k  K- v# m2 s0 Q: q; K
、如何运维自己开发的平台?" \+ i4 O5 c8 d" L, g9 u
  H$ A" T3 F1 K2 r* h
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?
6 ~3 W3 a1 u0 a/ B8 {/ y

+ }8 p$ U( r% J( R! i. s! `运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。
" T1 E* v7 J9 E% I0 d
9 A3 y9 o0 I; Z
用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。

3 R/ C& D$ _! e$ ~( y, W& I  H

" h8 Z* q" Y; b8 m5 Z7 O0 T
1、架构上的稳定性
: A2 `7 T$ ?  ^/ m
% d3 o: R% T$ a$ ^  I
- U8 t- L  I% L+ @+ F
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。

6 k6 T# E- ~2 M: U9 l/ ?3 T

# r/ O  V2 z: W3 B8 a+ }' J
2、快速地发现问题
# j& r! b- j9 y+ t/ `2 T4 |/ J/ d. }9 {+ y5 _9 V
, X* I4 _7 b9 {- z2 d" _* X; z
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。
* U. w; E4 d; L: n0 t* _
" u$ |' }: L4 h: l% O% {5 L6 B
还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。
2 e+ w5 }9 k. V

; c; g% i0 E+ z: \- h6 |( s: ^2 s
3、应急预案&演练( R$ [0 \! {! k' e) ?$ w! {. z: ~

3 H% E& ^. W0 X
- j2 _# P: Z2 M$ z2 z" t
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。
8 v2 }4 D8 t% R# c* X
, U1 k: D6 Y: C
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。
4 X! Q+ B$ I+ A+ G* S4 u5 U
: ?8 }- ^5 p3 c  V: E3 z
4、自我保护
: e( H+ U5 |/ K+ B" N$ V9 D) g- l: l5 T! f

0 f: G, g) t5 I# F( ]9 Q
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:

  @0 }5 i# N/ @1 o. q/ ?

  J) y# }  J7 C
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。
    7 Z' }6 x& M+ |$ R4 e: F; a6 Q

    3 G, r0 \, O0 ]- J6 W

  P1 M8 b6 X9 q' E2 P) I, K
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。7 c$ l! J0 d; k) }) |
    7 _! n9 a6 }! y! |
; t* ~+ q: Q7 g6 `3 o

+ Q5 Y" h4 O) y* ^2 n* m$ A
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。
    , q2 w6 j" M) E* ~! ~

    5 }) }1 e0 x7 X8 E% _* L. Q
  h3 v# s/ c. O# ?( y( R) }

( N# x3 }6 Z5 k" v8 \
  S8 B9 g& K( B  Y
5、容量规划
1 ~+ V6 q9 s. y% R8 m6 x. D( B
3 w' j5 M9 A! ?! W3 t3 |
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。DevOps

0 v4 t8 y! i/ ]3 B; ^6 @+ h. Q' C

: G5 |5 o6 Z- k1 m6 C笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。
7 H1 \* t; C" G- n- [( V
# E6 E7 ?8 Y2 [9 I
6、变更管理
+ T0 P! o, R# a5 P( L
( N  E7 ^" d) _4 o2 c( r7 S
0 h2 ]- ^3 q7 m) d1 O3 ~. F
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:

$ n6 x  U3 X- w1 ~
8 f( I& J1 ?. z- ?( f" b. z
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。# D( g: Y6 X- `: O2 g$ K+ I
    / ~; S* s3 f! l4 g4 ^  S8 x

' k6 s: _' q& Z5 ^, P
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。
      d9 Z. Q7 g5 H' Z0 e4 \+ h
    # _( G/ ]% f' A0 [: O: p: o* L

4 U( R, K& |/ o- m$ \& c

" o& \2 `9 `' {! u
- T# S9 f$ ^- ~9 ~+ P5 q! O  J6 K* q
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。1 M/ A9 `) a4 R' S; C

    : `6 J. m7 g# Q: ^, ^2 d. v6 O; W. o
1 k2 j2 s$ o" l' U* u% M% j
) _2 ]" ~0 V* O& m9 a
4 ]2 [8 R( G9 F2 t  Z/ ]  w2 T3 L

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

7 m' o% t' X, K" {, K

* u9 \6 B- W  j! I! u; Y
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。
, v" \) w5 D- i' S0 G

( M4 ]- N9 P, o& c因此,我们要考量的,还有产品和需求层面的东西:

1 X7 ?4 ~- K! O5 U

) L& u0 x% R. ~0 T, m0 E+ V
1、需求管理$ f5 z1 Q) P- }3 A4 a

' i( ^; K3 C, e" c! Z

! x! i9 q' k* G8 o# m& h" l0 m  |
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。
$ s5 S+ k+ w' O' G- A3 c+ o
# B. B1 e7 Q/ o5 H, U  @" _$ m
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。

    0 ^# J- W& N% m0 u4 w& A

5 A( V4 g2 G/ H  ~" o7 Y5 i

1 u7 j" v2 P- H7 h- B) e: F. y. g
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。
    " j: ^: f+ ]& L- {2 l3 P' R
" c" M7 q3 n5 @- C0 q
  • 对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。2 h( I, P$ z" I" q7 a; z
    $ X+ j4 b+ P: L. ^
2 _) r" X! K4 g( T: F. ]" N
4 R- H8 y. D7 V7 M
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。& a0 A& ^/ C8 ~; E( X5 S* }. |

    1 s8 j" @- q& ^; t
/ @- F1 V4 i: [* z5 I, V
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。/ f! m0 Z! R9 x! k+ z' }& [

    5 w  P) f% K1 a; w! W
" p- L1 K  b' t% V" f
3 x+ L8 [7 u2 k: U0 u, a' S4 ^
  • 因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。
    7 R$ k4 n+ V- Y; v

    + x6 W# G  N9 x) x

, p0 s4 q& L' b$ t

* W0 M; ?% D9 h: O/ N% S+ f( z# V
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。
    3 U: O" C! f5 c1 m# F5 {
    ' }2 ~/ l: k* }% U0 A

. s  {: z8 d: n0 P% j1 T
2、量化, v1 k: _6 [, J: \% L7 t
( N5 ?* Z4 u/ ^
0 k7 k6 J7 j4 T4 E
If You Can’t Measure It,You Can’t Improve It。量化是优化的前提。
9 }. N" d# c0 e# G
9 }) S; ]7 ]( N5 b3 H5 ^' Q
量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。
. O- _% q" K' ]7 E

( N- p$ c) P( F2 a
3、制定SLA
3 j- T0 J; r; p% F' N3 X" V
  j$ R! m+ @) l

2 a# p. v8 j% r, V; V0 {9 ~2 z9 N7 |简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
7 |4 W3 o0 ?0 b8 ]
9 C8 d/ ~: X2 u  F( u
一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。

' `) F7 {! G- y4 l- q: k

1 |% F6 e. W/ `% J2 k
$ r: I* _: K8 x& t" O- x! p

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


/ k$ q; U7 J, w! T, n! C

8 Q( @: f( Y- s5 M
1、制定规范,并让规范在平台落地
* z  m$ G! [2 c9 J& E3 Q* g- O/ |' `0 ]
9 g9 p  T. Z8 E/ I7 U' O
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。

& q, m9 R' y, _0 }  @

4 p$ Y7 o( c" M* N$ E6 Z( \规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。
  k; H1 q" ^) c8 r) d
* \$ D9 m/ e/ n4 l( N  q, h- X( `
我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

% c. J& W1 m7 r; A

8 i4 h" M& y; [5 ]# p具体的实施方式可以考虑限制和引导两种手段:

+ i' t7 E" W) k" N, Y$ a. ^
. ~' W! F7 i' L7 o4 m  {
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。

    ! O8 D5 E3 n  D
2 U( d% N6 \! V! u; J' [- i$ y  b
6 T4 |% p: \. a1 [0 O
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。
    1 ~1 K6 D# M+ e3 H  r
1 I; ^& V! f7 ~5 S( ~
2、协调开发与答疑
4 J3 N% b; R. C( K: ~5 L
4 w0 d0 Z1 p& z" `, ?- I* p
9 U1 k5 R& U- y& |, s3 e
运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。
9 U* s9 v+ ^1 z  A
& Y$ k% f, i+ G2 ?4 p# o
日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。
# _* ~# t5 ^& t

( r3 w4 a* _0 ~. V8 F3 G  d. w5 Q
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。
6 Q" r8 }/ v7 h( T
' @" b" C) E* V& V/ ^+ r
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:
# N9 {6 M& @" X, @
+ B7 T9 H# E6 j! n: F
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;

    . p% |2 T+ D3 j

    9 G; A: J7 K3 l5 k' O; F" s& D
9 t% q6 `2 |% _- m( a8 o* c
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。

    7 S, e* N. u2 ~6 M1 i5 ?
: `- J4 v$ ~) o. f" M
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
0 I& L' w9 E% E" }

# ~% G5 Q. z; e( S因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
4 K8 Q" B8 q$ Y2 {% M; I
; K3 q; R9 e8 J1 t; K: \
' b" W; n. Y5 [# j* O/ R

六、后记

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

  n( l' v* `0 J3 v, X

: {: i; p6 q+ C+ B' ]) E) c7 O0 t最后附上笔者思考本文时的脑图:

9 ~2 O7 E- }. Y+ c8 S2 {* ]$ X9 C
5 r5 `+ ~$ u% [3 g
5 _& S* b6 l  Q3 ^
- R+ \9 U9 @2 f9 i- @* T, ~

' o, V8 u( v- c6 R
' L/ _' W# R  i3 j
原创:高家升
* k3 \! o) j4 ~( A3 L8 H

" g, X5 _  ]6 a% K" e4 O+ b

本帖子中包含更多资源

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

x

本版积分规则

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

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

Baidu

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

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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