2013年に私たちに衝撃を与えた3日間

「これが事故であるかどうか疑問がある場合、これは事故です！」

（c）先祖の知恵



オンラインプロジェクトでの大きなクラッシュはまれです。 そして、大規模なプロジェクトでは-それほど頻繁ではありません。 もちろん、システムが複雑になるほど、エラーの確率が高くなります。 大規模システム、特にソーシャルネットワークの1時間のダウンタイムは安価ではないため、大規模プロジェクトでは、事故を防ぎ、ユーザーへの悪影響を減らすために多くの努力が払われます。 しかし時々、星が特別な組み合わせで積み重なるか、マーフィーの法則が真の力を発揮し、大きな事故が起こることがあります。 Odnoklassnikiの歴史上、最大の失敗は2013年4月4日に発生しました。3日間、プロジェクトは完全にまたは部分的に機能していませんでした。 私たちの物語は、その後に何が起こったのか、どのような理由で、これにどのように取り組んだのかについてです。

1.どうしたの？

ある夕方、監視システムがサーバーの1つに関する小さな問題を修正しました。 これを排除するには、構成テンプレートを修正する必要がありました。 勤務中の管理者は、このテンプレートを開発した同僚に助けを求めました。 前のコードのイメージと肖像に、1行の小さなコードを追加するだけでよいことが判明しました。 管理者は必要な修正を行い、ファイルを本番に送信しました。



すぐに別のサーバーで障害が報告され、その数は急速に増加しました。 アテンダントはすぐにログを上げ、変更された構成テンプレートに関するものであることを提案しました。 当然、彼らはすぐに変更をロールバックし、テンプレートの元のバージョンをサーバーに返しました。 しかし、その頃には、Odnoklassnikiのサーバーパークの大部分を構成していたすべてのLinuxマシンがすでに拒否されていました。 したがって、最長の3日間が始まりました。



ホットトラッキングでのその後の分析は、すべてのサブシステムを麻痺させ、雪崩の失敗の原因を特定するのに役立ちました。

• 当時は、古いバージョンのopenSUSEを使用していたため、すぐに古いバージョンのbashを使用していました。 必要な変更のバックポートは、新しいブランチに更新するよりも簡単に思えました（現在、bashは新しいブランチに更新されているため、一部のシステムとスクリプトの構文を修正する必要がありました）。 バックポートのプロセスでエラーが発生しました。このエラーは、構成テンプレートへの次の変更時にのみ現れ、すべてのサーバーに分散していました。
• テンプレートを作成してテストした開発者は、ファイルの最後に改行文字を自動的に追加しないテキストエディターで作業しました。
• しかし、管理者は別のエディターでテンプレートファイルを管理し、このシンボルをファイルの最後に配置しました。
• 集中管理システム（CFEngine）にはバグがあり、編集されたファイルには常に改行文字が追加されていたことが判明しました。 その結果、2つのキャリー文字が連続して表示されます（ファイルの最後の空行）。
• 修正したbashコードには別のバグがありました。これは、インタープリターが構成ファイルの最後に空行を検出すると、無限ループに入り、外部コマンドへの応答を停止したためです。

ご存じのように、シェルはユーティリティスクリプトの実行時など、さまざまな操作で使用されます。 サーバーで実行されているbashプロセスはすぐにサイクルになり、マシンの利用可能なコンピューティングリソースを迅速に消費しました。 その結果、サーバーはすぐに最大負荷に達しました。 しかし、それほど悪くはありませんでした。 実際、bashは集中管理システムでも使用されていました。 そのため、サーバーの過負荷に加えて、外部コマンドへの応答が停止しました。 ログインできず、ごく短時間のうちに約5,000台のサーバーが機能しなくなりました。

セルフテストに関する質問：

集中管理システムに障害が発生した場合はどうしますか？ そして、同時にサーバーにログインできない場合はどうなりますか？

2. 3日間の回復

残念ながら、サーバーを再起動するだけではシステムを機能に戻すことはできませんでした。 これは、ポータルのアーキテクチャによるものです。

2.1。 サブシステム関係

クラスメートは約150のサブシステム（さまざまなデータベース、ビジネスロジックサーバー、キャッシュ、グラフ、フロントエンド、構成システムなど）で構成されています。 そして、ほとんどすべてのサブシステムのパフォーマンスは、他のサブシステムの可用性に依存します。 サーバーをランダムに再起動すると、1つの特定のサブシステムだけでなく、他の多くの関連サブシステムの作業も中断する可能性があります。



サブシステム間の関係の例：











何かが古典を思い出させます：











