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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

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

参加活动:0

组织活动:0

发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式 来自- 湖北武汉
本帖最后由 adminlily 于 2018-11-14 10:54 编辑
# O0 r! [; S% r: ?
. J/ H2 o. e& a# Y
    前言    
DevOps最后一棒

$ b) K4 y( O- z. ~! X" v4 A3 K: s- @1 s4 O. o# p/ ?

0?.jpg

5 O* V' r" q  T


8 e, c1 \0 E- K4 B6 z- ~& C$ C

) ^3 E& g0 J- m) P

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

  T, Q% n% W( O4 }7 Q

9 S3 X# I9 p; E; v& h* }, R

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

6 L3 H9 N+ m+ g# F2 t9 c


* T9 t. e' x1 U" v

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

# g7 V9 D) C1 F; s0 P. h

$ q) z/ H( w" ^4 z1 |
+ {' u3 Y8 N) `5 _9 @

0?.jpg


$ M% T! C* O2 Y' J$ Z* U4 Y

$ o) z% u4 k% C. G, q; Q

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


. H, D- K2 W8 S$ E, I

' z* T6 Y" y( ]* [1 u

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

+ G( ]5 E9 u: o

3 ]9 C, g3 g, c8 X( w

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


8 {- Y7 ~. X, I6 }$ u4 K


* r3 y/ z$ U# A: l

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

+ M9 y0 k. V( c4 U5 x  E- d2 x2 n


1 H  u0 m3 J: F  @

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


) W4 I& r/ H; p$ O& X5 B


6 C; I9 _0 A' W; q1 d

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


6 t+ M9 Z4 X6 }# j& @


$ ^, }8 L8 ^8 ^; ~. G3 v

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

( _9 ?. O# R0 \& v5 X  W

0?.jpg

( I$ e9 [% v8 ]/ Z; H3 g) E

' l% Y; q* A+ O7 J: D  Q: t

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


' ]8 r* h$ u1 G& l& I3 J

6 U* K) K( E7 o% h1 y9 o, h) X, s

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

* A! H% X1 M3 r5 P$ _  d, _


$ p/ _! u) i! F- P1 {. T

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

* G+ k3 E) V" |" v

0?.jpg

4 X1 x3 ~! z9 C

0 L+ v5 ]# V' ?' o# `+ Y( D

7 Q7 |3 ^7 G: i. b% K3 }1 W

〓 繁——简


( t( L/ g9 N0 H) Y- x, l

" z  j* z6 R9 V3 [

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

# c2 C% }$ w; N: `+ ?


$ Q+ a  z9 z; q

〓 泛——精


1 v) }  ]- _: A, T$ h, E, i

