系统运维秘诀.doc

系统运维秘诀：变化，监控，扩展
Dormando的运维秘诀分成以下三大篇：
1. 技术篇
2. 交流篇
3. 实践篇
技术篇
为变化而设计
◆Google的秘诀是正确的——“为变化而设计”。“变化”就是不得不部署新的软件，升级现有的软件，进行扩展，设备损坏，以及人员流动等。
◆每一件事情都是在寻找平衡点。你也许会认为把你的系统和某个操作系统或某个Linux发行版牢牢地绑定在一起是一个好主意，但事实上这跟把它们完全隔离一样糟。如果实在有必要，你可以进行分层，并使用一点间接性。
◆这并不意味着你的系统必须是平台无关的。其实我们的目的很简单：一变二，二变二十，一个系统必须可以应对各种突发事件。也就是说，如果一个系统管理员被公共汽车撞了，你有应对的方案！如果挂载的硬盘出现故障了，你有应对的方案！如果某些人运行了rm -rf /，你也有应对的方案！增量的进行变更。记得安全更新，以及保持内容更新。
使用自动的，可重复的构建过程
◆不要手动构建任何东西。如果你一定需要手动构建，那么就做两遍，在做第二遍的时候把用到所有的命令都提取出来。
◆下面这一点十分重要：将新硬件上线到生产环境的过程不应该超过15分钟，而且这个过程必须足够简单。否则，当一个服务器出现故障，而没有人知道如何更换它的时候，你就该倒霉了。
◆下面这一条是普世真理：这个世界上不存在“一次性”的服务器构建。即使你的服务器只需要构建一次，但只要你构建过一次，就一定会有第二次。比如，当它损坏的时候，或者你必须进行一次重大的升级才能让它在在接下来的两年时间里更加稳定的时候。
◆测试，检查新构建好的服务器。这应该是比较容易的，因为你的构建过程都是自动化的，对吧！
◆脚本化的构建，意味着从某个Linux发行版的V3升级到V4应该是很快的。安装
V4，对脚本进行测试。如果有问题，参考文档并修复它，直到它可以再次正常工作。这最多应该是一个星期的工作，而不是一个长达一年的浩大工程（因为那时，刚刚完成的V5已经发布了！）
使用冗余
◆容易重新构建，并不意味着你可以忽视冗余。跳转盒，邮件服务器，计费网关，等等。如果其中的一半挂掉了却并不造成客户的宕机，生活将会变得更加简单。
◆按照以上方针来做的话，当某个设备在凌晨3点出现故障的时候，你可以“以后再处理那个出现故障的设备！”，把冗余的机器先替换上去。
◆下面这一条是个聊胜于无的解决方案：Rsync。DRBD也许也不是一个完美的解决方案，但是它可以提供令人称奇的服务。（参考阅读：DRBD笔记，DRBD实例1，DRBD实例2）
使用备份
◆备份是个严肃的话题。使用硬盘，烧录磁带。压缩它们，移动它们，并行地运行。对每一样东西进行备份！
◆如果你的构建过程是自动的，整个过程都可以被备份。如果到目前为止的几条你都做到了，那么一个真正的“灾难恢复”计划也许并不是那么遥不可及的。
监控正确的东西
◆监控你能监控的所有东西，而且要用正确的方法来进行监控。如果你的NFS服务器挂掉了，不要让你的监控工具发送1000条警报。如果对你的系统来说，超时的警报没有什么实际意义，那就别让它发。要针对各种具体的情况进行成功性测试：是的，这个服务可以进行一个新的TCP连接，它甚至可以响应，但是它还记得它要做什么工作吗？
◆如果你有500个Web服务器，其中一个挂掉了，你可能不必马上知道这个情况。但是，如果负载均衡器没有把这台机子踢出去，导致错误报告出现在了用户的屏幕上，那么你必须知道这个情况！
有关数据图形化，历史数据
◆图形的作用是让趋势可视化。历史数据的作用是让你对数据进行精确的分析。不要把这两者混为一谈！对图形进行目测，很容易获得错误的数值。许多站点都使用rrd类型的系统或其他的数据聚合系统，此类系统按照时间对数据进行平均化处理，然后保存在存储空间中。这不仅仅是难以阅读的问题：这根本是错误的！
◆如果你要浏览数百张图才能精确地对一个问题进行定位，那真是糟透了。想要找出极值？请使用脚本提取数据。
◆如果你必须使用图形来解决问题，尽量把各种高级的概念整合到一个单一的页面中，然后让这个页面链接到拥有具体信息的子页面中。如果你在数据库负载中可以看到一个峰值，你可以点击这个页面对那些数据库进行概览，然后找到那一两台可疑的机器。基本的理念是尽快地缩小范围，尽可能的减少猜测。
日志记录，使用多个数据流
◆无论是独立工作还是与开发部门合作，都要把尽可能多的有用的信息记录到日志中。无论是分析之后再保存，还是直接扔进数据库中生成报告，这些都无所谓。信息终归是有用的。
◆有用的例子：页面呈现时间（哪个页面？哪个设备？），面向用户的错误，数据库和内部服务错误，带宽使用率等。
◆建立图表，报告，并对产生的历史数据进行比较。
◆报告是十分重要的。每周或每天对你的基础设施变更进行汇总。
数据存储方式，数据库
◆诚然，数据库运维是一套完整而独立的知识体系。但是有时，你不能把一切都丢给你的DBA。
◆拥有多个冗余的数据库会给你带来很多好处。对于一个庞大的Oracle实例来说，从前，很多运维工作需要好几个小时的关机维护时间；而现在，完全可以在服务运行的同时进行。MySQL和数据库复制功能是一件奇妙的事情。
◆和DBA们一起努力，尽量为可能会发生问题的数据库争取到最好的硬件。RAID 10，大量的RAM，高速硬盘，乃至于强悍的RAM磁盘和SSD。运维人员对提供商要货比三家，这样可以减轻DBA对硬件的恐惧。从长远来看，找出哪个品牌的硬件更加优秀会节省大量的资金。
◆数据库配置一直在改变。现在出现了HiveDB，MySQL Proxy，DPM这些软件。我们绝对应该对巨大的数据集进行分割。我们也可以考虑一下像starling和Gearman这样具有一定创新性的软件。了解一下这些软件的用途，同时，了解一下并不是一切东西都要保存在一个数据库中的。
◆善用你的过滤器！如果这些数据很重要，应该对它们进行备份！单片的NFS服务器的快照很奇妙，它并不是一个备份！
◆可以虑一下替代的解决方案。MogileFS现在变得越来越好了（参考阅读：分布式文件系统试用比较）。实际上，还有其他类似的项目可以免费（或廉价）地维护大量的存储文件。类似的系统基本上都是是为、archive.org等站点而开发的。我们最终会让廉价的NFS过滤器成为标准！

