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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 997|回复: 0

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

[复制链接]
发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-14 10:54 编辑
. D( p7 I6 N1 D" ?9 [& k' N% A9 r' W( U: r; v
    前言    
DevOps最后一棒

6 f4 v' L1 o5 T) J( Q7 s8 \5 D7 z0 n" X  H

0?.jpg


) j. V% Q; b* L


% x* ]+ m7 v6 w: `. Y, E# a

$ r( _/ d1 x! h( Z$ r* ]

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


5 |0 E  f( h0 q6 }


% Q# \$ B$ s- }6 ~' i* B0 T

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


; W, ?6 R; ^: E  {2 z+ X  @: i, \

0 ?" B" e4 a' T1 c) |2 v- t' g

持续反馈于运维的理解
监控、告警与运维
' F7 N3 X; }8 a' x9 A+ u$ c. L

2 [  N8 s6 o$ V' H

6 r# F7 l# g6 |& F0 b. v

0?.jpg

1 ^1 T$ L& z7 k7 ]+ Q$ @5 u

+ m! M# E+ D9 Q% |9 F! l, m

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

# V4 M( y( @5 f


5 F  o! U0 a: H2 x

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

% K5 O6 k% f8 u

1 v' }. B& x  A

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

) d) b; _% G$ y& A2 z3 y: i


, N# q8 e! ]/ G0 U1 u  }; A! F' W$ F5 d

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

# w# ]4 ^7 j6 M# i

7 }: |( m1 E% n

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


" n$ R- N. G# F5 S; s

( K0 V8 e6 J7 y, d

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


* q$ Q, O) ^" `2 P* P


' `* ~( M- l! \+ \

      全面的监控点      
监控、告警与运维
4 _( t. H' C+ ]

0?.jpg


5 _/ U- V0 y) R) o' U% |& G% b

9 C: X/ B: _' \

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

9 K& v0 S/ w, u) D( d

8 Y; K: D+ s/ q% Q5 ]

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

' [2 a* `6 _: _& Y: v


! h: {, B# A; @$ q

运营阶段要解决的问题
监控、告警与运维
$ g: v! x! L8 V9 p/ {% V! r! }8 a

0?.jpg

: h' `+ D# `1 }5 T* A; N


7 o/ Q7 W3 b5 t0 e5 ^* S- c" E% [

' ?0 L% @) M, T0 P* b

〓 繁——简

) K' T( M5 C5 B


! t) u5 c% g) z

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

3 C) I, g9 m& K6 r* o- v


) M+ t( @  @5 L9 v* N

〓 泛——精


$ `  k2 t' n1 V2 S* r5 H9 h' x

- J: j( d3 J, r) j; @

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


0 E* y6 t/ }) \6 [+ |% h7 Y' r% C1 D8 e


. e/ M) l; N1 ?9 @+ g

〓 乱——序

6 N1 w" W" Q, j. Y& z


3 ?# y8 d' h" F$ T

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

3 t! \, X) \  j7 O7 A


3 g# K6 ^5 J; `7 F0 d, [4 Z) l

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

  M0 m7 S" @& O6 r0 T3 P


+ s5 P% b# R, l4 v) z

监控对象与度量指标
监控、告警与运维
" B7 N: F1 U. [* P. l8 r/ z

0?.jpg


, P6 T) l* [3 |2 H3 L) R, c