3 Z: A  }* N3 H4 {" J/ E

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


1 e  D7 _$ D: W  U3 C& T( c

. {8 U3 Y; J- {: j8 Z' @3 W

〓 乱——序


) P6 b3 N& e' P  ^" _' ^  B' h

, `" `! ?& k  H

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


% U  D  K1 `7 J" P) u* @% u9 u6 v5 W

; c( b9 r6 C0 C3 Y* X: W  Q# r

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

: x5 X$ {" W1 M# E3 j& t


4 y+ e9 ]/ s* a% u- G* \4 l

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

6 e, }$ Q' r+ z

0?.jpg

/ ?9 M" o2 \# p6 R


2 K+ q. Y9 z0 w5 n0 A

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

7 Q+ b4 N% w& {


. s) g4 q  \; N& y7 h0 i: R( ]9 F6 H

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

- B. s; D1 P  x9 B2 Z, o2 L; E


/ e$ {+ w' c7 p! d

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


$ ]+ P! @+ E+ K0 `


: j5 m% G9 i& U# u

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


* M0 |) T6 |0 a& _# N) P

2 @8 y$ h. O; x+ c! C* N4 C

☆ 低层次指标


6 n3 {& L' w. K1 `& b- X$ Z

, L1 ?+ R$ ^- l" j, D9 A; K3 I

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。
9 D( K5 C% U) {* V7 Z


& h0 N* u$ `( F! b* C


# ]* ^1 n1 J* ]

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

2 I2 ]' t4 ]. c0 ^- ~8 J


/ n# ?) m5 U. v& ]; Y8 K

☆ 高层次指标


3 _( O7 ?2 I7 M% m( H+ B


, I3 S( G3 s+ G0 @& ~

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


- ]8 ]2 T4 G% L* o' n8 `

2 A% e& W7 E; G( B6 T+ b, q

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


, p4 v7 n5 k/ v: ^

, s  p8 H; Y2 K' E  f% q% Y

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

8 |2 p( k) F' h* w. B+ k

5 s& v8 ~/ x* f

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


2 d* M+ i1 ^. W0 I, z, l

7 w+ p( O* Y' |8 o! c

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


( t- P! ]& t0 l

- x# ~. @+ N' Y, |

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

. R. E- e( o  M1 U# v

; G6 [6 l3 B. N

       监控的本质        
监控、告警与运维
/ D9 ]- M' j& a4 E  f

0?.jpg


2 |6 n2 g- B( w' q2 ^- H

6 q; W6 p8 F; h1 y( D8 u( K. c


* g- Q$ Q0 F4 T7 t+ ~/ R

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


3 q: L  L9 Z+ F3 A4 L! M


( B  K# n" v4 A5 J; y

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

* l0 G3 M/ L0 ?/ f7 }! x

+ V: F# B7 v' v& J1 o( c! m5 E
         误告警解决办法        
监控、告警与运维
& ^* p4 X- i: Z8 \( }) z

0?.jpg


3 s6 h: h2 }  V' f# `


  K8 [" S4 N5 o( ~2 c% }% r# P

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

- D1 c9 m9 F0 c" o% d& I" R; V3 }


9 V) u" f# f* z  e& o5 H0 h

◇ 关联分析


1 T- ]  W8 @3 n) R. s8 D+ T

- |) C2 ^. \) U# n

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

* ^6 c8 O6 t" D0 j+ G3 h& N8 z


: J8 F2 F% K3 S

◇ 无误告警

, P: a$ @. h  B8 U$ z+ t2 V7 _


. Q; l( q3 f1 J% \( Q8 Q$ ?- f

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


7 V; a# B/ Q0 L6 J. L3 k  Y5 q* C1 [

8 Y/ v0 o9 R- {1 P. K! d* L/ D

◇ 持续运营


( u0 G) }8 ?  l5 I6 J- |


& B  ?* e4 Z) w+ h8 k6 X

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


2 S4 W& L7 A9 ~3 Z

/ T) W( U& Y0 Z/ x# o% [7 ^

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


  F5 l2 y' D* Z- C


% z% j2 M# f- F8 i4 a$ ~) G

案例:海量数据分析思路
监控、告警与运维
) P* a( @; V* v: J3 r  A! n3 _
9 Q: _' w/ r9 z4 {

0?.jpg


3 _2 y5 N# ~3 n8 O7 y


4 A2 @6 s7 W8 V: A

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

: f1 s1 J# D9 E8 l6 H# ]
% p; L4 l' |/ ^2 h! l

0?.jpg


5 t. V% H. E" U


. k1 F1 I- g4 M8 y1 A9 G2 N

5 b& Y9 K4 \0 |3 S* `

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


% C' @% l1 z6 Y9 h
# y& B% ]5 J4 }( M4 \

0?.jpg


) y4 N, ]1 H% ^4 ?$ A

& r9 `0 t# w# I0 t3 o2 Z

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

2 U( t; \* i  x( }1 j' q0 a

0?.jpg

) I! p. S' `8 e' q. I6 M& P4 B

+ n* X, O1 ]2 v

' [5 @; U8 t4 L. X* X  ^

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

7 l& t: @& L/ O& Z

0?.jpg


( t) Q4 o! a: g. e8 s! _  z* g


: L2 f3 Q6 \' S! C8 m6 s# T0 R1 Z

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

6 Z+ `: j3 U  c& |$ @( n: @

0?.jpg


- b% G) I* X/ C4 h* N6 }- f


  j- L, }2 u5 e1 U4 c1 z4 V


- o* N* j( Y. V: h0 Z3 I  i! g

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


7 x& D7 Q9 \' v7 E/ w" `

0?.jpg


+ j) ^% b& n8 _8 t) s

) {! w) C3 k* g: V% q' G; L


