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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

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

参加活动:0

组织活动:0

发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式 来自- 湖北武汉
本帖最后由 adminlily 于 2018-11-14 10:54 编辑 ) d1 D5 h+ ~; Z' Q

! O  t4 {! p0 Y9 \" I* |
    前言    
DevOps最后一棒
  ^; ~1 M7 C4 T5 x) |
' ^& O5 Y# p. ]  B5 e

0?.jpg

% }6 F, C( D8 f9 l1 `

3 ?3 @% @% _' y$ V9 z. F7 f2 x# r

( I. @9 I+ v3 K- ?1 u* S9 B

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

% z) P) I' @( Q

1 `8 _) D9 u1 X1 c5 z; K- `% G4 Q

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

- @- G: Z3 G( {. L


# L* E8 K' L1 f+ f. @: c& [/ p( c# S, }9 i

持续反馈于运维的理解
监控、告警与运维
8 A2 W" z! r8 A0 O2 G) v
, w# P% j9 T( H9 x

* N- q3 Y) h; U! f  n$ Y

0?.jpg

' d( X. ]1 S3 Q5 L. I

3 J0 h& x6 L0 t2 P- h( v# w

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

& l+ F* c0 c+ w( X6 s0 a1 }

5 @, F: M8 g+ }) t( z* j

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


; @7 T% h/ t& K- k


) X2 a  [$ \& e) b9 `3 B

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

7 P' o0 v( U$ m% u6 R3 K* h

! O+ y# S6 R9 n% ^" [! y3 P$ J, h

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


2 l  h7 j& H: ^

* W; z/ @- q3 h

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

' n; f8 N0 G8 C6 P2 T: e+ E/ |


/ L" x# P6 M6 W; G/ E$ F1 W. W

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


  c. ~- R0 I5 s& n8 {- @, I7 j8 J, \


& `1 i3 @7 D- L0 p" ?, j

      全面的监控点      
监控、告警与运维
6 z3 R* B& N8 n

0?.jpg


. p: l3 M  o3 x$ p1 k

1 l3 ?, ?" r% H5 q! f; x0 b; o

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


' n6 z2 B' [- U2 R! d5 P" I7 N# P


) u# ?7 l; N5 U7 E( I% H0 b

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


; ]& x/ j' Y) N5 F' C2 \$ t


; K: X$ z# I! g% R$ a/ G

运营阶段要解决的问题
监控、告警与运维
5 J- ?9 i5 X' h6 G/ V% [. a

0?.jpg


* a& Y3 p3 \0 [! z6 `4 X

8 U$ K/ F, P  J/ i+ N% [


" w( {% r% i( `! f

〓 繁——简

  x4 n' K7 J8 o9 Q

) }. h* f  B5 p/ m, o* p: ?/ r- v

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

% ^5 G6 ^# b3 i$ }* e; V8 d


' _4 t' t  E, o6 h: |2 b

〓 泛——精


5 I8 c, f2 p5 U

+ m* n& g  S+ M% ~3 G$ O! o% p" u

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

1 ^9 e6 r4 P0 s, L

/ K8 m( i/ a' \

〓 乱——序

# y1 H. A- L" V$ Q- F( L. Y7 ^


, R& D4 \; r1 S, x5 b4 J5 E0 B) q! v

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


; A4 _% }% o) p0 j2 X  u" c) a


