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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 686|回复: 0

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

[复制链接]
发表于 2018-11-14 10:28:11 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-14 10:54 编辑
7 \) L/ {1 e5 e+ s+ @( r) _, {* V5 F0 x. H, }; P8 `: p+ t  W, L
    前言    
DevOps最后一棒
! ]6 m9 b" Y5 e5 m

2 E6 v- |2 W7 W! R6 t

0?.jpg

0 D5 c+ g/ N7 _5 h. h

3 [/ H. z3 w8 F9 S- B

% Z1 w" J  h$ @+ W4 f2 j

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

( a* O2 V, I" [2 m, w

; S, f8 R3 s8 O7 }% m% v* d2 B

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

, ^5 B1 H5 a' V' J


9 e- C3 }& u* u$ U1 V

持续反馈于运维的理解
监控、告警与运维
2 q4 c* y+ C5 K! ?2 j$ G' u

9 _: T# L6 h! R6 U0 X4 c
* D* H; R3 q+ m/ X# u

0?.jpg


  a' v; Q- J5 |$ m- @! j


7 k% e9 |% w$ A& d

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

  w2 J: ^5 {' I


* E) z, K  r2 [

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

) d' U; i6 S( ?0 H/ N* v! i


# X4 C& E4 r' G" d* N; t

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


& B' A/ G4 w+ t  @/ a  G


( [, @* i' V1 j" ?. O6 G- m% S! n

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


! L2 O7 K/ U9 r


2 y% F7 s7 S& W/ _+ b, m; p

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

8 ^" {& R7 u' A& \" }) w


8 u( \1 P  Q3 O

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

% t( U/ }& B+ k! i2 E; Y! d- P


- E$ J  m, N! h/ F2 L2 A# V

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

3 u8 k9 k. x; X) P8 d+ a5 U

0?.jpg


$ |0 ~, ^  K1 X6 l


. j6 x: }, d" B( r6 d. L6 J

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


% A6 z; z8 n4 ?& b+ x

/ N' U2 }6 M8 G! S

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

+ G$ |" O0 f1 J" B( o4 N6 ]

) W3 n" H/ x7 J

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

' Q( E7 q4 f, M

0?.jpg

1 w+ {& a  O6 Y" ]8 b


& p$ C. j6 X5 ]( J8 Q( Z) m, x

5 I* R0 O, h$ \  B8 u

〓 繁——简


4 X% k3 {: e* w/ V  t4 B( y) M


. m1 g$ A5 d. l% m# g

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


) Y3 k3 I- U0 w3 O: O

/ y  a  I- w0 F

〓 泛——精


- f7 e+ \8 r; O4 p

% i  J2 N- @0 D& g& b4 g

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


4 ?; @9 g5 d6 ]. H% T7 `  R  B

3 c# Z& @$ x! y  `, X3 [0 o( n

〓 乱——序

8 a! y/ J) `  g, S4 F- }2 k


. A0 _9 J7 i: x

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

; N8 l7 }: v4 u

' B3 S, k2 X" ?8 [6 u4 L

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

: g  K5 }. D( a9 L/ T) f4 V


% b. p0 y+ Z) t+ V/ t6 V( q; Y

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

7 I# g8 _+ ]9 f- p0 b) K

0?.jpg


) b) [# ?0 s4 f' y( q4 W


( t9 f& C( W8 b4 A& b! Y0 P

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


* @5 h$ H0 d9 [7 J% j


3 t% ~. }4 j7 T6 `* ]

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


4 o! T: b9 G* i8 D. ~


. I+ ~6 g: ]* Q5 O0 Y

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

* \3 O+ R7 q2 z* [/ ~; X  y- |


5 y9 ^7 }2 n, Z: T9 w. c

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

' s& S% B+ g) r& D: B


6 U: O" `2 y- b9 s

☆ 低层次指标


