如果在一个晴朗的夏日，配备您的设备的数据中心看起来像这样，您会有什么感觉？
大家好！ 我叫德米特里·萨姆索诺夫 (Dmitry Samsonov)，我是一名领先的系统管理员，从事“”。 照片显示了安装了为我们项目提供服务的设备的四个数据中心之一。 这些墙的后面有大约4台设备：服务器、数据存储系统、网络设备等。 — 几乎占我们所有设备的 ⅓。
大多数服务器都是Linux。 还有几十台运行 Windows (MS SQL) 的服务器，这是我们的遗产，多年来我们一直在系统地放弃它。
因此，5 年 2019 月 14 日下午 35:XNUMX，我们一个数据中心的工程师报告了火灾警报。
拒绝
14:45。 数据中心的小型烟雾事件发生的频率比您想象的要高。 大厅内的指标正常，所以我们的第一反应相对平静：他们禁止进行生产工作，即禁止任何配置更改、推出新版本等，除了与修复某些内容相关的工作。
愤怒
您是否尝试过从消防队员那里了解屋顶起火的具体位置，或者亲自登上燃烧的屋顶评估情况？ 通过五个人收到的信息的可信度是多少？
14：50。 已收到信息称火势已逼近冷却系统。 但它会来吗？ 值班系统管理员显示来自该数据中心前端的外部流量。
目前我们所有的服务前端都复制在三个数据中心，采用了DNS层面的平衡，可以让您从DNS中去掉一个数据中心的地址，从而避免用户在访问服务时可能出现的问题。 如果数据中心已经出现问题，它会自动退出轮换。 你可以在这里阅读更多：
火灾尚未对我们造成任何影响——用户和设备都没有受到影响。 难道是意外？ 《事故行动计划》文件第一节定义了“事故”的概念，该节结尾如下：
«如果有任何疑问，无论是否是意外，那么这就是意外！»
14:53。 任命一名事故协调员。
协调员是控制所有参与者之间的沟通、评估事故规模、使用紧急行动计划、吸引必要人员、控制修复完成以及最重要的是委派任何任务的人。 换句话说，这个人就是管理消除事故整个过程的人。
拍卖
15:01。 我们开始关闭与生产无关的服务器。
15:03。 正确关闭所有预留服务。
这不仅包括前端（用户此时不再访问）及其辅助服务（业务逻辑、缓存等），还包括复制因子为 2 或更大的各种数据库（, , , ETC。）。
15：06。 收到信息称数据中心的一个大厅发生火灾。 我们这个大厅里没有任何设备，但火可以从屋顶蔓延到大厅的事实极大地改变了正在发生的情况。
（后来发现，大厅没有任何物理威胁，因为它与屋顶是密封的。威胁仅针对该大厅的冷却系统。）
15:07。 我们允许在加速模式下在服务器上执行命令，而无需额外检查（).
15:08。 房间内的温度在正常范围内。
15：12。 据记录，大厅内的温度有所上升。
15:13。 数据中心一半以上的服务器已关闭。 我们继续。
15:16。 决定关闭所有设备。
15:21。 我们开始在没有正确关闭应用程序和操作系统的情况下关闭无状态服务器的电源。
15:23。 专门挑选了一批负责MS SQL的人（人数很少，服务对他们的依赖性不是很大，但是恢复过程比Cassandra等需要更多的时间和更复杂）。
Депрессия
15：25。 收到有关 16 个展馆中的 6 个展馆（7、8、9、XNUMX 号）停电的信息。 我们的设备位于7号馆和8号馆。 没有关于我们两个大厅（1号和3号）的信息。
通常情况下，发生火灾时，电源会立即关闭，但在本次事件中，由于消防员和数据中心技术人员的协调工作，并不是到处都关闭电源，也不是立即关闭电源，而是出于必要。
（后来发现8、9号房间的电源并没有被切断。）
15:28。 我们开始从其他数据中心的备份部署 MS SQL 数据库。
它需要多长时间？ 整个路由的网络带宽是否足够？
15：37。 修复了网络某些部分断开的问题。
管理网络和生产网络物理隔离。 如果生产网络可用，那么您可以转到服务器，停止应用程序并关闭操作系统。 如果不可用，则可以通过IPMI，停止应用程序并关闭操作系统。 如果没有网络，那么你什么也做不了。 “谢谢你，帽子！”，你想。
“是的，总的来说，存在很多混乱，”你可能也会想。
问题是，即使没有火灾，服务器也会产生大量的热量。 更准确地说，当有冷却时，它们会产生热量，而当没有冷却时，它们会产生地狱般的地狱，最好的情况是会熔化部分设备并关闭另一部分，最坏的情况是......导致设备内部着火。大厅，几乎可以保证摧毁一切。
15:39。 我们修复了conf 库的问题。
conf 库是同名服务的后端，所有生产应用程序都使用它来快速更改设置。 没有这个基础，我们就无法管理门户的运行，但门户本身同时可以工作。
15:41。 核心网络设备上的温度传感器记录的读数接近最大允许值。 这是一个占据整个机架的盒子，保证数据中心内部所有网络的运行。
15:42。 问题跟踪器和 wiki 不可用，切换到待机状态。
这不是生产，但如果发生事故，任何知识库的可用性都可能至关重要。
15:50。 其中一个监控系统已被禁用。
他们有好几个，他们负责服务的不同方面。 其中一些配置为在每个数据中心内自主工作（即，它们仅监控自己的数据中心），另一些则由分布式组件组成，可以在任何数据中心丢失时透明地生存。
在这种情况下它停止工作。 ，工作在主备模式。 切换至待机状态。
验收
15:51。 通过 IPMI，除了 MS SQL 之外，所有服务器都在没有正确关闭的情况下关闭。
如果需要，您准备好通过 IPMI 批量管理服务器了吗？
数据中心设备救援到此阶段就完成了。 能做的都已经做了。 有些同事可以休息一下。
16：13。 有消息称，屋顶空调氟利昂管道爆裂，这将导致火势扑灭后数据中心的启动时间延迟。
16:19。 根据数据中心技术人员提供的数据，大厅内的温度已经停止上升。
17:10。 恢复了conf数据库的工作。 现在我们可以更改应用程序设置。
如果一切都是容错的并且即使没有一个数据中心也能正常工作，为什么它如此重要？
首先，并非所有事物都是容错的。 还有各种辅助服务还不够完善，无法在数据中心故障的情况下生存，并且有主备模式的基础。 管理设置的能力使您能够采取一切必要措施，最大限度地减少事故后果对用户的影响，即使在困难的条件下也是如此。
其次，很明显数据中心的工作在接下来的几个小时内不会完全恢复，因此有必要采取措施，以免副本长期不可用而导致磁盘溢出等额外麻烦。其余的数据中心。
17:29。 披萨时间！ 我们雇用人，而不是机器人。
复原
18:02。 8号馆（我们的）、9号馆、10号馆、11号馆温度已经稳定。 其中一个仍然处于离线状态的设备（#7）包含我们的设备，并且那里的温度持续上升。
18:31。 他们批准启动 1 号和 3 号大厅的设备 - 这些大厅没有受到火灾的影响。
目前，服务器正在1号、3号、8号馆启动，从最关键的服务器开始。 检查所有正在运行的服务的正确操作。 7号馆仍然存在问题。
18:44。 数据中心技术人员发现，在7号大厅（只有我们的设备所在），很多服务器都没有关闭。 根据我们的数据，那里还有 26 台服务器。 重新检查后，发现有58台服务器。
20:18。 数据中心的技术人员通过走廊铺设的移动风管对没有空调的房间内进行吹气。
23:08。 让第一个管理员回家吧。 有人必须晚上睡觉才能继续明天的工作。 接下来，我们发布另一部分管理员和开发人员。
02:56。 我们推出了一切可以推出的东西。 我们通过自动测试对所有服务进行大量检查。
03:02。 最后一个第七大厅的空调已恢复。
03:36。 我们将数据中心的前端引入 DNS 中进行轮换。 从这一刻起，用户流量就开始来了。
我们将让大部分管理团队回家。 但我们留下了几个人。
小常见问题解答：
问：18:31 到 02:56 发生了什么？
答：根据灾难响应计划，我们从最重要的服务开始启动所有服务。 同时，聊天中的协调员将服务发布给免费管理员，由管理员检查操作系统和应用程序是否已启动，是否有任何错误，指标是否正常。 启动完成后，他在聊天中报告自己有空，并从协调员那里收到新服务。
该过程还受到失效铁的抑制。 即使操作系统关闭和服务器关闭都很顺利，一些服务器也会因为磁盘、内存、机箱突然出现故障而无法恢复。 当断电时，故障百分比会增加。
问：为什么不能一次性运行所有内容，然后修复监控中出现的问题？
A：一切都要循序渐进，因为服务之间存在依赖关系。 一切都应该立即检查，而不是等待监控——因为最好立即处理问题，而不是等待问题恶化。
7:40。 最后一位管理员（协调员）去睡觉了。 第一天的工作就完成了。
8:09。 第一批开发人员、数据中心工程师和管理员（包括新协调员）已开始恢复工作。
09:37。 我们开始提高 7 号大厅（最后一个）。
同时，我们继续修复其他大厅没有完成的事情：更换磁盘/内存/服务器、修复监控中所有“烧毁”的东西、主备方案中的反向角色切换等等小事情，但还是相当不错的。很多。
17:08。 我们允许所有常规生产工作。
21:45。 第二天的工作就完成了。
09:45。 今天是星期五。 监控中还存在不少小问题。 周末即将来临，每个人都想放松一下。 我们继续尽我们所能大规模修复一切。 本可推迟的常规管理任务已被推迟。 新协调员。
15:40。 突然，另一个数据中心的一半核心网络设备堆栈重新启动。 战线不再轮换，以尽量减少风险。 对于用户来说没有任何影响。 后来查明是机箱有故障。 协调员正在同时修复两起事故。
17:17。 另一个数据中心的网络运行已恢复，一切都已检查完毕。 数据中心正在轮换。
18:29。 第三天的工作以及事故后的总体恢复工作已经完成。
后记
04.04.2013年， 、《同学们》 ——三天来，门户完全或部分不可用。 在此期间，来自不同城市、不同公司的 100 多人（再次感谢！）在数据中心远程直接手动和自动修复了数千台服务器。
我们得出了结论。 为了防止这种情况再次发生，我们已经并将继续开展广泛的工作至今。
目前的事故与404事故的主要区别是什么？
- 我们有一个事故行动计划。 我们每季度进行一次演习 - 我们演练一组管理员（轮流）必须使用“灾难响应计划”解决的紧急情况。 领导系统管理员轮流履行协调员的角色。
- 每个季度，我们都会在测试模式下通过 LAN 和 WAN 网络隔离数据中心（依次），这使我们能够及时识别瓶颈。
- 坏驱动器更少，因为我们收紧了法规：更少的运行时间、更严格的 SMART 阈值、
- 我们完全放弃了 BerkeleyDB，这是一个旧的且不稳定的数据库，在服务器重新启动后需要大量时间来恢复。
- 我们减少了使用 MS SQL 的服务器数量，并减少了对其余服务器的依赖。
- 我们有自己的 ，过去两年我们一直在积极迁移所有服务。 云极大地简化了应用程序的整个工作周期，并且在发生事故时它提供了以下独特的工具：
- 一键正确停止所有应用程序；
- 从故障服务器简单迁移应用程序；
- 自动排名（按服务优先级顺序）启动整个数据中心。
本文描述的事故是自第404天以来最严重的一次事故。 当然，并不是一切都很顺利。 例如，在另一个数据中心因火灾损坏的数据中心不可用期间，其中一台服务器上的磁盘崩溃了，即Cassandra集群中的三个副本中只有一个仍然可用，导致4,2%的移动应用程序用户无法登录。 与此同时，已经连接的用户继续工作。 此次事故总共发现了 30 多个问题——从平庸的错误到服务架构中的缺陷。
但本次事故与第 404 次事故最重要的区别在于，当我们在消除火灾后果的同时，用户仍在发短信和视频通话。 、玩游戏、听音乐、互赠礼物、观看视频、连续剧和电视频道 ，并且还流入了 .
你的事故进展如何了？
来源： habr.com