知识
互联网时代，知识是一个特别简单的问题。互联网就是一个非常有效的知识存储系统，对很多问题而言，“我来为你 Google-下"都是高效且往往也是高产的回答。关于操作Web基础结构的几乎你想知道(或不想知道)的任何事情，你猜对了，都在Web上。
把自己限制在Web上查找信息，喔喔，那就局限了。在这个过程中，尽管感觉不同，可你并非独自一人。你有同伴，如同你需要他们一样，他们也同样需要你。用户组(各种各样)遍及全球，这可是分享知识的绝佳场所。
要是你正读到这里的话，你肯定早已经知道书本对于获取知识的价值了，所有资深的Web运维工程师的一个共同点是都拥有一个相当规模的书架。试着在你的组织内部成立一个图书俱乐部，如果你的组织太小，那就在本地用户组里问问，看有没有同道者。
互联网行业的一个独特之处就是几乎所有东西都是公开的，事实上，有专有权的东西也是极少的，而更为独特的是，几乎所有规范文本都是免费的。互联网是怎么工作的?交换这里有IE的规范说明交换的原理；IP:这里有RFC791；TCP:RFC793；HTTP:RFC2616。你可以读读这些规范文本，从而对互联网的工作原理有一个透彻的理解。这些协议规定了网络服务的规则，你对这些协议的理解越深，你的决策就会越有水平。但不能就此止步!TCP可能是在RFC793中描述的，但TCP的各种细节、扩展以及后来的“发展”都是在RFC1323、2001、2018、2581等文本中描述的，所以，还需要进一步深入研究。或许研究一下TCP是从哪里来的，也是值得的:请看RFC761。
让我们再来看看理论与实践的难解之谜。TCP的RFC就是理论，每个操作系统中实现TCP栈的代码就是实践。理论与实践的辉煌撞击(glorious collision)就是不同TCP实现之间互操作性(或互不操作性)的微妙之处，而由此产生的爆炸就是慢速的下载，挂起的会话，以及沮丧的用户。
在你走在从学徒到师傅的路途中，尽可能多地占有信息是你的职责，这样你的大脑才能将那些细微之处进行排序、过滤、关联，使其成为一幅简明、精确的图画，从而有助于你的决策一一不管是长期的架构设计的关键决策，还是临时的排除故障的决策。
工具
工具，在我的经验里，是计算史上持续时间最长、言辞最激烈的争论之 对Emacs、Subversion对Git、Java对PHP一从不同阵营的争论开始，迅速地演化为愚蠢的门派之战。
简单的事实是，虽然这些工具各有优缺点，然而人们使用这些工具却都取得了成功。为什么人们要使用所有这些不同的工具呢?为什么我们还要制造更多的工具呢?当ThomasCarlyle和 Benjamin Franklin说“人类是使用工具的动物”和“人类是制造工具的动物”时，我认为他们道出了人类本性中某种重要的东西。因为制造与使用工具是我们的本性那为什么我们还要进行无谓的争论呢?虽然 Thoreau/在某些问问题上很尖刻，但他的评论“人类已经成为他们的工具了”，我觉得在现代语境下，也是同样准确的。
这个简单的事实，在Emerson那里得到了最好的表达:“所有的工具和机器归根到底都只是人类肢体和感觉器官的延长。”这很好地道出了那个古老的格言:师傅不是用工具炼成的。在互联网应用的环境中，你会看得更清楚，五花八门的语言、平台、技术都能够成功地组合在一起，将这些成功地构建为一个架构的，不是Java或PHP，而是设计与实现它的工程师一一那些师傅们。
工程上的一个真理是，不管在用的工具是什么，要了解你的工具，这是在这个行业登堂入室的前提。你的工具必须成为你的肢体和感觉器官的延长。对于工程师和非工程师都同样深入了解，不要仅仅为了一张证书。你必须了解工具的效果，以及与环境的交互能力 清楚的是，事情发生时，再抱着本工具说明书来看，则无异于远水救近火。对你的工具要句话，必须要实用。
运维工程师的工具箱中的一个强有力的工具，就是系统调用跟踪器(system call tracer)，系统不同，这个工具也可能稍有差别。Solaris的是truss，Linux的是strace，FREEBSD的是
ktrace，而Mac OS X本来是ktrace，可后来换成了用处不大的 truss系统调用跟踪器就是一个窥视孔，透过这个孔，你可以看到操作系统在用户空间和内核空间的交互作用，换句话说，如果不是计算密集的操作，这个工具能够告诉你应用程序正在请求什么，满足这个请求花了多长时间。
在Solaris、Opensolaris、 FREEBSD、Mac OS X，以及其他一些平台中，Dtrace具占有独特的地位。但Dtrace却应该在这里提一下。Dtrace在系统可观测性(system observability)方面是一个巨大的飞跃，有经验的工程师通过这个工具，可以获得对系统更为深人的理解，这在以前是不可能做到的。然而， Dtrace就像神谕一样玄妙深奥，一方面是其深邃的洞察力，另一方面就是答案的质量取决于问题的质量。从另一方面来说，系统调用追踪器的预言就像雪崩一样汹涌而来很容易引你上钩，但要在大量的输出信息中找到所需要的东西，却是一个真正的挑战。
我们怎么谈论起雪崩和神渝来了?支撑Web的架构没有固定的形态，一般也都是异质的环境，从这点来看，这倒是一个恰当当的比喻。使用 strace探测你的Web服务器正在做什么肯定非常令人兴查(而且不用花太多时间，一般也都能做些优化)。但发生问题时，除非是非常有经验的工程师，你要是第一次查看那些输出，则对你基本上没有价值，事实上，却反而浪费你大量的时间与精力。问题在于，这是一件需要经验才能对付的事情，而你只是个新手。在发生“问题”时，从这样的工具中查看输出，试图找出不寻常的模式，是符合逻辑的。很清楚，你如果在正常操作模式下都不能使用探测工具的话，则比较的基础也就不存在了。从而所有输出模式都是不寻常的。那些看起来与题有关的模式，其实并不是，这种情况经常碰到，导致在这上面浪费了大量时间。
传播关于工具的争论往往是重要的，这样你就能够针对工具对问题的适用性进行选择，而不会仅限于自己的个人喜好。 FREEBSD项目是一个极好的例子，它的发布管理绝对是一流的，使用的工具却是被大多数人认为完全过时的版本控制系统(CVS)。许多成功的架构是建立在PHP语言之上的，而PHP却缺乏很多现代语言都具有的一些特性。而从另一方面来看，很多项目，虽然装备了最强有力的工具，仍然失败了。灵巧地运用工具的能力，比工具本身的质量要重要得多。话虽如此，有经验的工程师还是应该手边备一件合适的高质量工具的。
经验
任何情况下，经验都是最有力的武器之一。经验意味着太多的东西，所以特别重要。从最本质的意义上来说，经验意味着良好的判断力，而良好的判断力却是从很多失败中取得的。从理论与实践的冲突中，我们可以看出残酷与美丽。冲突无疑有牺牲一一数据丢失、服务中断、激怒用户，以及金钱损失一一但同时，冲突的完整情景和病理却有着深邃的美:职责受到了挑战(你可能因此而丢掉饭碗)，非预期的结果也得以彩显，而比这些更重要的，这是你成为病理学家(pathologist)千载难逢的机会，而且对于理论与实践在哪里分道扬镳会有更加深入的理解。
经验与知识是紧密相关的，知识可以认为是他人经验的总结。你有了这些知识，并不就能把握知识背后的深刻意蕴，这是需要直接经验才能获得的。经由经验磨砺的洞察力(这种洞察力在仅有知识的情况下是不会有的)具有洞幽烛微的能力，才能够探出问题所在，而知识背后的深刻意蕴则能够让你灵活应用学得的教训，解决这里的问题。
经验既是一个名词，也是一个动词:获得经验，与应用经验，同样容易(也同样困难)。
无经验者的机构化挑战
尽管获得经验就像简单的“做事”一样容易，但在Web运维中，就是一个制造糟糕判断并从中脱险的过程。然而，问题在于:身处这样一个激烈竞争的行业，有哪一个机构愿意让
自己的员工制造糟糕判断呢?回答这样的问题并执行这样的计划，对于想拥有职业Web运维工程师的任何一家公司，都是基本的要求。这个问题的答案分为两部分:一阴，一阳。
首先，为了让初级和中级工程师制造糟糕判断，必须保证安全。这通过将每次糟糕判断的责任和造成的损失控制在一定的限度内来实现，环境(工作区、网络、系统、代码)要能够完整地从偶尔的糟糕判断中脱险。你肯定不希望被通到这样的份上，仅仅由于一次糟糕判断，就将员工炒鱿鱼(虽然我知道这不能完全避免，但总是一个美好的目标)。失误越大，从教训中学到的就越深入和持久。这让我们进入了答案的第二部分
相同的糟糕判断水远不要犯第二次。错误可以发生，糟糕的判断事实上也总会遇到，但不能从自己的错误中学到数训，是不可原谅的。虽然意外总是存在的，你应该期待并倡导这样一种文化:对重复糟糕判断的零容忍。
“资深运维”的概念
一直困扰着我的一个问题，是初级运维工程师申请资深职位。他们的想法是知识决定了一个人在团队中的地位，正像其他领域一样，这是绝对错误的。一名资深工程师最大的特点是其致与可靠的良好判断力，很显然，这要在需要做出判断的场合经受锻炼，而且有一个简单的数学算法需要做出判断的场合的困难程度乘以任职期限。在一个经常发生灾难性性事故的运维团队中空降，是可以在“快车道”上迅速成长的。在一个位置上待10年，从来没有做出过挑战性的决策也是可能的，其结果就是，没有积累起任何有价值的经验。
X一代(甚至Y一代)奉行即时满足的文化。我与一大批的工程师共同工作过，他们期望他们的“职业路径”在5年之内能够达到最高位置，只是因为他们非常聪明。我认为对这么一大批人来说是不可能的，不是每个人都能够做到资深工程师。就算5年之后，你做到了资深工程师，难道这就是你的顶峰了吗?再一个5年之后，你就不累积宝贵的经验了吗?到时候应该是什么呢?“超级工程师(super engineer)”?5年之后又是什么呢?“无敌工程师(super- duper engineer)”?我认为我们这个行业的年轻人不值得为此烦恼，真实情况是，极少有工程师会在Web运维领域干上15年。我们这个行业的变化性很强，很多人被选拔到了管理岗位，或作为企业家冒险运维自己的事情去了。
对进入这个领域而没有什么经验的工程师，我的忠告是:耐心。然而，这句箴言明显自相矛盾，在你能够领悟其真意之前，你的耐心恐怕早就跑光了。
纪律
纪律，在我看来，是我们这个行业中最大的灾难。Web运维，从其进人结构规划、过程设设计、人员训练之后，业绩就非常槽糕。作为我工作的一部分，我做了很多评估，走访了很
多公司，对他们的组织结构、运维实践、整体架构进行复审，以便能够识别出一但业务规模上来之后，什么时候以及哪里会出问题。
猜猜我经常看到什么?我看到的是懒懒的牛仔和持枪歹徒，这是狂野西部(Wild，WildWest)啊。情经常被吹嘘为程序员的必需品质，在Perl社区(这一点已经成为其符咒的一部分)，其意义并非真如字面所示(在符咒中已经进一步简化为野做)，而是通过尽可能正确面高效地做事，从而为解决同样同题，面尽可能地少做工作一这其实离横情已经很远了。不幸的是，程序设计和运维领域的其他人却将真正的懒惰作为一种我称之为“我的地盘你休想”的做慢。
纪律就是可控制的行为，来自于培训、学习和实践。以我的经验，纪行律应该是Web运维团队最普通的要素，缺乏纪律的结果就是不协调、效率低下。
纪律不是通过书本可以教的东西，必须通过实践养成。你接手的每个任务都要用长远的眼光来对待。对你的岗位和职责要长期经营，处理问题的解决方案要5年之后还能够满意，这些是实践的良好基础，纪律从此实践中即可养成。
软件工程(一个密切相关的领域)在纪律上却有不错的成绩，我觉得这挺有讽刺意味的。我猜Web运维领域缺乏纪律性的根本原因是缺乏职业路径，这看起来好像是一个鸡与蛋的问题，我X对这个行业很快就会有一个明确的职业路径还是充满信心的。
参与职业的网站建设规划设计，对于在这个行业工作的工程师来说，肯定是是非常重要的。Web已经在那儿了，架构在Web上的服务正在变得越来越关键，Web运维“职业”是不可缺少的。通过参与，你就更能够确信，当初吸引你进来的这种工作的特质，将持续你的整个职业生涯。
本文地址：//www.xrqsnxx.com//article/3303.html
