【51CTO独家专访】过去两天的O'Reilly Velocity China 2011的会议上，来自OmniTI的Theo Schlossnagle带来了两个系统运维们应该都很关注的话题：一个有关监控，另一个有关运维的职业生涯。观看了两个演讲之后，51CTO编辑整理了一些大家可能会感兴趣的话题，邀请Theo做了一个专访，现在将专访内容整理如下。Theo的两个讲座视频和PPT在未来几天可以在Velocity大会的官网上下载到，想要大概先了解一下的朋友们可以先到我的家园相册看看部分Slides的照片：
嘉宾简介
Theo Schlossnagle 是 OmniTI 的创始人和首脑，为高流量网站和其他需要可靠、可扩展架构工程的客户设计和实施解决方案。他是高可扩展的 Momentum MTA 架构师，Fontdeck CDN 的架构师，Circonus SaaS 监控平台背后的导师。Theo 参与很多开源社区，包括 OpenSolaris, Linux, Apache, PostgreSQL, perl以及其他很多。他是可扩展系统和分布式系统方面的作家，也是开源会议上的资深讲师。
以下是采访内容的文字整理：
51CTO：您在昨天有关监控的课程中讲了很多统计学的内容。您认为DBA和运维们需要了解这些知识吗？
Theo：我认为对于工程师而言，了解基础程度的统计学是一项基本要求。因为我们每天都在关注系统的各项数据：硬盘是不是慢了？网络是不是慢了？我们将“太慢”这个概念量化成具体的数值，从而理解这个系统。如果我们每天看这些数字，而没有统计学的基本知识，那就说不上真正理解这些数字。
51CTO：像是Nagios和Cacti这样的工具目前做到这一点了吗？
Theo：算不上吧。Nagios做的仅限于提供一些数字——目前大部分系统都是这样做的，它们被设计隔一段时间做一次检查，比如每隔一分钟做点什么动作，返回一个数字。而现实中，我们面对的很多行为，好比硬盘读写的行为，它往往在每一秒内会执行成百上千次，所以如果我们能够仔细研究每一次读写的实际行为，通过这样对硬盘读写的理解，肯定要远远超过只是取一个每分钟的平均数。你想要了解***值是什么，***值是什么，你想要了解一个分布的情况，98%或者99%的读写速度在一个什么值，如此这般。这个我认为是我们需要的。
Cacti相对好一些，它目前提供了一些基本的统计功能，你可以查看数据的标准偏差，但是其他的相关数据还很有限。
51CTO：那么你们在OmniTI用的监控系统，是完全自己写的，不是通过其他监控系统修改的是吗？
Theo：是的，我们完全自己写的整个监控系统。这个系统是开源的，而且监控数据写入数据库，你可以直接用来做统计分析，或者像很多专业数据分析人士做得一样，将数据抽取出来，放到比如R这样专业的统计工具当中去。用R来做统计相对高阶一些，但是很多时候我们通过借助手册的帮助，也可以很容易的做一些基本的分析。
比如你在网站上放了JavaScript监控代码，它能够返回每次页面加载花费的时间。假设它放在那里跑了一天之后，收集到1亿次用户点击，也就是1亿个PV。你想知道的情况是，页面加载的速度如何。如果给你一个1亿次页面加载时间的平均数，这个肯定是没啥用的；你想知道的是分布的情况，有多少次访问在1秒，有多少次访问在10秒，等等。这样就会收集到很多数据点，你需要一个视图的方式明白的呈现出来这些数据代表了什么意思，那么这时候就可以用R语言。当然做这个也有其他的工具，但是R是最简单、***的。
51CTO：运维工程师的工作，一直以来都无非是部署、监控、安全、备份、排障、调优这些。您认为这方面的工作在未来会有变化吗？
Theo：我认为这些工作不会有太大的变化，只不过是有些工作变得越来越简单了。备份数据，部署新的系统，我觉得这些方面的技术已经越来越好，越来越容易做。咱们每天工作按8小时来算，以前你可能花6个小时在分发、打包、部署、备份这些工作上面，而现在你可能只需要1个小时了。这样下来，你就有更多时间考虑性能优化、资源规划这些事情——你以前在这些事情上可能只有1小时的时间，但它实际上值得你花每天8小时。
51CTO：那您认为运维工程师这样的技术人员应该多花时间去了解业务吗？
Theo：哦，当然需要了。当然，他们不需要了解所有的业务；不过他们至少需要知道，自己管理的这些机器为什么在运转？我自己见过这样的事情：有一个系统在运行了好几年之后，才发现这个系统早就没有人在用了。那是一个数据仓库的业务。最开始你有一个数据库，以及一个数据仓库。后来，又启动了一个新的数据仓库。所有用户从旧的数据仓库迁移到了一个新的数据仓库，但是居然没有任何人通知系统管理员！所以旧的系统还一直在跑着，磁盘阵列跑着，耗费着电力，还有一堆之前设计的自动化脚本在运转。系统管理员一直也没去看这个系统，以为还有人在用；而业务方面的人则没有一个想起来要把旧的系统关掉。
51CTO：难道系统管理员不会觉得奇怪吗？比如发现一直没有用户请求之类的。
Theo：哦，这个系统很久以前就没有用户提需求的，因为都完全自动化了。在一个数据仓库系统里面处理的任务可能是将每天的销售数据打包存档，发邮件到某人的邮箱里面去。换了新系统之后，可能由于某种原因，也一直没人去检查那个旧的邮箱，所以就这么一直跑着了。
还有另外一种情况，比如带宽的使用。你购买了一定的带宽，但实际上未必需要用到那么多，不少企业对于这其中的成本浪费并不是特别明白。
还有另一个例子：我们有一个客户，他们的首页一开始不用缓存，因为页面是动态显示数据的，客户说必须要让页面随时显示***的数据，比如最热卖的产品之类的。因为客户坚持不用缓存，最初我们在架构设计中只好为这个首页安排了60台机器。每次在软件工程师提出要为页面做缓存的时候，客户就大摇其头的否决：“不行不行，我们必须要显示***的数据，不能让首页显示老的数据”。***一个SA实在受不了了，问道：“显示***数据的商业理由究竟是什么？难道1秒之前的数据都不行吗？”客户反馈说：“这个啊，1秒钟当然是可以的啦。”所以***，60台机器优化成了一台。
所以我觉得很多时候，是人们之间没有沟通清楚。我们没有真正明白，究竟为什么要跑这个应用软件。客户丢过来一个问题，我们就埋头解决这个问题，启动机器，然后看到没人抱怨，我们就当作没问题了——这其中其实是很有问题的。
对于运维这个领域我一直是这样理解的：运维（Operations）的本质是让业务跑起来，而不是让系统或是一堆计算机跑起来，所以身为运维，必须要去了解业务。如果他们不去了解业务，那么他们就不会明白如何让业务***化的运行。在现实中，整个需求的传递往往是一条长链：业务需求传递给产品经理，产品经理传递给软件工程师，软件工程师再传递给系统管理员……而到了这里，可能我们早就不知道真实的需求到底是什么了。我认为就是应该将最原始的需求拿出来，大家在一起讨论比较好。
51CTO：您的意思是我们要尽量减少这些中间人的存在吗？让用户的需求直接传达给实际干活儿的人？
Theo：我认为这是一个平衡的问题。在优秀的公司当中，整个链条是存在的，我们有产品经理，有专注交互的，有专注界面的，还有底层这些。我想说的是，从一开始，我们就需要来自软件工程师、系统管理员和DBA们的参与，让他们参与“定义问题”的过程。大家聚在一个屋子里面各抒己见，才能够更好的理解各自的观点。
51CTO：您在早上提到了运维的职业发展需要向“多面化”的方向走，那您认为以后这个领域仍然会按照系统管理员、运维、DBA这些职业进行划分吗？
Theo：哦，职业细分这方面肯定还是不会变的。你很难在每个方面都成为专家的。所谓多面化的意思是这样的：在规模很大的公司里，尤其是在对性能优化非常关注的互联网公司，比如淘宝这样为这么多用户提供服务的网站，他们遇到的问题都是很难解决的问题，他们会需要对各方面都熟悉的人才。因为在一屋子的人都是较窄领域的专家的时候，他们很难去“越界”的处理问题，因为缺乏在其他领域的能力。好比你遇到一个数据库的问题，而这个问题如果你对数据库下面的操作系统有一定了解的话，可能会很容易就发现问题所在了。
51CTO：那好比OmniTI招聘的话，你会期待一个什么样的工程师？
Theo：这个问题真难……我们的话，首先会要求对方有很好的分析能力，能够按照严格的科学方法去发现问题，然后解决问题。你知道，有太多的人会在还没了解问题的时候就急急忙忙的跑去解决问题。我面试过的很多人，他们之所以没有拿到这份工作正是因为这个原因。我会问他们一个问题，比如“我们的网站很慢。你要怎么做？”而他们没有提出足够多的问题，而是直接开始说“我会这样这样做”等等。他们根本连问题是什么样子的都没搞明白。而相比之下，那些更善于挖掘问题的应聘者——他们往往是相对不那么聪明的一群人——往往能够给出更好的答案。
这是方法方面。第二就是，这个人必须愿意学习。这样的人真的非常难找！
51CTO：那你们现在也会通过社交网络等方式来寻找这样的人吗？
Theo：实话说吧，在招聘方面我们算不上多成功。我们的员工都非常的优秀，但是我们招聘的速度实在是跟不上需求。
社交网络方面，我们主要关注代码社区，比如Github；传统的Job List方法也在用，招聘网站什么的。反正是什么方法都用呗。
51CTO：***一个问题。随着云计算的发展，人们预测外包业务将会越来越多。这种情况下，您认为系统运维的就业环境是否会变得越来越局限？
Theo：这个我倒不完全这么认为。现在很多用云计算服务的主要还是小企业，他们的需求也就在50台到100台机器上下，在内部系统方面，肯定IT管理员是会减少的，因为像是搭建Exchange邮件服务或是配置电话交换机这种工作，放在哪个公司都差不多，外包在这个方向更有优势；但是网站和Web应用就不一样了，每一家网站的业务都是不一样的，有定制，有优化，不太可能交给外包就能直接搞定。你搞电子商务的，把网站外包出去运营能行吗？我觉得是不行的，因为这样你就失去了你的差异竞争力。
所以我觉得以后会是这样：Exchange这样的同质化服务会趋向于外包；小规模的网站会采用相对通用的云服务而不专门聘请一个SA；而对于有一定规模的网站，即使他们的业务是托管在云平台上运行的，他们也仍会需要一些了解企业业务的SA——他们了解如何从不同的角度思考，而且会在凌晨3点起来排障。他们可能会跟软件工程师这个岗位融合，但不管职位叫什么，这些网站仍然需要这样一批人。
51CTO：好的，十分感谢您接受我们的采访！本次访谈到此结束。
【编辑推荐】
