应用运维和系统运维

运维工作对于很多人来说其实就是看一个看说明书的工作。从man page到各种软件的readme，install file都要看。理论上看着挺简单的。但是接触多了这就分了应用运维和系统运维。
我这2个都做过。老实说系统运维是更轻松的，毕竟系统级别的改变一般是比较少的，比如碰到系统内核升级，centos版本升级，数据库版本升级，CDN改造这些不是一直要做的事情。这是一个长期过程。系统级别的更改往往是非常慎重的，得经过非常多的测试，比较和优化才可以进行上线。
系统运维首先需要保证的就是系统的稳定性，毕竟所有应用都是架设在系统平台上的。所以系统运维既是一个基础的工作，又是一个非常重要的工作。说基础是因为它是一切应用的基础的，说重要是因为要是系统不稳定，那何谈应用的稳定性呢？系统稳定性，这个基本是由于驱动导致的，有些驱动问题在一般情况是看不到的，但是一旦在高并发的情况下，比如AS5对于某些品牌的网卡在大流量下网卡会崩溃掉。还好linux的驱动开发者还是非常热心的，一般很快有patch会出来。但是还是由于我们测试不够仔细才会有这样的问题产生。
系统的优化也是非常重要的，曾经有个以前同事说他们的游戏服务器压力很大，主要的压力是在io上，其实就是磁盘上。vmstat看到io部分值非常高。这个有应用导致的，也有系统平台和系统软件导致的。比如这个问题就是由于使用sendfile读写大文件，而改成使用普通的read方法就立刻降下来了。但是有时候还有缓存读写等等原因。另外一个优化是对于系统参数和网络参数的优化。其实这些都是要根据这个服务器具体跑什么应用来决定的。
下面说下当初做应用运维的日子。在那个SNS网站的日子，我就彻底经历过了。应用运维是要保证应用层的稳定性。但是对于大型SNS网站，网站更新是一个常态的过程。于是你就会发现发布成为一个天天进行的东西。但是发布和到底怎么发？发了后的预期结果是什么？到底会对现有应用有什么副作用？这次发布是代码的发布还是一个新的应用组件的发布？
于是应用运维首先要建立一个严格化的发布和测试流程。但是有时候开发会用点非常新的软件为了实现产品需求，但是应用运维如果不知道这个东西，那一旦出了问题你就没法一下子确定问题的症结就麻烦了，特别是对应用的稳定性造成影响后，那你身上的压力就特别大了。
这次velocity会议上淘宝运维的九峰同学的PPT还是非常不错的。基本上对于应用运维做了一个很好的总结。一个好的应用运维基本要在产品设计阶段就要加入进去，这个时候加入进去对于你理解业务逻辑是非常有好处的，同时你可以发现某些肯定会对系统稳定性产生问题的设计提出自己的修改意见，毕竟产品一般都是不怎么懂得技术的。当然我们更关注的是产品的稳定性，至于产品要达到什么效果那是产品仔细考虑的东西。
而在开发阶段，那需要跟开发商量通过哪些现有的开源程序可以达到产品需求，这个时候尽量使用那些你了解的，稳定的，最好版本已经超过0.5的那些软件。而不要使用那些你都不知道它的工作机制的软件。这个过程通常比较容易，毕竟开发也想这是一个稳定的应用，但是有些激进的开发者往往会自己造轮子，那你得明白这个轮子是怎么工作的。曾经在的那个视频公司就有这样的问题，很多东西都是开发自己造的轮子，连数据同步这些都是自己造的，但是由于不够稳定，给我工作造成了极大的麻烦。
测试阶段，分为功能测试和压力测试。大部分公司都是这样分为2种，如果只有功能测试的公司，那你得注意了，应用的稳定性跟压力有时候是成正比的。
发布阶段，这个比较简单，备份备份备份，可回滚可回滚可回滚。
前面这些其实都是应用运维的先期工作，应用运维真正的工作现在才开始呢。通过各种工具查看系统和应用状态。基础的有:cpu使用率，内存使用率，io情况，网络连接数，网络流量等等。业务方面的可以看下现在的pv,uv以及你自己定制的各种事务流程。而这些数据不光是看应用是否有问题的，而且还是以后扩展这个应用还是砍掉这个应用的核心数据。
应用运维的报警工作，比如pop3服务是否正确，应用的内部调用是否正常，有阻塞没？ 这些要是能做到预警机制那对你非常有利，在运营还没发现问题的时候你就解决了问题，那不是很好阿。当然这些你需要对这个应用的内部逻辑非常清楚才会方便的建立好。
通过上面你可以发现应用运维包含了部分系统运维的工作。系统运维对于系统软件的工作机制和文档和各种操作系统发行版的文档要非常熟悉。而应用运维有时候更象是一个架构师和应用说明书。
具体的troubshooting就不说了。
###########################################
Best regards
Timo Seven