実際、プロジェクトのアーキテクチャを開発および変更する際に、サーバークラスター全体が同時に障害を起こす可能性があるというシナリオはありませんでした。 一部のサブシステムのコードは、一部の関連コンポーネントに完全にアクセスできない状態で起動および機能するメカニズムを提供しませんでした。 機能の重複とバックアップマシンの使用により、すべてのシステムが少なくとも部分的に機能すると想定されていました。

セルフテストに関する質問：

相互接続されたサブシステムのすべてまたは一部が動作不能な状態でサービスを起動するメカニズムはありますか？

2.2。 サーバーの再起動

メインサブシステムを同時に起動するには、最初に少数のサーバーを復元する必要がありました。オフィスと特定のサービスを実行する必要があります。 これにより、それに依存するサービスの作業を徐々に復元し、その後、他のサービスの作業を復元することができました。 可能な限り、最も重要なサービスのために重複サーバーが忘却から取り除かれました。



覚えているように、約5,000台の車を復活させる必要がありました。 それらをリモートで再起動してネットワーク経由でダウンロードすることは不可能でした。これは多くの場合、このために構成されていなかったからです。 これは、インフラストラクチャを作成するために一度選択されたアプローチの結果でした。 結局のところ、Odnoklassnikiは最初から数千台のサーバーを一度に展開しませんでした。数年かけて徐々に公園が成長しました。 したがって、数千台のサーバーを手動で再起動し、ネットワーク上のBIOS制御を許可して回復を自動化する必要がありました。



当初、一部のサーバーでは「ブートストラップに到達」することが可能でした-クラスターの説明を取得し、データが保存されている場所を正確に見つけます。 サーバーが再起動されるまで、サーバーは非常にゆっくりですが、それでも構成を提供し、一部のサービスを開始できました。 復旧プロセスを高速化するために、これらのサーバーを再起動する必要がありました。 ただし、各サブシステムの開始または通常の操作では、それに関連付けられた他のサブシステムが使用可能である必要があります。 再起動により、一部のクラスターの説明へのアクセスと多くのサブシステムを起動する機能が失われました。 開始できるものはもう開始しませんでした。 そして、働いていた人々は仕事をやめ、彼らを元に戻さなければなりませんでした。



もう1つの問題はハードドライブでした。 高負荷で停止することなく長時間動作する場合、オフにすると失敗することがよくあります。 私たちが直面しているのはこの現象です。 そのため、故障したディスクを定期的に交換し、データベースの一貫性を復元する必要がありました。 作業コピーとそのバックアップを備えたディスクに障害が発生した場合もありました。 さらに、サーバーは異なるデータセンターにありました。 偶然だった。

セルフテストに関する質問：

• サーバーはリモート再起動用に構成されていますか？
• データバックアップシステムはどの程度安全に編成されていますか？

2.3。 データ復旧

作業コピーを展開してサービスを開始するには、蓄積されたトランザクションログを入力してバックアップを復元する必要がありました。 いずれかのデータベース全体のバックアップを復元できませんでした。 次に、新しいストレージクラスターを並行して起動し、そこに不足しているデータを転送し、他のサブシステムからそれらを収集します。 最初に、どこで何を探すべきかを考えてから、サービスのロジックを変更し、データを転送するためのスクリプトを作成し、新しいクラスターを構成し、データを転送しました...最後に、すべての失われた情報を完全に復元しました。

2.4。 サービス開始

サーバーの再起動後、OSを起動し、構成テンプレートから不幸な空の行を削除するための一連のスクリプトを送信しました。 スクリプトの作成とテストと並行して、24時間手動でサーバーを復元しました。 Odnoklassnikiチームだけでなく、他のプロジェクトの従業員もこの作業に関与しました。



サーバーの再起動後、機器とファイルシステムに障害が発生しなかった場合、スクリプトはサービスを稼働状態にしました。 他のサブシステムへの依存関係のためにサービスを開始できなかった場合、コードを編集する必要がありました。 これが役に立たない場合、彼らはそれを整理し、解決策を探しました。 幸いなことに、大量のデータとサービスがデータセンター間で既に分散されていたため、機能の復元に必要な部分のみを復活させる必要がありました。



監視および統計システムはインターネットプロジェクトで広く使用されており、Odnoklassnikiのような大規模プロジェクトも例外ではありません。 機器やアプリケーションの正しい動作、およびユーザーの行動に関して、膨大な数のパラメーターが常に監視されています。 失敗が多すぎることによる事故の解消中、情報はゆっくり収集されるか、まったく収集されませんでした-モニターと多くのサーバー間の通信の試行はタイムアウトになりました。 その結果、モニターは長時間修理されたサーバーに障害が発生していると指摘し、その逆も同様です。モニターがポーリングするためのキューにまだ到達していないため、非稼働サーバーが機能していると見なします。 多くの場合、監視システムは一般的に故障しています。 最新のサーバーステータスデータを取得できず、アプリケーションが正常に動作しているかどうかを確認できませんでした。 したがって、手動でチェックする必要があり、余分な時間がかかりました

