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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 441|回复: 0

DevOps最后一层:有效构建海量运营的持续反馈能力

[复制链接]
来自- 湖北武汉

参加活动:0

组织活动:0

发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式 来自- 湖北武汉
本帖最后由 adminlily 于 2018-11-14 10:54 编辑 # F6 a  L7 x& y4 m$ V" W
/ ^: I% T* K/ v) S  b
    前言    
DevOps最后一棒
4 l+ D5 ~; N0 \. m0 L1 e) v3 z' L( [
( w0 y& q& x$ M# V2 Z& b/ h

0?.jpg


" y* Z+ |( L( y3 B

! H! |* d* W" U; j# @  d7 P: m1 y


3 V- D; y7 A+ h" O  z) [

此图概括了整个DevOps体系,它最后的环节,是做运营和终结的环节。对于运营和终结的理解,我认为应该包含两个维度:第一个是这次运维活动质量的运营与终结;第二个是产品的技术运营与生命周期的终结。

/ W; \8 Z3 |* t, o

1 {" E: M& [0 D' [) T' I

今天聊下产品生命周期结束前的技术运营阶段,如何构建质量体系,实现持续反馈和优化的目标。

9 R. B6 [# h0 L1 Q% I

# J; Q' Y( z7 A

持续反馈于运维的理解
监控、告警与运维

' |1 X$ D9 g' |" |3 D
. s1 Q$ E/ w  o) i7 ]! J. ]

, j$ d% Z1 H) D

0?.jpg

