自己对精细化运维的一些理解

最近运维部一直在倡导”精细化运维”，到底什么是精细化运维呢？精细化运维是在运维标准化、自动化、服务化做到一定程度后，建立在对系统对应用有较深入了解，并且进行日志收集详细分析的前提下，有点运维数据挖掘的意思.
   就我个人感觉，其实”精细化运维”无外乎两个字，”精”和”细”。所谓的”精”我们可以把它理解为对应用的理解和掌握的程度，要清楚的了解应用的瓶颈在什么地方，用何种的方式去优化。而所谓的细可以包含”细心”和”细致”，就是要在在大量的信息和数据面前找到对自己有用的信息，这点在平常的故障排除和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