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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 2662|回复: 0

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

[复制链接]
发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-14 10:54 编辑 ' @# g; P: w& P# L, V! ~/ _
: Z9 y: y5 m. ]3 Z
    前言    
DevOps最后一棒

  U. g% u2 V! m
7 g. B3 U3 B. l: Y; l

0?.jpg

+ C9 n& ?; j6 `! f! ]3 E9 a

6 a; s. x, v+ {% I, R3 W0 _


( H  a) d/ Q  s( j2 [. d

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

5 G! p. {. L- |


+ x7 R* h; h  `: p

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


, z7 u# Y* h. u  M! @# B

: e1 |* c* h( ]

持续反馈于运维的理解
监控、告警与运维
% _5 i2 A' V* C4 w0 }: t) U9 ^
) ?' B2 K/ H* h& k  \  j

# h% V  v2 j# Q) f3 z* X

0?.jpg

4 V5 q1 ?, j5 B7 ]

! d# f: B) k0 U5 H$ _! v; I& @( |

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

1 m- L; A6 ^# D7 [& ?

: X! n; Q# N4 t/ T$ u( N2 s  e, o: ~

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

; K' F8 Q; ?. f" ?: a1 {# V


( T9 Z+ s9 A( E! }

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


7 ]0 a% M1 ~! r  M1 h

  ^6 x# H9 ]5 x

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

' Y6 O7 _! @' _/ c

( f% B, W& @, ~  Q( Z# F

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

$ S2 }) @4 L) d9 L3 }  w

* s6 Z; _9 t8 M$ @; t

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

$ f( L0 N* F8 `' T


# H3 S6 z+ g" L' C( j, j8 e

      全面的监控点      
监控、告警与运维
: _4 g% b7 U, t' N

0?.jpg


3 c1 H4 w! f, f0 n


  Z; [- B( S) H, g

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

8 P# f: m) z  D  j


. J/ ?4 ?, N$ l4 }' F

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

' g0 D+ R: b7 `! ^

" m: K5 ^: g' `7 ^

运营阶段要解决的问题
监控、告警与运维

/ n/ ?/ h$ |1 S& r  z2 i

0?.jpg


7 e1 ]7 U# W* D% I- s2 X


