论坛徽章:: 0

1楼 [报告]

发表于 2011-06-30 11:09 |只看该作者

使用备份\r\n\r\n　　◆备份是个严肃的话题。使用硬盘，烧录磁带。压缩它们，移动它们，并行地运行。对每一样东西进行备份!\r\n\r\n　　◆如果你的构建过程是自动的，整个过程都可以被备份。如果到目前为止的几条你都做到了，那么一个真正的“灾难恢复”计划也许并不是那么遥不可及的。\r\n\r\n　　监控正确的东西\r\n\r\n　　◆监控你能监控的所有东西，而且要用正确的方法来进行监控。如果你的NFS服务器挂掉了，不要让你的监控工具发送1000条警报。如果对你的系统来说，超时的警报没有什么实际意义，那就别让它发。要针对各种具体的情况进行成功性测试：是的，这个服务可以进行一个新的TCP连接，它甚至可以响应，但是它还记得它要做什么工作吗?\r\n\r\n　　◆如果你有500个Web服务器，其中一个挂掉了，你可能不必马上知道这个情况。但是，如果负载均衡器没有把这台机子踢出去，导致错误报告出现在了用户的屏幕上，那么你必须知道这个情况！\r\n\r\n　　有关数据图形化，历史数据\r\n\r\n　　◆图形的作用是让趋势可视化。历史数据的作用是让你对数据进行精确的分析。不要把这两者混为一谈!对图形进行目测，很容易获得错误的数值。许多站点都使用rrd类型的系统或其他的数据聚合系统，此类系统按照时间对数据进行平均化处理，然后保存在存储空间中。这不仅仅是难以阅读的问题：这根本是错误的!\r\n\r\n　　◆如果你要浏览数百张图才能精确地对一个问题进行定位，那真是糟透了。想要找出极值?请使用脚本提取数据。\r\n\r\n　　◆如果你必须使用图形来解决问题，尽量把各种高级的概念整合到一个单一的页面中，然后让这个页面链接到拥有具体信息的子页面中。如果你在数据库负载中可以看到一个峰值，你可以点击这个页面对那些数据库进行概览，然后找到那一两台可疑的机器。基本的理念是尽快地缩小范围，尽可能的减少猜测。\r\n\r\n　　日志记录，使用多个数据流\r\n\r\n　　◆无论是独立工作还是与开发部门合作，都要把尽可能多的有用的信息记录到日志中。无论是分析之后再保存，还是直接扔进数据库中生成报告，这些都无所谓。信息终归是有用的。\r\n\r\n　　◆有用的例子：页面呈现时间(哪个页面?哪个设备?)，面向用户的错误，数据库和内部服务错误，带宽使用率等。\r\n\r\n　　◆建立图表，报告，并对产生的历史数据进行比较。\r\n\r\n　　◆报告是十分重要的。每周或每天对你的基础设施变更进行汇总。\r\n\r\n　　数据存储方式，数据库\r\n\r\n　　◆诚然，数据库运维是一套完整而独立的知识体系。但是有时，你不能把一切都丢给你的DBA。\r\n\r\n　　◆拥有多个冗余的数据库会给你带来很多好处。对于一个庞大的Oracle实例来说，从前，很多运维工作需要好几个小时的关机维护时间;而现在，完全可以在服务运行的同时进行。MySQL和数据库复制功能是一件奇妙的事情。\r\n\r\n　　◆和DBA们一起努力，尽量为可能会发生问题的数据库争取到最好的硬件。RAID 10，大量的RAM，高速硬盘，乃至于强悍的RAM磁盘和SSD。运维人员对提供商要货比三家，这样可以减轻DBA对硬件的恐惧。从长远来看，找出哪个品牌的硬件更加优秀会节省大量的资金。 \r\n

errrra

稍有积蓄

论坛徽章:: 0

2楼 [报告]

发表于 2011-06-30 11:11 |只看该作者

欢迎进入网管技术社区，与100万网管技术员们一起互动交流>>点击进入 \r\n\r\n　　◆如果你有安全团队，取证专家，或其他人手，那么你尽量不要接触那台机器，把它隔离起来。这意味着不要重新启动它来“清除一些奇怪的进程”。他们需要这些证据。如果你必须这么做，就去做吧，但是要记得把系统彻底地清理干净，打上所有的安全更新，尽量搞清楚他们是否已经破坏了重要的数据。做你能做的所有事情。\r\n\r\n　　◆安全实际上是一种权衡。如果你做错了，开发者和用户们都会“揭竿而起”：他们会找到一些方法来绕过安全机制。如果他们可以绕过它，那说明你的工作并没有做好。如果他们不能绕过它，那么他们也许会放弃，然后离开。\r\n\r\n　　◆紧抓访问控制。这意味着运维人员必须要为已经锁上门的“房间”提供一些窗户。不让开发人员进入生产环境，意味着他们必须抹黑解决难题。你的确不能让开发者们直接对服务进行修改，但是你可以提供日志工具和调试工具等等。对于各种产品来说，这些都是成功的秘诀。\r\n \r\n