4 m. c1 k0 N8 h  v# h' z) N" V: w


) {8 v& d1 |$ {* {9 J

◆ 监控——覆盖率、状态反馈、指标度量


5 a0 X+ I: w+ x3 ^" U$ a' G. S


0 L+ t. ~" m3 Y8 t0 i% O$ j

监控要做到360度无死角,业务出现什么问题都能发现,有了监控的反馈,可以看到实时监控的状态,同时,当指标发生变化的时候也需要注意反馈信息。

) i8 ?. I. ~7 A% s# [" k

" r, z2 |+ L! v& A9 R0 A+ M

◆ 告警——时效性、准确性、触及率


* L/ I" j% S. ]1 [! M) W* T9 t% A/ N

( ^: ?9 X7 a- u

业务越来越复杂,层次越来越多,每一个监控点都会产生数据指标、状态异常,会收到越来越多的告警。未看到或者看到未处理都需要承担责任,因为收到的并非都是错误告警。


' L" a. p# O! \/ j9 n) C) p. O# x

! P& N" K+ j4 b  Z. B2 B, O) k% {' Z

◆ 运营——RCA、事件管理、报表/考核

4 Q" j' `2 K! @2 t4 }


3 ~0 k* d/ |$ R1 A( \" C

问题再三出现必须从根源优化。通过事件管理机制保证RCA可以落地,最后通过报表和考核去给运维赋予权利,推动相关优化活动的开展,包括架构和代码的优化等。


# `8 }$ L% O; d2 l4 O: R


- X1 T* {/ e( y* ^  [

      全面的监控点      
监控、告警与运维
- ~! F1 P4 K" s

0?.jpg

; o7 C% j1 j, d& d5 S0 L


2 s5 ^9 _/ R7 f3 m0 d. s

腾讯业务按照不同的层级进行管理,自下而上,有服务器层、数据库、逻辑层。中间计算的这一层,有接入层、负载均衡、机房、DNS服务、客户端、用户端等,为了做到无死角,我们布局了很多监控点。


5 f8 v: c5 W) D0 m' z: T

! B& C7 i7 V. c$ b

实现舆情监控后,监控点做到了100%的覆盖,但并不能高枕无忧,因为当监控点做得越多越立体化,360度无死角后,每个最细节的点都有指标去度量,指标数据爆炸很可能成为另一个潜在的监控隐患。


: |7 T  M: w) ]; \; {# n

# e7 g% t, C# K) b- T

运营阶段要解决的问题
监控、告警与运维
6 y& h; _; N( I7 W4 h" w

0?.jpg

4 Q9 p& i+ R3 t1 U


6 O" s. C, @4 i5 U( }) [


" i9 }7 b" M4 K: v

〓 繁——简

  W6 U7 T' P3 t0 q9 b

; b) ~  e9 G- p' q, x' z% H

在具体生产过程中会产生运维的事件或者故障,经常会有死机,以及各层监控告警,这些繁琐的告警、故障,该如何简单化?


! O) Z8 m& J( R

' C% b; H  S. ~) m; n$ t3 M

〓 泛——精


; k! q  H+ \1 G


) t7 B1 w+ e6 b, n

举个例子,在一台核心的交换机下,假设其下连有1000台的机器分布到数据层、逻辑层、接入层等等,当这台交换机故障不可用时,由于有立体化监控的存在,每个监控点都会产生大量的告警信息,要如何发现这些告警是由哪台核心交换机故障引起的?


0 [2 N! C  s# V# \: ?


8 i4 s8 b% X8 ]

〓 乱——序


4 c4 }$ W: O$ v% Z


- @. f* h1 l9 l2 W2 [7 C9 q

由于指标采集方式和计数据量的不同,直接导致了监控流处理效率是不一样的。告警收到的次序不一样,要如何排序并有效识别优先级?


! J' \! P, k9 z9 z4 a- k, ?

* X* k: |, k+ V" f6 G3 b

所以在监控匮乏的时代要积极地搞建设,但是告警泛滥的时候要学会过滤。


/ K0 R, C. J: Z% ^


' p! ]# F; a8 q, j

监控对象与度量指标
监控、告警与运维
6 b5 b7 Q5 ?' p9 l7 k

0?.jpg

9 H1 M% ~2 A; c& `* A7 O9 X


$ Z6 b0 U& M/ u3 U

腾讯业务要监控的对象如上图左,按照业务逻辑从下往上,下面是通用的监控层面,网络、服务器、虚拟化还有应用,应用包括了组件的一些监控。


5 t! e8 P9 c+ `7 T. s/ f! B

4 x% h9 ?- C) N! ~

这里举了申请QQ号的业务场景案例,假设用户在PC端发起申请QQ号的业务请求,请求走到WEB前端,而后是注册服务,注册QQ包含了三个信息:个人信息、个性化设置、增值服务。是不是QQ会员,是否要开通会员类似的服务,这是业务逻辑。

$ d5 X: L# }  r


. Z: I; m" p  ~1 U, k1 d

基于立体化地监控,假设用组件监控,无论是QQ还是QQ空间、QQ音乐,都有一些通用的指标可以衡量。如,打开的内存是多少?长连接数是多少?用户进程、吞吐量、流量、CPU,业务层面返回码分别是什么?省市连接的成功率、请求量的分布是什么?这都与具体的业务逻辑无关。

- s0 ]- t! I* d; v+ `


2 x0 B1 H& I8 p7 j( ?

在做监控时,把指标划分成两大类:


  g/ K5 V  \+ c3 v2 _, _+ ^: V6 X


0 o- u/ Z/ e1 Q2 P

☆ 低层次指标

+ S! v3 B; Y- q

0 Y! P2 p; X- @& [' Y! ^$ L, `

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。
4 D0 L7 F: j( {  H

, v* o6 w! ~) P- |


4 @" o0 c% b: r, t# T3 O6 D

越低层次的指标让监控系统或是告警带来的噪音越大。在规划监控处理或者优化监控策略时,要尽量把低层次的指标自动化处理和收敛掉,尽量以高纬度指标来告警,因为这才是最核心最需要关注,最能反馈业务可用性的告警。如果一个公司用低层次指标来代替高层次的指标作用,那质量是很难管理的。

0 H5 A% C( n2 y2 @


+ j* J; o8 G7 h0 _  B' `

☆ 高层次指标

. R8 T, a7 B: w$ d) d

  D& Y0 ]4 ^1 L, A8 A7 j

高层次指标要能更直接地反馈业务可用性的情况,如成功率、延时、请求率等。

2 U4 y* ~, v: y) h8 G5 e, G

9 S, k+ b1 j% h' W" S4 ~8 E

高层次的指标,要能够实时反馈业务真实状况的,在海量规模的业务运维场景下,人没办法看到单机的层面,必须要看到集群的层面。

& q% G0 Q! m3 K$ I6 Y2 r; P


* \- q: _! ]8 B$ R1 ]$ p

以模块为统一的运维对象,模块是提供单一业务功能的集群。为什么要管理到集群?简单理解就是把运维对象给抽象,做减法。拿腾讯的SNG来说,10万+服务器,抽象成模块后只有一万多个模块,较之前面对10万个运维对象N个指标的告警量,现在面对一万个模块告警量要轻松不少,如果再把低层次的告警优化掉,可能只面对5000台的告警。


% E, N" V7 O' ^2 s