3 {1 f$ K2 R1 `. G

6 o) t! b( r' d/ X$ Z$ @$ Z- V5 J

〓 繁——简

0 g. o5 B7 P3 ]7 i, M, E8 l


+ F! B$ e6 @# U: x

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


3 F: x! {& z; \: i" a


1 i: r2 l( y- Y; V" k

〓 泛——精

, q* n8 j# Q3 e& I: l5 \* R  v- H


$ O" v  r+ K( A# e+ i6 g- z+ a

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


9 @, x$ u0 `( h2 [' \6 I: @

- D' v1 G  N' m: H0 ^

〓 乱——序


! ]2 i% F0 D* I; G# G- l

, l0 U  B: K/ F3 H

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

$ s' u: A4 g# N5 W. o# J' s3 g; g9 S3 J

2 b1 E1 T  v: N4 t' L( y

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

, S; M6 c; |' @, g- M3 ^# j

- [5 \! M) j7 \$ @! C

监控对象与度量指标
监控、告警与运维
% X9 K0 ?1 d. _' f7 W

0?.jpg


  {9 l* _" O0 D. ]

9 i% S0 s$ X  A  S4 E. _9 |( R' o

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


3 b: ^  J$ c3 h  m( {- k2 K

- _' R3 T( x" E. c, U8 r

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


. b. e$ T) N, T7 t* F( S; z. J9 {


# V( b) y1 U6 x5 p

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


- r' B7 F, T, F" x/ T/ ?. R6 z

2 _) \/ E$ D" s' W0 M9 x

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

4 Q% g  Y' X" T7 ]


  k( T: M4 ^1 k# D

☆ 低层次指标


- s# k7 g+ E8 g8 A4 K9 c

/ }! a9 M# @' K% x. \8 m) ~: r! J

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。" J/ p( N( l! h

6 u* `- l' a  W& l% B( V

$ u' p4 Q8 ~) l; z+ I

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


' ^* c- @# Y% e; C

; h/ V$ G3 W3 S* M

☆ 高层次指标

; ^! E5 v+ B1 a3 P$ x+ ^- ^


5 f1 Y- s5 r, r+ j* m

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

# h  c8 x) F5 D1 W+ d0 _  o6 Y

& _6 w0 }: u) Q2 v8 z4 K1 Y1 ?1 p

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

1 k3 \& D. z* y) g$ M


3 `% `/ z, x+ b# b& G

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

- ]4 H1 B- j/ J  h" [5 x) ]

6 D) O0 s+ g" ]- m1 Q

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

: r9 {1 y4 y/ B  K" e& n7 u


2 @  C! f, J, b8 V. c3 N! T  P. T

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

! g; o! r7 T/ F& n  R

) ~, H! @2 {) e! ~) H" e

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


) E  v2 j! a" u6 O* b


$ R& C8 t8 l, P! f' Y' B* P7 U

       监控的本质        
监控、告警与运维

+ t' r$ @  e! V6 p& \5 A3 V

0?.jpg


) p9 @  [, M; [1 ~, F

, V. H* x0 V' Z

8 I; ~- e- E8 I% j! G1 ?

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

# Z1 `& J8 u! {- B6 X3 q' ?


9 B2 j: t& c+ |+ I  U1 V

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

& a) S: f" w4 {


" }! B( _! }- g. ]  g6 U0 ~
         误告警解决办法        
监控、告警与运维
- Z5 X) E, M$ N, s/ U4 K9 ~& s5 h  l

0?.jpg

$ ?3 X+ Y! |# B' I+ u

* n1 f  X8 M7 S5 S7 R8 m

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

, ~# V6 [1 B8 s, U: r! \" Z


. ~$ Y. I) d' Y( g8 n

◇ 关联分析

5 F# O- h2 P# q; a. }( k& u( X3 E


7 Q+ W" z6 q# |

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


) y: d2 }! W3 U6 k2 m

, [: }1 U' `/ y1 \

◇ 无误告警


' }" z8 J4 m/ C/ ?3 M

/ P8 d' r0 X* L0 u* C" T! j

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


1 w1 F$ ]8 }- L( v

. n8 z' C5 `  Q" k* U9 C

◇ 持续运营


, G+ S, r! e4 B: k1 M) J' S


. z. E! ^  Y6 y7 l5 {! K) f9 z7 \5 j

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


3 E% u( p* G; g" f: ]

. a. Y0 j- z3 E; g7 q  f$ _! @, h

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

" f4 l# x. c& J/ i


/ O7 u8 K) a* o1 b" ]/ X

案例:海量数据分析思路
监控、告警与运维

0 r; d/ B% t; I: q2 h" u
# |; I. ]8 r/ D) e

0?.jpg


& D6 u. {* G5 U7 i; h

# V! P0 v3 [9 d( H5 t/ O$ F

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


5 l# ^+ W4 d  z. L' C& P  v7 N
1 x" p& q; B4 e) x3 K( j

0?.jpg

, ?+ Q0 v& D7 k0 R


3 `& F  a& X2 T! \: o4 }. u+ F

1 J5 T' T3 x( h2 p

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


( \. D: O, c, b* ^( }+ K

7 n% k: N' u/ X0 h* \

0?.jpg


; z. t  Y: I3 n$ J, X: x: _5 o9 D6 t

4 w2 f; c) T& G+ c3 p2 b

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

. d. S: o5 z! [( g

0?.jpg


% Z8 F1 I' z; n. I% n


' z6 w/ R6 x- E+ f2 o

; C) f3 G' s6 y9 ]; \- a: ^$ k, k

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


" R# Z! [/ h. i6 Q3 p  q: P

0?.jpg

  y! K4 i; X9 t! Y( o* u


3 R9 Y0 S5 o# _5 p, H1 ?

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


( u7 Z$ G& {  A8 U) h3 q5 ]

0?.jpg


4 j7 K0 R+ {0 A$ `


2 G6 b& I) t2 o: A9 H" I4 Y; f% O" @