多一些横向扩展，少一些纵向扩展
◆横向扩展是我们应该走的路。应该使用常规的（即：可用的，价格适中的，标准的。而不是特便宜的！）硬件，然后和大家一起努力，确保各方面都可以进行横向扩展。
◆横向扩展从两台机子开始。另外，进行冗余的时候也会涉及到横向扩展。
◆尽可能的横向扩展，但是不要傻乎乎的扩展。在MySQL复制中有一个经典的白痴扩展的例子：使用一个master对很多个slave。所有的slave必须完成全部的写入，而写入次数是与读取次数成比例增加的（大多数应用都是这样）。也就是说，你添加的slave越多，通过添加slave扩展的资源就越少。
◆留意一下替代的解决方案。按照用户或区域对多个数据库进行划分，同时避免增加过多的slave。实际上，有许多种方法可以达到这个目的。
◆一切都可能扩展！路由器，交换机，负载均衡器，Web服务器，数据库，等等。
◆记得纵向扩展吗？以前那些邪恶的大型机们有很多核，很多IO板，配备了非常昂贵的存储设备。而现在，多核这个概念开始蔓延了。
◆RAM是廉价的。
◆将以上两点合并起来，这意味着你只需要再次合并服务就可以了。这儿有一个负载均衡器，那儿有一个Web服务器……如果一个应用程序可以使用许多个CPU（比如apache），那么这是完美的。如果它不能（比如memcached），那么你最终可能会由于离散的服务太多而浪费掉大量的可用资源。
◆作业系统（job systems）也许可以填补这个鸿沟。哪里的核心的越多，哪里的工作线程就越多。
缓存
◆对于开发者和系统运维人员来说，缓存可是个好东西，值得大力发展！的确，它是不可思议的。它是与众不同的。有时你可能必须要为它做一个权衡。有效地使用缓存可以让系统的整体性能提升10倍之多。对于你当前的系统来说，这是一个巨大的“放大镜”，并且，它的成本在总成本中只占很小的一部分。
◆Memcached。它可以为服务提供缓存，让数据库结构非标准化（这可以提升性能！），对squid缓存进行优化，甚至可以提高操作系统缓存的利用率。
◆测试它，玩弄它，并打破它。使用缓存会带来新的问题。要做好准备。
让工作异步化
◆可以使用Starling, Gearman, The Schwartz等工具。作业系统可以给应用程序提供更多的灵活性。工作线程可以一次性地产生出来，也可以是持久的（载入缓存数据，准备数据等）。它们可以在不同的硬件上，它们的地理位置也可以不同。它们既可以是同步的，也可以是异步的。
◆维护这些东西是一个运维人员的问题。使用它们既是开发者的问题也是运维人员的问题。
◆当用户点击“给我所有的朋友发送邮件”的时候，把这个工作列入计划，然后马上说：“OK，已经完成了！你的朋友马上会收到你的邮件！”——通过异步化的方式来处理这个工作。
◆作业系统是衔接各个服务的一个场所。博客投递-〉IM通知，定期计费-〉收费服务，网关认证等。
◆容易扩展。在请求进入的地方会有一些瓶颈，所有的工作线程必须要做的事情就是“拉”。这个是相对于HTTP中大量推/拉的状态而言的。
安全和巡查
◆一定要安装安全更新！这十分重要！有很多疯狂的网络专家致力于在尽可能短的时间内给你提供这些更新。不要因为你害怕改变而让他们白白地付出劳动。
◆安全性也是分层的。明白你能确保什么，以及不能做什么。MySQL有密码访问机制，并不意味着可以允许直接通过互联网来访问它。
◆在SSH上禁用密码。使用经过加密的passphrase密钥来进行身份验证。远程的用户无法猜出你的私有密钥。他们必须从你这里才能得到它。把它保管好。做好这点，就没必要在防火墙中关闭你的SSH端口了。
◆搞清楚你的应用程序是如何工作的，它具体需要做些什么，并相应的进行调整。比如说，如果你的应用当中，只有付费页面和Twitter投递服务是需要连接外部互联网的，那么就把它们做成工作线程。将这部分工作线程放在特定的设备中，让它们只能访问特定的主机。这可以神不知鬼不觉地把你的网络的其余部分保护起来。
◆对于PHP站点来说，以上这些建议尤其重要，但是在其他地方，它们也可以发挥作用。如果有人要入侵，那么多半是通过你的应用。即使有人从前门入侵了系统，也要让他们花费很大精力才能进入保险箱。你需要确保的是他们无法将数据带走或上传至别的什么服务器上。
◆除了这些具体的建议之外，你还应该多读一些资料。自己判断，自己动手测试。如果你不知道一个安全模型是如何工作的，一时半会儿可能问题不大，但是这就会导致你不知道它的限制在哪里，甚至于无法判断它是否在工作。
◆基于测试，理论，攻击树的安全机制是不会在背后给你一刀的。当人们构想出模糊的安全模型的时候我也很喜欢它，但是像我这样的普通人都可以把它弄的支离破碎。
◆尽可能地进行巡查！登录，退出，以及使用的命令都要进行审查。对面向外部服务的所有访问，包括所有在请求中指定的参数，都要进行审查。对于你的应用程序来说，找出极值，然后彻底禁止输入超出范围的值。做你能做的所有事情，让数据以可追溯的方式工作。
◆如果你怀疑某些东西可能会被破坏，应该采取适当的预防措施，最好懂得一点计算机取证方面的知识（或者聘请一个专门从事这项业务的公司）。通过移除可疑的网络访问来做出响应，通过一系列的控制台或直接通过终端来检查整个系统。在已经被破坏的机器上，避免使用任何的服务，配置文件，或数据。很多人都是“清除了一个木马”，但是不知道它是怎么进来的——这样并不算真正地清除了这个木马。
◆如果你有安全团队，取证专家，或其他人手，那么你尽量不要接触那台机器，把它隔离起来。这意味着不要重新启动它来“清除一些奇怪的进程”。他们需要这些证据。如果你必须这么做，就去做吧，但是要记得把系统彻底地清理干净，打上所有的安全更新，尽量搞清楚他们是否已经破坏了重要的数据。做你能做的所有事情。
◆安全实际上是一种权衡。如果你做错了，开发者和用户们都会“揭竿而起”：他们会找到一些方法来绕过安全机制。如果他们可以绕过它，那说明你的工作并没有做好。如果他们不能绕过它，那么他们也许会放弃，然后离开。
◆紧抓访问控制。这意味着运维人员必须要为已经锁上门的“房间”提供一些窗户。不让开发人员进入生产环境，意味着他们必须抹黑解决难题。你的确不能让开发者们直接对服务进行修改，但是你可以提供日志工具和调试工具等等。对于各种产品来说，这些都是成功的秘诀。