4 H; S: s% x/ X# Y/ [) c% o

在高层次指标中,还要有效的区分开单服务的高层次指标,和业务功能的高层次指标。要理清两个概念,可靠性和可用性。


% X+ A1 t3 N! K2 k) A

7 J7 a1 p  ^. l! x" H% F

可靠性是指单个服务失败的次数,由于单个服务的失败并不一定会影响整个QQ号申请业务功能可用性的下降,因为微服务自身有失败重试的逻辑,在腾讯的运维经验中,我们会在可靠性和可用性之间做出一定取舍。

$ X6 Y1 _. l) h/ j8 k

0 o: K* F  K* R. Y6 `' w" P

低层次指标虽然比较基础或者可以自动化解决,但往往是一些高层次指标的根源问题,善用低层次指标能够帮助运维快速定位高层次指标故障。

. \* n# b7 F" e. ~

. \9 M, Y9 K' M" m

       监控的本质        
监控、告警与运维
4 c9 i. X: _2 O  t2 t( s

0?.jpg


/ A9 s) ]% t; K' d

. Q% W& [* T  o0 i2 k


5 ?3 l4 j3 H8 C/ W4 R; @# b

监控无非是监控很多的值和率。把值和率分开是有考虑的,因为值报上来就是一个值,率是经过一定的计算才变成率的,其实都是把扁平化的信息包装成高层次的指标。

+ g3 o' r/ x: }

. a' i  q' y9 C

监控最终的目标都是要分析状态和发现异常,要从图、表或数据中,分析现在业务的真实情况,分析现在服务是否有异常。

$ m% I2 n: O5 {# I) P

! m) b$ ?1 @  N% P' B# e! G
         误告警解决办法        
监控、告警与运维

7 Z" @- k- l4 P. ?, I/ R

0?.jpg

% [  k' D, A# s) U


7 D! q4 a' S1 h% ?0 [

立体化监控,会带来监控指标的爆炸,更有可能带来告警数据失控,如果不能妥善处理,就会把告警通知演变成“狼来了”,失去了原来警报的效用。想有效解决告警多、误告警多要面对几点:


5 r( y/ V' o6 t  E9 m

% Y9 Z1 a  L  l2 B' c

◇ 关联分析


2 W1 N& j  l' c$ Q% q  d: b! ^

, R2 c9 H$ F. T9 E: f

把一些真正重要的,需要通过事件、活动、指标提取出来。不要把什么事情都告警出来,从而过多消耗告警的诚信。

2 j  O( R! J6 g6 J" J' G1 O

0 M# D3 b  ^' m/ F$ s5 o- x

◇ 无误告警


3 v9 y( I/ O% D% [# z7 I3 h, H

9 @; L- e! D, ~$ x5 C% s$ |6 d

怎么样把收敛策略、屏蔽策略用到极致,必要时可以将两者组合,以达到更强化的效果。


3 S: B; a9 c4 }0 a' R9 J" x- H! \( V

% X( y0 B' u& q* m) ^( y/ E

◇ 持续运营

: D* q! `! ]4 i+ Q

6 S4 n8 F6 Z9 l

做好持续运营就是做好跟进,确保重要事情有人跟、有人度量,防止问题再三出现,要在流程上有保障的机制。

8 h* s' r0 x4 `: d( Y3 p& N9 c+ Z


& n7 \2 s! {% t, b2 `# |; P/ W# g; n

这样就要求有一个质量体系来闭环管理,当监控发现业务架构不合理、代码不合理等问题,能够通过该质量体系,推动业务、开发、运维去将优化措施落地,这也是为了最终的商业价值,这是DevOps的观点。

$ B' g" T2 G/ ~. w3 x& Z+ ?) P


5 x& z# J0 w0 J+ J1 W7 T7 u

案例:海量数据分析思路
监控、告警与运维
) W" M0 k7 ~) f

- Z  Q' o3 x7 w. ^8 k/ y

0?.jpg


* ^: D/ t. k$ j# O8 x+ v

+ Z% z: `5 M* U0 t+ s

这是手机Qzone的一个多维监控案例。当客户端第一次连接服务端,会有一个心跳包,它是一个命令字,我们以成功率来度量其质量,其实就是考量它维持长连接的可靠性。(如果长连接断开移动客户端连服务端的话要跟基站建立长连接,起码3、4秒耗掉了,好友消息没有办法接收。)如图,一般的功能,我们要求三个9的质量。但是千万别被平均数所蒙骗了,一起展开看看真实的情况。

6 k) j- K6 T- x, N- i
. h. X) b  f5 ?% g# D. b$ r  X