1 ~2 c. B6 q. [* z  H; p

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

! v" Y+ A3 ^( p  x, l% h9 {

0?.jpg


; ]6 J$ n9 N$ g3 i2 R/ w

/ V; U: J6 x" q1 Z- K

- o% f3 x6 Z6 j4 O; w

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

, g5 N: G' G6 ~  Q, N) r, c

9 n/ C, R- K# @2 l

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

$ q0 j' B2 H! ?6 J8 p7 Z
4 z9 U: v4 i0 K0 \2 X( }
海量分析三技巧

' p- M) r: K; M  q7 L0 A% @( f- `4 Q1 s) O0 n8 c

0?.jpg


: D! [* l  ]5 n" B0 K


) O5 L8 T3 v9 c. V9 B

- W: h: ?/ Z( Z7 l5 D: l- w

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

" [- e* j' u) |, u6 }* n. B


" W9 N& {! K) p/ @( J. r' M4 q

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

7 P6 I2 t8 v5 a) b- D8 J, a


+ m% M: |. @/ e8 h( ~5 Y0 s
        溯源分析      
海量分析三技巧

& M" D3 M/ N/ v8 a

0?.jpg


; V& l" ]8 O1 M% ?- G5 R! ~

+ C7 H, u5 ]7 U- S; u% \  P

〓 高维与降维打击

9 L# j( F+ T/ A! F; U6 k9 z* o


- q& z* k+ o/ g- X3 f

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

- q# I  s- f# v1 c4 d$ p0 E


# M8 k3 L- h" s" I

〓 级联分析

/ s5 t0 c" S, K5 z: X8 G  n7 U) f

& w& K' F. h8 z- V

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


1 p7 S' i9 K6 ?- L- X- a  _$ P

