若是遭受要紧运维问题，应该采用哪些正确递次？了解这少量越过要紧。若是你作念出造作的政策采纳，你可能会失去责任。前几天，我和一位DBA聊天，他在十年前经历了一次越过着名的失败。最终，他仍是免不了问起那场事故。我很心爱听别东谈主讲指示而不是资格，因为成效的资格经常都是相似的，独一资格是资产买不来的。尽管转头惨痛的指示关于当事东谈主来说可能是骄气的，但这么的转头经常是一种价值的提取。

他转头事件后示意，咱们那时最大的造作决定即是按照厂商的提倡罢手使用第三方复制开发。事实上，在这种业务岑岭、开发性能故障的场景下，许多身分都是省略情的。咱们对第三方开发的特色也知之甚少。咱们那时不应该作念这种操作。违犯，咱们应该先限度业务流量以保执系统开动，然后在生意厅放工后而不是在生意岑岭时段进行高风险操作。行为。若是真实这么，事故粗略就不错幸免。

他讲的这个问题即是我今天要讲的第一个原则。在各式处置政策中，当先采纳最苟简、风险最小的处置政策；在你所承担的拖累中，采纳所承担的拖累最小的一项。举例，诚然系统开动性能大幅下落，但仍在业务的可容忍界限内，莫得恶化的迹象，咱们不错采纳承担此次性能故障的拖累。若是咱们不想承担这个拖累，而必须在短时代内束缚问题，那么咱们就应该在我方的能力界限内悉力进行优化和袭击。若是那时的流毒超出了我方的能力界限，与其冒着犯造作的风险而承担更大的拖累，不如承担这较小的拖累。

在现实责任中，瓦解这少量并罢免上述原则并拦阻易。咱们在现实责任中看到的经常是较小的运维故障因处理不妥而导致超大故障的情况。比如RAC中某个节点出现故障宕机了，这个时候咱们该何如办？大多数一又友可能会采纳重启，也有一些一又友可能会采纳不雅望，什么也不作念。

事实上，若是是一些负载较高的中枢业务系统，那么咱们当先应该检查活节点的日记，望望是否有极端情况，是否存在宕机的风险。然后不雅察活节点的活跃会话数、会话数、负载、恭候事件等，望望是否存在风险。若是存在风险，当先通过杀死会话来踏实系统。一切踏实后，分析宕机原因并详情重启故障实例的风险。

若是您无法判断风险，且那时随机是业务岑岭，您不错采纳暂时不重启故障节点，待业务岑岭畴昔后再处理。最忌讳的是在RAC故障切换后不久、业务还莫得踏实之前，重启故障节点。这种作念法的痛苦例子多如牛毛。

第二个原则是不要合计一切都在你的掌控之中。动作又名DBA，数据中心有太多不懂的东西，是以在酌量问题的时候一定要留有想考的空间。不要采纳看起来最佳的束缚决策。

大致十五年前，某公司数据中心的两个机房都停电了。诚然数据中心接纳两脉络会供电，但供电公司的两脉络会同期出现故障。这种故障是由于数据中心建设时为了省钱而采纳双路供电形成的。诚然两路电源来自两个220KV变电站，但上变电站是同样的。若是上司变电站出现故障，两路供电都将丧失，电力公司无法给出明确的成赶紧间。

在处理这个问题时，我给他们的IT总监打电话商议政策。我的政策是先罢手中枢业务系统和存储，然后让外围系统先开动。我的根由是，现时是盛夏，若是三四个小时莫得回电，诚然UPS能活下来，但机房温渡过高，中枢系统会被关闭，从而导致几个小时的停机。小时。但是，IT运用不承诺这个规画。他投诚，若是外围系统能在八小时内关闭并还原供电，而他的UPS也能坚执下去，中枢系统也能保住，那将是一个伟大的成立。关于机房的温度，他立即找到一家制冰公司，让他们将冰块送到机房降温。

最终，机房内的温度和湿度超标，导致中枢存储系统自动保护，因损坏而自动关闭。中枢系统数据库出现大宗坏块，ADG备份机也出现故障，磁带库磁带损坏无法还原。终末咱们用BBED帮他强行拉起数据库，导出数据，重建数据库，补充丢失的数据。中枢系统用了两天时代才还原里面功绩，用了一周时代才还原对外提供查单功绩，对公司声誉形成了很大影响。

当发生一些罕见严重的运维故障时，字据我方的能力采纳要采用的递次是DBA的一个要紧原则，当先酌量那些风险和危害较小、我方比拟擅所长理的要领。这是DBA保命的要紧原则。一朝这种事故演变成要紧故障，就必须有东谈主承担拖累，而DBA即是最佳的替罪羊。

鱼云专注于提供高性能云功绩器和物理功绩器租借功绩。咱们竭力于为企业提供安全、踏实、高效的束缚决策，确保数据无忧、业务顺畅。