セルフテストに関する質問：

異なるデータセンター間でデータとサービスの分散を使用していますか？ これによりフォールトトレランスがどの程度向上しますか？

2.5。 復旧完了

最初から、作業の順序をまとめた回復計画を策定しました。 リカバリ中に実行されたすべての手順が文書化されました。 人々の仕事は調整され、誰かが次のタスクを完了すると、次のことが与えられました。 タスクの配布は、現在の状況と運用計画に基づいて実行されました。 つまり、プロセスは管理しやすいものでしたが、一部しかありませんでした。 私は多くの即興演奏をしなければなりませんでした。



ポータルが少なくともロードを開始し、機能の一部が機能するようになったとき、主要な作業能力の回復には約1日かかりました。



事故は木曜日の夕方に発生し、日曜日の朝にポータルを完全に復元しました。

3.学んだ教訓

3.1。 インシデント管理

Odnoklassnikiでは、他の多くのプロジェクトと同様に、インシデント管理が使用されます。 つまり、すべての偶発事象が記録され、カテゴリに分類されます。

• コードのバグ、
• 構成エラー
• ハードウェア障害
• 従業員の誤った行動、
• パートナー側の失敗：支払いアグリゲーター、通信事業者、データセンターなど

事件の原因と結果を排除するために、執行者がすぐに任命されます。

それとは別に、ユーザーに深刻な結果をもたらす、または潜在的にこれを可能にするインシデントを分析します。 これにより、不審な傾向（たとえば、カテゴリの失敗の数の増加）を検出し、重大な事故を防ぎ、失敗の悪影響を大幅に減らすことができます。



以前に重大な事故が発生しました。 たとえば、2012年、Odnoklassnikiは、通信コレクターの火災によりデータセンターの1つにアクセスできなかったため、数時間動作しませんでした。 その後、グローバルな目標を設定しました。データセンターのいずれかが失われた場合、ポータルは完全に機能する必要があります。 近いうちにこの目標を達成します。

セルフテストに関する質問：

あなたのサービスが利用可能になります：

• 複数のサーバーに障害が発生した場合
• 1つ以上のサブシステム？
• データセンターの一つ？
• インシデントをどのように処理しますか？

しかし、私たちはこの規模の事故の準備ができていませんでした。 すべてのサーバーが使用できなくなり、そのような複雑な状況が発生すると想定した人はいませんでした。

事故後、すべての修復作業の順序と進行状況を分析しました。

• どれくらいかかりましたか
• どんな困難が生じたのか、そしてなぜ
• 彼らはどのように決定されましたか
• 特定の決定が行われた理由。

3.2。 インフラストラクチャ、監視、管理の変更

分析の結果に基づいて、必要な作業の計画が作成され、さまざまな事故に備えられました。 現在までに、次のことを行っています。

• Berkeley DBに基づいて、信頼性の低いストレージシステム（以下、SHDと呼びます）を交換するプロセスを完了しました 。 Odnoklassnikiの基盤そのものから、さまざまな小規模ビジネスエンティティの大きなバイナリデータとキー値を格納するために、同様のシステムが使用されてきました。 これらのストレージシステムには、多くの欠点がありました。 たとえば、シングルマスタレプリケーションアーキテクチャの性質により、マスタに障害が発生したり、場合によってはレプリカに障害が発生したりすると、変更が定期的に失われます。 また、事故の際、バックアップからの復旧手順は非常に遅く、信頼性が低いことが判明しました。 現時点では、 CassandraとVoldemortに基づくシステムへの移行が完了しています。
• IPMIを介してスタンドアロンの集中サーバー管理システムを実装しました。 これで、サーバーを管理してIPMIへの電力とネットワークアクセスができるようになりました。
• 監視システムの信頼性と精度の向上。 事故後、すべての監視システムの動作のポイントを調査し、次のことを行いました。
  
  -安定性を向上させるためにスクリプトを完全に書き直し、
  
  -チェックアウトタイムアウトの削減、
  
  -ネットワークを介したサーバーの可用性に対するアプリケーションチェックの依存関係の導入、
  
  -ソフトウェアを更新し、
  
  -アクティブチェックをパッシブチェックに変更し、他の多くの変更を行いました。
• すべてのサーバーの構成変更に対する保護を実装しました。 これで、変更は、データセンターのいずれかでのみ、勤務時間中にのみ自動的に適用できます。

セルフテストに関する質問：

