如果在一个晴朗的夏日里，配备设备的数据中心看起来像这样，您会感觉如何？
大家好！ 我叫Dmitry Samsonov，我是
Odnoklassniki的首席系统管理员。 图为安装了为我们的项目服务的设备的四个数据中心之一。 这些墙的后面大约有四千个设备单元：服务器，数据存储系统，网络设备等。 -我们几乎所有设备的1/3。
大多数服务器是Linux。 有数十种Windows服务器（MS SQL）-我们的传统，多年来我们一直在系统地拒绝使用它们。
因此，在2019年6月5日14:35，我们数据中心之一的工程师报告了火灾警报。
拒绝
14:45。 数据中心中的小黑烟事件比看起来的更为普遍。 展厅内的指示器是正常的，因此我们的第一反应是相对平静的：我们禁止生产，即不得进行任何配置更改，推出新版本等工作，但与修复相关的工作除外。
怒气
您是否曾经尝试从消防员那里找出屋顶上到底发生了什么大火，或者自己上了燃烧的屋顶来评估情况？ 对五个人收到的信息的信任程度如何？
14:50。
收到的信息是火势正在接近冷却系统 。 但是会来吗？ 值班的系统管理员将显示来自此数据中心前端的外部流量。
目前，我们所有服务的前端都在三个数据中心中重复，并在DNS级别上进行了平衡，这使您可以从DNS中删除一个数据中心的地址，从而保护用户免受访问服务的潜在问题。 如果数据中心已经出现问题，它将自动退出轮换。 可在此处找到更多详细信息： Odnoklassniki中的负载平衡和容错。
火灾尚未以任何方式影响我们-用户和设备均未受到影响。 这是意外吗？ 文件“事故行动计划”的第一部分定义了“事故”的概念，该节的结尾如下：
“ 如果有疑问，那就算是意外，那就是意外！ ”14:53。 任命了事故协调员。
协调员是控制所有参与者之间的交流，估计事故规模，使用“事故行动计划”，吸引必要的人员，监视维修完成以及最重要的是下达任何任务的人。 换句话说，这是负责消除事故的整个过程的人。
讨价还价
15:01。 我们开始断开与生产无关的服务器。
15:03。 正确关闭所有保留的服务。
这不仅包括前端（此时用户不再登录）及其辅助服务（业务逻辑，缓存等），还包括复制因子为2或更大的各种数据库（
Cassandra ，
二进制数据存储） ，
冷库 ，
NewSQL等）。
15:06。
已收到有关火灾威胁到数据中心大厅之一的信息。 我们在这个大厅没有设备，但是火会从屋顶蔓延到大厅的事实大大改变了正在发生的事情。
（后来证明该大厅没有物理威胁，因为它与屋顶隔绝了。该威胁仅针对该大厅的冷却系统。）
15:07。 我们允许在服务器上以加速模式执行命令，而无需进行其他检查（
没有我们最喜欢的计算器 ）。
15:08。 房间的温度在正常范围内。
15:12
记录了大厅温度的升高。15:13 数据中心中超过一半的服务器已关闭。 我们继续。
15:16 决定关闭所有设备。
下午3:21 我们开始在没有正确关闭应用程序和操作系统的情况下关闭无状态服务器的电源。
15:23 挑出了一组负责MS SQL的人员（人数很少，服务对它们的依赖程度不高，但是恢复健康的过程比例如Cassandra花费的时间更长且更为复杂）。
抑郁症
15:25
收到有关在16个房间中的四个房间（第6、7、8、9号）中关闭电源的信息。 在第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 最后的第7层大厅的空调已恢复。
03:36。 他们使数据中心的前沿转向了DNS。 从这一刻起，用户流量开始到达。
我们解散了大多数家庭管理员团队。 但是我们留下了几个人。
小常见问题解答：
问：从18:31到02:56发生了什么？
答：根据“事故行动计划”，我们从最重要的服务开始启动所有服务。 同时，聊天中的协调器向免费管理员提供服务，该管理员检查操作系统和应用程序是否已启动，是否有错误或指示器是否正常。 启动完成后，他通知聊天室他有空，并从协调员那里收到新服务。
该过程还被故障铁抑制。 即使操作系统关机和服务器关机正确，由于驱动器，内存或机箱突然故障，某些服务器也不会返回。 断电会增加故障率。
问：为什么您不能一次全部启动所有内容，然后修复监控结果？
答：一切都需要逐步完成，因为服务之间存在依赖性。 并且应立即检查所有内容，而不必等待监视-因为最好立即处理问题，而不是等待问题恶化。
上午7:40 最后一位管理员（协调员）上床睡觉。 第一天的工作已经完成。
上午8:09 第一批开发人员，数据中心的工程师和管理员（包括新的协调员）开始了恢复工作。
09:37。 我们开始提高7号大厅（最后一个）。
同时，我们继续恢复在其他房间未完成的工作：更换磁盘/内存/服务器，修复监视中着火的所有内容，主备电路中的反向角色切换以及其他一些小事情，尽管这些事情很多。
17:08。 允许所有常规生产作业。
21:45。 第二天的工作完成。
09:45。 今天是星期五。 监视中仍然存在许多小问题。 周末前，每个人都想放松一下。 我们将继续大规模修复所有可能的东西。 可以推迟的常规管理任务被推迟。 协调员是新来的。
15:40。 突然，OTHER数据中心中的网络设备核心堆栈的一半重新启动。 从旋转中移除了前端，以最大程度地降低风险。 对用户没有影响。 后来发现这是一个坏机箱。 协调器可一次修复两个崩溃。
17:17。 恢复另一个数据中心中的网络，检查所有内容。 数据中心在旋转。
18:29。 第三天的工作以及总体上从事故中恢复的工作已经完成。
后记
2013年4月4日，在发生第404个错误的当天 ，Odnoklassniki
在一次重大事故中幸存了三天，门户完全或部分不可用。 在整个这段时间里，来自不同城市，不同公司的100多人（再次表示感谢！）在数据中心远程直接进行手动和自动修复了数千台服务器。
我们得出了结论。 为了防止再次发生这种情况，我们至今一直在进行并继续进行广泛的工作。
当前事故与404之间的主要区别是什么？
- 我们有一个“紧急行动计划”。 每季度一次，我们进行演习-我们演练出紧急情况，一组管理员（依次又要使用“紧急行动计划”消除这种情况）。 领先的系统管理员轮流制定协调员的角色。
- 以测试模式每季度一次，通过LAN和WAN隔离数据中心（依次隔离），这使您可以及时发现瓶颈。
- 不良硬盘更少，因为我们已经严格了标准：运行时间更少，SMART的门槛更高，
- 完全废弃的BerkeleyDB-一个旧的不稳定数据库，需要大量时间才能从服务器重启中恢复。
- 使用MS SQL减少服务器数量，并减少对其余服务器的依赖。
- 我们拥有自己的云-one-cloud ，过去两年来我们一直在积极迁移所有服务。 云极大地简化了应用程序的整个工作周期，并且在发生事故时提供了以下独特的工具：
- 一键正确停止所有应用程序；
- 从故障服务器轻松迁移应用程序；
- 自动排名（按服务优先级排序），启动整个数据中心。
本文所述的事故成为自404天以来最大的事故。 当然，并非一切都顺利。 例如，在另一个数据中心的数据中心刻录机不可用期间，磁盘在其中一台服务器上崩溃了，也就是说，Cassandra集群中的三个副本中只有一个可用，因为有4.2％的移动应用程序用户无法登录。 同时，已经连接的用户继续工作。 根据事故的结果，总共发现了30多个问题-从普通错误到服务体系结构缺陷。
但是当前事故与404事故之间的主要区别在于，尽管我们消除了火灾的后果，但用户仍然在
Tamtam中进行通信并进行视频通话，玩游戏，听音乐，互相介绍礼物，观看视频，电视节目和电视频道。
OK ，并且还流式传输到
OK Live 。
您的事故如何？