交流篇
通过多种方式来学习
◆订阅一些RSS feed，每星期至少阅读几篇好文章。LWN，kerneltrap，undeadly.org。凡是相关的，或是仅仅是有点擦边的内容都应该关注。
◆阅读“达人”的博文。有时他们会投递一些有趣的主题，并且我们还可以通过评论直接和博主进行交流。
◆阅读几篇非“达人”的博文。通过他们遇到的问题，或者他们做了但没有做好的工作，我们可以找到一些感觉。（译注：这一点我个人深有体会。阅读一些新手的博文，我们常常可以得到启发，因为我们的一些做法虽然不会出问题，但是太程式化了，每天都重复同样的事情，我们无法进步，而新手由于缺乏经验，他们会不断地尝试各种做法，他们遇到的问题很可能是我们没有遇到过的，这对我们来说是一笔财富。）
◆想尽办法认识一些可以“痛扁”你的人。注意，一定要谦虚。
◆通过多种来源学习。通过多种方式吸收知识有助于找到最适合你的方式。
◆仔细研读其他公司成功或失败方面的故事。可以尝试打电话给他们的CTO，通过免费的午餐从他们那里获取一些有价值的建议。
尝试各种事情
◆如果你不断地进行尝试，你会发现你能做的事情远远超出了你的想象。以前从来没有见到过？那就试试看。
◆尽量不做一只危险的“菜鸟”。在你有把握不会把整个房间都烧掉以前，应该在“沙箱”中进行尝试。
真正地搞清楚冗余是怎么一回事
◆真正地搞清楚冗余会对哪些事情造成怎样的影响。在什么情况下它可以发挥作用，在什么情况下它无法发挥作用。
◆尝试破坏你的系统。你可以在测试实验室中尝试，有时也可以在生产系统中这样做。了解一下当你处于受限状态中的时候可以做什么。比如，拔掉电源，抽出网卡，杀死进程，拔掉几根内存，抽掉硬盘，拔掉网线。
◆在冗余存在的情况下尝试替换和升级系统。
真正地理解可扩展性
◆关于如何开发出可扩展的系统，有很多的资料可以参考。虽然你不用自己编写一个这样的系统，但是你要尽量搞清楚这方面的理论知识。
◆学习虚拟化。创建几个虚拟机，然后尝试着摆弄一下针对多台机器的应用程序。在本地的不同的端口上运行多个实例。
◆通常，运维人员要做一些系统承载量方面的计划。如果你不清楚应该把什么资源应该添加到哪里，你就不会知道应该添加些什么。
成为一个能够解决问题的超级明星
◆问题忽然发生，而时间是宝贵的。你必须要有自己的知识储备，并高效的使用它们。
◆经常练习着解决问题。挑选出一个可以正常工作的完美页面，然后试着跟踪一下它是如何工作的。
◆strace, ltrace, lsof, logs
◆搞清楚load != load（编者注：此处理解为load参数不等同于真正的系统负载情况）。主机运行情况的所有信息都需要查看。
◆熟悉IO系统相关的工具。“不可思议”的性能问题通常都是由于你的RAID或SAN配置出了什么问题。
◆记录文档。Checklist，解决问题的技巧，构建工具等。
◆构建更多的工具。不只是为了你自己，也是为了其他人。你也可以给现有的工具添加一些功能。
和IT人员一起工作
◆信不信由你，运维人员和IT人员之间存在交集。
◆运维人员必须要为服务器维护高带宽的网络访问。IT人员必须要做同样的事情，只是他们的服务对象是人。IT人员也往往是运维人员进入数据中心的“桥梁”。在这一点上，大家在一起工作是很有实际意义的。
◆彼此的分工要明确。IT人员应该负责管理邮件，而运维人员应该负责管理开发环境的服务器。不要插手职责之外的事情，尽最大的努力把你自己的事情做好。
◆不要疏远他人。Mac是流行的，Linux也（慢慢地）获得了一些市场份额。信不信由你，强迫大家都使用微软的生产软件可能会对你造成不好的影响。实际上有许多替代品，你可以试试看。在你的公司中，很可能熟悉Google应用的人比熟悉Outlook的人要多。
◆尽可能的让大家觉得Unix并不难用，毕竟这是他们要支持的系统，你肯定希望他们对Unix更加熟悉一些。当然，除非你家里是卖Windows的。
和开发人员一起工作
◆你们都为同一个产品工作，你们的目的也是一致的。试着多配合一下。
◆一起开策略会议并不等于在一起工作。
◆开发人员更了解代码资源，运维人员更了解硬件和部署。把这一切都记在心里，你可以让一些事情变得更高效。
◆交叉培训。传播双方使用和设计工具的心得，这可以提高工具的可管理性和灵活性。
◆注意不要过多地要求对方。这不是“我们”VS“他们”。每一个人都是有人权的。每一个人都应该尽可能地为公司多做贡献，而不是为了他们自己。
◆如果大家相处的很融洽，就可以从容地应对各种紧急事件了。
和其他领域的运维一起工作
◆每个领域的运维都有他们自己的专长。网络，数据库，OS。不要忘记彼此多交流！
◆一味地墨守陈规是消极的，令人厌烦的。让你的运维们重复的做相同的工作可以很快的增加他们的流失率。要尊重系统运维们在网络运维们的背后观察学习的机会。
◆时刻记得给人们尝试，学习和成长的机会。
◆注意别给你最优秀的运维安排了太多的活儿。你想要用的运维是那种有能力给自己找出空闲时间的人。
◆浑水摸鱼者（编者注：原文为bad eggs，直译为坏蛋）。对待他们要足够强硬。大多数人在帮助之下是可以完成任务的，但是他们必须要学会独立。