• バックアップからデータを回復するのにどれくらいの時間を要しましたか？
• すべてのサーバーをリモートで管理する機能はありますか？
• 本格的な事故が発生した場合、監視システムは正しく機能しますか？
• 1回の構成変更で、短期間ですべてのサーバーの動作を中断する物理的な可能性はありますか？

3.3。 ポータルの変更

• 構成の変更を実動に変更しました。 別の従業員によるすべての変更の強制チェックを導入しました。 変更のテストがより多くの環境を通過するようになりました。
  
  -不安定（「withでこじ開ける」ことができる仮想マシン）、
  
  -テスト（ユーティリティシステムのフルセットを使用しますが、実稼働環境では使用しません）、
  
  -安定（さまざまなタイプの数百の実動サーバーの専用グループ）
  
  -次に、データセンター用に個別に運用環境で。
• 新しいサービスシステムまたは変更されたサービスコンポーネントが受けるテストの種類 （負荷、統合、フォールトトレランスなど）を決定し、例を追加しました。
• 追加の緊急事態シナリオを考慮して、サービスシステムとネットワークを再編集します。
• インフラストラクチャへの依存の軽減、重複の追加、緊急時の組織的なアクセス。
• アプリケーションの起動を妨げる依存関係を修正し、サービス障害テストを実装しました。 現在、継続的に機能がテストされ、サブシステムが完全に故障しています。 また、サービスを強制的に切断できる「サーキットブレーカー」も導入しました。

セルフテストに関する質問：

• 本番環境に加えられた変更を確認およびテストする手順をどのように構築しますか？
• サービスサービスとツールは、インフラストラクチャの障害にどの程度影響を受けますか？

3.4。 事故対策計画

私たちにとっての主な問題の1つは、このような大規模な事故に対する行動計画の欠如でした。 実施した修復作業の分析結果に基づいて開発しました。 計画に含まれるもの：

1. 監視チームのチェックリストと連絡先の責任者のリスト 、および連絡先の詳細。
2. 役割と責任の配分：
   
   
   • どの従業員が事故の撲滅に関与しているか、
   • どの責任分野を誰に分配すべきか、
   • コーディネーターは誰ですか
   • 運用計画の準備を担当するのは誰ですか
   • 修理状況の定期的な一般報告の責任者
   • 誰が、なぜ、どのように役割を引き継ぐことができるか-これは、修理自体、その後の分析、および事故後の可能な行動の両方に関係します。
3. サービス回復チェックリスト ：修復する対象、順序、方法 優先サービスのリストとその復元手順は、ここで定義されています。 制御する必要があるツールとシステムのリスト。 何か問題が発生した場合の対処方法に関する指示と情報へのリンク。
4. コーディネーターとして働く人のための個別の指示。 事故撲滅プロセスの責任者は、規模を評価し、計画し、必要な情報を上級管理職に提供し、委任し、制御し、追加のリソースを引き付け、必要な情報を記録し、インシデントの分析を整理する必要があります。
5. データセンターがクラッシュした場合の個別の指示。 データセンターの1つが落下した場合の特定のアクションのリストを定義します。
6. パートナーとのやり取りのルール。 パートナーとやり取りするときのコミュニケーションの方法と役割の分散、およびパートナーとのやり取りのレベルは次のとおりです。
   
   
   • 情報-この場合、通知のみに制限されます。
   • リソースの動員-この場合、パートナー側または私たちの側でリソースを大規模に動員します。
   • ワーキンググループ-この場合、パートナーとその参加者が参加するワーキンググループを作成します。

「緊急」アクションプランは定期的にテストする必要があります。 この手順の重要性を過大評価することは困難です。 そうしないと、数か月後に計画が廃止されます。 そして、ある日問題が発生しても、あなたの行動は状況を改善したり悪化させたりすることはありません。 そのため、四半期ごとにアクションプランを確認します。新しい従業員のトレーニングが必要な場合は、より頻繁に確認します。 サーバーの移行、マイクロサービスの開始と終了、オペレーティングシステムと監視システムの変更などにより、調整が必要であることが判明するたびに。

セルフテストに関する質問：

重大度の異なる事故の計画はありますか？ サーバーが配置されているすべてのデータセンターに完全にアクセスできない場合はどうしますか？

結論にいくつかの言葉

Odnoklassnikiがそうであるような複雑なシステムでのすべてのイベントと障害を予測することは不可能です。 ただし、プロジェクトのアーキテクチャ、セキュリティシステム、およびあらゆる種類の計画された手順により、データセンターに障害が発生した場合でも、ほとんどの機能とすべてのデータを保持できます。 さらに、近い将来、データセンターの崩壊でもポータルの運用に影響を与えることはできません。