0?.jpg


; G( t  I/ U7 Z# S$ A5 u


) ^7 }. l* |( ]: Q/ Q3 a5 R7 |( G

" ]0 \/ r- k3 r& P% V: k$ J

腾讯的服务是多地多活的,有一些分布在规模相对小的AC点,有些分布在比较大的DC点。根据全国用户访问服务端点的不同,腾讯内部称之为SET。讲平均数按SET的维度展开,为什么“无SET”的成功率只有2个9?再展开一下。


- C1 L! ^( i+ P

. ]. h  N; g4 ]3 r/ H$ P0 E1 i$ j* c

0?.jpg


. o3 t3 j& _6 K" \* e9 ?( A- T, ~0 ^


. z4 n) s2 Q8 z! b

按APN(接入方式WIFI、4G、3G等)展开,服务质量越来越差,只有两个绿了,发现4G是100%,WIFI环境为什么只有两个9了?

; c3 o. Q' D$ _) Q1 w" ^, B+ o+ G

0?.jpg


& Y+ F: c8 \( ^$ D2 K/ B) [6 w3 S

" |4 t6 [4 k7 n- O

) D4 T+ A( }. q2 w: j9 V

按运营商展开,质量数据更红(差)了,虽然符合预期,但最终的问题还没有找到。

" d% W+ q6 z; l

0?.jpg

! @: s4 e" j. o. U/ Q6 N


" _9 ~# t5 y9 ]! I* B% a

继续按地区展开,发现全是红的,但还是没有头绪。


: g9 X3 ^! Y0 U- t* w3 V" c, n0 C" G

0?.jpg

1 G6 |: K! _6 b2 p2 D1 G" ?

; H3 h0 e1 z. ]/ @" W7 H& ]

" o# c/ k, O- \( K

当再次按地域展开时,展开到浙江地区,发现出错的全是安卓版本。而IOS的版本全是100%的成功率,共性问题呼之欲出。

( z2 F. O% i, J8 q

0?.jpg

: I! x0 S  s- J( z! H

  w; H! o; Z+ I# M4 S+ l- I: b

0 G6 U; }& I( s, x! v

这时候回过头来检讨一下排障的思路,可能打开的方式不对。在第三步的时候直接展开,好像真相就已经出来了,其实是安卓的某几个版本可能有这样的隐患,导致这个心跳逻辑有问题。

) J+ g$ l) U: z( Z


1 J) T' v1 l5 q9 b( L* L

这里说明一个问题,对待海量多维数据的处理,分析方案很重要,在规划和建设监控体系时,应该考虑好这点。今天给大家带来3个小技巧,希望能给大家在做监控数据分析时有帮助。

! @, N- Z$ S+ F0 D+ J" t
0 O- ?+ R- r) ~( l  z
海量分析三技巧

$ `$ c) Q5 C  x& k5 ^7 {' B4 `! e3 T* k

0?.jpg

* Z- H7 d" l+ G: p


; X/ y- t5 H9 _


; Y: C8 M" v! I% J! ]

海量监控数据分析的技巧:溯源、根因和优选。

6 w) E- D1 n) m  e

, s) t) h  k# R% K

为了加快告警信息量的处理往往把监控的协议格式化,格式化处理完了之后再进一步格式化,把很多原始数据的蛛丝马迹丢掉了,导致没有办法查到真正的问题。因为之前做的格式化会让监控数据失真,影响排障的效率,所以上报协议的时候尽可能的保留字段。


% R9 c/ v" [5 r8 \0 p0 z: X


/ n; a9 A: s# ?7 I
        溯源分析      
海量分析三技巧

# d) _# M2 d: m

0?.jpg


# v/ r1 \& `. e: k8 `

  y* J* {" v( s& @! f

〓 高维与降维打击

+ L* ~) ?# i, F+ `+ m

: k0 A2 B/ \5 H* Z

高维与降维打击,把一个指标的结果值或率以不同的纬度展开,要把每一个维度的指标组合状态异常都变成告警,这是很不现实的,因为压根处理不过来。反而多维度的指标异常能通过日常报表汇总分析就能发现异常,然后通过考核去持续的推动,把异常指标给理顺、优化掉,这是就是高维、降维的打击。

! N! U6 i$ c, X0 f

/ Q# C; O7 c5 c

