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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

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

参加活动:0

组织活动:0

发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式 来自- 湖北武汉
本帖最后由 adminlily 于 2018-11-14 10:54 编辑
- L  U6 D+ c! u+ ^' U5 _; {, L
2 `$ Q& y8 Y, m" A3 R9 T3 J1 @
    前言    
DevOps最后一棒
9 m4 W) x/ r* O

) T5 _/ u, V7 @) J

0?.jpg

% [. j: x, v& l1 W0 ^' }


" K1 G/ q% o3 ^6 \6 P  r* N! A


- M# a. E( C2 k/ v+ t) V

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


1 T6 [# X. ?0 w- g1 h


5 O: ~" F' Z; F

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


  m7 K% E' w" P" A$ I$ h


4 g' n+ f4 ~" u" H5 \5 k* @' ]

持续反馈于运维的理解
监控、告警与运维
1 S/ A# c" M4 e: F

$ C, t! Y# v0 F" {6 h! K  j. p+ I

; ~! Q* N# u# a: F8 f

0?.jpg

# w& r: B" `7 ?1 D. S4 |- _

6 m9 U: E" B+ ^9 }# x1 E# `

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

" m% L$ G# R5 {2 t& m

3 m% v& B- l( w# Z3 T; u

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

# u0 s% b8 P& {- e2 v2 {

7 G! i4 o" L- t4 ^; j2 x

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


: _* j. t7 X$ Z: M- s& i( n


7 x7 {) x' F  W- \2 j$ Y4 A

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

! N4 S( I: `( Q. g* A) U) @9 p

9 \$ H( f! Z! W) q7 {! x0 w

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


8 X1 U3 k' n+ V* S


# S. Y4 B" ~# N; A/ q# g& \

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

' t6 @" |3 j8 N; q, D

: M) ?8 i; y$ |" O/ a7 A9 `* v

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

4 a) x  F; q5 i5 A$ H( D( [

0?.jpg

, j: y" P  b; h7 r8 M! i8 a, y  y/ e


" q3 U9 m. l6 V9 l4 L2 t

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

# d4 w; _% L( M4 h5 v+ l+ l

* S* T5 {! T4 h4 c

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


! p! K4 }3 t  ^3 |; X


, e* N$ r# U/ y

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

- w$ N0 }. s# g) H! A

0?.jpg


" a4 Q* ^" v" v2 U+ e2 c


8 N! g& c- X. C9 \4 l( s& Z1 c

* m$ Y2 b! v4 ^! K

〓 繁——简


! v& O3 `  D- z2 M5 x" X. [


' }! E  h5 I7 [( u4 z5 Q

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


  G  Z3 D9 P9 Y8 ~% T( y


! K( \& P/ d" g$ o% ^2 q% _4 r

〓 泛——精


/ W8 @8 @5 h+ T; d' m/ z1 ^


" }& [* m% O$ o% @

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

7 M: C: i0 q3 Z* t2 d% w4 o" I  y4 Z1 A


% a% F3 r5 |$ x6 c6 {

〓 乱——序


7 L. O* ~1 j$ N5 L$ t+ E+ P


+ ~. T3 Y5 M) L3 \

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


( h5 H2 y; z: D( f: J* P: j


7 [! m( i4 Y5 [; [3 S2 J

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


" o. {& T$ z4 C0 H$ o6 U. v, T


8 M4 w0 m# j) H

监控对象与度量指标
监控、告警与运维
' T# i* b3 R! J2 l8 f

0?.jpg


/ _% _+ K% b* v$ p' m


# w! w0 X' v7 ^8 N0 A

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

! N' Z3 l: c, v. }2 m


% `" R3 f  J- Q- j

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


- u% r3 ?3 D, G8 a/ I  [


0 j+ \1 v& W% ]: {4 W& i' j

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


. F0 P( b3 B  k* `) C" u& z

8 \+ t  r% e0 ]3 I$ G

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

6 z) ], b* X7 F& |


4 |4 h- W! r0 j7 B

☆ 低层次指标


' |" I: ^* S8 y" B" x2 s, q

! n' m+ J- g4 I

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。6 A$ a. ]: N4 f; P3 v0 S1 R' U

7 s9 G) v5 C4 i9 l' Q3 m" c! U


0 }# j+ H! B- F3 u

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


! I9 X8 s0 ]4 b3 ?" `

2 _' ~  }6 Q9 B4 u9 p; j: L9 w

☆ 高层次指标


& \* q7 N5 F9 R' v6 f


: N  D: L3 I& S+ L4 [/ i9 D. Y

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

7 B# Q' G6 A2 ~7 E


* B, Y) J/ z3 A1 R2 y' V# D) C" A

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


  ^% O' ~# ?+ Z/ T

6 |5 J( `* e  k( X7 s

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

$ q+ r& n/ u8 \


" _4 j3 a5 A  i# ~1 ^1 S

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

, j  ^1 n. P4 V5 ]9 o+ F3 @

7 G, T3 b0 r2 h  d8 d

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


" Y+ I) `' ]$ B8 l

# ~2 G  `7 R- K3 B3 v& |, u6 T

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


- n1 t/ y) V% W3 I% f8 a


' l( O7 t$ @) f

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

: Y* p6 Y2 j- g/ l( g) U. {

0?.jpg

$ e( K2 j% x6 P

- J6 y* x0 d1 H% ]0 ~

* A7 M; f: X3 [) {* g! |

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


' r6 U3 ?) K8 e) Y6 {9 ^

  K6 r$ m) V5 m, k7 E

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

$ _% D" q6 P, S3 R1 L


8 v0 k8 V0 [0 I1 B& s
         误告警解决办法        
监控、告警与运维
/ Q- L% x1 S7 S& o1 S; _- r+ m  D

0?.jpg


! Y3 W6 ?% O' \1 t+ a

4 B$ `5 g+ ~+ d# W

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

5 R2 f7 a+ a9 j

; R4 e0 D4 O7 {: b( m4 c

◇ 关联分析


& m. L# ?4 v* x( l8 Z+ H, j

6 B2 m( x. ]9 _

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


4 e) e( D- I* _) j


* j: A& t! w: m: |1 q

◇ 无误告警

/ \* U. B  d# B# f6 i' k- u% b% W


4 M  o( O9 o' V* U

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


" y; z# h) k" r, b

4 c' H1 x* B  M. ?1 _. u

◇ 持续运营

) O. m7 ]& M2 ^

4 b5 F5 m# r5 R# K) {/ T

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

4 s4 s. T! C+ e& |


6 y0 C2 {1 M5 U  N

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

# r  I) w1 k, T0 S. d6 M) I& U! N

+ c$ f* P: t% F, w& v2 x" e

案例:海量数据分析思路
监控、告警与运维

) |$ x& f( s) O4 L  F
' N$ G/ s8 E# F, }5 b( ]

0?.jpg

5 y& ~: Q" T- D  X/ g. m2 u% a

- M" F/ g' q& x( d( r/ H3 R$ l+ I

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

0 O# {3 [$ h+ D  ?  W" L

  m# a. J* i; y( {% _( i/ m* i. n- s

0?.jpg

& T4 V7 E$ `+ K% t8 [

  W: o" k! ]9 {  f9 h" \8 X6 X) A/ j


% e, d. L& z0 X" R( [

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


# ^+ V' p" d/ ~$ I6 r$ G

  t1 F) `3 N/ t, F/ [

0?.jpg


# x, M( z. O0 }  ?


8 _, G, D5 W  j/ C- `  K& k0 z9 S

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


% p- W, }2 j" N. U4 l

0?.jpg

! ?1 ^& a* L# l: H5 i" T7 Z

, t! C: d: M1 L: U9 l1 B4 N

$ C" b) P2 K) H+ |  S

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

7 ?, h5 L, y$ D+ m. m) P4 Z" \, M

0?.jpg


/ X- j6 W8 K$ e; R& |


. @. \. L- ~; C- ~' H; ^

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


, E& T( Y; n" U1 d" Z( D/ m7 s7 ]

0?.jpg

8 z% d( e4 ~" w- m8 C% K: g3 U7 D

" a+ o% g' b# L6 k5 X

; u" H! f& \5 K3 M

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


5 [7 }1 p; F% z4 U* C/ h

0?.jpg

0 g" y" {6 @- m$ V& r4 D& T

) S# d% C7 {5 N" l* l( [0 E


" Y8 Q0 H0 F8 M1 ~2 s1 B' @

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

( B: Z: \! K" O7 }: r

! i; z3 S$ c0 t

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


/ C5 |5 M: g# M5 }; ]; i" I" V# P1 v- q: V; K# Y
海量分析三技巧

; ?: Z+ ], o0 s( J# p# S: @8 D# q" }7 W1 a, J  J

0?.jpg

( T  x( p( _$ y0 M

" o+ z: }5 v% N# e


' R5 j7 `- W- n& [$ h

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

* ]/ p% q! \( v1 N/ ~/ O+ ^


# d/ L0 t6 a* C& B

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

, v. s8 Q1 I* Y( N$ {" a


+ n" i1 N+ }+ z6 n9 J3 _: b
        溯源分析      
海量分析三技巧
6 X5 V6 q; c6 j

0?.jpg


# t1 h5 P; Q7 Q8 m+ d8 F  o


" C$ B% O9 u' q* h# S, l

〓 高维与降维打击

2 c8 c) c) Z; |: c, K+ l& J5 i

3 \& g. x" c% E( F

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


% l# W4 [5 X$ b) g

4 S+ D9 H7 S, i/ u- C3 o

〓 级联分析

/ R" F1 e6 b" j  L2 U

1 Y+ V! ]5 Y/ q. d$ i9 H

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


, d% W8 m$ g! x0 q9 Q


# I% D- m9 x4 H2 K) X2 ~6 @) k/ j: z

〓 逆向思维

) q  N" n3 @; A$ y) A6 X7 ]! y  K8 L


( j( V4 Y0 }5 T- E0 R% o

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


0 W4 V7 J/ h+ P6 n' @& b


/ i9 L' q0 T* t; E9 |

        根因分析      
海量分析三技巧

8 z. @0 F" e  S

0?.jpg

1 X/ i( x" g- R; o4 {

* B, |4 s5 ]3 c* E5 U# z; i
  • 用高层次的告警 收敛 低层次的告警

    , _  V; \4 w& J

/ g3 N7 M# @- F" [, D1 R4 q8 r
7 M9 r! Q/ B5 }+ M( @3 ~' D

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

7 X0 U% n) v2 l) w8 B


: Z- Z5 X7 ?6 I) m- z

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


    " x6 r, k, l0 U* o: W4 W& C# {
    7 I" \7 I( S: n' J& {3 R
, B' u2 x/ M! H5 q

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

# _5 K# S/ {: Z# }

+ w6 I" Z9 E& p6 K$ n; M' C  n

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


    7 T% |7 f/ z1 w* i  s, H# K
    $ v1 }1 y! u7 H) s2 m: z
! Z4 j" J& |4 \, m( W

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


, h# _5 X7 A. }' K$ A$ I: `


, ?9 i" ?4 k( J7 }' E  h4 D' F
  • 用主动触发的活动 屏蔽 对象的告警:

    & `; e2 Q9 X3 V
0 |# J  r' a  _
$ B- w2 b' M1 x: h& r% x

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


1 E8 v- |# d0 T


  t' h1 Y# j4 Z5 c' F9 I  F/ G

        优选指标     
海量分析三技巧
" x! s6 w" u6 ~1 o, a
1 l! s! w6 L6 D

0?.jpg


+ `. e# D5 P# B


0 }& m8 i! S3 t

核心指标论


# B$ v; L2 h$ z' g) b8 k. Q


- O! z6 p! C6 a( `) C' H

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


8 o/ N( B1 U2 ?% d5 {+ _3 a

: i% s# C7 |- p0 `& l

监控的相关性

1 E, k- J9 N# e" N0 k


! f7 g  k! C# ~' Y. R

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


/ w6 Z- k: X$ b

- b5 J4 T% T: \. ~" f( o+ {

告警分级管理


. m2 S$ A( m9 `


  U8 o) ?( V7 \/ F2 s

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


; h/ Q" Q5 P; e7 {- `


) }1 [+ h$ i' [/ Z3 P. x% a0 \) o

降低流式监控的计算量


! K/ x  U) O; v! [1 L5 T6 D* x

1 R. p+ Y, p5 V. x$ e3 Z

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

8 b7 M2 O+ B. e9 r' B9 h

+ X6 F8 Z. w# y# W( O1 z

      用户舆情分析监控   
SNG织云监控系统
% x1 W" Z/ ]2 t, i" S+ V

0?.jpg

! e$ g! N+ A/ s! a


* j( x' \0 J9 `, a

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

& {: |2 y) g& J" z6 z  g7 v

) t( J+ t$ S3 V/ J& I9 W  _4 w

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


7 t+ I, J8 F# h% T

4 j5 G- B, ?. f% @6 _! t

   有策略更要有自动化   
SNG织云监控系统
5 K3 }& o' H" h, M, T0 f

( W. o& t& e8 N, @9 l; @  F- O

0?.jpg

6 L' E% m4 m5 J4 \, J) x: w1 t2 r


* z; Z! L/ ?% H

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


) w7 ?$ e3 `8 `  T- \7 v. `


* z. T8 C8 }7 m6 M
精准试用的算法与策略
SNG织云监控系统

8 q) A- v( F, [" i' i6 q1 h
9 _! }" Q* g) T3 a

0?.jpg

# R6 D/ C6 C/ {. Z, I: k+ y! S

; B0 ^& I' Q3 k8 W4 b" p6 t% a

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


2 S0 u) Y5 m( a" }


' o" b7 I/ g: I& b' Y+ ?1 Q4 |- d

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

$ r) k( F8 M3 E1 M' o3 V4 b

0?.jpg


  b; Q: i/ l9 h; L

( v% S( ~7 F8 q2 p+ m% J

4 B6 A3 j0 l/ E% ~# h/ A

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

  g- T/ n) f! i; O


3 Q0 c& P+ b  v) \: L& D" W

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

3 K% l; W' M, w

0?.jpg

* a8 P( N" A* a, s

2 [) ]9 t- G0 w& ^

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

9 N" |7 l2 _% x( l4 g/ j, G9 }

: I& ]6 Y: `: X5 `9 U/ m2 C

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


! A7 l7 J( ?" \. Y- w


0 l; ^0 g- _( T' K

      常见的收敛算法   
SNG织云监控系统
" t; F4 U* }- G2 f, P, J7 A  Y* k/ E+ F

0?.jpg


( R) Y5 G- @) Y- \; w# s

! U: d2 f. _  c! k


: Y  Q+ r# P! [8 m) u

◇ 毛刺收敛


. c- z; `& ]  e: ^* _7 Y. F

3 r4 i; }/ m, f* H% g

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


, C+ E' d, r0 w5 u3 _

- O' E1 D. N- [, _; J: J4 U6 O

◇ 同类收敛


% b' h- A# P) c: W2 \


  B* f( o! \; X5 |7 q) t

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


" s  H7 e% o* K5 `


: s7 `8 U  l1 A$ r3 T

◇ 时间收敛


& P7 P, B3 c9 T. H


" c; e5 n/ I8 b* _: B: n

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

* a2 s' V& w8 s. ?, ?1 O


4 `) b; ?: S& ?3 O' ?

◇ 昼夜收敛


" s5 w) N& f  z. W


' b6 x$ K( T; `2 R! A! i! _& M

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


- _2 u* B" y% D6 R0 ~. |  l


# Y8 Q5 A, J7 D/ b/ D' R

◇ 变更收敛

! B$ k/ G' g- {; Y

- ^6 c8 u) e" [8 w/ v) Z4 W  q

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


8 S; I% }4 i! A7 U/ C
  ?0 {1 N5 ^  g" A+ Z
织云监控构建的质量体系
SNG织云监控系统
9 `, u0 p6 A3 ^) e& R

0?.jpg

3 z, ?- V( \" r/ i$ ~  p% o


6 c" \2 W, Q6 u( @. w7 d

5 j% i9 h& y) i  K. b5 S& M- Z

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

' U4 Y, h# S( K2 N% s4 j; R


3 e9 p: j% p! W* b
织云监控:质量体系  
SNG织云监控系统

7 j5 _# H( g. c! ^% |% v6 }

0?.jpg

: X7 N3 F2 ~5 _( I( ~6 R/ [

2 t, Q4 N' g/ u- D7 y* a

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


( E4 m! F# B! Y9 r

5 E+ X4 x  K& C% y

  • 监控能力


    % g: g5 B& e) o# `9 U* U( H5 y4 ~

. t* L  L6 M6 r+ Y/ Q( z* _1 T- x9 e; _

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

& M) l8 F3 T7 _& R2 q2 [9 j6 u, |: s


; U4 [4 w  W7 t" u7 s

  • 业务可用性


    0 y/ ^: t  G% s8 v# o
    " P- L$ Q, `! {. N( ?9 f5 W
$ C: o$ p  |% Q$ J

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


& p4 m; @: q% _1 z


$ q# O2 [  R; |% E2 Q, w. F

  • 用户体验


    + u. E: N3 b# @1 j4 g) _& `: ^

    & w5 q) W& s) o" @7 T9 v

* ~9 Z$ C5 Z" Z5 W- E1 n: j1 ]( v

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


1 f+ g. ~- R* B5 t3 K  @! g

, F4 Z9 ]5 f1 I7 g

  • 技术解决
    9 U, k: E7 x2 |- C

( Y' ?# u" K& a5 [9 }7 W' d! v2 _  N4 T9 k( ?  m
要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。
) h: t8 m1 A# _. I; n

+ F3 h8 c  |/ W( j

  S1 t% P) \/ T+ v& ]- I! }

  • 统计分析

    - t: w6 H0 v9 `' |, }

9 m6 y/ Y& Y0 I6 _* K4 P+ b

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


+ A! _( ]1 u; ~# a

  a+ o0 c0 S: _* Z

持续改进

  W+ `6 s& x) i! A

, D  i, V$ R+ [* u+ o& [; E3 N

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

6 W+ P+ p+ X, ^5 L  N1 [

0 D* E6 r9 j* s9 N6 c& N2 s- P0 F

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

3 K4 K9 w' g, H

    结语    
DevOps最后一棒

+ |; K7 |7 ~/ P' Y: R7 K
* H( w0 }/ d7 e. r

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


0 ~" u1 V8 }3 k# J, \) q
* w; c2 P2 T1 @+ [7 }# |6 [, _3 h原创:梁定安' E! h; K8 o/ t

. |8 c0 k# u/ S% h" g
9 }- g/ D/ P( n7 D* R' U- v  q: n

本版积分规则

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

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

Baidu

GMT+8, 2019-5-24 13:26 , Processed in 0.264570 second(s), 31 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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