8 N4 s9 J5 q; U( b! r8 |

〓 逆向思维


- H4 j7 M' B1 o+ h4 ]/ D) Q

; ~4 k* a% _/ o8 K: ^/ W5 @

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

2 L9 w- ^* T3 D' V/ H

1 e9 J- @+ ~) [5 x, M

        根因分析      
海量分析三技巧

# F! `7 i: Y) Q  K0 l& c( Q

0?.jpg

  Q/ t4 e5 p# ?  a! a: T0 w


. [$ |' p: C5 c' e# p# K
  • 用高层次的告警 收敛 低层次的告警


    7 g2 O* D8 N6 ?, a7 p, [9 G

/ `* |6 E/ I- I: X' S& g
# I1 h$ |0 j. l1 p8 }6 u4 |

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

4 \+ e( V# i, T9 R0 |$ R) O


; e: R, n9 r  z& O6 |( t

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


    / B. D& U: m3 z8 r+ E+ s, Z

    . b' R' F3 c8 J4 D' h
) u- m4 u4 f3 I( T( k1 A

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

% K* m. y! s8 _- m

8 X0 _# ?8 b' H, @3 |! V1 W' Z

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


    5 _% r* a$ T6 h; b7 G6 }
    ; X% W; T6 T* k% a' z
: N- b: G8 a5 F) m; O! B. z

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

2 t1 r  @" e% r7 J3 @

! w, W; W7 F& X8 i0 N: w3 ^
  • 用主动触发的活动 屏蔽 对象的告警:


    ) c! o( \' k) I+ L# s% J

7 T* |0 A# G; Z' }5 l) F+ H8 w4 v! P& x

& ?: m: M) P" G6 x# J

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

5 C. Z1 N& l; g$ H2 Q( \+ b4 w


' d  }: e$ Z$ p/ J8 D

        优选指标     
海量分析三技巧

& o: ^+ H' g+ X) B5 M; m: s) k7 P5 k- ^  p) H) d

0?.jpg

. ]& i& i, k# m" l) X; i: @

5 n0 }  o' d9 a- V

核心指标论

# F1 E, z3 ]; K9 h  M

* h6 w: g) X; o( x

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


3 b1 }3 ]4 Y- e2 ~

9 Q- Z% w8 }; S# K

监控的相关性

* y. v, N, k0 t: B5 S: h# J, y

+ U/ h. n' i1 A, W8 C

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

/ n) Y) w4 N  h; V* G8 n6 D

9 l& ?2 x! s  ]1 ~; o: ^

告警分级管理

6 \+ D/ I' V; F; \5 ^0 m. ~4 o

; r- Q6 j/ N" y, ^3 Q

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

  X& `/ E& n8 `- F

/ s# D' J8 K0 h6 D8 J- G9 v$ e* d

降低流式监控的计算量


1 N6 ]. ^5 @* w6 v! T9 S

4 T; e* ?: _; z& G& ?

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


$ S. h( V! N+ n


2 G" c- l: E" o" c6 n4 O: a# X

      用户舆情分析监控   
SNG织云监控系统
9 u1 ~0 y: \4 v! p! a; W

0?.jpg

* @! W- o8 D9 Y4 f0 Y: v


8 F3 \  l# O0 V# w  r% }

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

4 G, m1 p3 Z5 e; w" T( Z2 F


; S! }  d8 Q6 ?* t( n

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

  M/ H: _( r9 \* B, O

7 S3 l4 U$ |) J# c2 |9 A

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

# @  L* k. d% C' \' J$ }2 c4 c

+ b; H3 b* T0 m9 K

0?.jpg

, w1 H. ^: \6 k! R! O- A


( M8 o; k3 S/ `

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

! K: T: V0 |3 n; e4 m


; m  t# I; e! c% l& F
精准试用的算法与策略
SNG织云监控系统
4 T7 Q2 C6 C( ]/ [) }( Z  l/ Q
1 |; H7 }& ]$ v5 P" v

0?.jpg

# y  B/ A- @0 c8 n- B# z8 C- H

  C' O& ~; E& l% k7 k" G" f

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

% J# {, c% \1 n* z2 i+ ]2 y


6 H. r# l- O4 ]; x$ S

常见业务监控图形与策略
SNG织云监控系统

7 N0 \) s' M( y% a! B  r. |0 M" [

0?.jpg

7 d# U0 }9 L* O6 |. E

8 D3 k: G0 t& v6 ^- V

6 [! j- y9 I& d- c' r1 c1 E

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


( G3 T- B; ~( Q1 e0 i% t+ H7 z, Q

0 N5 w+ g2 U0 j/ Q

       案例:监控自愈      
SNG织云监控系统
6 K4 y4 k8 o7 L) u8 [  j& z# }

0?.jpg


( v, L6 c. x4 g0 z


  a# s& ~* ]3 x& M/ _; c& K& \

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


$ y& s9 e. B- X) t


  U) B% d; q$ H

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

3 p1 u( W9 B5 V" W! C9 u

( h$ A: v, R) j1 K

      常见的收敛算法   
SNG织云监控系统
9 \8 D) g4 V& }

0?.jpg

0 O( V; w5 V) |1 H4 m1 I


, J5 j3 d& g& Z: i! P3 B


) s. K; f: u# N8 [+ ]; o2 @

◇ 毛刺收敛

