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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 2446|回复: 0

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

[复制链接]
发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-14 10:54 编辑
( X  k# U9 q# z3 A& v' l
5 j% B8 S' P9 u
    前言    
DevOps最后一棒

, [; X7 `% N! S6 Q# g* o8 B5 F5 _% c) V9 N0 F6 W* C

0?.jpg


9 L1 z+ s' U5 m# @2 z* q


) R6 d' t% b7 n+ a- K. F


3 a$ X% |8 _/ z! ^9 ^! C

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

# F" s# M5 ^- ?( H

+ T+ L7 A2 r/ g1 S

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


6 U: P3 F3 x# I$ \0 ^" l" U! f

* @0 u  B) G; \1 ]1 X

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

. R" t4 x; o) _

$ L6 \: W: Z: P1 }( _! e$ w  i  v' k
! n4 `# m* L  u* p4 l. e

0?.jpg

' M5 j! D) E) m( I" J

: S  r! R8 e' D; J1 H- E; C

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


8 ^- H2 j3 }) Y" J' L- K5 v6 [

9 H; Q5 c) Y% c* L6 {

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

: x! i+ e/ B& Z8 Q. V& u


( ]2 A- i, b  P" l

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


" B/ W4 u% a$ W  Y. _1 k6 u; W' \1 ]

) x# I4 {' q* F0 f8 I9 C

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

4 P  E# V' `( u, X$ s2 C2 J1 d% [

' C- m8 B* S1 n. K# v$ V

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

- N' r+ G! P" s$ b/ M6 c! g


) |7 C- r6 o' h

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


% C1 }$ V, y" J4 Q( J

0 ?4 c1 {3 P" r0 ^, e7 {- f

      全面的监控点      
监控、告警与运维
- v3 `' o! F# @# B0 |8 m

0?.jpg


7 A( {: k5 L6 |9 \

% b( h& m# [* ]/ V& n$ E

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


9 w" I% |! i/ x  @0 T3 \

6 ~4 x% e8 k7 V9 k2 L/ r* Z/ e( l) z  ~

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

" }7 b$ k4 X8 P! I3 o: g: a  t


$ K. `. L# I( t: H: A7 v) U

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

: z: k3 z# ], W

0?.jpg


: J5 Q. X! G/ a5 C$ _  o) Z' w, J


' j5 s- O& z  Z; J; a' G3 D1 ]

8 U# J0 c: V+ a: V1 y4 H& a

〓 繁——简


$ e. l  D) t' A$ z; n, D- T

% u9 x  }. R) _: v

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

; T% p" b5 ^# K  N8 p

, v, a- I2 y. f3 s' I- {4 K6 F

〓 泛——精

& n* g3 w) R5 L; q


( V: A: j0 J4 U/ g2 \1 i+ W5 o

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

- _7 u0 j8 v" ?: B


1 I% J: A( d+ }  {

〓 乱——序

$ s- E9 x/ z% e/ {  h

3 q: }# L) F1 j' T: J2 U6 k2 e

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


1 q# M4 g1 ~) K% h( ~5 y8 H


- v% s, N7 V6 a8 i

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

; x- r9 X: X: N* B


& \4 ?" w6 D% q( X( \  B& h- O

监控对象与度量指标
监控、告警与运维
9 J7 Q  p- |; R% w0 K4 s* \" e

0?.jpg

* |2 X  l, x& G7 q


) e* Y& P; n+ @( E) O

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


/ ~) B% `& F3 Y0 M

/ s& v) S0 w+ Y* B. c. ]

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


, p- G4 S* \8 c9 P  p2 @9 q

2 |0 e% K( i0 T6 k

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

: z9 A: Q" a  u


% h9 u2 K" \* _  [2 ~

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


4 D2 K5 W! @) e7 M7 ]& n


0 S5 n, |6 |" b& A6 }+ I7 N

☆ 低层次指标


% p6 s; F) M& J% ?7 u5 t9 u% u


9 B1 t' B4 V& @2 I) Y

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。7 Z& t- z; N+ w' f/ K. Z


6 s9 [) H0 `" R: h


7 S: [% K$ Y7 j3 v# m# o. o2 Q

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


0 _3 y) n! c2 I7 l$ |


( {3 B* V% d- d* a

☆ 高层次指标

! Y6 t6 i. \7 s0 m2 }

/ ~4 N# ~/ ?& f. ^( N9 R

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

/ M  p5 x+ k( W5 S" h2 m


& F1 J/ Q. r9 m5 w& @

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


" k  R. [" C# P7 ]* G( P+ F


) }6 A- ~8 c$ D9 w; s' i( I

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


/ x: J" Z6 v( M8 y5 s" m

