2016-03-29 16:09:39
来 源
中存储网
运维基础
国外牛人分享系统运维秘诀:Git,招聘与软硬件选择(实践篇),运维工作就是要让代码更好地运行。并行化,建立起回滚重启机制。

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

  1. 技术篇
  2. 交流篇
  3. 实践篇

实践篇

现在就修复它,而不是以后再修复它

◆如果一个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、甚至企业现在都在使用开源软件。给开源一个机会。最糟糕的结果也不过是浪费一些时间,而最后从你那些心惊胆战的提供商们那里获得一些不错的报价。

原文:http://dormando.livejournal.com/484577.html

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。