〓 级联分析

1 D5 W+ j% P2 W% Y. U- ?

3 W, L( w$ }0 _! s

网络有一个词叫微突发,网络突然拥塞了,导致一大波低层次和高层次的告警产生。比如,一个交换机异常,引发下联服务器爆炸式的告警。当此类情况发生,统一告警平台全部不理,做好全局的收敛,以保证监控告警的有效性不受影响。

& ?3 G4 }6 a. ^# o7 y0 u' @

0 V; E  n# t9 ~( S  t

〓 逆向思维


# R" |5 p" \7 Z9 \7 P


* O! s9 k7 N- V( k& G  e$ {0 o: N  ]

不能只看结果数据,要回到原始数据来看。如果要做到逆向思维可生效,流处理集群在真正加工完,存储的结果数据之前要做最基础的分析,把那部分日志备份到大数据平台做离线的计算,然后结果数据再走正常的流,去做告警也好,异常波动也好,因为很多异常的东西必须要看到原始数据。我们曾经深入分析相册上传照片的流水日志,找到了大量异常的用户照片,从而节省了大量的运营成本,这些都是结果数据无法做到的效果。


0 S: B- C6 [4 V( [0 e' g


+ g  N, g: c9 P7 i

        根因分析      
海量分析三技巧
& W+ ?5 X- f; E6 N/ ~

0?.jpg

! u' p$ I& j) L* J" X


4 \3 d5 p) a0 g8 r0 I: S
  • 用高层次的告警 收敛 低层次的告警

    1 f9 ~/ P1 S8 `  J' G1 B+ N, @* O

! `) g- Q( h- h2 R9 H" G' V

0 S2 I( k4 v$ Y$ w% O

同一个集群下既产生了低层次告警,又产生了高层次告警,低层次的告警不用发。


6 }- U3 g6 n$ h" h. I0 w  o- _9 f


8 P- Q: q/ s+ v+ ]# t+ L- H

  • 用主调的告警 收敛 被调的告警

    4 q# Y. E& i3 V# H
    3 f  i' e0 w$ A3 y. m

+ y1 }& a0 {+ o& [4 k  A

模块A调用模块B,B挂了,A受不受影响?从保障业务可用性的角度,如果A没有产生告警,证明该场景只是B的可靠性告警,告警通知开发而不是运维。但如果B挂了,A也产生了告警,运维就应该收到A的告警,B还是告警给开发。推进告警分级(分值、分级、分人、分通道)的机制,其实是慢慢把一些运维要做的事情分给开发,运维只看核心的,软件可靠性这些开发来看,可靠性是开发的问题,可用性是运营质量的问题。


3 d2 e* v7 P7 @2 }8 z' R  |


0 ?1 t4 N7 c' z5 @0 S, b

  • 用原因告警 收敛 现象告警:

    % m8 ~, E' b) e0 z# C
    ! x' H, U0 N& _$ k, w

4 h+ |7 V/ J* i

在业务逻辑的调用联调中,用原因告警收敛掉现象告警。


, C2 W+ M& @: P' O# s0 H

" G* x3 ^& g$ ~( S
  • 用主动触发的活动 屏蔽 对象的告警:

    ! F0 Y- F* ]5 ]! k" V/ K

/ G* m+ `2 l( s  _( t+ ^2 R6 \

8 i+ M, J! J0 c1 S

有些告警是由于变更行为引起的,要收敛掉。如正在做升级引发了告警,运维系统要能关联这些事件与告警。有高层次告警、低层次告警,还有运维的活动事件,都把这些集中在一起,通过权重的算法,有一个排序决策说告警应该是告这条链路,而不是每一个对象都重复告警。

  n8 v. J6 K" `" O8 W5 w$ I