3 Q1 \; q( |$ |

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

0 p3 u9 ~5 l, A/ X0 k

: Q; i) o  I/ I* n2 T$ R

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

: q1 e3 P/ v9 R1 R

$ e3 h8 t: I1 u% N  s0 l

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

1 c' d, b! J3 K+ C

; T" E/ P" W6 y+ p

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

6 A8 G6 m6 ~3 M2 Y- @

0?.jpg

8 i- _6 u8 ^$ B2 s

5 v) T: u* X/ q$ e: v* t. I& W

* Y& f, M0 ]& W3 D: ~& V

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

* U6 B4 q! {. {4 R( f


2 J* P- s# @5 v! s1 I1 b

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

6 l- N1 ^$ D9 ^7 p0 m: p

! j% p+ T: {# i/ c
         误告警解决办法        
监控、告警与运维

$ P7 G9 A. e' M1 x- y: O

0?.jpg

+ D3 y" v( r! N% C' _# B+ j

8 z1 z% m: e0 N; y# g* b' R. n; h

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


, @( D$ Q5 t% g7 p, }


6 }8 H- p$ W) y# T

◇ 关联分析

) z& s1 J# g9 y/ ~: a5 p: w2 @$ e- M


& t' \) ]# i% V7 a: i+ E7 H" L

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


3 i4 r& P5 @$ K9 @4 z& p

9 h% l4 j  v: j5 y% h, z; b) r

◇ 无误告警


0 K! h$ t+ g" H- Y2 c: j


2 N- H  ?$ ^6 J7 w! e( S

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


$ y& [, A% {& C

# Y% C* d/ M+ D  [' S- d# N$ y

◇ 持续运营

1 z; S, n% w7 q


9 c6 J' B; s6 q1 N

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


! X% Y/ D, S# r


; _, T5 _* |1 ^' k6 ?- m

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


+ S: O/ R6 T% ?


  c# o" ]+ D+ p- \

案例:海量数据分析思路
监控、告警与运维
4 d* v: I8 F1 w& ], H' |3 ~6 g
5 e1 `' ]: M' v

0?.jpg

5 `$ C% S9 r. R


% ]0 m% z# R" X4 l  R) N/ T* ^( A

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


3 `! w1 h: n6 v
! u/ y; o" f) H) |, W9 q* [3 I) t/ m! ?

0?.jpg

& L# z4 j- f0 C) }1 E+ N7 K

- D- `, b) X; K2 ^: c


( z, o. {! h$ J; ^

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

& y  `+ ]  W9 n; B

" K% z% ~; |7 p* a4 ?% b

0?.jpg

* m6 Y6 {8 _- Z/ i& T


* J2 Q7 W( D4 l+ F4 @; ]

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


& ~( P$ e) H; Z& a) l

0?.jpg

& d! [2 ~+ ]  ]8 y1 s

0 R, s8 C$ }) x  _, S& t% j* }

+ i; y8 V% O) f

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


2 r2 Z- Y0 x$ K# g* ?7 C' @

0?.jpg


" G1 k5 q- b4 V5 ]" Y2 Z1 ]& i* _2 I

: z7 s4 s3 P& f2 L. j

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

% Y1 O3 q0 K. [1 ^2 q3 j

0?.jpg


+ J7 o  B: {; d) I2 k

% @0 t1 R3 @7 o2 i


, r6 X& w0 X0 N6 u- |7 y5 Z

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


* D/ ]! B7 ]# k0 T  n

0?.jpg

/ y% X9 I5 c1 U


* Z  g( g, s3 s$ f  @

: _  U+ w' A% A, U

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

! u$ T7 g, ^; U9 g3 I4 t


! |: ~. w: N9 T/ w

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

* q3 U6 P5 B- t# y  E
: z7 Y4 v8 g: _$ Z4 D7 Q# S
海量分析三技巧

5 {# c0 p5 g& t/ V2 }0 X( e1 a8 p. ]

0?.jpg


  `  d& Z0 i* S# ?/ x( D

' }! l) _/ E7 v6 ?# {4 o

1 h3 w7 N1 K8 ?) G7 ?" j3 h8 P

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


8 D8 f1 L( i- l/ C4 U* K! T8 s7 v

. G& e' L: m: P

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

) Z9 h! `* |( t7 _" ]$ h  w


8 ^: d+ h: X' \
        溯源分析      
海量分析三技巧

* b" ]5 d! |- R% ^4 D

0?.jpg


+ j* o$ m+ a% T4 e; Z

/ J8 s' Q$ s3 }; u0 U

〓 高维与降维打击


! m3 r, P3 y4 [. C  Q


# a& P6 ~, T8 _& [& D

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

: n% E2 f, }$ a3 Y0 V


3 ?; v# D, J# F) N3 O

〓 级联分析

- U8 m( a) A' S  l% X, h: q


% }1 A* j' ?& g7 M

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

$ p* P! p* \* ~3 C) L


: V: A7 E! V) d0 @/ a3 n

〓 逆向思维

7 q7 N+ `% J5 q, d- e


6 J2 J8 ^% G/ f

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

7 H1 q( U4 C# P& u1 e

3 \7 w; O3 I. O

        根因分析      
海量分析三技巧
9 Y3 x1 e) q$ q! O: V

0?.jpg


0 Y2 g# F6 i; I5 F. V. n9 u


8 A0 S( J* c6 q& }7 d
  • 用高层次的告警 收敛 低层次的告警


    * E  A; G( H+ Y

' P8 ]% D9 Y+ t" m+ l/ B
. k2 a) B. y7 u7 K* W" Q8 f0 ?

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


7 m, t0 c0 @$ |8 e: R


, ]2 Q/ j' G1 q! _( d

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


    , |% ?: h' m& y( m5 {7 {; j% @

    * R, G+ V2 R+ `

' w6 H, j! N* ]

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


( X% U& r" f# w' o4 E  Z1 m+ m0 d* ^" x


5 u( g6 _. i7 ]5 C

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


    1 Z# Y$ `3 ]$ ~# e. Z% Y/ s' r* Q) F
    ! Y! W$ o* W% r

