在运维管理的过程中，我发现了很多有价值的秘诀，本文是这些秘诀的一个总结。虽然这些秘诀可能比较“唯心”，但是我还是把它们总结出来了，相信它们会对你有帮助的。

　　Dormando的运维秘诀分成以下三大篇：

　　技术篇

　　交流篇

　　实践篇

　　下面先从技术篇开始。交流篇和实践篇会陆续整理放出。

　　技术篇

　　为变化而设计

　　◆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现在变得越来越好了(参考阅读：分布式文件系统试用比较)。实际上，还有其他类似的项目可以免费(或廉价)地维护大量的存储文件。类似的系统基本上都是是为youtube.com、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站点来说，以上这些建议尤其重要，但是在其他地方，它们也可以发挥作用。如果有人要入侵，那么多半是通过你的应用。即使有人从前门入侵了系统，也要让他们花费很大精力才能进入保险箱。你需要确保的是他们无法将数据带走或上传至别的什么服务器上。

　　◆除了这些具体的建议之外，你还应该多读一些资料。自己判断，自己动手测试。如果你不知道一个安全模型是如何工作的，一时半会儿可能问题不大，但是这就会导致你不知道它的限制在哪里，甚至于无法判断它是否在工作。

　　◆基于测试，理论，攻击树的安全机制是不会在背后给你一刀的。当人们构想出模糊的安全模型的时候我也很喜欢它，但是像我这样的普通人都可以把它弄的支离破碎。

　　◆尽可能地进行巡查!登录，退出，以及使用的命令都要进行审查。对面向外部服务的所有访问，包括所有在请求中指定的参数，都要进行审查。对于你的应用程序来说，找出极值，然后彻底禁止输入超出范围的值。做你能做的所有事情，让数据以可追溯的方式工作。

　　◆如果你怀疑某些东西可能会被破坏，应该采取适当的预防措施，最好懂得一点计算机取证方面的知识(或者聘请一个专门从事这项业务的公司)。通过移除可疑的网络访问来做出响应，通过一系列的控制台或直接通过终端来检查整个系统。在已经被破坏的机器上，避免使用任何的服务，配置文件，或数据。很多人都是“清除了一个木马”，但是不知道它是怎么进来的——这样并不算真正地清除了这个木马。

　　◆如果你有安全团队，取证专家，或其他人手，那么你尽量不要接触那台机器，把它隔离起来。这意味着不要重新启动它来“清除一些奇怪的进程”。他们需要这些证据。如果你必须这么做，就去做吧，但是要记得把系统彻底地清理干净，打上所有的安全更新，尽量搞清楚他们是否已经破坏了重要的数据。做你能做的所有事情。

　　◆安全实际上是一种权衡。如果你做错了，开发者和用户们都会“揭竿而起”：他们会找到一些方法来绕过安全机制。如果他们可以绕过它，那说明你的工作并没有做好。如果他们不能绕过它，那么他们也许会放弃，然后离开。

　　◆紧抓访问控制。这意味着运维人员必须要为已经锁上门的“房间”提供一些窗户。不让开发人员进入生产环境，意味着他们必须抹黑解决难题。你的确不能让开发者们直接对服务进行修改，但是你可以提供日志工具和调试工具等等。对于各种产品来说，这些都是成功的秘诀。