( D& F" I, Z5 ?' D

        优选指标     
海量分析三技巧
) C; j$ Z% N( E2 N' ?
/ T# ^. d$ V, V% O( R( b

0?.jpg


. o7 c/ n' A$ j9 e, P* i7 [

% o' |6 f7 e' `& T

核心指标论

$ }3 Y) h6 L$ b) o

& q# _% f) A1 d- m6 y- P& O  j3 y) _

优选指标应该是第一次对外分享,腾讯内部的系统代号叫DLP,是一种通过人工来筛选核心指标的方法,在大数据时代的今天,这种做法稍稍有些不够优雅。如一个模块可能有300-400个指标,这300-400个指标中,包含有低层次的指标,高层次的指标,但当这个模块出问题的时候,这300-400个指标可能都会产生告警,那么应该怎么样收敛呢?倘若我们提前已经对该模块进行过核心指标的人工筛选,这个指标能代表模块最真实的指标。

4 b3 I0 U2 @3 P- `3 \


4 T: W* ?/ _4 K7 `8 a5 z" N

监控的相关性

  @) ?+ j$ W1 C% n; X


' _1 }6 m" @& @& O4 u

监控是相关的,例如300个指标告警了,最核心的那个也会告警,最核心的告警了这300个指标可以不告警,只看核心的就可以了,为什么要人首选核心指标,因为暂时没有办法人工识别。


2 E8 _7 s6 N! i5 Z" T, k

( t9 l8 _6 X( {% x2 s# e

告警分级管理


+ Q1 U5 ]: Q$ x! n


, x: M: R8 r3 {) z' L

基于核心的指标对告警做分级,非核心的开发自己收,核心的运维收,做到高规格保障。


  [* _6 S' M9 ]- e

& I! T  N0 \4 c* r( c/ D

降低流式监控的计算量

% ~( t/ l: \5 L8 Y

  @- S/ y% ]* u8 T' i

监控点越多,流的数据越大,整个监控流处理集群规模很大,10万台机器光是流处理的集群都是接近1500台,当运营成本压力大时,也可以重点保障DLP指标的优先计算资源,保证优先给予容量的支持。


4 y) q4 d3 `. E% V

  _( V7 r) [; S/ c. G8 u5 z, U

      用户舆情分析监控   
SNG织云监控系统
  |, T7 b- O( H8 \

0?.jpg


  h. n) v2 ~3 _7 D6 ]

  _' L; J, [2 E; y

还有一个很核心的指标,就是织云用户舆情监控系统。简单介绍这个系统,用户舆情监控顾名思义就是监控用户的声音和反馈。用户的意见反馈来源可以分几部分,一是AppStore的入口,另一个是App内嵌的反馈入口,还有的就是腾讯的用户反馈论坛,所有的数据都会被汇集到织云舆情监控平台上,然后通过机器学习实现自动分类。系统会把类似“QQ空间打不开”、“QQ空间用不好”等这些词汇进行语意分析和归类,然后统一告警成“QQ空间异常”,时间间隔是15分钟颗粒度,技术细节不重点介绍。


% e% }2 W* Z& W5 J


% q9 h! S0 T5 T8 C

当实现了用户舆情监控后,我们基本有把握说业务监控是360度无死角的(假设用户都会反馈问题,且不考虑时间因素)。但这套监控先天就有门槛,因为要基于用户的主动反馈行为,同时需要较多的用户反馈数据量,腾讯的用户量基数很大,用户主动反馈的量也很大。舆情监控可以用于监控技术上的质量问题,也能用于监控产品的体验或交互问题。


. M& D9 B7 G/ D+ \2 q; s


$ U9 Q# o% s8 _6 M2 F

   有策略更要有自动化   
SNG织云监控系统

. k, o2 i) a- `* Y
! Y4 z2 K- }  B+ h1 A

0?.jpg

& E+ p- y* X& Q8 x2 j

7 j+ g3 D7 z4 C- _7 L2 m7 A( Y

告警自动化处理的前提是标准化运维体系,在SNG织云监控体系下,所有告警处理会先经过预处理策略,然后再经过统一告警平台的策略和算法,最终才被决策会否发出。


: f* [: B. G4 H  x


- `2 t& F' s4 I. O
精准试用的算法与策略
SNG织云监控系统
' q4 n/ a) n3 P% b! r* K