* ]/ c2 g5 U' i7 i- K

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


; C' N% q  Q" U


/ \0 B* f  @) t3 @9 p, O# t' ?) j
  • 用主动触发的活动 屏蔽 对象的告警:


    & @" V& x2 n7 x9 Y! ?* x

8 ~( }! O# B+ I4 _' z& M
, ?% a9 H/ P5 _1 R/ B

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

9 @, ]( Z( G4 U6 B, {! [* ~

% n  r9 ~2 \5 M  k

        优选指标     
海量分析三技巧
! l4 G% j% n" [

; W2 K& S3 V1 E' r) c8 ]+ M& _

0?.jpg

4 M: J7 b) h7 W- g7 K


/ O7 \7 y: \: O; w

核心指标论

0 o! w$ G6 {4 }4 r0 ^' B- g* F


% p: ~* C' j" E4 W2 U# m2 k

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


4 }, ^5 a" @4 P: D

+ x4 ?* D6 ~. o# f' z

监控的相关性


8 I: j7 _. R2 a1 o


1 i/ g; B+ ?, z8 u) m+ p' ?

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

. i5 i1 S1 o7 r


4 X! L* |0 D6 }* l" \4 L' \* q: W

告警分级管理


2 p% T. X7 e2 V2 H' c/ q& _

