最近运维部一直在倡导”精细化运维”，到底什么是精细化运维呢？精细化运维是在运维标准化、自动化、服务化做到一定程度后，建立在对系统对应用有较深入了解，并且进行日志收集详细分析的前提下，有点运维数据挖掘的意思.
   就我个人感觉，其实”精细化运维”无外乎两个字，”精”和”细”。所谓的”精”我们可以把它理解为对应用的理解和掌握的程度，要清楚的了解应用的瓶颈在什么地方，用何种的方式去优化。而所谓的细可以包含”细心”和”细致”，就是要在在大量的信息和数据面前找到对自己有用的信息，这点在平常的故障排除和qos的优化上是非常有用的，而这里我把它理解为”数据化运维”的一种过程。
下面以webcdn的维护为例来简单地说下自己的看法：
   1.精
   过去刚移交webcdn的运维到vod组的时候，大家并不清楚一个cdn节点可以跑到多少带宽，之前的数据我们也没有办法知道，系统的瓶颈在哪里，如何优化来增加单机吞吐量更是一头雾水，在一段时间的摸索和分析中，大家了解到以现在的结构，单机跑到800M左右qos就会变差，webcdn的瓶颈在io和squid的单进程上面，之前一直提倡的双网卡绑定在webcdn的节点上是没有作用的，这也为以后的性能优化提供了信息，即：需要解决io和使用支持smp的cache系统。
  又比如，当一个url出现504的时候，我们能很快的想到是squid回源出现问题导致，这个由可能是squid本身的问题也可能是squid到后端源站的链路问题。如果返回502则可能是squid或者源站不能响应，也有可能是源站出现了499，当然在某些特殊的case中，我们也可以通过”制造”502来缓解源站的压力。
  又比如，通过对整个结构的了解，结合分析nginx日志中的upstream_time和response_time，我们可以确切的定位到某些响应慢究竟是在哪一个环节？是nginx—squid还是squid到源站，还是源站的响应慢，这对优化访问速度提供了很好的信息。
  对应用的熟悉可以让你在故障排除时快速的定位问题，也能让你在性能优化上获得很好的经验。
2.细
我们主要来说下”数据化”在这方面起的作用，也就是分析hive的数据对细节上的优化的重要性。
1）比如最近出现的唐山网通节点epg的问题，这是个不大好监控的case，服务器的squid可以正常响应，但是因为不能正常reload配置文件，导致对部分domain返回403，这个在平常的监控中是不太好发现问题的。然而我们可以通过在hive中对服务器的403数量进行分析。
比如我们对1小时的数据进行分析：
hive -e "select serverip, status, sum(total_cnt) as failure from webcdn_log_sum where status = '403' and dt='120904' and hour='21'  group by serverip,status  order by failure desc limit 20;"
ip1   403     22493.0
ip2     403     16003.0
ip3  403     2587.0
ip4    403     2014.0
ip5   403     1903.0
ip6   403     1849.0
ip7  403     1718.0
可以看到部分节点的403比例比较高，通过对这些服务器的403 进行分析，可以得出下面结论
a）player.test.cn:这个域名的所有/b2b/baofeng/1.0.0.9/?id=*&num=0都会返回403，需要找研发了解信息。
b）oversea.test.com和xiaochuncnjp.test.com 这两个域名有大量的爬虫信息，源站上对这些爬虫设置了reture 403,虽然返回了403，但实际并不能解决问题，而且还会在webcdn上产生一定比例的403.这就需要源站来更改防爬虫的机制。

