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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-3 17:24:59 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-3 17:33 编辑 5 d. c$ M: S* w' Y2 c, a) d- [, j+ m
* E; N9 j' T4 K( Y# V

* q& f" u0 ?/ a& ~( J+ h
/ V* L% G9 Q& {' j, I  z
运维开发这个岗位与普通的业务开发不同,与日常的运维工作也不同。要求兼顾开发与运维两种能力。既要掌握不弱于业务开发的开发技术;又要负责SRE同学日常的运维能力;上线之前,还要像QA同学一样,对自己的服务进行测试和分级变更。

& o, L/ X/ f% E8 E, W

1 r% f& x/ o8 R/ a) y6 @% W
多种能力的交叉,造就不一样的视角:这群人给自己起了一个很简约的名字:DevOps
* j3 e& ]' U" ~
1.png
DevOps

0 {: p0 d3 Z/ W8 b

  A- Z- b7 y, S
按百度百科解释:DevOps是开发、技术运营和质量保障三者的交集。在我看来,DevOps其实只是一种方法论,从这种综合的视角出发,包含一些基本原则和实践方法,仅此而已。
! o7 D1 u# T3 h) F* \& i

0 R4 t5 [: m- q. R& Z: n, w# GDevOps从架构、开发、测试、发布、运维、变更整个流程来考量,从这种综合的视角出发,能将部门之间的沟通隔阂消灭于无形,会给我们公司和项目注入新的活力。

, z/ c0 A+ e' C5 I+ ?( ~* l
' Y+ U0 z7 Q5 H0 u6 y1 w7 C' k9 w
DevOps这个概念,本文暂不做讨论,本文内容只针对运维领域自动化平台开发的工作进行探讨。

4 e7 r5 m  ~- U+ V( C% U6 t

. }1 Q( v8 _- E
5 H& H" c$ s" A9 U* o5 o

一、前言

1 U; s; n/ l5 {7 {( Z0 D
, K( J$ {! D2 A/ w' W5 Q
运维开发的工作,所需能力的复杂,工作性质的交叉,自然会导致很多同学在其中会有些困扰。

0 ?8 `) j7 F) B

4 C9 ^& N* ~9 ?+ t# ]! K8 U
很多刚毕业的小同学,接到运维开发的offer的时候,很可能是一头雾水:“运维?开发?到底是运维还是开发?”

7 M, [# |( ^( G
+ Z+ m5 I5 l8 q6 ]) ?$ K
有很多从业多年的同学,拼命的追求技术与对底层的探索,却忽略了产品层面的思考。
/ `0 l2 ]5 m( t6 P$ e' L
! p) l  m5 E2 p/ D" w# q
还有很多整天忙忙碌碌的同学,在业务方各种零碎的需求中修修改改,消耗了大多数的时间,最终平台却变得千疮百孔。

5 J" Y) y+ T. P
+ l+ r1 U) Y* E8 B' {
本文,我将自己关于这些问题的思考分享给大家。

2 V, M4 F$ G! s. i
. s1 H' ?, @' n/ U; ]

$ [8 O2 g' _) C0 a* w2 B+ B2 D

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

1 G; a% A, R- |* B' X

1 r' K# n6 \  n: T6 P
既然我们是在做平台,那我们要了解的第一点就是:好的运维平台是什么样子的?
( j# z' H  I+ z- k! b8 r

( [5 w: E$ Z% E# k$ v8 V
如果让我们来从头设计一个平台,我们应该如何去考量?

* D' [3 [6 h* k9 I

0 O4 B8 M! t8 K7 S: [& Q
1、效率 & 成本的均衡
# p# N, C' R  C! q
! {$ [5 ]0 w0 T7 c4 K( f  w2 t
运维平台是服务于运维的。对运维来说,除了稳定性之外,最重要的无非就是效率与成本。如果我们的平台可以用更少量的时间或资源成本来提高更多的效率,那就是一个非常成功的平台了。

* @* r2 }2 B/ w* V8 e! G

9 B6 F2 C8 X" i& m+ v+ P2 H; d: _至于如何量化比较,就因系统而异了。

; p: m& z8 q" K: |0 H9 E

4 N  z8 ^3 w. ?! F& i
2、体验 & 人性化

2 ?7 ]1 Z' J2 U$ x( }' m/ F0 n
. W. K4 m0 x( r+ _, J6 F
为什么我要把体验放在第二位?
& F9 {" ~8 X& G! K/ i. l: [
( ]3 C5 [9 |& @7 ?# s
因为有太多的运维开发工程师,在开发的过程中,过多地注重系统的稳定性和性能,完全不把体验放在眼里了。
" g* \8 J/ k. o, p3 @2 P
5 j8 ~7 X% R- T& u
我想说的是,有时候,如果不关注用户体验,我们做了再好的功能,没有人用,那这个功能意义何在?用户价值与用户体验在某些情况下,是会画等号的。
) W* \' _7 u2 ?) K
! l4 u$ U- u* I9 e7 u' Y! k* Z& X+ |
3、优秀的系统架构
* ]: [1 `7 W# t5 f, H6 X# `
$ ]- l6 k+ s2 L
在业界,无论是运维系统也好,业务系统也好,优秀系统的架构都是大同小异的:

  ?) z4 s1 Z! p( c; ~
: G( [7 }7 P# C
  • 稳定性:负载均衡、多活等。

    . }9 }! W( C& g2 a. h0 i
* I9 h- Y# t" g- h+ M7 G- B- N1 L
  • 扩展性:每次增加功能,可以很小的开发成本实现,而不是每次都要重构。
    3 x  _$ ]8 m& O
. [1 u  ~( Y, Y, l1 }# b" ^/ @
  • 伸缩性:没有核心的单点,大部分性能瓶颈,都可以通过横向扩展来解决。
    6 {1 B- `1 h. V" Z+ N! U
- y, r( u: ?* O0 v% j, Q
  • 自我保护:把可能会导致性能瓶颈的点都拆解开,用队列、限流等手段消除流量突增的高峰带来的危害,保护自身。

    : g" w# X* b; R$ o; S' k

# N5 n* `  B; E! A# U! {
  • 安全性:敏感服务加入权限与认证,Web服务避免常见的漏洞如SQL注入、XSS、CSRF等。做好操作记录方便后续审计,尽量不要出现短板。

    , J4 ^+ V9 F# R4 p* {4 \
7 u0 `; {0 K4 J' o( V

: p( X/ N9 t/ d

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


- _- v" [2 X0 @4 c

* x1 m# A  k/ }* E) M3 b6 W# H
运维开发在大多数时候,要负责运维自己开发出来的系统,俗称吃自己的狗粮;而很多人跳槽之后,第一件事情,也是从运维别人的系统开始的。那我们如何运维好一个平台呢?

' ~) _6 F# [7 v" n( I# J& U

6 J" z6 {5 [- X' J8 p5 G$ j运维与开发的工作,思路其实不尽相同。虽然都是基于稳定性来考量,但可能要想的更多、更广,任何有可能影响到我们业务的稳定性的因素,都要考虑在内。
  _* l3 o2 m5 C  @9 O

6 F& J6 H% ]* i2 o' K用我的总监的一句话来讲,就是:我们运维同学与开发同学,最大的不同点,就是稳定性的意识。

8 P: M8 S9 M: |
) o) |% F# W, o/ z9 \8 z  P, o. n% V
1、架构上的稳定性

! j) R# }3 ]' [- y9 g. v) f
' u+ W6 a9 T$ }; H3 J
这个其实更多的是比如多活、负载均衡、流量调度、硬件冗余之类的考量:服务在实例挂掉的时候,如何不影响稳定性;专线断开的时候,如何仍然正常的提供服务等等。

( e' p3 B$ y/ F) ^8 x- D+ _

: y. j6 t! k+ t  l
2、快速地发现问题

2 t" n5 Y% d3 q. B2 J
3 K% S; z' @- O. |! D1 f  U7 s, f+ f$ n
无论我们的架构多么完善,也很难做到尽善尽美。那么在一些需要人为介入处理的故障中,快速地发现异常,能直接降低服务的不可用时长。因此,对于一般的服务,将报警配置地更完善是我们能快速定位异常的第一步。

& ?7 [! D: w6 `3 ]

2 q6 X3 W7 M2 w% Y2 i还有,对于监控系统,自身的故障不能通过自身的监控来发现,最好还有一套独立的自监控。

% ~3 W* p# b2 l) j! a) B
! h% h! ?: |9 n; m. o8 B
3、应急预案&演练
2 V: S! }/ k8 n" @% T  n
6 z) ?+ Q5 }" F! m
在梳理一个服务的运维工作的时候,其实我们能很明确的感知到某个地方出问题需要人力介入。而除变更之外的一般的故障,我们都是可预见的。一旦真的出现这种问题,如果我们没有准备,即使知道如何去做,也可能会因为手忙脚乱而出错。

  \5 Z" H5 i; I0 Y3 o% |7 w# E# o$ f
8 b# m4 W  _4 y, U; }) k; R: c  ~9 h
因此,设定一些可能发生情况的应急预案,定时演练,是一个可以在故障时快速恢复服务的手段。
1 k0 Y( Q/ c7 P3 v/ W: q' d1 _; ~5 x
5 F1 M! F8 e: |0 s; P5 r0 z* v
4、自我保护
# m( r) X% `/ R) a0 G1 Y9 _% Q  {+ R
- X2 w1 t1 c0 N* B  V' \
一般的系统,都有上游,如何保证上游的数据异常对自身产生影响,也是很重要的一点。总结起来,总共有三类:

6 U8 {  [5 j2 z! x- u

  m% @: H7 J6 |0 F: x
  • 过载保护:上游流量太大,导致自身服务不堪负重。这种情况要根据场景不同,考虑加入消息队列,或者限流。

    . v" B( D, j  O& u( Y' [) a9 c

3 |  Y  w3 G! u/ {- s6 p! `+ F! l
  • 脏数据保护:上游来的数据,是否应该完全信任?是否有脏数据会来影响我内部数据的准确性?比如安全扫描的流量,很大程度上就会对很多系统产生脏数据。这种最好有过滤的规则的配置,能摘除这部分流量。

    ' Q8 P' {. y. ]

+ t2 M, W7 q" q5 r
$ t$ Z  k0 L  V* P
  • 上游变更保护:上游的变更,需要及时知晓和跟进。如果上游不够规范,很可能会修改接口或者数据格式。即使上游规范,也要跟进上游变更容易造成的影响,人为确认没有问题。

    + p0 P, z8 `0 H
) u& u" ~/ y, |/ ^& k4 \1 B- y
5、容量规划
* T6 H" ^, W( }! n; |+ V

5 y9 v1 b/ S$ K0 ^0 ^
随着系统负载的升高,系统的服务能力并不是线性下降的。当负载到达临界线的时候,一个逐渐变慢的系统最终会停止一切服务。因此,要在系统瓶颈到来之前,预估未来一段时间内服务的量级,在量级到来之前,做好应对措施。
3 Y1 l6 @+ O: ~$ V4 o/ k
; M% S* o& g* o0 T$ ~
笔者公司目前有一个Topic,就是全链路压测。运维团队与所有业务团队一起建设,压测常态化,每时每刻对系统全链路各个环节的瓶颈都了如指掌。其实也是在做这件事情。
" P' O* P/ e/ _) v* r6 C6 \

7 o& C& ?0 q* H- C9 R. u& o
6、变更管理5 Q# ~  b4 `& E& ~9 e% ?

) j2 \" T2 ]+ A0 k+ |2 G. G& {
SRE的经验告诉我们,大概70%的生产事故都是由某种部署的变更而触发。因此要管理好我们的变更的机制:
( U0 X! n9 r) ?' N+ O

1 m: }5 u  Q  P9 k
  • 采用分级发布机制:先pre、再小流量、再中流量、再全量。
    ' g5 I* y6 L4 e6 i# u
; r  n. W5 I: s( O% q( C7 k

$ n" g* ]. f  f& I
  • 制定全面CheckList:保证变更部分所有功能都有测试可以覆盖,能快速发现问题,第一时间回滚。
    + w3 z3 H* l/ ~! d

6 C- b  L9 I: p! t7 v
  • 出现问题,先回滚,再定位:这个不用多说,先止损,再慢慢查问题。

    + q9 E- X# Z, \7 Q5 ~/ c% y3 ]
3 s3 G6 R3 a9 ]; g- {( [
1 r: {5 F8 t8 t4 z

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

: F! S  i# e, Q* F5 z/ N

4 y0 H5 \5 M4 B! B* J5 h- X+ G
运维开发的定位,注定要比业务开发承担更多的责任。因为这群人除了是自己的RD,还要自己做自己的PM、OP、QA。

; _! F5 |: ]2 u3 }
, l$ {9 r; }; I0 S
因此,我们要考量的,还有产品和需求层面的东西:

( y7 G- w' T9 f8 K1 O! `) r) ]3 Y/ c
8 @! j* ]4 b0 u3 ^
1、需求管理

. s- b7 x; n% f1 ^

% Q4 a  l9 d0 A1 ]
作为开发,尤其是没有正经PM的开发,管理好需求可以让我们把精力放在最重要的地方,解放我们的精力、提高产出。

$ q0 J3 J: R- P# k2 q: [6 f

0 A8 }& J5 e$ w- `' y9 f
  • 流程闭环:从用户每次提一个需求开始,一直到这个需求跟进结束,或者需求被讨论后打回,都要有一个详细的流程管理工具,笔者公司用的是JIRA。有了这个工具,就可以很好的看到需求的状态,便于跟进和统计,真正解放我们的笔记本。
    $ y3 f, i& p4 n# j% `
2 U, F1 S, |/ J7 C! C/ S0 l
  • 把控好优先级:根据项目的定位,来划分需求的优先级。比如,对于一个运维平台项目,一般来讲用户比较固定,针对的是一群高玩SRE,那优先级考量是:稳定性 > 性能 > 功能 > 体验。
    ' z* t1 S  S- Q/ r0 }8 D7 o- ?6 W: G
    对于优先级的考量,要经常与自己的上级沟通。由于观点和视野的不同,个人考虑的优先级会与小组或者部门的优先级有所偏离,此时与上级及时的沟通,可以将个人的目标与团队的目标对齐,争取产出最大化。
    + g8 Q/ P2 L; [  u5 e* Q

: x6 d& z; }6 w# l; A$ X$ p
6 R5 j) l* Z( F$ D

  W; V3 \7 b; b4 F) X6 o/ t
& ^5 T/ e( n4 F4 G( l9 C7 V  ^' |
  • 产品视角 & 抽象能力:我们管理好了需求,确认好了优先级,是不是按照我们的优先级埋头苦干就行了呢?答案当然是否定的。视角、见解不同的用户们提出一堆细碎的需求,如果我们从头来实现一遍,并不能真正让这些用户满意,却只会让系统越来越烂。

    ( f" M: j( }6 G7 a- C$ s: I/ T& p! y' _7 j) C4 q
    因此,去深度思考用户真正需要的是什么东西,而不是被业务推着走。将用户细碎的需求,真正抽象成平台要建设的一个一个的功能。
    7 u) w+ X  V# a( N  V3 z
    9 c, N0 z2 k& u
8 g0 m' S. G5 }! H  x, I& F. R
% Y, U  n' y" u" q& u; \
  • 笔者之前就经手维护过这样的系统,勤劳的工程师兢兢业业,满足了一个又一个的需求,各种各样的高级功能。后来,却由于系统过于复杂,导致最基本、最常用的功能都要找半天。最终不得不重构。

    2 F* ~6 ~" m9 z3 F6 l! r$ w1 \

; J7 v3 p0 A# Z) u* j4 n% U7 c

0 a8 E  U2 |$ x3 h$ S9 F
  • 经常思考一下:用户虽然提了这个需求,但是他真正的痛点在哪里;多个类似需求之间会不会有什么共通点;是否可以抽象出一个公用的模型,用一个功能来满足多个需求。
    3 X5 `' o0 q2 |5 k

1 y7 Z9 j# f4 P
2、量化
* h$ d. j5 V2 Z7 n5 D6 v9 [

3 H- V0 k' H& i1 c9 t$ H; vIf You Can’t Measure It,You Can’t Improve It。量化是优化的前提。
/ t* P2 n/ p$ m% B. @# }

- y! E1 E. _2 I% f% C+ s% `量化有很多方面,比如说量级、延迟、成本,都可以量化。把所有的点量化完之后,我们做事情就不会蒙着头乱撞,所做的事情、所维护的服务,也不再是一个黑盒。我们可以对它的上下游关系、自身的稳定性作出宏观、统筹的分析。进一步的压测及SLA均要依赖量化。

8 l7 I8 \" {( ?, v( e5 q
/ a% g' H- V# W, y$ K5 o
3、制定SLA

9 z0 D- w4 Z4 D+ R
. u- f0 M1 P# s
简言之,SLA就是在一定的限制条件下我们服务可以保证的质量;是服务的维护者完全的了解了自己的系统,对系统的瓶颈有了深刻的理解之后,所给出的服务质量的保证;同时也是我们服务自身能力的一种说明。
% Y& D5 T. ?) g" Y2 o. _

, h7 U- Y" U0 i5 j1 j4 m, k6 R一个系统性能再好,也总会有瓶颈。而把瓶颈和风险让用户知晓,是我们的义务。对服务的维护者来说,在提供服务之时,约定好服务的SLA,既能从一定程度上规范使用者的行为,也能在出现问题的时候保护自己。

5 f% c3 h! P; |' \8 P! i
5 F, t: a- X1 M" D# b+ |

* d/ q  F+ [7 x

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


( a3 Z: b' w' i, t. \* y! }/ A
9 h2 N3 I/ o: R7 Q/ e# v. R
1、制定规范,并让规范在平台落地

4 [- ^3 B( a* g! e

$ C, s6 R* d% H
规范的制定是一个比较宏观的事情,一般情况是由稳定性负责部门向全公司整体给出的建议。约束的可能是全公司的变更的规则、以及平台的使用方式等。
! P! i. l3 H  C
+ V. R) k+ m$ v7 P% a1 z
规范的落地,不能仅仅依靠各方业务的自觉性,也要在平台做好限制与引导。
% G- e5 B+ [- M; c4 Q% Q" V" B
3 @- u( b4 Q* b$ O: _  v, G
我们做平台,最终产出的仍然应该是业务的价值:比如效率的提高、成本的降低、稳定性的提高等。规则在平台的落地,可以产生直接的业务价值。

, O1 i- B+ y0 O/ O6 I
9 k: U  b7 e4 u" d0 ~3 I8 q
具体的实施方式可以考虑限制和引导两种手段:

$ W: A* H/ ]- Q* N8 V( P0 {9 b3 ^
$ E7 p' x3 W1 \% W. |. J
  • 限制:上线窗口的规范,非上线窗口必须走紧急流程由部门一级管理者审批;监控单台机器上报指标数的quota,都是使用的限制的手段。

    $ x. `" W! c, L0 _4 l6 V

5 B" x5 w( I  u% k# j) O
  • 引导:通过一些方式,让用户自觉的依照我们的规则来执行。可以使用奖励、通报的一些方式。比如笔者公司的变更信用分、监控健康分都是此类手段。

    * p. Z: m% Y. Z+ n3 r& ?

4 q3 o  [8 q: \7 D
2、协调开发与答疑
0 t* L4 o5 u/ H. o) [+ d

& i% ^9 N$ K# s运维开发的同学们,除了要做自己的PM和QA之外,有趣的是,还要担任自己的客服。

" P/ ?5 m( e- h9 h
* i7 J( R+ _+ B3 S6 f% a
日常工作中,经典的答疑主要分为两类:使用方式、对平台的质疑。
8 R/ }* `/ Z. I" s

. \/ q1 M7 d9 ~! Q1 }: ], a) W$ e
使用方式的日常咨询,首先可以完善用户手册,把所有的使用方式和常见Q&A都写好。其次可以考虑机器人答疑,目前笔者负责的系统都接入了机器人自动答疑,把一些常见的问题以及文档都加入到知识库里,基本问题都可以解答出来。

, }* ~( L- v* G* w7 n# ]
: d7 D; }9 L6 X+ \( O, B' z+ f# G
除了日常使用的答疑之外,也会有很多的“高玩”来Challenge我们的系统。这些人基本分为两类:

0 t$ V, M& A  V9 S. h; e/ @, t

* T2 j5 Q7 r& K/ C' P) |
  • 一类是对运维平台有深度思考的人,Chanllenge的同时会带来很多建设性的意见和建议;
    + @/ y6 `6 M, J$ y3 ?* A

! n6 x0 e8 B1 x
' F: J* u; ]. D2 V: u
  • 另一类就是单纯的小白用户,对系统思考不太深入,喜欢无脑Chanllenge。

    ; E) s  n* ~6 \0 q* }  l8 x

( y' u! V6 g! T* ^
我们也要同时思考如何与这类用户说明,提高小白用户的体验。
) V" o8 o. C6 E; C* f
: t) V$ }- {: q/ g
因此,给出服务的SLA、做好服务的自监控、将所有内部状态通过自监控暴露给开发者,而不让自己的服务变成一个黑盒,是我们作为DevOps的基本素质。
" ]$ _3 J& C0 U" T  `( q

, v. H8 t. {8 |+ [+ a2 Q* f; x
/ i2 R* p# w2 ?" g% q

六、后记


, H! E9 A% f% b* W8 Q+ q8 K* t; l
( V- C, [5 U  F7 d/ I' r2 o3 d# m
时光荏苒,倏忽之间,我已从一个小小的实习生,成长到现在勉强可以独当一面的样子。这些年来,我一直在自动化运维平台开发领域耕耘。从刚开始重构服务树、权限系统模型、堡垒机登录;到后来的流量调度、监控系统报警与存储的深度建设,有很多个人的感悟与成长,梳理了一下,分享给大家。

; [  z5 _# `# o

. O2 p* {- k5 F: R最后附上笔者思考本文时的脑图:

# V1 H' m, j; y- |
1.png
7 y. H1 c7 I2 H: m2 g, @. Z4 T

& |3 p" E3 S" l1 `$ M3 Q7 V

1 e2 b+ l- p. K: r/ ~4 E* E6 f
作者介绍
+ o5 v: j6 v8 Y  P+ a- R

; P3 C& G- l; k& O
高家升,现任职于滴滴运维部,曾负责滴滴登录系统的建设、监控系统存储与报警链路的重构。曾任职于小米,参与小米自动化运维平台的建设,负责服务树、权限、堡垒机等模块。专注于运维自动化与稳定性建设,代码熟手、Open-Falcon Commiter。
. v) q5 n# x- Y1 l+ v8 w" _; |% Q

本版积分规则

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

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

Baidu

GMT+8, 2019-3-20 03:29 , Processed in 0.577224 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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