. w. [0 {# r/ T3 Q( ^0 F

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

' y# m& W4 a  Z" _& \- L4 Z# E( E


- C. M, q" A) j; }5 I

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

+ ~3 C9 S+ z1 s; `4 v( y: D! J0 J
6 b- R% l; ]0 S$ x' x2 o( k% f
海量分析三技巧

: h# c1 }5 X# c9 u) n) R- Z1 P1 A7 I2 X0 K% H2 O' S- B

0?.jpg

' n6 U5 R% b3 L7 [) _7 j% K

2 e' x4 H/ F* Q


8 R& p" C7 R* h* s* h: {7 G; M9 @4 m1 E# Z

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

- {9 y) J; C4 A7 Q" x) w) W

- d2 z' Q' O6 n- l2 b; R4 u

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

) u) P" d2 a* Q4 ~5 l( S/ e

4 y# |5 t8 D/ f% Y
        溯源分析      
海量分析三技巧
, {" _) c; _* |1 N# ]9 e

0?.jpg

8 ?9 o8 a# {1 n* ?9 k7 x

( h" [; I; }" v# v9 J; B; o& |( }

〓 高维与降维打击

6 n# b( [9 @4 v$ Z. l% o" W


0 L  T! o2 G4 C! B' r5 ~

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

7 u# y/ S9 C; [9 X2 ?, A


/ Y# M- ?6 w0 ~, Y- h! u* D4 M' p

〓 级联分析


: Y: ^7 s' \/ b2 u, w$ ]# v- d0 w

# o, i. o. L. e5 u/ H

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

! t( h# p1 `; A5 C( X

  J' a& t; a6 N0 ~( Y

〓 逆向思维


: W! K  H  E( D4 ?) [& F2 g. q$ K

1 G2 `, T! F; L$ Y

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


- [9 ?$ ?6 \/ ]5 x


0 o# ^/ O* z) \6 X$ c8 ?

        根因分析      
海量分析三技巧

3 U, H! K' e8 k! w. L* i9 z

0?.jpg

& D. `$ E  }5 {

  T7 \" x7 c, B  _4 B; n( j  [
  • 用高层次的告警 收敛 低层次的告警

    ( g8 |$ B1 p: m  T: Q, D
6 ]6 l2 b, U" |# d
' I, t) f6 ?# D8 j

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


7 ^" }; j3 F# r2 q9 X% B


% _8 p  Z* U3 ^( ~. l% A! k) t

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


    ) |+ E# M- Y; T  ]0 ~

    5 I7 L! I3 B+ x) ]

# K- R/ e0 U8 A/ j

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

8 Q2 ?: ~# z. d8 F" n


9 e$ W& t8 E/ \/ ^3 s- Z

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

    / S8 o2 V8 ~6 ^5 E; y7 c

    : T$ z* o8 E0 U& v1 {; H% d" h

; ^  o; Y4 D3 j

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

! H) ^! D4 T! _+ b" R$ R% `  l6 c

6 |: E& s5 s/ E- ~
  • 用主动触发的活动 屏蔽 对象的告警:

    ) ]0 O: p" `% |! e

