1) 承载能力优先 ——随后再进行优化 —— 不遵守这条规则必定带来故障停机时间。不要在故障停机时间的压力下进行优化——要先集中精力提高承载能力。
2) 以Postgres为例，一定要确保你的每一个网络都能匹配得上你的WAL文件、Slony复制、快照技术以及基于磁盘的DB版本化（快照的衍生品）
3) 不要把问题‘优化’到你的架构之中。为了解决问题而新加进来的一些东西往往后来都会变成运维沉重的负担。 要确保在运维工程化中开发出来的工具交接完整。过后再回头进行进一步的开发往往不灵。更重要的是，变更请求可能会破坏已经安排好的工程计划。
4） 保持简单。保持简单，因为你很聪明 别把事搞的太复杂 因为你行的。
(译者:KISS 原则 Keep It Simple, Stupid)
5）应该非常谨慎地使用 缓存 ，为了保护资源一致性，它很难进行水平缩放。
如果你作的是一个可以横向扩展的东西，
明智或审慎的做法是不要添加的缓存层。
如果非要使用，它应该是为最终用户获得性能，
不是为了赢得一个网站的容量;
6） 不要所有代码都自己写; 不要所有东西都外包; 在合适的时间使用合适的工具,完成你的工作.
(译者: 不要重复造轮子)
7)协商-真正有效的谈判唯一方式是先作一些调研,制定一些可行的性方案.这样你可以挑选你的首席开发商,如果你真的需要. 别虚张声势.
8）一直保持N+1。如果N=1，无论任何情况下不要轻易使用+1，这个1只用于当N down机情况下。当使用冗余服务器来承载负载时候，不要让你的系统超过49%的负荷。当有机会能只用N+2的架构时候，使用它。
9）数据丢失不是任何一个公司所能承担的风险–这是举世所知的真理。数据丢失造成的损失远远大于保持数据不丢失所花的成本。
10）无论何时何地尽可能并行化。这是复路考虑最重要的手段。比如，如果利用MogileFS来做位置感知，并且需要实时的复制数据，一个可行的方法是每一台MogileFS服务器可以复制它的数据去MogileFS的负载均衡中心。尽可能多的启用多的平行。
11）阅读手册。至今，我还是坚持要先通读RAID卡的手册，以确认是否有什么细微的差别。恶魔都隐藏在细节里。做足功课吧！
12）知道瓶颈所在，并知道怎么去定位它，一层层排查，查找是不是硬盘、内存或者cpu的阻塞了。通常这个很简单。
13)定期做系统容量管理程序。积极一点。如果没有容量数据的曲线，你很难知道你系统的薄弱之处。
14）不要促成失败，不要害怕改变。
15）别挖陷阱给自己跳。不要认为你的工作成果将能作为未来的工作的动力。
16 ）运维人员写的代码应该是运维工具，而不是应用软件。
17）在运维团队中，不要低估了项目管理、文档撰写以及财务分析人员的价值。他们比给予工资更有价值。
18）监控一切。报警异常问题。其他部分记录数据用来做趋势分析信息。
19）定期的流程查看各个地方的趋势数据。
20）不要把监控弄的很乱，不然他就没有啥意义了。
热门专题