通过对数据的进行分析，可以在用户出现问题之前定位问题，解决问题。
2）比如对webcdn的服务器的504状况进行分析
504:
ip1  504     337666.0  #移动机器
ip2  504     186535.0   #移动机器
ip3 504     81662.0
ip4 504     70750.0
a)可以看到移动的机器504比例比较高，虽然其200的响应速度比较快，但是高比例的504还是会对qos有比较大的影响，通过分析，我们得出移动到上海电信的源站链路质量问题问题，导致回源产生大量的504，通过对回源dns的更改，调整相关view的acl，问题可以得到缓解，提高了海外用户访问的整体qos
b)也可以看到两台宁波的机器504也比较高，而同机房另外两台相同配置的机器504确很低，通过分析，我们发现是由于其/etc/hosts中的backup地址存在问题导致，通过及时的调整在出现问题之前将其解决，避免了对qos的影响
调整结果：

504数量：
hive -e "select serverip, status, sum(total_cnt) as failure from webcdn_log_sum where status = '504' and dt='120905' and hour='21'  and serverip like '115.238.%' group by serverip,status  order by failure desc ;"
9.4:
ip1     81662.0  #调整前
ip2     70750.0
9.5：
ip1 504     61.0  #调整后
ip2     46.0
响应时间：
hive -e "select serverip,avg(upstream_response_time),avg(request_time) from webcdn_log where serverip like '115.238.%' and dt='120904' and hour='21' group by serverip order by serverip"
9.4
ip1 0.06637393263529844     0.09185731877046226  #调整前
ip2 0.06911512039974103     0.09504132781839313
9.5：
ip1 0.02827659273775481     0.05298921686543412 #调整后
ip2 0.02240534088895182     0.0482839538175451
3）比如，对所有服务器的响应速度进行select，可以发现某些存在问题的服务器，从而对单台服务器进行分析和优化，比如整体访问比较慢的兰州27服务器，9.3和9.2号数据又明显差异，则是由于keepalived进行关闭导致（报警和监控不存在）
  hive -e "select serverip,avg(upstream_response_time) ,avg(request_time) as r_t  from webcdn_log where status="200" and dt='120901' and hour='21' and serverip like '118.180.6.%' group by serverip;"
9.1
ip1    0.06245718414337235     0.1448556008319338
ip2   0.057380338650377845    0.13371867899804438
ip3    0.0610939503089629      0.1386927687818987
ip4    0.060881416483272194    0.13792972429274453
9.2
ip1    0.039894856133882245    0.1040104321877427
ip2    0.04930844481417491     0.11429710308109924
ip3    0.039233239664999704    0.10264311862268857
ip4    0.045614512687653784    0.10929291320101434
9.3
ip1    0.020114086361685563    0.05631543599700746
ip2   0.02032063779438302     0.0554855384591068
ip3    1.5908160432256953      1.6569508899215097
ip4数据没有
4）比如，对webcdn的squid整体命中率的分析，让我们可以在域名方面对cdn进行优化，对那些命中率低的域名进行调整或者是去除cdn（比如epg.api域名）,通过对hive的数据分析也为某些调整前后的对比提供了非常有用的信息。

以epg.api的gc调整为例：
hive -e "select avg(upstream_response_time) ,avg(request_time) as r_t  from webcdn_log_sum where status="200" and dt='120904' and hour='21' and host  like 'epg.api.test.com';"

0.2365636122613054      0.263690234998106  #相对于8.31-9.3有显著的减少，时间都在upstream time上,对应用源站的数据来看，大部分的时间是耗费在squid-----源站上的时间,如果缓存时间加长，相信响应时间还会减少。

Webcdn时间（取20:00-21:00数据）：

 
源站数据：
hive -e "select avg(upstream_response_time) ,avg(request_time) as r_t  from epg_api_test_com_log where status="200" and dt='120904' and hour='21' ;"
0.023255747869000733    0.02919541815990996  #9.4号

源站趋势图:

通过对数据的细致分析，可以在细节方面做出很多优化，提供qos，所以大家要用好hive.
以上就是自己对”精细化运维”的一些看法，大家可以说下自己的想法。
 

本文转自菜菜光 51CTO博客，原文链接：http://blog.51cto.com/caiguangguang/1004033，如需转载请自行联系原作者