( z# O: |$ k1 n+ [8 i) b

0?.jpg

( H4 s' P7 P% _0 n. S' ~2 t! q

! i( u4 ^$ M) |$ u. ?

在定义指标状态异常时,我们的经验是尽量不要用固定阀值,要用也是动态阀值,否则在监控对象的阀值管理上就会有大量人工管理的成本。其他的推荐策略如图。


3 K6 ]$ M! I9 Z


- _+ t# n, f, \& Z5 b

常见业务监控图形与策略
SNG织云监控系统
1 m8 k/ U& b( c( Q+ A+ y2 Y( t

0?.jpg


9 N5 {$ S( T+ ?8 s& e( O. G5 U


( q; j( M; N- w# |( e* Y


0 F; t/ r8 k) C* w" f

我们在日常运维工作中,面对的监控图形如上图,趋势有小波动、毛刺、无规律的,建议有针对性的套用监控策略,让监控告警更精准。


3 z4 o' p4 a* `: l/ b

* y# R5 q$ K" }6 H. @+ `, Y

       案例:监控自愈      
SNG织云监控系统
+ G. @8 Z) V+ Z4 U* O

0?.jpg

* C  q* K/ t7 ~  L+ R


# x' P9 v, b0 r

分享一个织云监控实现进程自愈的案例,流程中的模块在部署时,运维自动化流程就会把进程和端口的信息注册到CMDB中,然后监控服务会读取该模块需要监控的进程与端口信息,并把监控配置发送每台机器的监控Agent上,本地的监控Agent通过定时Ps检测进程和端口的运行情况,如果发生异常,则自动通过标准化的管理找到命令进行启动,如果启动成功便实现了进程自愈。

5 m, y6 a, y' q* _1 n. _  X

+ M- H/ b1 W* T/ o- \3 I- m/ j

如果启动不了发给统一告警平台,统一告警平台来决策是否需要告警。当该告警原因是因为基础设施正在做变更影响时,也不会发出告警。一系列的监控自愈方案都是构建在织云的自动化运维体系中。

8 s. f4 `$ B$ D0 @+ B8 V' t! v& j


4 g( l; V8 B; a0 N! ^5 W

      常见的收敛算法   
SNG织云监控系统
; f' n% E5 y% v

0?.jpg

7 Y% i9 [5 d3 i- ], Q- U% V: f, D# c! e


* R. l1 {: J5 [# g6 r6 X7 F

) h$ y5 ^. ^# v) M$ y8 ~

◇ 毛刺收敛

& H8 h6 n' H" _# X4 E, W6 b' \


$ l$ h* Y5 l2 b* @( E8 ]- ]

在织云监控中,告警策略为了防止毛刺的影响,会将告警策略定义为10分钟发生3次类似的模式。

! a, `9 w, @* B- G) Q% H. Y

2 @5 F6 S9 i3 W8 m; e6 H$ B4 l$ [

◇ 同类收敛


! l. {7 [( r8 p7 a9 I0 j: Y. h


# _& X  Y9 o7 S; Y& p6 u" Z3 \: d, e

一个模块有300个监控实例,产生了300条告警,只要有一条告诉给运维,对于运维同类收敛掉了。


0 C( `) H. i; h% y8 k* @' m

; b6 ]1 G8 p) Q/ Q3 ^+ R

◇ 时间收敛

& R1 |+ P8 P, M. u% _0 ?

) g6 F% v3 f2 y4 [# I

生产环境中有很多定时的任务,如定时跑量会引起I/O的陡增等异常,这种可以针对性的收敛掉。

+ G3 y: e* F( A3 q7 ~


8 v( t% o0 U# U8 f& i' b( n3 m

◇ 昼夜收敛


, N6 v3 n- A/ v( p9 h- b3 Q  o, S: j


: H) f: H4 b+ H7 u

有一些告警,在分布式服务的高可用架构下,晚上不需要告警出来,可以等白天才告警,更人性化的管理。


7 W2 S; l% T* M/ ~


' F4 p5 y1 F% ~4 \

◇ 变更收敛


2 _9 X5 J) h  U; v! O, p0 y


) G! b! J( _: G' O/ A+ ?

如果告警时间点有运维的活动,就要收敛掉它。怎么做到的?取决于要把运维的活动都收口在标准化运维的平台,运维平台对生产环节都要将变更日志写入在变更记录中心,然后统一告警系统能够关联变更记录来决策是收敛还是发出告警。

; H; O; j, S9 q

& `" X; v3 {/ C' B
织云监控构建的质量体系
SNG织云监控系统
# w9 m, K* I. ~8 o2 j* r

0?.jpg

; o$ j# M+ `: V% z; M

: ]( r, l* n( w. a- p) {; j

! \( ]) }* d3 k) ?- x

织云监控构建的质量体系,分成用户端、客户端、服务端、基础端,定义核心指标DLP,并且善用分级告警、分渠道告警,结合短信、QQ、微信和电话等渠道实现告警通知,整个质量监控体系都是围绕预警、自愈、分析、排障碍的能力构建。


) z) }/ T# }# L# n- A' }


7 ~& ?. m' i# p5 P5 Q8 h! Q
织云监控:质量体系  
SNG织云监控系统
, b' f; S) R$ s3 \  U

0?.jpg


# S: a: d8 @: M/ I+ H+ f- G+ ]" @1 `


* ?' a' i) t# S/ Z4 G: C1 \

织云监控的质量体系,希望打造一个闭环,能够实现持续反馈、度量、优化,让团队间能够有效地协同工作,更高效更有效。

3 [# X/ h5 w/ A/ M9 }. u# ?


/ F, @! d, |! j  `

  • 监控能力

    " a5 {! \3 A1 @' _6 i4 v
# \1 x0 {, n4 V& j

全局地看、需要什么样的监控能力和监控点,同时要理清指标是怎么分层的,哪些指标是重要的?最终把它转成业务看得懂的高层次指标。


( x( z3 c6 {5 b

' b8 Y. M+ x: R7 }9 n$ @0 T

  • 业务可用性

    , P$ H# L. n: |( V4 P' P3 N

    ; a2 J( G8 d* x2 \6 g( u
4 w/ y7 n5 @( ?: ^$ F

运维要看什么,要看可靠性还是可用性,如果规模不大看可靠性可以,但是在海量的场景下可靠性太细,要抽象核心指标来度量,用于衡量可用性。可靠性则可以通过考核体系去度量与管理,结合QA和老板的力量来推动开发团队的投入与优化。

& p! |$ |7 `8 M: [1 t9 Y


8 I7 X* z/ D8 G; b) J

  • 用户体验

    ( r% I  f! `, [+ P5 C. c# U$ h7 n

    - X1 b3 L+ A1 ~6 T

1 C# h8 k' r3 a, @

做技术运营会有视角的盲点,会经常迷恋可用性的数据是4个9、5个9,但这并不完全代表服务质量好,当用户连接不上我们的服务端时,几个9的意义都不大。这是一个很现实的问题,因此用户体验监控一定要做,因为内部的可用性再高都不代表用户用得好。

" Q) i8 t& j2 I: \9 P

- H% O+ D# p. _+ N0 \5 H

  • 技术解决
    $ [- E7 _+ V3 W& I( M; O: h
( H3 M  {# p3 B: E' k7 F  d
( {0 U' C* e# a$ ?( B
要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。
+ N" e- }# Y# y5 t2 l' Z5 f


/ x2 {' X# t8 F# }4 G& a8 C


& `! l0 j' Y, W4 K/ e- u4 W

  • 统计分析

    ( W- D# k7 Y! Q4 Q/ A( `

# x3 T  @0 G. \3 g% m

最终形成可度量的指标、可考核的、可展示的,最好是DIY展示的,监控数据的统计/报表能力服务化,应发挥更多的角色来使用监控数据,而非仅限于运维角色。


: u0 h& x4 M4 P( q


+ H0 U3 N! L$ H( w5 y  q. `3 s

持续改进

# F" {9 r' I: j: r


0 k& p8 R  Y& X" y7 Y

最终持续的改进无论是架构的问题、代码的问题,还是因为标准化的问题或非功能落地推进不了的问题,都是需要数字来度量和推动。最好,这个数字要能间接的反馈商业的价值,也就是DevOps提倡的思路。

3 I( v' d; J7 d, t/ I5 ^


3 G) U6 a* i5 O& Z

最后,质量体系肯定是反作用于监控能力再去形成这样的闭环,跟开发怎么沟通?跟产品怎么沟通?跟QA、跟客服怎么沟通?要把他们用起来,要把他们关注的点牵引住,最终落到运维想实现的目标上是最好的,这很DevOps,也撬动了老板的思维,争取从上而下的支持做好质量体系的建设。

! H+ g/ T5 L. D# _5 x( H6 ~

    结语    
DevOps最后一棒

/ W$ k+ ]; Y, O  @
' Z, i& D& D; O4 d' i# a

我们经常说DevOps很难落地,为什么难?因为我们总是想要去影响老板,先改变文化再改变工作方法,但这谈何容易。如果是运维和开发能联合起来,先从小的重点的业务抓起,用数据说话体现DevOps能给业务带来的最终的商业价值,说不定会起到事半功倍的效果。

/ z; Z) a$ ^, n8 C! m) ^& n
4 P4 f$ D6 u+ t3 r0 w& H/ Q2 I+ r" A
原创:梁定安
$ C, j7 u; I$ a

1 U+ }1 z! [: ]: A8 F2 C( p) u; F' W- j8 R

本版积分规则

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

Baidu

GMT+8, 2019-7-17 04:50 , Processed in 0.244832 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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