/ L% O. g* f2 `8 Y- J: i2 k* [

: V. J; J* x( m5 N/ G

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


; A) i" ?7 r( R

0 V! u) G: H1 h% j" w) F7 F

        优选指标     
海量分析三技巧
3 F1 P$ ~  ~% P9 i3 O( x* G
3 {3 ]# z, A! y& v; Q) G$ _

0?.jpg


% x% d0 u/ i, d- O3 A3 |


; {% r! e, @* G2 g& ~7 V: ^" E. f

核心指标论


3 r" C  f) W& b  o

6 g2 ~. |7 A9 O* M0 a' N/ h

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

+ n. m6 ]6 ~' K- y  }! l5 h' f: s$ o

2 F* f% u* `% L7 U

监控的相关性


/ _- t5 {8 l$ p) R9 S; ~0 P$ O


8 L2 t' y5 M  N; i8 c

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

) z, g0 k% z) z1 V3 A3 Z$ M

" }& ]6 d* v5 N  |' @

告警分级管理

6 s4 c  I7 d3 i! W1 E8 o- c8 k


8 ^1 d/ Z- f: F

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

+ g) V, u5 j' `: h' ~


7 g; A4 U$ }/ R& W9 R

降低流式监控的计算量

+ S$ e$ k5 b& c, O3 o- n# C, h3 j

  c+ w: m# N$ b

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


+ w" n4 N& Y' f5 d8 Z! b0 M$ P9 e

' _( ]7 a; k$ e5 Z9 L

      用户舆情分析监控   
SNG织云监控系统
- L5 G/ [) l8 p2 c. Z9 H0 ?( d

0?.jpg

0 c1 V+ h5 j* i8 a

" X& n. @: R1 I

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

+ e- Z& ~& i* v* |) K2 O/ F/ Z" s

# Y+ J: l2 i& `$ m4 B& X

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


# K. A2 P0 G/ g$ Y- t- y  w

) z" u& j: x& A! S  j" A

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

" q! D. T, l8 X4 f9 }" J6 P/ x
/ s7 Y( X* S! q+ q) ^. s

0?.jpg

. G5 s6 k' Z/ C8 W2 q4 i/ {


# i$ T# S" n1 l0 [

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

( v. c# h/ G* |


. U, A% e  L% S
精准试用的算法与策略
SNG织云监控系统

5 R# e5 |, i: w7 p! \* {" C- g# [

0?.jpg


2 \9 f% ^! F6 E" C


0 ^, Q3 F! s. u7 u1 t. s6 H1 k

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

. u1 ?3 m8 E" \1 J+ p4 I! J3 ?


0 z% m7 h7 W$ H  `

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

" [& U0 b0 c$ r: e  j% s; M

0?.jpg

# T9 ^* h1 a2 X( P

) {: |6 M0 q: X! m* _


: k8 A* g* a5 o2 m

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


  n0 O4 D$ T$ E

% X: |/ _1 H& p0 u7 d( F  j

       案例:监控自愈      
SNG织云监控系统
" E( \1 ]1 ]6 x) y) v

0?.jpg


& G0 ?1 k  r% h+ q# s


. v0 T; `; \) f) L$ u) i2 L

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