( W% p+ A, C( s1 b4 {, {


0 U& w' r' M/ \5 I) q

把公共的、基础设施等在业务逻辑之下的指标称之为低层次指标,如网络、硬件、虚拟化等。. n( {% S  g# q. L

- ~+ e% o6 ?# T% g1 Z+ S

: M0 I+ K! j% K" q, X

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

/ |" k8 k/ n/ ]0 m0 f% _


( z' E. p: @" j2 i3 N8 H

☆ 高层次指标


" _1 C# ]& T9 M, m9 \$ M' A


$ a) G+ O9 c0 C/ K

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

: R& E% f3 Q2 {; ?; [! t

6 Z1 M0 c6 M! [* a! `

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


  O6 {$ @+ ]& X- a8 _


6 N4 f( H6 M5 }7 \2 o3 ^: c

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


, B1 l/ U  N& `" b+ R% u


# Y8 U* D# Z0 l( |

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


& Q0 F" H, m0 e


0 O2 y" `4 i& k7 k; I3 k

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


6 n; Y9 U+ U" u& @: `, ?9 \, X


7 k% q: r4 {) {5 f+ o

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

, B& }7 \% q! b9 n  v) C

" n7 @) b& C4 Y7 `& |6 b' c2 T/ z

       监控的本质        
监控、告警与运维
$ q- c# v# u# p& H6 C  P( q

0?.jpg


0 H: H8 n! M/ O$ k  v% @4 f6 h* j

' p  Y2 [# o% A+ Z2 r2 w! i


, s# b3 Q' D: _- M

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

+ I5 F# q! ]! f+ T" y5 D


( B- {" d- j- u/ a: _" Z$ y

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


) P: Q/ x/ O* [3 w8 C

8 D8 v! P! E( w' R# m
         误告警解决办法        
监控、告警与运维
4 d5 h. W; g9 n) K

0?.jpg


, ~( |4 S. Q2 y1 Z- ^( j; U: J

; T  }( i9 c$ I- k$ P2 R

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


& K+ l* h7 S- N$ S2 c2 a8 A! [


9 \8 q% ~; C! w* I, b0 A

◇ 关联分析


  |9 n* B' g/ n1 O7 }

% C: c- p, d4 q1 ^+ ^/ f

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


$ g* ]. {" g: Q! R2 u


" b+ i  j6 w" z6 Y

◇ 无误告警


* a- k2 J4 X/ ?' P* k$ z! f# J& [% D

2 f9 D* q3 Q* p  R. H  a

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


: z7 f5 f6 F, }5 G+ G

* Z3 e* l! I* \/ I0 ~

◇ 持续运营


$ }; M) N3 x, A& t) K9 S

+ s0 I; W' Q* m) C% W. l% i, ^

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

+ N& R/ L" _8 d


8 c8 F2 K+ e. z+ d" Z

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

- O- U2 B7 G& _5 s: y( G


# P0 W0 m" c) C6 J5 P/ ^+ a2 x

案例:海量数据分析思路
监控、告警与运维
5 h; _7 v) D3 x

; I6 Y& H' h  M! u# \7 c

0?.jpg

. ^! ]8 ]3 b% z. L

% E( L* I0 O2 @8 N0 s3 {6 k

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


& J4 F2 |" q; [% b" P! c: V' ~
4 K4 @& e# C* w5 F/ s, f; x

0?.jpg


, m5 T8 ?) K, \3 m2 ^3 o; \


6 t5 f3 N* a+ N% b$ u


$ {+ {. K( k8 ~4 V1 u* f

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


+ W7 a' j8 ?& h# `

0 O4 |8 p1 Z9 f' _; x/ R( R

0?.jpg

, U. _* Q+ J  r) U9 e0 [


+ O8 s# D' Y/ x! |1 \

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


, S8 n5 k- k2 L! k, N

0?.jpg

+ i3 s( L- W7 m* C# v, i& v4 |

  s. e4 J1 [: r' _$ P% X& |


5 j# N$ T6 J& V+ d" b5 P% K. B

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


& w" w) d4 X* B

0?.jpg


# d" @" c0 K3 D5 W4 w


9 l$ G8 G$ v# S* ~, W  V+ W

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


, v7 i# [0 l  j( M

0?.jpg


0 b/ v9 A* K5 Y


! s/ K& Q1 ]+ A) w/ _$ y/ [4 f" |

9 R1 v3 ?+ j1 c0 u, F

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


1 i4 z9 @# R+ C. l5 u4 ~4 Z0 O6 l* d

0?.jpg

9 _* O" ]! b: _# ~


0 b% s9 ]9 J2 o( X% M" E; F! t. [

/ L4 ^! v6 s7 A, b

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

/ E' H: B* Y5 O4 l

8 T9 H- c0 w- }4 R0 m7 ?( ^3 r

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

, k! x6 E( V2 X; ^) e4 h! s
+ {0 E8 L% k, B4 _0 v2 B
海量分析三技巧

1 f! D, c  i1 _# D% x- V* ]' O+ N6 @

0?.jpg

3 p# T$ }4 g! ^( F. n! A* s

9 l) C% W6 S: {, I: |4 O

3 f  N7 Q. K* B, ^8 K! m4 _

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


* n: n7 f4 J2 |2 o


; S1 [2 i9 @: b; O) w8 f

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

& g* z3 f- b( T% d1 W) Q


$ c4 B1 |, e9 X- B6 _
        溯源分析      
海量分析三技巧
  v6 x9 u! c& A# J  R! H  R" b# g0 \& Y

0?.jpg


1 D; _+ J7 C% Q- V  C  O3 S* c


) @1 k) p3 D! d7 ~6 _: l! x

〓 高维与降维打击


$ L( \9 L: h3 J( L. L

' w. ]' V% N6 N* E) x4 y2 L

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

8 ]( L+ }; X( R


- L) U* e, w' {, o  v

〓 级联分析

& M  c- h7 j! t* l" S6 j, V


$ K& f/ U0 D+ |/ W

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


9 ~' m) Q% b4 {! [* q/ u# C

: ~2 ^- h9 t% P6 _5 ?

〓 逆向思维


0 ^7 ^8 u. L% l8 G8 t& h( g


: B! Z6 A# `# ^  f6 L) D

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

1 ]0 R# a, k% u) M, u


" {/ v. Y0 `9 _* q

        根因分析      
海量分析三技巧

+ J5 D, [0 A  G  c7 I% o- L) Q; N

0?.jpg


" I5 H1 r1 p0 s" ?" B: O

" c& e3 g" H- W: {: l9 e
  • 用高层次的告警 收敛 低层次的告警

    ! y) j+ Q( t3 j+ m

/ k1 t9 `+ Y" t
3 ]0 D3 {# D. f2 a5 j$ C1 O1 j

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

8 c% ]- R+ o2 H7 U- K

. \" t$ k/ V$ e

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

    2 J; K4 c5 @5 g3 w0 V- Z7 r
    $ t( ?6 _1 b& z; \
& G9 x/ i  T4 R8 g5 J

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

! e! H( v. t7 h. Q  j0 E' r

- _% U3 p2 n  [: ~& h

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


    $ s* b' k* C, w* ~, s" x. t9 J
    $ T1 X7 f* x6 v" ^. i0 ^

  O; i6 X1 H$ B( n

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

) \9 K$ D. n/ U9 j; M# n2 t% G" E

; N( q2 s7 @9 m. f# X  d. o
  • 用主动触发的活动 屏蔽 对象的告警:

    ( ~$ h2 `( Y! H7 z* u* u. D
5 N% m! j0 o8 u/ A

+ b. o; Y3 @" n0 H; n8 S/ Q% a! D

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

8 b3 O- u  [. A2 N4 ?" J2 U! l3 b; x; [


0 @& m% n9 X9 y3 g0 N) M

        优选指标     
海量分析三技巧
# \0 m! i9 B$ M# i. j; `
4 o+ s- x# K' |  J) U4 [$ Y& h

0?.jpg


( j' T8 k; j; K+ i: s* \  v7 F% n


9 }+ x$ o) a1 _' X/ e

核心指标论

+ C# F1 n$ a. m4 R: {. ]

! |& K! G! f$ w$ t/ F/ x2 s

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

( @6 s2 m8 y& ?+ I


4 I9 q2 i# o/ X7 ?5 s

监控的相关性


! Z0 U, w+ s% u9 w, f& `

/ ^0 R& O3 o# J4 B

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

: O0 O1 S1 v9 B. {+ `; I


! @: m( g6 I  _% _2 M  ~

告警分级管理


9 d0 ?7 |; g: N3 ?

$ c. Z0 q, T( t. i& j

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

* V9 s0 Y7 q4 p4 s" P

4 t0 m1 ^" T1 N7 w6 H* X2 v6 p

降低流式监控的计算量

& d8 ~. R0 z+ d7 U


6 O, Y0 _8 p" \

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

7 M$ z" Z& N- R5 i- z2 `/ D( W


4 B* ~1 r& A* h0 T  n% `% r

      用户舆情分析监控   
SNG织云监控系统
5 V3 J! B, v; p5 p* m

0?.jpg


) p* w% R* T7 \0 Y


; }3 K/ E' h0 v5 w/ G# _5 x

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

% [; k: \5 {/ K. t


& W, R% z8 N0 D/ @+ r( _

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

: f/ q9 W" L. c' M

5 C: ~7 A2 e9 Q! s. o9 Y# j

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

) z+ k6 i% {" j1 t" x6 n

/ n! A. b% q2 h) q. j

0?.jpg

" @3 p6 z1 D. C9 \

: \) N0 G9 v3 m! {4 G9 ~

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

9 n( Q/ O' Y0 A& D; W; j/ |! f

" y7 B" U" }) h) m. y; b. ~
精准试用的算法与策略
SNG织云监控系统

$ w3 S4 M- h% k4 t. v+ X+ u! k
6 K( a0 n0 y, I  ~! L: T. x

0?.jpg


; }  C$ d# s% H3 }

% ^' p6 E" }! @

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


* n% c2 Z+ @/ B+ U2 ~" N2 t# ?; e


" Y# w* t  G, [  Z6 A

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

# F* S* E2 N1 R8 t# b. W! V! n! N

0?.jpg


* c; F# p( o+ f' z- D+ j


2 `! w! J! U' b8 [


3 a  u# l, d( B& @6 l

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

: Y* m7 [( I6 e( ~% I


" h" P& h- ~. N1 G" x; \4 U2 b

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

: r. ?& N  {2 Y+ T

0?.jpg

: T. y( M; Q" W) H4 S

0 q* m$ x9 }$ u+ v

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


; }9 z: J2 X- r/ T

. g- q- v* e% D" N: d" A

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


8 |! O: n/ c% f* Y% e


! _6 |" i9 P) w

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

2 r/ h. n2 W3 J" |9 W% u3 h

0?.jpg


: B& L5 j3 F# I5 c- Z

, U6 D' n0 n6 d. Y0 g$ V% a) l; i

( P% s8 E4 N( h$ @7 x

◇ 毛刺收敛


1 W: e9 p8 y! I; z6 X, y, j


1 e# \) H1 W8 N

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

+ w5 v0 Q2 G0 t


! R" u3 G2 @9 X) d, C. X

◇ 同类收敛

/ p, {, J8 e  d/ [% E

7 ^) }* b6 k' R

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


: R  z* h8 ]" A0 _


  Q. J! K4 w- U! [, z2 R( B7 P

◇ 时间收敛

! b. m0 f3 |2 K. S

/ D' i& z% v5 S& D( I& s  c7 y

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


/ w- F, ^9 E7 }) a  k


% n' ?; _0 @8 K! I' c% `) K- U) r

◇ 昼夜收敛

$ i4 u6 G, T4 S1 z! N

- e! D* i- z3 S: ^- z6 g4 ^) L

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

. {) D. _8 a6 D3 C/ Z

2 C( Y/ V5 q: J4 H' Q) ^1 H

◇ 变更收敛

" @" x( z0 [+ L% `/ e& E

4 p4 `& F& k" m- z

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

5 y: n6 Z# {6 B( A) ?. k4 ?! F

+ b, `0 X* l' b2 p5 M  s
织云监控构建的质量体系
SNG织云监控系统
6 [6 v, ?; M& J+ r/ `9 p. K, @

0?.jpg


* T) C) B4 D8 ^( S4 i

" y/ t. L* Y# T( Y

' C5 P9 f+ l% p3 _# v8 ?, i% [

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

& E; t) V0 c. u6 g


6 X& D0 i% G8 w3 [( p9 X( x
织云监控:质量体系  
SNG织云监控系统

1 |2 |$ k, I" [; ~5 n

0?.jpg


+ U# ?  }1 e2 f, H: R- l* h% V% d

. j' L7 m6 G1 w

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


& T3 k! h( ]& M; s( B6 Z


) ]0 {$ G. l) m1 n. r

  • 监控能力

    + B5 q& D! m) B( k/ ]) C( g

' t: Y' z  i6 ?: z

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

6 w( u) b. ^" |$ S# ^

0 q7 N) N/ O' @6 o( `

  • 业务可用性

    + v. y3 `0 {9 E

    2 S! A5 b5 @+ Z4 c

4 z: J0 d9 X! D0 ?2 W

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

4 t9 u+ Y1 X: d


3 y; N/ J; N6 N, R

  • 用户体验

    $ U5 A6 \5 t- i" t+ r

    / O4 _% Z2 y' \

6 a& P9 V9 B0 e4 w

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

! r' f/ O  t3 m) V" b2 t

6 m+ f* F- m) p4 ~$ h7 r

  • 技术解决9 ?- R. T' Z- H- D& {7 x  G3 u% ~2 U

3 |- f' W0 J9 }7 n  ]& P
/ R; C) @" g3 _* U要有技术解决方案和自动化工具,还要有协助用户排障的工具,以及根因分析的算法平台等等。
. z9 z; G, j& J$ M" ?7 w

0 u- j1 H3 t& @9 U, [

! }. f# Z4 [! C$ B& J! m4 {  H2 i) ]7 K

  • 统计分析

    ) b$ |# N$ A3 o3 v

# L! K' \9 N0 D# X( @

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


" |# y- j; P1 l

5 ^+ b4 N& b7 [$ m6 ]6 S. x* V

持续改进


9 e8 A. z, V; P8 O  ^5 V0 w5 K; t


, R) G" ]9 C5 O2 q" H6 Z, U+ b. j

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


& Y/ \& N' ]$ I& s

0 y, B# O( P( w+ N

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

; a. R$ R9 w: S' |1 A) @" M

    结语    
DevOps最后一棒
/ t( V5 ]0 y- c0 U0 Z5 C  n) ^+ T
  \5 J# e3 }8 [9 q1 F

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


- g6 ?9 g" ?7 M* b* W# o1 P' D/ U/ u
原创:梁定安
5 ^& D- t; Q1 `5 s; @4 K: J
3 W1 x2 N$ v9 l$ q1 C
5 J: s1 V7 z) N- P; W$ m1 u+ f

本版积分规则

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

Baidu

GMT+8, 2019-10-20 01:44 , Processed in 0.168439 second(s), 24 queries .

Powered by Discuz! X3.4 Licensed

© 2001-2017 Comsenz Inc.

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