, c7 O* d, o9 K5 [6 n

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

* a( }3 n- [# H+ ~8 l

2 e1 L  \' A8 U: {$ @

监控对象与度量指标
监控、告警与运维
" S, Z3 Z$ u5 R% `6 M; M

0?.jpg


3 P0 o+ h( X- \% F( x3 X7 S


0 B) ^& a* t& L" v6 c

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


. U3 [% a! j1 a# C


7 I4 A  C3 D4 J0 v+ ?9 \! v

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

$ {+ y) e' C. c7 w1 R3 e" ~


) k% g- n4 L% t

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

* m! G% j, Q9 B. p6 C


) t$ y: y" V, c: A

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


0 `( G% n+ U1 t  x/ z' }4 l

& i- v! J4 ^$ ^& w5 |4 _, D+ a

☆ 低层次指标


1 \; W5 N6 |6 D" r$ z) Q! Y

3 @/ O9 ?4 `2 p% R

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。$ |3 S& r6 M* m$ u- c- x  m9 D

, y6 Y2 a; w0 Z; R


- v3 ^& H( a/ u/ V. A  X

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

" Q  U) C. s2 d  s1 K


. x$ `# f1 B; r! f8 o! h

☆ 高层次指标


* H8 x# O/ f6 `8 l& S9 p- t8 j9 P0 i


$ e# I! N) C1 l* e

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

3 A  w  B2 h5 E! _: x4 ^, U, z! r


/ R6 M+ u( x$ i" u8 s

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

' \2 G. j+ I$ B; V


# z" A3 P* i* m5 b

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


- ~8 E2 A$ A  g( C/ H) A9 b% B

/ T; l! Z& o6 A8 ~

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


6 Q5 C  Q6 ^; m! |7 Y


+ \# |5 j  v, P7 j; j

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

: \8 O$ Z! j: r4 b0 {" [2 |


/ G' A8 y3 U( |1 P, Z' _6 q7 w

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


2 l0 ]7 w$ r; c; I2 I


  t* ~& S, M2 A% S- ~" w; h- d

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

; O) T' Z* N$ C

0?.jpg


9 B4 N6 D& G( i! S4 ]# b  q. Z

' f& t! m  Z8 g( |4 e

9 h; f9 w, w7 ]9 Z  @- u& K: D

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

' f* g" b1 Q* t3 o: U- \% [

6 y0 V6 M5 }  z1 d. [1 R& a1 @/ L

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


6 `: F$ X9 p5 _7 V: v

% i8 K" X; j$ Y+ a+ ]; _7 X
         误告警解决办法        
监控、告警与运维
# X6 `6 F3 U3 V# B7 j9 `

0?.jpg


- Y7 O6 n0 o: N

/ |7 |* V7 n- |- `8 L  c# ~

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

- r  F" w6 C8 l

$ l  G0 ?8 B- `: k& L/ O2 B/ @

◇ 关联分析

4 q4 k& |( P  Z


  Q$ U, K$ M3 w, r  r

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

3 G0 y7 p; \! n% m% Y

- U- F2 d5 N* Z7 M

◇ 无误告警


! r; }6 P) J# i% g/ b

" U" M; \# a5 f9 T1 Z0 O

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

; ?. K* k" b1 x* _

$ s0 Q5 Z. J8 [' l* Y5 ~* m

◇ 持续运营

8 Z( y+ A' {  U7 W& ~


9 {( X3 Z/ t1 ]+ B" H$ r

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

4 p) y, g0 [) W5 \

) Z9 O% i: Q5 d4 {4 l

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

7 |* y2 B5 r3 p( g8 I

) N. g' a8 N  `$ y+ @- Q# y6 _

案例:海量数据分析思路
监控、告警与运维
% U- C  y8 T( b! g$ D8 b
# T" R# V7 i- H8 x9 s! L5 E

0?.jpg


# B, V1 t2 _, C  H: B* I' h0 G

# }, W! d8 R' ]+ w* v9 w: M6 ?

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


0 {$ F" K" B- x& v

2 c' v' N# |2 g. v7 W

0?.jpg


6 q+ E% J! }( s* \

! s- a5 i& n* v$ h5 A& l! k, _

9 ~5 |6 J, A# w1 }7 n, ?4 H

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


1 ~/ i( `; W7 p. ]+ S  z' R( W
( W& Q( }9 |4 x

0?.jpg


+ {+ w# @; ~: h( y. I


3 U$ z6 `& B4 i2 g( j

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

1 J" G1 e# _1 N0 D  f9 q  G* Q

0?.jpg


# z0 t% x% `* l4 _; Y: Y9 Y" x; z


' @3 ~7 y0 h/ [' v7 p9 m0 q2 d

/ f; D- [0 U" s' O9 r

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


$ n; N* B- W3 q+ H% r$ m6 I

0?.jpg

* N& h: F8 s5 ]

, a- O- ]5 L" ]* N5 Q4 l: }

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

& i2 C2 j% Q! G3 x2 q" x

0?.jpg

  V0 B# C: d% \% }8 C

# X& s$ y& b# v! `+ k9 H0 H9 s6 v


8 _  S2 z5 u- \, P) K1 |

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

- U: u: ^/ H9 a  e) q6 C& I

0?.jpg

4 Y8 ]; y8 |" a: c. ]

2 o" y1 o/ G2 {1 ^% T, k. J

/ w1 T3 ]3 J: d+ d% O0 s: \$ Q( V9 \0 C

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


7 `/ H1 X1 X$ {. U

, j) H4 c  L9 X/ D: p0 }6 l1 F

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


# B" \; b. y2 p/ }' _" ^- X5 U: w' o/ `; n3 f0 z& H6 H0 H
海量分析三技巧

' \, l* {) d6 M, T4 ~  p# _* A% k/ L3 ~1 y' Y0 P" ]

0?.jpg


. D9 k" B6 E$ j3 h' ^


6 m7 |8 |- g% n' }2 M4 b5 \# o3 a( C


. S  A  i5 f% T+ o, f/ e

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


+ {; i( c; J6 K4 {3 o  w; p1 I

7 `% t) E3 I" {8 I2 }

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

1 U% s) O  k$ q! D; [0 c


5 @" [/ F. h! V/ u1 g8 p! ^6 q" J, J
        溯源分析      
海量分析三技巧

2 Y$ J' M6 |5 n6 k4 ]

0?.jpg

- X5 k1 y) V, Z1 L# a


, V; \+ r, Q/ Z" `

〓 高维与降维打击

' i0 M. B7 Q6 e0 m* O% b1 @" g

" l; U0 W% [; c* J/ R( W, L1 ]- G

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


& v0 Z# }$ D0 `% k/ q$ m) a- @


$ o8 [+ x" H) z$ }& x9 W

〓 级联分析


! i  l' O* M) z% o) {) ]& K7 a


$ L1 W. w9 ?( O. `. e3 ~

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

% m6 L1 }9 s/ j: a7 u7 H8 L! |, U


$ T" W8 {, T* R+ Y

〓 逆向思维

! x  n! E7 a" Z' e2 p. v

7 k# i$ j& a* p) N4 V/ ^) a

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


" I1 r; ^* u0 @. @  u; k3 Q8 P


( J4 L0 ]7 v4 S9 i

        根因分析      
海量分析三技巧
1 q1 E- ?$ N- [

0?.jpg


( B1 E  b" g) ^

, N5 O9 x' u& n( u2 {+ g' U' L
  • 用高层次的告警 收敛 低层次的告警


    " Q5 D/ E0 }" z: b) l

3 e9 \4 I- e! `
$ W" ?! A6 P) n/ n. t% e! W9 E4 z

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

3 w9 R9 {( N  z# ?% l# V- m

+ W$ Y; ^, A# B

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

    3 U" @) s' r/ L/ J& u/ v, ~
    9 _$ c8 ^( Q+ u$ j$ q3 ?* A
) O+ A6 t3 G: H4 |3 R  c% d# ?

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


! ?5 \7 S: O& ~$ C: ^( \


: T- m+ y2 L7 O$ h, _

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


    " L1 m7 H7 n8 w
    0 h+ [& D: j( m, o2 E
0 a* W- a* _( x) b: S

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

7 q/ V" g" C. y& |" b5 K. G+ P( g

3 v7 I5 C5 C# O( w
  • 用主动触发的活动 屏蔽 对象的告警:

    $ Q) P- x; k2 u: F1 J: K6 n

1 n6 v7 y: s( J
6 C# d$ q. T& g- r

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

% b5 Z0 q; p' C


# t# w' ~0 h: I

        优选指标     
海量分析三技巧

2 I4 C+ K+ c/ n
5 K, S. i5 W! V" {+ B

0?.jpg


$ r8 ~( D* W8 ^

0 d8 ?3 b5 A3 N* k1 P/ o( z& ~  _

核心指标论

6 B. b2 ^. ~& z, h( y: i, a

2 G1 h& C8 _" `6 ~" l/ \" O/ h

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

, `6 x8 D. }9 |7 H/ c: D

, N3 R* J% k+ l) V  U4 G, ?

监控的相关性


2 ]+ x2 t0 j3 T4 \


+ T* T& s) a6 u& X5 [

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

! J5 [4 W+ q7 g4 c% Q( A


4 Z1 K- S$ }% `, c9 p# z6 b

告警分级管理


# ^  s) A3 b7 o- \% I/ y: o0 j6 V; ^

3 x1 a9 i2 Q9 D

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

0 c- K* \5 F0 l& }6 S

: ?% i! [$ O8 m" _" x

降低流式监控的计算量

: K+ N  s, G* e! @8 b

3 L3 [  J& |- @- o9 P' C- ^% U- U4 h

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


' l/ I& G. c2 m0 _; z3 V7 e" f" Z$ D3 L

" F: R: ^. f! B2 @

      用户舆情分析监控   
SNG织云监控系统
/ X4 @8 Z# m3 @# m1 a

0?.jpg


5 Q* o! B- K% C  \% O( ?


! Z9 a5 k% y6 |3 j+ f( h

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


- F: Q6 V% r& r


: t( v# n2 [. g) D1 E! M, O

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

. o2 r/ G- V7 t

! g5 r% L( D) i  D6 D- y

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

7 }! V  a. b6 i( [
* T9 ^7 R6 S0 m. k, ^

0?.jpg


( I4 H6 r# {& R. U


6 |9 g4 J8 j9 g+ C0 w

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


2 M$ q) N- \) g, z& v

8 O* w+ h% l; U* v& w
精准试用的算法与策略
SNG织云监控系统
0 _0 g' v8 N: i% u- G; z

$ r8 t( I- o& s$ ~9 G

0?.jpg


( z3 \: E. m, Z


9 V/ q4 i) M* U! C! T- m! X

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

! ]1 N, |/ A6 l5 n+ ?


. g0 a: O) _4 V$ ]. W

常见业务监控图形与策略
SNG织云监控系统
& s1 N- l# L) v: N  N

0?.jpg


2 M2 U# L: j  G: f) `3 ?

- r9 t; B0 z8 S: J- T, f

1 B& t% g/ `4 k/ M! ]

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


) A# ~( S/ U9 x6 @7 v& }* C/ z' T2 b


0 v2 L3 E, [+ l: {

       案例:监控自愈      
SNG织云监控系统
  q( _, G& a! G0 B+ J" f

0?.jpg

5 N' v  _4 p" _8 \

, _1 m9 @1 F2 s0 l, U

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


1 l' J( Z7 d, P) R- ?

( r: x, T" S" f; Z

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


/ I& K9 n5 D! L8 ~2 B

# T9 g  O+ a  S) r

      常见的收敛算法   
SNG织云监控系统
" F, |0 D5 e# `1 m8 A; r0 y1 p! b' V4 S

0?.jpg

* p( S* h# R5 X. M+ V* r


; _7 f# v# D1 I; G9 b* _


; @$ p) a% J4 J, C0 |

◇ 毛刺收敛

8 A- g  S; a$ l; I# V2 J5 R% L9 U

2 @. \! I7 e$ o/ p

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

+ P& h" g' K* D

$ S' G/ x1 V1 k  q' F+ N; a' n

◇ 同类收敛

/ C' l2 u6 Y" `- W8 {

- N) X) g5 Y7 B( V

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

9 ^. y' Q& h( Y$ u1 Y7 U5 l7 a

7 \7 _. t" t/ W( V& j; y# q

◇ 时间收敛

" F& m. T( b' V$ d" I8 n

" @' F* ~) D, t% s. D

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


" V: m  |/ G' V' e; I9 u5 B


' ?4 K3 ]- d& d* ^

◇ 昼夜收敛


9 u9 t; a$ p: D, v" F. |  q7 S2 L3 k


" g( K$ L) f2 a3 a5 i. \& q% a

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

) _, @7 e1 L) {& j( k" ?

7 d# }/ A5 w: q, Y8 j

◇ 变更收敛

( A( s( t/ \) Q4 z

) _& u, `* I5 U: e. D

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

3 q& X9 Q1 p% d) s* s: X" x

; ^0 _4 l9 U( _* z1 A
织云监控构建的质量体系
SNG织云监控系统
; F& _5 k6 ~8 V1 U+ r0 L

0?.jpg


6 u- |' B( P; w7 c3 B+ b: H9 p& R6 ~


8 Y- \% c( ^! P- @

3 Y* {. e0 L4 u3 {

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

! |6 Y' h3 T- t6 ?+ }' l, M: z8 }

2 g, P9 h9 C; ?, F4 }% m, z
织云监控:质量体系  
SNG织云监控系统
! g- S8 H# [; i0 |

0?.jpg

: @. G4 `) m7 ^, M

. c7 R: \7 M2 `9 X% t$ D

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


/ j3 Z/ w- s3 D


; ]9 W7 n. ^0 z. a# C

  • 监控能力

    ' t! \0 Q$ T% i$ h/ _" H

* ?, ?; A9 H, d* j) H

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

" m$ f; C8 ~9 w( y' u; Q: w


- h# S9 d" J5 z8 R3 `

  • 业务可用性

    2 d& B. h3 d7 v' V

    # |* N3 {. m' ?
7 J) |" l! D; l& d" t9 a

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

, n4 u+ `8 ~- ?) L0 N: U


* y) s3 J: f! Q6 x. ?5 r& t

  • 用户体验

    / F6 E) a+ \6 @( o' W$ t" O; w
    7 S3 R( T+ x3 u2 {7 O: z

* J* v1 s" e& K: o: [, T. T/ u( U

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


9 v# F8 K# H1 g5 t

2 K+ E+ a4 F! h2 D* y- q

  • 技术解决. b- C( n; I' Q

- d/ T; q9 t  Z* U; ]. P; O
" y4 s" u7 Z- Z要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。! }: a* K; H  w, ?


. t/ a* w8 T( F( V! Z  V' i( c

- u# k; Y, q, N4 O+ M

  • 统计分析


    5 p+ F1 e) J4 ]+ e8 }% X, u5 g, H

) Q) W" e5 A! }

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

4 z4 y6 X" k, D8 c1 y/ p9 x. h


! I/ Z0 ~5 H# }5 U

持续改进

& [; A9 K( \1 L6 a

) t# V$ c+ ^( Z4 ~. T

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


) h4 j% ~2 n( D

% O& i$ R* P8 p5 j

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

/ L: R4 a  C2 L5 w3 B; M: k+ ~

    结语    
DevOps最后一棒

( k% e; o# o5 r/ e) @' o
) W0 n1 i+ ~* T4 F

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

4 P' ^; M8 O0 I

" E8 M! `& e3 E$ g% r) X' q7 l原创:梁定安2 `' T6 [& J; |" @, l  |% Q/ G% M

5 Z% P; h6 u: c6 V! t) g7 p4 x" O2 h

本版积分规则

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

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

Baidu

GMT+8, 2019-1-23 22:19 , Processed in 0.334940 second(s), 31 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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