( f% V/ l3 \: X


  q6 \& `2 r0 \) `. @& i1 h

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


- ]0 T. B* A; {: K. s* i

  Z: H# c4 p; l7 u% c1 j

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

9 X& K: M7 a# u/ s

0?.jpg

$ d- `4 C' d7 I9 @# h! L


$ w1 Z3 J4 {9 \$ L

, w" w' x  d) t

◇ 毛刺收敛

& U' h$ E) Y) p/ N; C


% m( }: f3 v& T' T) p6 H6 i

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

$ s' O& w7 |; n- Q& ?9 }


4 t6 u/ B9 m% u/ }9 X# O

◇ 同类收敛


  i! l; V& Y  |- F( U

. @3 I$ [+ A% K5 ?

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

5 R) g8 y3 p1 ?


) A( K( }' v, U( d! @9 L

◇ 时间收敛

+ v6 N* ]: A( x3 c3 H1 P0 U

- j( d% Y: e- o6 p2 ?: u% K

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


& U- P2 g" [5 O  a, e8 i# {


2 Y/ W5 a1 M5 J

◇ 昼夜收敛

) C6 d' f# a- v- a  u) K( F

6 e0 p( V3 u3 N5 G

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

0 ]5 u4 N) z& z' ]2 R


) {9 l) d6 i$ R- |" s' R

◇ 变更收敛


+ L( V0 \  r) q- j' q: p. a# @" ^# d


4 @6 l3 m+ Y& d; @- T4 `

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


. r% r; X+ x$ r2 z* u

7 ~5 B& s* ?4 j0 F
织云监控构建的质量体系
SNG织云监控系统

- N0 ]6 {2 \/ N9 h

0?.jpg

7 s: t9 N, J9 J8 Z


, D6 Y, A  C; o2 `  F

) j5 I4 }4 }: w& \, c

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


6 J0 k" l" S" @3 w* ~


3 [8 m% w4 ~( u& [0 H9 k
织云监控:质量体系  
SNG织云监控系统

( J! M* `% k9 `5 O) T, {1 R4 k. _

0?.jpg

2 n0 j0 x, W& W% K; z

- H4 K7 I" K9 z$ c3 S/ A

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

$ Z2 Q3 O# p; b' ^; l4 U


5 E9 q5 `2 r& R' L$ |- e5 ~

  • 监控能力


    0 R9 M( r: N' s3 w! o) V

% j- v/ E! x' X6 ~; z' l. R5 {

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


/ F4 W$ x- N+ L. D


2 }6 X& @" `% S& n2 j2 h3 X

  • 业务可用性

    4 J! d# I$ C5 d2 J; f$ f
    & m9 N+ t# V. \9 N% s# u

: ]  V+ p" w% \4 S

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


; M' Z% C9 _( M# E* D6 Z8 {

3 m& S1 I6 ]  n# c3 i' v1 ^

  • 用户体验


    / g( X( l4 `# O: A! o1 M
    1 i# ]2 {9 b" V) _8 Z, G( @* C
1 g% S1 l/ Q& N

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


( q9 j% D0 U5 d4 A% [7 f0 Y


( K( U! ?# r# A+ i: X& I' D# x

  • 技术解决
    2 {1 z" I* u# a0 f  }
: |7 f  w9 d/ }3 f) j2 R5 p1 r

% l8 a' {: l) X9 N0 O要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。
; q; o7 Y) P& N) _* S2 k8 ]& Y/ k7 O

7 _& w, `0 A7 b6 q" R% o, {4 ?


2 i5 a5 f$ u. A9 d8 e$ Y" \

  • 统计分析

    # P' ^" I/ ]+ {! I; {' F3 O7 S

7 [5 M8 F- x" k! Z, l4 M) {

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


7 H; n/ w3 `8 L* h$ U" ?' b& `

5 B0 F, G$ Q! a

持续改进


/ ^$ L0 I! M% q) \6 @


4 Q* m: |' u- J: ^  j

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


* ?$ t* ?! D1 U# c! |

5 `) N# W0 d" [

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

: m; \+ X& t6 }  S. t

    结语    
DevOps最后一棒
$ O5 w- W4 t2 }7 `1 t* G& `( r

4 v+ w$ P2 T  r; ~

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


5 _9 h$ r/ j5 l7 W4 }3 R- S' h/ Z* g9 a3 p# r2 ?" x
原创:梁定安
3 u6 j- B( h9 U% Z# ^  M

) J( i+ p+ M' j$ m4 F/ J
. `* t/ L- }# r2 ]

本版积分规则

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

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

Baidu

GMT+8, 2019-3-20 03:30 , Processed in 0.264992 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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