分享系统运维诀窍[操作系统]

 ◆Google的诀窍是精确的——“为改变而计划”.“改变”就是不得不布置新的软件,进级现有的软件,举行扩大,设备破坏,以及人员流动等.
    ◆每一件事情都是在探求均衡点.你大概会认为把你的系统和某个操作系统或某个Linux发行版紧紧地绑定在一同是一个好主张,但事实上这跟把它们完好断绝一样糟.假照实在有必要,你可以举行分层,并利用一点间接性.
    ◆这并不意味着你的系统必须是平台无关的.其实我们的目的很简单:一变二,二变二十,一个系统必须可以应对各种突发事件.也就是说,假如一个系统管理员被大众汽车撞了,你有应对的筹划!假如挂载的硬盘呈现弊端了,你有应对的筹划!假如某些人运行了rm -rf /,你也有应对的筹划!增量的举行变更.记得安全更新,以及保持内容更新.
    利用自动的,可反复的构建历程
    ◆不要手动构建任何东西.假如你一定需求手动构建,那么就做两遍,在做第二遍的时刻把用到全部的号令都提取出来.
    ◆下面这一点非常重要:将新硬件上线到生产环境的历程不该该超越15分钟,并且这个历程必须充足简单.不然,当一个服务器呈现弊端,而没有人知道若何改换它的时刻,你就该倒运了.
    ◆下面这一条是普世真理:这个世界上不存在“一次性”的服务器构建.即便你的服务器只需求构建一次,但只要你构建过一次,就一定会有第二次.比方,当它破坏的时刻,大概你必须举行一次庞大的进级才能让它在在接下来的两年时间里越发安定的时刻.
    ◆测试,查抄新构建好的服务器.这应当是对比简单的,因为你的构建历程都是自动化的,对吧!
    ◆脚本化的构建,意味着从某个Linux发行版的V3进级到V4应当是很快的.安装
    V4,对脚本举行测试.假若有问题,参考文档并修复它,直到它可以再次正常工作.这最多应当是一个星期的工作,而不是一个长达一年的浩荡工程（因为当时,方才完成的V5已经公布了!）
    利用冗余
    ◆简单重新构建,并不意味着你可以轻忽冗余.跳转盒,邮件服务器,计费网关,等等.假如此中的一半挂掉了结并不造成客户的宕机,生活将会变得越发简单.
    ◆按照以上方针来做的话,当某个设备在清晨3点呈现弊端的时刻,你可以“今后再处理那个呈现弊端的设备!”,把冗余的机械先替换上去.
    ◆下面这一条是个聊胜于无的办理筹划:Rsync.DRBD大概也不是一个完善的办理筹划,但是它可以供应令人称奇的服务.（参考阅读:DRBD笔记,DRBD实例1,DRBD实例2）
    利用备份
    ◆备份是个严厉的话题.利用硬盘,烧录磁带.紧缩它们,移动它们,并行地运行.对每一样东西举行备份!
    ◆假如你的构建历程是自动的,整个历程都可以被备份.假如到目前为止的几条你都做到了,那么一个真正的“灾难恢复”筹划大概并非那么遥不可及的
    监控精确的东西
    ◆监控你能监控的全部东西,并且要用精确的办法来举行监控.假如你的NFS服务器挂掉了,不要让你的监控工具发送1000条警报.假如对你的系统来说,超时的警报没有什么实际意义,那就别让它发.要针对各种具体的情形举行成功性测试:是的,这个服务可以举行一个新的TCP衔接,它乃至可以呼应,但是它还记得它要做什么工作吗?
    ◆假如你有500个Web服务器,此中一个挂掉了,你大概没必要即刻知道这个情形.但是,假如负载均衡器没有把这台机子踢出去,招致错误报告呈目前了用户的屏幕上,那么你必须知道这个情形!
    有关数据图形化,历史数据
◆图形的作用是让趋向可视化.历史数据的作用是让你对数据举行切确的解析.不要把这二者混为一谈!对图形举行目测,很简单得到错误的数值.很多站点都利用rrd范例的系统或其他的数据聚合系统,此类系统按照时间对数据举行平均化处理,然后保存在存储空间中.这不但仅是难以阅读的问题:这根本是错误的!
    ◆假如你要浏览数百张图才能切确地对一个问题举行定位,那真是糟透了.想要找出极值?请利用脚本提取数据.
    ◆假如你必须利用图形来办理问题,尽大概把各种高级的概念整合到一个单一的页面中,然后让这个页面链接到拥有具体信息的子页面中.假如你在数据库负载中可以看到一个峰值,你可以点击这个页面对那些数据库举行概览,然后找到那一两台可疑的机械.基本的理念是尽快地缩小范围,尽大概的削减猜想.
    日记记录,利用多个数据流
    ◆无论是独立工作还是与开辟

[1] [2] [3]  下一页