. {( `( J9 c6 C! n

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


5 V  \& Q8 ?; f* G. c7 J

/ [9 o: E! a$ Y9 N5 {0 y

降低流式监控的计算量


1 w. Y' P7 ?) t: Y4 a/ @0 J


! \1 s# i* z8 J4 T

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

: ~( V( r% c) a+ I" Y5 c


. u# Q9 f) C9 T% S% h  M

      用户舆情分析监控   
SNG织云监控系统

5 X/ B- m8 J% }8 |! h

0?.jpg


9 G. I9 ^, n" u* j5 j6 S


6 M0 W2 N0 Z% d

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

# `7 R. D' W# D

; Q6 E3 ~. `* E: T

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


9 n8 O& s. u8 c/ h5 S

* M4 T" _1 W" h# w3 E: g

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

# k9 _( r7 E; P5 H, Z+ Z

9 Y" b! [$ k% Y& ~. {' U

0?.jpg

7 Q4 l/ P: w3 ]8 L- L


% a6 l) R, u4 y1 h7 |

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

. _1 Q3 ?/ u2 k! _8 D- A2 O4 J8 `7 @

0 p; ?; {5 @% R9 Q- l* U$ o
精准试用的算法与策略
SNG织云监控系统

9 [% q( ^( v# L3 t% V4 ~; m0 O! N# C5 a5 K5 ]) @0 r4 Z

0?.jpg


) o4 ~% v9 h. s6 r3 A


7 C' k4 n0 U( H8 I; b$ B

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


; f% j6 [3 `( B

2 q% z2 U4 {  j$ H

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

' X& B( D7 s/ B" Y6 O7 n' |

0?.jpg


* v4 M" C1 ~3 H: u0 h- U; X


4 ^: b+ W, k( }4 R# o* y3 D

6 N  I, k+ h& z" c& W- Z' U

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


& x' v: C* L  R, D, g  I3 n

  r7 P6 i# {- ~! R% ]0 e

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

6 ]) c& d1 l2 Y: Z$ a0 O* d

0?.jpg

$ h* Y0 r) ?# g


7 F  z4 L1 w$ x0 `+ F  ]. T

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


# P4 M* |1 j$ I4 N( K

4 s6 V) Z5 O8 X2 @7 j

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


* w8 z5 m8 b" {0 L7 l


$ C  {3 A0 r5 L& N6 H( l$ g

      常见的收敛算法   
SNG织云监控系统
2 f" M7 V+ {7 Z  z$ T* ^

0?.jpg


6 @, k7 u! W2 G3 m  H, ~. J

4 R0 m  R0 h8 D$ _0 n

- u; q# R  `. Y" ]* t" R- a

◇ 毛刺收敛

3 n8 T3 i( e% \9 P7 r# M

$ n, {7 i# C7 Z7 e& C

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


( g$ k, t# }5 p5 A1 g

, e! H/ r. C, q: L9 y

◇ 同类收敛


& L" p# Z+ V, J% S/ O$ ]$ N

7 [# Z1 |+ k9 h

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

  k3 I$ J) d8 f+ r# E# e

# m* H: }8 q+ u

◇ 时间收敛


! M! v5 Z2 e7 g5 ~- K3 h

" L' {4 V: i; }9 `+ k, Y8 D) L4 ^

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

) f- j$ o2 V. P& ~, i) @


6 E0 K6 G, a* G% y  Z/ q1 K8 S& L/ W

◇ 昼夜收敛


/ a7 C. c% i7 x: H2 d, ^7 P


  ?/ q7 `) s- L- I: ~1 @/ g3 ?

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

) ]$ i  Z8 _. ^


& Q4 Z- A' D8 N3 `5 n1 y

◇ 变更收敛


  I1 V; W2 m1 {8 I* H


9 ~. ~0 }* [! ~  `4 C+ L- f2 W- I

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

6 Z7 _# R+ ~, w3 q" S( S5 Q3 S
% y9 w# v' n' y3 f; o7 k& U
织云监控构建的质量体系
SNG织云监控系统
- L% x3 b' \' Z$ p

0?.jpg


; ^7 ?6 @) t# w0 f( p: U


9 k# k2 g1 O; |( s, W' T& L/ H


  l! v* B% [% B7 [* d1 ~; w

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


; c" i* ?7 w, S: I% V# @6 K


9 ]( k* C3 o, u- w7 L
织云监控:质量体系  
SNG织云监控系统
1 [4 _( T8 X- n3 N2 X

0?.jpg

3 k& y( I8 E8 O7 D7 R8 S: r& @


9 h6 e( X" @  V; Q, g$ E& `3 D- r6 E& q

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

' b: R/ J0 ~. g( ^; j


1 e2 n7 c5 N& D9 ]

  • 监控能力

    7 e/ }# H; x0 v) V( n
- w  ?/ W; P* v+ e! b+ B1 i

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


9 C5 j$ H0 R7 d) Q) z. p# A6 N

9 u3 {% `( |8 i: r- D+ s) F3 J

  • 业务可用性


    % _  \7 i, o" k0 {

    , }  f0 s- A, J$ F; g+ z& Y- Y4 h
# |; P8 D$ G. g% Q, j; I

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

! n" s4 n$ R6 x* z6 S


( l  C* ]1 S; P  }

  • 用户体验


    8 v' ^% _* l' p0 A

    # v7 q' g% y0 N5 `

: J* y: ?: ~7 \5 ^& e5 Y

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

% u* W5 V: j+ q% c' q/ r


* Y2 Z  R0 A1 r/ F( E# b

  • 技术解决( \& z3 F' [& h8 i6 |: f* V
: S: @5 e3 ~) c# X' |! a1 Q9 h
% u: j) _. {, l" i8 A) r% d
要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。
  R( Z1 C9 A" u1 M


% U+ S6 t% ?# u, N9 A  R


7 L0 h' a) ]/ x

  • 统计分析

    ! j- M9 [1 v8 U; E) w4 v6 U
/ @" X# ^" a  x

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

+ T) V! l+ m1 z& H


" d$ Z0 |; l! U2 c8 E8 T

持续改进

4 e5 Y* g$ v8 E! L+ C: H


: e7 p. o/ F5 w

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


, G! {4 U. j2 }% M

  e* J  [. \  k- i2 y' B4 n. `

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


  P; O% s+ C, X) k5 M

    结语    
DevOps最后一棒
8 i. i$ k* C# |* [8 j) j

4 ]3 w% e4 ~" ~( W4 d

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


5 O$ j6 u; R- @. p3 E/ M0 m( M3 M4 X7 E0 Z% h4 n
原创:梁定安
$ K9 w) d& e! b: S( H
! m' Y( ~/ O# n( C0 \

0 p& u& j  Z; d! ?) [& r' E




上一篇: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-8-6 08:04 , Processed in 0.136041 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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