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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 2517|回复: 0

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

[复制链接]
发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-14 10:54 编辑
7 i; ^8 |; d9 l& I6 S/ U5 x8 z! K7 x7 H( X7 V
    前言    
DevOps最后一棒
3 A% I. I. Z8 f7 O$ v: K
, \" L0 z2 b4 H2 \  R

0?.jpg


0 V8 {6 j* z6 f, i) e) [


4 X. N! Y9 Q0 r& {$ O

; q; `( ]- W# s) J0 v6 ~1 V) q; |0 q9 K

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

' G. u9 ^( Y7 J8 @- X) G

2 J9 U. s0 R; S- y

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


+ M8 Y$ d( ~3 S8 @* o


: o2 V  @5 z' P1 |/ D! ?

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

# c# I6 ^! @7 o& l
& b- ]9 ~! T' g' V- Q

$ n: |$ t1 t2 }+ K6 A0 ]- B

0?.jpg

8 Z6 [% b; i0 ]+ \& E


9 P  |" ]/ m: M

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

% \6 X# }0 t5 s5 X! A

0 L5 A3 {( P. O" W. {

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

/ l" v7 W7 z- f& j9 u! e0 ?

; N  t) }1 S4 |7 E6 ]# W

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

) @1 K$ P, L6 r4 q- z: W

5 }0 @( r' A; }( q0 K

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

' m7 V6 w# p0 G. ~* [, p" j

  D* r: ]1 x! V/ U" @3 N( x

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


: r6 ]$ o* R  \6 m- z

" a: }1 E( d4 ^+ n' u

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


+ o# f0 `; m* p

1 k0 q" E6 E" l7 o! t- I

      全面的监控点      
监控、告警与运维

9 n, `: l- _# R4 R. L. z4 n

0?.jpg


/ t7 I$ t& A9 g4 |; A( S

" H/ b5 d6 T' V5 T! q* i

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

3 i, O% s  d% c3 Q


& I7 [* s' p- P. Z6 h% |

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

1 K+ d+ v0 A/ A% g- a$ X% d7 ^1 e


  v7 E# W0 o8 G( f

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

" O% `) v5 c8 L# C

0?.jpg

! z0 S% V/ I, l# x3 B


& E8 `2 x; q! c% W% R5 E

  i; C" c8 d. ~8 E" [  i

〓 繁——简

% R2 u% p: c! R& _! u( v7 t


8 B% p- Y! q/ Q- \7 H7 R$ Y3 d

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


) Q" A  g8 W9 F$ t


" u2 r; d3 V: `2 X! E

〓 泛——精

% v2 c( ?0 t% e6 K' L  `


- v) `- u+ T% N3 l

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


, d8 V3 n, z6 j. v8 `, U

) Z% I- ^+ g6 W% [2 O; K

〓 乱——序


6 Y. E$ V3 e0 \0 Z


8 V3 q8 p: l1 I

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


2 M/ t* Z/ [( p3 D1 [

: a) }+ d5 v7 b: q  D" `4 z

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

- N- Q  B. P( _2 [  t5 K

* c! S! Y& ~* [! V" v; a8 Z- y

监控对象与度量指标
监控、告警与运维

: s; u* K3 U( x/ B& z% s

0?.jpg

8 _3 c3 p9 J" s


7 G& d* Y! k0 z

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

' h. g8 B7 w3 T

# N# P% ~% \2 ~- D- D$ b: I( ?* A9 z

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

; L$ m7 n7 W' p( k. |0 V$ o

  {$ F- M$ i& E  g% ^8 [* X

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

7 ^# ]8 G) X) R) T3 M2 q


+ N$ G) C% J+ s- X( w: g

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

* w1 `, W& {  a& ?5 W2 X$ a& T

( w1 k, P+ C3 H; O" b

☆ 低层次指标

: {2 b9 Y) L0 Z) x8 e


% a( ?2 o" @6 |9 r0 c. i6 V

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。
4 g0 W4 i# |  p5 E* o  ?. P; ]! U! {* q


. }- h/ F9 s# ]+ C

2 H1 z. L5 i5 U4 k1 ~1 ^5 a

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


- Q5 Q, [3 Y$ V8 b6 D% T+ X! d


& ?" b+ S3 s9 y( a0 M( {  u+ A5 L; y

☆ 高层次指标

! o2 @3 _# x& Z+ H: B0 z# _


& Q8 p9 ?& D0 b9 U

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


1 V- M; v, y8 a: Q0 I


* o8 t! e+ i# H* F, ^

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


( ~8 Y1 a3 U. D% E


) ~2 l; b3 a0 a' H! y

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

+ W" y! J: W  Z" i7 i! ]8 j) r


6 s; H' T% w$ V! K# p+ @

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


1 b( Z6 a7 @% D; `2 b: h


" U, v) J, A9 E! h8 d' |- t

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


& ]3 m0 R6 l. y( t* s% N6 B6 r2 r


8 i: t( Q6 ~+ J& N7 T

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


/ u0 n: V- i+ Q5 D' m& S" l  x) _. c

/ z7 g9 W: s2 n$ l  d/ }) t

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

: l% G( a6 O3 n

0?.jpg

: w6 u) `% E; d) |* a

8 C. G. ?; q3 X' V( \2 }


% H- S" \. c  u0 X

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


) [, O. `) X1 }+ u

8 q1 T/ G; {: ]9 F  ?

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


6 d: W4 b$ j2 }6 ?


3 F: l* X  u4 Q4 P' L- A
         误告警解决办法        
监控、告警与运维
0 ^) n) ^  X, O* N* M

0?.jpg


. h2 w4 O% X' M2 U0 R0 l


" I: H- ]. Q: G1 w

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

- o) k9 [  {# f8 ^+ N5 I


4 i, q( v2 }* B7 W; [" T% T

◇ 关联分析


2 T9 e& F; o- o4 ^1 W+ S3 v

8 |, P( {+ A% H

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


% w5 f& U' i# g/ ?, c


( S% R7 r) V% Q" D

◇ 无误告警


4 _- D4 _4 ~1 V& Z9 I' ]


7 R: I/ k. g# l) Q8 K+ p

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


4 u8 j9 {  u7 ]


' h) P+ A: j  E

◇ 持续运营


% g: ]" U3 ^3 w  g


7 g8 x2 E1 K% n- t. ?

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


$ ^% N; v& t+ ~/ `( F


! O% z2 R  ~7 r5 W6 {/ e

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


) E* I# X+ M" Q/ W" R/ {5 t


) `0 S- R6 ~' H4 y

案例:海量数据分析思路
监控、告警与运维
0 V0 o- g) d. y$ b, s- d# }
+ e1 n/ x" F& h; x" ?" B& X# Y( E

0?.jpg


' g" ~2 q4 |  c9 {! R( c' E


# f, m) I5 l0 z7 Y  m" K

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


( ?* v$ w' n: z3 o- a3 C8 s* r
2 l+ \/ S, Z$ l. h; n

0?.jpg


4 H+ a7 e+ U- g( ~7 T0 W

' b# ]0 U; Y/ v) K( c% o) y

) L% N/ N4 P2 |' {" D

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

! S0 A, b* u1 C) T& D. ?+ z
- ~. a8 i6 k% w3 b- K5 C

0?.jpg

3 c* I5 L0 }3 E4 p; R0 t' Y6 R


, f# C7 g. p% T; Z, p8 ~4 P$ y1 e% |

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


8 a4 v/ {5 q4 P) h. n* L

0?.jpg

  K% v1 i/ ?/ F& W0 M; V4 ]* U( z


6 Y6 R9 u( g7 Z6 S5 M


! z$ ?) u9 z8 H% }

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


3 n+ `$ B% g, {% O4 m6 ]

0?.jpg


) |+ T- Y/ E8 a( Q: @

% u* m2 F" x6 a$ m' @& a

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


- E8 S) i/ P9 G: m

0?.jpg


6 M4 d! m3 {" \& a7 b" i7 ~


- x3 Y# _& u$ }. R


% k$ T2 D0 p  T6 K0 S( K

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


2 f1 ]% K% z) b( X" h) k/ C

0?.jpg

% G1 y$ l( s9 n1 B  j. r1 H

# Y: P& ~" b' R) X


! k' C* J. F4 U/ U! |* c; G1 ~

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


) Q2 T6 N. o2 O9 [" B& S


: x; `# B1 Q9 Y- {, D: F

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

* N9 D8 `  m4 j! H

( r, ^; w& i& B* s( H8 [
海量分析三技巧

4 @0 Q4 G- M* w: k" _6 ]# x) A

0?.jpg

! d& t( V' }) p. Y$ e! ~5 T5 i% P


3 k) V9 R" W1 x6 @9 e+ g" h) l

3 L; W8 S( G# B  G8 Q; C

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


2 P7 `! A" c! h' V$ r

7 F& a8 X3 H. R+ c4 K# n1 E

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


. L3 ^5 h8 R# v0 o: X0 ]

. m' J2 Q/ n% P3 ?0 \6 ^
        溯源分析      
海量分析三技巧

0 m' f' G+ W6 v* @' _7 L4 ]

0?.jpg

2 g+ T# Y5 e  p$ @. Q( {


! E* \, q& D* f" N# Q9 ]9 G9 _

〓 高维与降维打击


+ y2 |. g8 {/ {; B: @# e


, ?* g1 G3 j3 _" w' Z$ B; I+ ?

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


( e2 K0 W9 [4 l! b


( t9 n: i" `, H9 H, `

〓 级联分析

9 ~+ ]! x' G/ n  @9 K4 u9 D3 y

0 N- s6 ^/ o- Y

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


" [! b2 Y. b: {9 g( K

1 C8 a1 b4 b$ {; D) |& {0 v- M

〓 逆向思维


% I- Z8 L4 l: F4 ]. y& W

- W6 J: i  e3 j" ~7 C* d, v' S6 J% ?

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

, x7 j# U- `% Y  e

& z3 j* `" q& D0 t% k7 u1 F

        根因分析      
海量分析三技巧

- v4 U' A7 e0 o) r/ H6 A

0?.jpg


5 P  f. F5 S+ S, `$ O. F

' O9 N# V+ L% k+ o$ l. k/ I. Q
  • 用高层次的告警 收敛 低层次的告警


    & X8 x+ O$ ^3 D, X6 j4 z- @3 ~
* L1 t1 G5 r3 A) v

( W; J4 U% V) K% b

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


/ K) W9 {1 \; [" T1 y  y


& x( [( a: f/ H, S

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


    / r  U, e; T# Y* l; K

    - P/ _; j  V% \

# b" z7 T) d6 V- j$ H& L5 G

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


9 b; R+ q; a1 b* u

, P2 s' ~: L1 k& s* f) h/ H

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

      o: t. a6 N- k) ?" l' ^) w

    4 m+ B! o+ I& m" ]6 t
6 ~8 V) ]7 l( g

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

1 M4 E  ?! X+ }9 u

7 a/ c* G  N$ r. c
  • 用主动触发的活动 屏蔽 对象的告警:

    5 c( I! b  B! D# v8 @" e! p- m
: y( P3 |% P. |3 k% Z: b0 ?" }3 u  ~

4 ]& F: r( P' D! o

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


3 q; n3 F6 {' @; J' m


9 e  `1 G3 ]8 c% W1 Q0 c# h

        优选指标     
海量分析三技巧

# `" p1 A6 K& `
0 b" X2 n) ]6 v& Q% l( p4 m

0?.jpg


& V5 s  O6 Y0 m


: \4 C# y1 m8 c+ u$ l

核心指标论


1 L" w1 A% [/ ~3 S  S) I/ e) K


9 c: k. [# D: C# ?) S

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


( l3 x' W& z7 {+ ]


: U: |+ E9 H/ L/ K9 O' X

监控的相关性


$ Q9 L$ [5 ?. N: D


" k: q" n. U3 Y' \0 q+ i. D0 j

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


! v  _! _) \4 r3 f! n; _) K


. m* V$ a" @# l, U

告警分级管理


# G6 t: Q# a2 }" D% B


$ J' [' {# O4 z) t: _

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


- M; W( j  _/ j- @5 _7 u- u


5 x! l) {2 d; p, a* }

降低流式监控的计算量

4 ^! w' d- H% ^0 ^


) N: q. q8 {' m, \! B' z: _9 V* V* U

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


9 R" Z! }6 K2 w; ^6 e


% w3 z! q8 N: ]6 o. p7 O3 Z

      用户舆情分析监控   
SNG织云监控系统
: B" s. ~0 D/ g/ O0 C

0?.jpg

: n& a6 P; P3 b


' [# `+ q+ F$ V# x: h, x

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

; X' b6 J1 t1 d


& i9 u" n7 P2 R0 u/ _$ @

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

; S$ p3 w5 M: T: J$ Y4 X, w

! m9 H) V/ W  z1 I9 [" e# R1 ^

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

3 Z' r- K& }- k7 N

# y. ^* V( k/ b6 o: t  e

0?.jpg

5 g/ X% |7 V% [) Q! V- P$ T

6 F6 u/ [; z5 P. h7 x

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


/ J7 C' P4 t/ y. V+ {! ]; G


0 G- G6 k* s" \6 |7 h8 T
精准试用的算法与策略
SNG织云监控系统
: a  A5 W4 [6 x$ x' A0 l' P* V
, N: o0 Q; Q  Q( r

0?.jpg


# b3 z1 i% K% L2 o2 h" G

2 V( c" b4 ]/ K' V

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


7 ~3 P4 n2 a2 p% U; @2 j

) x# Z' c8 K" w6 w

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

; f% R! M3 [$ h* O5 E8 z

0?.jpg


4 ~7 O! @/ g2 G3 P. C7 s. R0 I


! l+ t2 s; p' A! ~' |


5 q% w: Z$ |1 c  o+ \8 Q$ m7 e4 r2 Q/ d. L

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

5 p# ~: n& Z" k# d1 U1 M' n

) @. c3 V" A8 o5 V2 D, q

       案例:监控自愈      
SNG织云监控系统
, @, o8 W. b) i3 i& x4 W" x

0?.jpg


4 g- y" H/ s0 Z/ C


, O6 Y8 m9 N4 N

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


" [1 a( t' R% E' v2 O, i2 A

4 _9 `+ J7 C8 w/ c5 J; ]

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

) C; j9 L, C' S5 p0 B


% J2 ^2 W, [0 o7 g

      常见的收敛算法   
SNG织云监控系统
. B, T. ]8 e) ^2 l

0?.jpg


5 m3 L1 D: ?( K


5 e: d/ S. _6 i/ D


' k( x: ~, c+ q' e7 s

◇ 毛刺收敛


$ P5 l! c" C! t  s; Y


0 h/ s- N( w2 p& c

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


7 |) O! |  K5 C- S! G6 L& ^


- u$ ^$ ~# j: |+ L7 U7 k/ }2 r: k

◇ 同类收敛


7 s, G. U0 h  I" r) j& L* |$ l


, p6 m7 u4 L0 H0 e

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


% g1 P) @5 K  s9 [" R$ t( ~) B

; |1 o4 T5 A9 L+ j

◇ 时间收敛


- r) H1 E. s! ~% Y$ L0 }  T& g

$ [% W$ S. G( q% ], @4 y

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


, U' ^6 [9 Y& j( L, _


* B) u0 }; y  q" a/ |' s

◇ 昼夜收敛

) r8 _) R% F/ Z+ D- r# k$ d* O+ H

/ v# J1 a2 I, z

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

1 v; S. F# b) I/ H3 @

( s, v" Z; H% P! i9 O, Z) ]) x! O0 d

◇ 变更收敛


# ?/ w" c, X; j4 M- ~% \


; h* j4 E9 t& K9 \3 p0 O0 [

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


; n5 d& k% ^* t+ J. B1 {* {
# i2 p3 a; ~3 j6 t$ n0 Y; j
织云监控构建的质量体系
SNG织云监控系统
4 o. Q/ u5 N4 E

0?.jpg

' j- e# Q: N! O. r& e* L8 x

' E, K) B* R% U


# e# p/ T, }. \2 L4 s/ r" B3 R

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


1 o% D- v9 D8 J) U

6 W+ T2 d2 W1 J* d$ r; ?
织云监控:质量体系  
SNG织云监控系统

6 T3 r# K2 r6 @/ i) J+ P% x' Z

0?.jpg


1 `- c7 w3 [" `+ x# l' l

5 y$ b5 B( O$ U! b2 t

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

  U! J( u1 r( H% K0 \2 M% D

% X* c! ?9 m, L0 _' s

  • 监控能力


    + _4 ?0 W% I  X! K, d( g) I

# K6 J0 S4 h, j& H; F( Y) Y: W

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


4 |1 l6 E9 _1 f, ~, T; s


* L* q- l! l* x9 x5 P

  • 业务可用性


    , O. T* D! B3 w' N/ V( I+ k
    / `0 F% u6 p3 j

$ t$ L/ S+ T, O' z# U

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


5 ]1 N4 }5 h# R4 _5 Q


! i" l. ^0 k' d2 Y; t! ^! f

  • 用户体验

    * k. W, `& X) t1 x% w$ }

    9 a- D8 C1 Q; B( ?4 D& S
3 }8 }' {) G5 Z; R) d" L+ ~5 l* y

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


% m( _5 ~$ M% o' {  T


, C- }1 s6 B. k* b

  • 技术解决7 D) t0 H1 q1 R6 ^2 Z' A
2 i+ K9 K8 o' ^. X
; s7 S& r% Z. F5 R
要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。
9 T: I3 m; ^9 K/ j5 G


' d: l" w9 s8 [, p


" s8 h) |% I, w

  • 统计分析


    , g& |3 Q/ u1 P$ j5 [

$ G/ x4 X, E  c8 O; c; O

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

- Q3 \- \& a$ E, S% B

: V8 |; X$ D$ x- I: Y  w' W& r

持续改进


/ ?1 Q7 Q# Z$ k3 h* E" T5 ]1 l0 ?0 k* j

) Z# ]. N: K. c* u

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


& d6 k4 b3 Y2 V" b7 R9 Z0 [

- T! L; M# w" |4 a

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

' V( ]4 Y! l2 K1 z( ~

    结语    
DevOps最后一棒

; }% w" \# n7 A7 D' w+ w: m  z

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

  p+ _4 ^( H4 j) A, ?

/ a2 f  C4 L) U+ I1 w原创:梁定安
1 y! y  M+ T: K: p. v  V

; W" j2 r+ E& K  W
- N# q  M% o( e9 i




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

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

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

Baidu

GMT+8, 2021-12-2 23:51 , Processed in 0.245756 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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