! e/ t0 L: w- [6 H" ~- }( ~


2 R; O+ d0 m  N' ?6 L7 E

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

3 j1 i1 D8 N. S

8 ~' A8 ^2 u/ [5 o7 x

◇ 同类收敛


( [: T7 |! f- r7 D  n3 v


7 t( G# |9 u1 w# b* @. c) A

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

  X5 X, P4 J$ g; F


/ ~2 c; \) b' W8 [* D4 s

◇ 时间收敛


* ~$ I- _: _6 a5 w


% J3 j6 l8 S' ^

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


1 ^0 ~  x8 P9 a6 P( d9 h


. V& t/ P5 |, Q$ e

◇ 昼夜收敛

, s+ |2 y- L5 s; p* S# @

. x( `; I8 E1 j

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

2 n* U$ _( s+ m

* e2 q" D/ {6 a9 ?9 {/ t

◇ 变更收敛


5 Z1 s2 E+ D: F6 {

; v0 F" y- f3 _3 F0 ~

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


, x; X& L, ?8 O8 _  ?
3 S4 I/ j9 O1 Q7 g0 j" ^& d
织云监控构建的质量体系
SNG织云监控系统
8 X) f& f1 |& W/ F6 ]1 L

0?.jpg

/ Q, o/ o9 r0 q# n5 l

7 {' J+ _' q. p# l( m, s$ o

8 o/ O1 H, {; H, t* e0 D

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


' j% Q+ v. n( Y9 u


. |  i$ _& y' ~: d' i$ Z
织云监控:质量体系  
SNG织云监控系统

" q1 [' T5 k, n. o

0?.jpg

- O) M# H& q4 s) A" a4 c' f

) H) _" p6 a2 J4 X) I* o- x/ [

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


( `( ]0 x6 B) u/ f) v- b

3 h1 F- ^- d" a  _/ ~3 T% H

  • 监控能力


    ; X. E- n/ b- G& `* ^; J$ x1 X- c
& W6 n5 n- b/ z5 D

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


4 y$ P: P% d$ O7 w6 j" b

! s, @4 J( R4 N

  • 业务可用性

    6 i7 v2 B* D* s

    / W2 f9 R- Q- ^0 }/ I

4 f6 J3 n3 p- \' ]

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


+ ?1 E; U+ K. R/ w4 x1 n

7 ?. n5 o  t8 Y' s; ]4 c, o

  • 用户体验


    4 e+ B0 D/ V- F* k6 r
    5 R  U. M) C5 P1 `5 B/ X3 \

% n# Y" Y  q/ T' M/ y1 ~

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

1 R+ l6 J: L. }* ]2 W

& I7 Q. p8 R  G- v9 T$ p0 E

  • 技术解决
    ' w0 l! a4 s3 K; G

+ ~& Y% y3 G3 s; R7 ~! c% k8 \0 f1 j3 t" F( b  y; o1 u2 l
要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。
5 w% U1 i8 n4 I4 j' M9 r

( T7 _+ a' O9 [" }4 k

/ b8 q! M" L& S0 m& p- t

  • 统计分析

    7 \( @* G6 P1 `! @3 [

4 _5 j1 J# u" |, i/ @# f; s. j

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

( H; ^3 l" z" E7 G  @

* G; e$ A7 F8 H& x. k2 ]

持续改进


7 ^9 j* t3 S& e& _

- v: [8 h; |" |+ D

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


$ N% t8 Q+ v  O! E6 ~

. X: H3 X) c! G4 Z3 z& B8 q2 p

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

* ^% X  v4 ]5 N

    结语    
DevOps最后一棒
% e0 z8 g0 d0 e( y( F

& b( X* g+ R1 L1 P# P6 r

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


9 ~2 S9 i4 w& U# _- x3 v1 x0 q' i, R: N' a- K3 j$ X& I% X
原创:梁定安
* \3 x7 ]0 x% Z  S4 A" ?

- r+ y$ }  r9 M) h9 {# M1 ~+ g7 a; a' A! m3 p




上一篇:15个标准衡量DevOps是否成功
下一篇:解读2017年DevOps最新现状研究报告
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

GMT+8, 2022-7-5 14:36 , Processed in 0.152727 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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