8 w, Q$ i! J8 ~4 H$ e& u7 o+ v( @

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

+ `+ s* z- f' a


% C: t) Z5 V- r' b

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

2 N5 q2 q2 m6 o


$ z0 l" [/ R- [4 k

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

( E; x' d8 l- |/ @, G# x% L$ E. n+ r

; r7 w5 V: E6 l

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


5 k5 W6 E' J- m

+ E* E. N6 Y8 b: D; w) B6 `

☆ 低层次指标

& H7 u- ?5 {' a/ \, O  f

7 ~% |$ u, e, y: w8 L5 s& G  K

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。
4 n7 g2 ^9 q" V! l


: G0 m4 E. i% G3 h( W* ?

: H, Z) E8 c4 Y

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


1 S& y! M5 F; [9 c& @1 ~& X

; ~  O4 l+ x; ?1 c9 k

☆ 高层次指标


! N. N8 l' q( t  M

, q3 \2 `! a9 R/ s

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


' n; I* k$ w2 g. C3 z0 s# s4 h/ X

  z/ f: M' s6 \& h% m/ E6 k8 W

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


2 S9 c2 `5 e7 x


  {# V" g& ?9 x

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

" `1 e! R! X: ?' l


5 x! R$ t( F- \/ q7 ~+ y. Z5 @* n/ J

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

$ r) |6 b/ E4 R% v$ b/ ^

6 {6 y  U+ P2 N8 q2 |! ]

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

3 l5 `) @: Z" [$ M, d


, C0 c* M# X& l2 _2 n  t- H4 |

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

1 D- W' y# i) a8 B


* G4 e2 m8 k$ C8 T

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

: u, G7 m6 Q, ?- I; R" c2 L4 s

0?.jpg


5 |4 _! X) o5 B! R0 i. T/ V; m


2 m' B; g5 c- l. ~& f3 u

+ e; c/ p, b5 B

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

1 \7 w  M' r! K/ o+ @, y


4 A  m; x& g- j# j

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

6 W4 I6 H% k) O- I* H: L

" Y$ H  T8 W9 H- R# E$ h( s
         误告警解决办法        
监控、告警与运维

  `( `0 X) g9 C

0?.jpg

+ g# p$ G2 ^% l  v$ m8 x" e9 r


/ x! I) R0 A* ]1 y; G

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

3 A% }3 ]7 ^& t; S1 {( g


9 d" B4 @/ x0 l4 Z

◇ 关联分析

4 ~; T" h/ ?- {. B

1 d. [+ X0 }2 l' R( e. N6 Y6 P

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

+ }# o6 J0 ^- Z) w

6 p/ t+ Y% l$ r

◇ 无误告警


$ R6 c' s1 [* K


+ L/ ^) N2 W% H+ p6 ]6 Z

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

$ ]7 z3 ~, B' e


: ^" |# i# G7 q3 F& s1 [

◇ 持续运营


/ L# c4 f* G1 \


; u$ \, S* n6 D" {$ j& X

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

, ?& b) u) l6 V; ~$ j; M0 d

6 u( p* @/ A0 d; _4 b0 Y

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

- D1 K5 n  h9 b' l


* L. F4 v  K: P  i, \

案例:海量数据分析思路
监控、告警与运维
. q) W3 q8 x* p* O4 P  e6 N

4 @6 h. o* B1 `4 M/ h1 O% M

0?.jpg

* K+ d( ]: K! a' @  O

6 G& {8 ?/ `6 i% n) r- Y

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

9 ?" \9 a, R# ?
" o+ J" }1 B; g1 \5 H

0?.jpg


6 Y% t( W, d7 }5 }: p% F


& M9 _" O0 d" F  l/ p: C


1 c6 g, r8 l8 z" T) d

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

7 U* {* s" I; y0 C

( [" \  U7 M! f  l

0?.jpg


% f1 @/ U9 n. F, c

0 g- Y4 y% |! P

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

" H) Z9 A% L/ `1 @

0?.jpg

- M- e' w8 p1 ?( j# v7 M8 L9 w


- L+ s% h( U7 O: C


" n6 x0 y+ k4 O: y( D

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

+ s" t5 z# J. q$ ?

0?.jpg


& y6 n2 z3 G9 {  |0 I5 g. d


1 I$ c' F: H' N1 Y

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


6 Y& P* F5 J! i; F+ r, v7 d  Z( T

0?.jpg

" A0 F2 ^) W: w- |4 z

% H$ n5 T! O. j+ {2 V# _- C) i

8 F9 P6 t% p: ^2 z: B! u

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


+ |8 @. e# u3 m# j! @0 `9 F( N* C

0?.jpg


- F0 u# t0 R7 V% G: w


# d, Z+ s8 ?' p2 d

. I3 t7 x! d$ E" L+ Y( G

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


2 Y6 I+ ~, Y+ C/ f6 y

' T8 x0 M" ?; ~, _+ N6 ?$ z

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


4 b# ?' t# S  Q/ _
: s. |: j3 k  N5 w. d, A# P) n
海量分析三技巧
- }2 s( G% s& {1 M' g7 }+ q
- w: k, J9 }5 y# v4 x& V5 l

0?.jpg


' c4 q& q: N% G- E% Y9 ?

) u$ ]* g/ I2 r. a, C9 T


+ O2 [4 \: l5 ^& B; j9 r

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

  z* b( z- Q3 l3 y


6 \) [1 C1 G  m; Y/ w( ]$ Y' ]

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

0 e; A9 E$ s: E1 Q/ X1 D) j

: A5 s+ p" A: o& V
        溯源分析      
海量分析三技巧
% h3 C" h. F' D/ k' H6 r

0?.jpg

( [! X; ?7 ~( \" h! b+ V

; N8 _- w9 t# J/ q3 H) `$ ?

〓 高维与降维打击

' _: `! J  @' d8 _% s" j


+ z, j: _- j& Q( b! A

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

4 b; ?% x1 x8 q; s


5 N9 z9 i0 d# y1 Q; i

〓 级联分析

8 R8 J/ [# x1 b/ K" ]" v, }3 A

2 b4 L. f' Y7 r6 Z* W; s

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


; s' n$ o0 I4 j


) X6 S( j. @2 z: E4 S, M

〓 逆向思维


' R# Z. {" O: v3 e  A

4 w+ L" v$ T4 q# |+ y

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

0 I; U. `. `' R, S. C


3 k/ \, t' D) k  _

        根因分析      
海量分析三技巧
3 c) R* l. \8 o

0?.jpg


! i6 P$ j- e% u$ F$ ~8 X9 J" a0 T

& q. B8 l2 F  y1 H, _
  • 用高层次的告警 收敛 低层次的告警

    # E3 Y3 w3 y" V  w
9 q7 k& ~. L) V; q3 B
* m0 g: j- U/ s2 L" J4 S! }! C

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

% p1 p# ~* @$ P, a" n/ A# J

- g; K+ ~* w- g) `3 d5 B; D% t. d# a

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

    / V7 R$ @3 c8 g; `8 u, w2 k

    8 }, g" `# a4 {' k# \" V) |) O: D
, M9 H9 C) R6 d  x

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

, i) G, p) J1 w7 W0 N, z" R

6 q  e# V( H& X4 |. Z9 e: V, Y

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

    / s  m2 _' F1 o; L* K( C" r
    * q8 A* g7 ?+ z: y
' P4 _$ R6 x; T7 D7 S. H! o

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

: i# q( o. r( c& k% u; V

; K" _) w' a3 ~
  • 用主动触发的活动 屏蔽 对象的告警:


    % w* d! ~1 ~" D$ {
% ], K! B* x1 Z- s. g
& ^( S6 }4 A( M, T" b9 E

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


) J  y& j2 i7 v: V+ T, a8 G. ^" O* c, v

' X% G+ P" p; Q6 u4 f2 A

        优选指标     
海量分析三技巧
8 G' ?( e7 \3 l+ r
/ j, H' C7 C' o; r; g% D

0?.jpg


$ B8 W5 \3 T7 N


: |  n2 q& U  |& Z

核心指标论


* e$ O( R3 g1 _8 g" }  R

2 X/ }' U) Z: y& R( Z* P9 q

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

5 A; b& h& l3 x. b5 @- u) [2 l4 b) |


0 }! k: r1 s. C+ u. ~

监控的相关性

; _# S0 Z  |6 e$ _5 T( b; @' d3 e

% Z8 w( g8 C: `) s. J" V% h( i

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

* D4 r' g- E5 s& V% O


1 U6 }$ l9 P; i+ I0 w: V" m

告警分级管理


/ V8 s) @2 y; Q


  A$ m& W# Q2 A

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


) y0 E- M/ h% J* k7 }( H  h, X, L

2 G5 Y4 v6 G% L7 Y2 I

降低流式监控的计算量


2 _6 [) y/ l6 R, Y

# R9 D. v# C: F' q2 C' W! f

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

6 E$ G* s* j- T  L7 f& R


5 L' e5 M, t7 C4 {4 s! i9 l

      用户舆情分析监控   
SNG织云监控系统
: d( }; B# ~$ ]* I# `7 z

0?.jpg

" m7 B/ E. X$ Y5 @- K! y3 q

/ C* U! h3 X- M: R  E

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


  I5 T- M; r' [/ w5 G6 A

  D% \  U7 N* D

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

% k" m1 e+ a3 |+ k& `" Y( r


- J1 z2 B3 c+ x9 m' Z' F" ?6 U$ ^" d3 g

   有策略更要有自动化   
SNG织云监控系统
8 w7 d0 K& M1 q( _/ e( j' ~: W

9 r' l( i& e" t% X$ ?% ~& u

0?.jpg

  t8 K, H; S* a0 {8 b  u

3 {. _9 K7 j1 w2 [) V

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


3 I8 H- e7 p" v1 w9 l8 Q4 f


0 s* ]: ^4 ^. p! h. n
精准试用的算法与策略
SNG织云监控系统

6 S! a( n$ H" K8 T" C* L# G5 S; O2 k
8 n+ {& F# ^* E9 R" q( ?

0?.jpg

. t2 }  L: q" P; v( P" F0 M

# b' S" l) I, c. j, b

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


- _+ c/ }5 ?  {3 o! q


1 K7 i& [$ v  l6 Q! B

常见业务监控图形与策略
SNG织云监控系统
3 W& R. v( r* X" B/ K

0?.jpg


" i2 ~% d. x. L6 o( c


0 Q) ]! l6 f, r" N0 o& y


  c) r7 m& o; [% q+ I: i4 ~6 |: M

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


6 R% v$ v* j5 z0 |/ @9 _

6 s% u; K. s6 F6 p% p$ r8 i: j

       案例:监控自愈      
SNG织云监控系统

) l* b, E: h! }4 _6 K4 V& h9 F6 r

0?.jpg

/ t5 `! ?. |/ g: T

5 K. ^2 I5 r3 }  j" b1 @8 X

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

3 j: v% O( A& Q3 F* m/ G' }1 p

, Y& d; C3 ]# _2 p8 Y2 d, J  J

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


/ u) x$ p( ?. |4 ~2 V7 |9 d

2 |3 [# t6 {, w

      常见的收敛算法   
SNG织云监控系统

: H9 n2 `/ I3 Y- O- e; u

0?.jpg


( @( ~/ Z9 a- {2 I9 C4 a1 f" M

9 L9 O; l' z6 @5 `

2 r2 T4 d7 G( _; s- K+ N% k

◇ 毛刺收敛


: c# j- e9 g$ n

! x: ?: }* Q/ {+ D. d; U+ c- T' _3 R

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


& @8 r, h% p- k, c4 y$ z: i0 |* |  V


8 f% Q' A/ u* i0 P

◇ 同类收敛


/ c4 J) R3 |8 o


4 T$ g& D7 d# a! e! d( F

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


5 {& H) j4 y( }) B3 y: B' S


; U5 ?$ R- M# u7 C

◇ 时间收敛


" k& M% t( ~, `" d5 T! t

* u3 f9 i0 w5 u" I. V

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


  Q3 g( v6 w' p


8 d+ Q, E9 U0 T: G

◇ 昼夜收敛

9 m: g; l( g. f6 g6 A


  |/ ~4 v* e6 l0 z

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


$ C% m: M0 t& \1 O; [& ]


2 U- a* S; h) _0 J, t" f( H

◇ 变更收敛


' I* P- c  y7 m" A' _; f# g

4 e) C" ~. E0 ?6 ~2 _

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

- U- p$ {# T5 f$ U& ^
5 _. Y4 y4 k' `
织云监控构建的质量体系
SNG织云监控系统

3 O) B' O0 `& ~: U" q( D

0?.jpg


  t$ f  ~/ v8 D$ [8 I

( V, d- d+ _% v


, X: M4 h% d0 k6 i7 c

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

; e: {7 E# A$ Q4 a) r2 r  c& [% B

; F. b  j4 Y  X+ i5 u* T! h
织云监控:质量体系  
SNG织云监控系统

0 m4 G& J2 N" c9 T0 K

0?.jpg


5 Z7 ]: H9 I& Q" H- }; [


8 X5 C0 b+ Z, I3 `8 k* a1 n' J

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

% k) y  {% Q1 z3 z0 P. B


# x8 ]- ^& }2 x* d) e, o( c

  • 监控能力

    5 T# a/ ]4 k' K" j8 `9 }( [6 y
: O. Q+ y: D( x- U

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


* }( [. [& v8 {# F


, ~' M% T3 z0 n6 z3 A# C, s' w

  • 业务可用性


    ; N) A1 ]* d( I5 f0 M0 n& \. I

    8 h0 Q( H3 D# W! }+ U
0 }/ C) S( d- Z, x

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

- ^+ M' a% W% T. `, S

. \7 P9 o4 ^7 e" K0 \4 p

  • 用户体验

    ) G# p! z6 x. k& _( v" X1 b# l0 h
    - ]9 C9 J$ D. j

, T$ T" s2 _5 N5 x6 r' O

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

& E  p8 i0 p+ b


1 o& O* s9 O# T' t9 v# a

  • 技术解决
    * V; `2 m9 y7 E+ ]* X1 l
; j5 x8 G6 |: p2 G; f
" D6 F4 z+ b* f
要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。
1 i1 e9 J; N; p


0 d& E* h- u8 t

  [) J8 B% m/ e3 Q

  • 统计分析


    ) O# V" _' ^/ S  B9 x9 ?" v7 |
* n# y6 q; ~7 h7 t( w

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

/ @: m5 |# a' ^7 x& k: t9 O


; [. v; K- [! ^5 t" I

持续改进

+ U9 P2 e+ @" `& I9 W: J  K

3 \+ u3 {9 g( r% U! d  R6 f

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

- z5 F+ \4 T" O" U

7 h8 x  d9 A% H

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

: G* R2 c: x" q% l, |5 D

    结语    
DevOps最后一棒
3 [9 f1 _8 G. G! r9 D
% f$ ~, }) {: O2 G3 |

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


% j4 p7 X5 i4 ~  D+ y5 C5 e8 a* {- u" Y
原创:梁定安" z; V- V) C& v; a5 D9 X" t; ^3 T4 v
3 F! W; z- y* q# A5 U$ K- K
2 H6 `* U# [' u4 f" g4 P

本版积分规则

购买ITIL 4中文教材及Foundation和中级过渡认证、DevOps专家认证、ITSS服务经理认证报名

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

Baidu

GMT+8, 2020-2-21 14:24 , Processed in 0.177346 second(s), 25 queries .

Powered by Discuz! X3.4 Licensed

© 2001-2017 Comsenz Inc.

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