实践篇
现在就修复它，而不是以后再修复它
◆如果一个Web服务器处于脱机状态，不要担心，因为你应该有10个备用的！
◆在一周中，专门挑出一天来“清理门户”。更换掉所有存在故障的硬件。在欢度周末之前，确保一切都是完好无损的。
◆如果令人讨厌的小问题突然发生了，在早上要做的第一件事情就是永久性的修复它们。日志塞满磁盘的情况在上周发生了两次？明天再说吧！如果总是这样，这些问题会堆积起来……
◆如果你的构建过程是自动化的，充分利用这个优势来修复一些你可以马上修复的问题，或许也可以批量进行修复。
让每一件事情都自动化
◆人们无法（轻易地）搞乱脚本化的任务。
◆从第二次开始自动化。如果第一次你必须手工来做一件事情，那么把你做的事情写入一个脚本。
◆带注释的脚本是绝佳的文档。与其把如何安装一些东西的方法详细地写到长达20页文档中，还不如编写一个可以自解释的脚本。
◆脚本可以被放到自动化的构建过程中。如果要更接近这个目标，应该把一些经常做的事情都应该变成“零时间”的任务。
只进行必要的变更
◆只做小规模的，独立的变更。
◆如果不是必须改变，那么就保持原样。
◆这也意味着你必须搞清楚什么时候才应该进行变更。找出什么东西是必须要进行变更的，然后对它进行升级，把它拿出来，让它标准化。
Design for change
◆这里的Design for change（编辑注：技术篇的第一条也是Design for change）针对个人的成长。朝快速解决问题大师的方向努力吧。
◆如果快速解决问题比较困难，那么你可以学习一些基础知识，做出一张清晰的升级路线图。虽然你的新邮件系统也许并不是你梦想中的、带有强大反垃圾邮件功能的巨大系统；但是架设两台配置干净的postfix邮件服务器会比你想象中的效果还要好。
◆大家都倾向于把未完成的项目放在那里置之不理。这是你要避免的。
尽快地把更新的内容投入实践
◆一般来说，运维工作就是要让代码更好地运行。并行化，建立起回滚重启机制。
◆运行内容包括软件更新，安全补丁，配置变更。
◆使用puppet，cfengine以及你需要的任何工具对配置进行控制。让它干净，简洁，并且容易操作。
◆文件数量越少越好。如果只是为了推出一个新的数据库就要在20个文件中分别添加一行，那么你的方法一定是错误的。创建简单的模板，不要重复编辑需要手工编辑的数据。
规范化，坚持按照规范来行事
◆OS的规范，httpd的规范，数据库的规范，打包系统的规范。
◆坚持按照这些规范来行事。对一些方法进行调整和改进，让它变得更有意义。
◆永远不要紧抓着主版本不放。如果你的产品功能还没有永久性地冻结，你就必须要按照规范继续向前推进，把过去的一些事情都抛在脑后。
◆按照规范来做的事情越多，你的工具可以发挥作用的场合就会越多。用于支持其他运维领域的软件包越多，可以适应的场景也越多。
文档化
◆把流程文档化
◆把产品文档化
◆Deep Trees和Shallow Trees
◆不要让文档出现冗余。如果一个脚本的帮助文档很长，可以进行引用。好的文档是一个持续改进的过程，它要一直保持准确。
◆把文档和代码，perldoc，pydoc等联系起来。
◆过期的文档是有害的。留出一些时间来更新它们。当新的员工遇到问题的时候，和新的员工坐下来一起更新文档。
◆适当地使用问题跟踪系统（issue tracking）。为操作历史保留文档是十分重要的，以避免为了某个DNS故障的重现去骚扰他人。
使用源代码控制工具
◆使用git或者mercurial。避免使用SVN。
◆把配置文件、脚本等各种东西都放到源代码控制工具中管理起来。
◆为代码迁出提供各种入口。
◆保持迁出的严谨性，精准性和可控制性。禁止提交无法进行审核的变更。应该提交的变更应该是不用源代码控制工具也能容易地进行测试的（在虚拟机环境下，可以直接在一个单独的测试机器上进行测试）。
招聘
◆区分出固执的人和精明的人
◆不要避免聘请“老前辈”。某个领域的“老前辈”可能已经跟不上技术变革的脚步，以至于你可能不想聘请他们。但是，总是要有几个“超级巨星”来压住阵脚的。
◆不要避免聘请新手。我认识的很多人都是从一个真正的新手开始的（包括我自己！实际上，我认为我自己一直是一个新手）。经过这个阶段以后，他们会迅速地成长起来。现在正是确立职业生涯的时候。我相信我们中的绝大多数人都是这样的。当然，不包括那些不学习的人，没有积极性的人，或者入错行的人。
避免提供商锁入，同时和你的提供商保持良好的关系
◆购买专有硬件的主要劣势是提供商锁入，你不得不总是使用这个提供商的产品。这可能是一个特殊的SAN，NAS，也可能是特殊用途的随设备存储，备份系统等等（51CTO推荐阅读：别把鸡蛋放在一个篮子里）。尽量避免发生这种事情。如果你完全按照上面的设计建议来行事，那么应该可以很快地在不同的平台上搭建起测试环境。然后，你可以进行硬件评估，自由地进行选择。
◆如果所有东西都很深奥，都很不明朗，都还没有经过文档化，并且直接依赖于专有的负载均衡器……那么最好别用，因为用了你就不自由。
◆对你最终选择的提供商好一点。如果你每一次采购都在价格方面把他们逼到墙角，那么你只能得到一些垃圾硬件了。
◆有时候数据中心有很多潜在的可用资源。尽量把一些免费的远程协助服务写到合同里，比如就更换硬盘驱动器，提供商的出货/RMA条款，以及一些基础硬件的安装等方面的细则进行谈判。我有一个机架的设备，其安装上架的过程我们的人完全没有操心……真的很不错。
给开源一个机会
◆nginx，mongrel，lighttpd，apache，perlbal，mogilefs，memcached，squid，OpenBGPD，PF，IPTables，LVS，MySQL，Postgres，等等。在你选择可信、可靠、昂贵的专有安装程序以前，给开源一个机会。你会发现使用开源软件意味着可以自己添加插件，扩展，代码修复补丁，或者你可以把一些自己无法实现的功能外包出去。在我看来，开源软件是很可靠的，它们通常比巨大负载之下的大型的，昂贵的硬件更可靠。
◆“一分钱一分货”这种思想是一个彻底的谎言。如果你无法让开源软件为你工作，需要协助，你可以找一个提供商。如果你的团队既睿智又积极主动，这些小伙子们想要搞清楚他们的基础设施是如何工作的，那么你一定无法抵挡来自于GPL或BSD系统的诱惑。
◆MySQL和Postgres都不错。如果你要使用它们，可以权衡一下利弊。没有什么东西会在晚上从你的衣橱里爬出来“吃”掉你的数据。与经过测试的、稳定的冗余master<->slave MySQL集群实例相比，其实庞大的、处于脱机状态的Oracle实例更容易把事情搞的一团糟。
◆关于LAMP架构的文章数不胜数。无数知名网站、ISP、甚至企业现在都在使用开源软件。给开源一个机会。最糟糕的结果也不过是浪费一些时间，而最后从你那些心惊胆战的提供商们那里获得一些不错的报价。
【51CTO.com译稿，转载请注明原文作译者和出处。】
原文：