🍛 ⤵️ 🏇🏿 サービスの仕事の問題9月24〜25日 🧓🏾 🚵 🦖

まず第一に、Selectelの歴史の中で最大のダウンタイムをおwantびしたいと思います。以下では、イベントの時系列を詳細に復元し、そのような状況を将来防止するために何が行われたか、およびこれらの誤動作の影響を受ける顧客への補償について説明します。

最初のグリッチ

問題は9月24日月曜日の夜（ ダウンタイム22:00-23:10 ）に始まりました。外部からは、ネットワークのサンクトペテルブルクセグメントとの接続が失われているように見えました。この失敗により、サンクトペテルブルクのすべてのインターネットサービスで問題が発生しました。モスクワのネットワークセグメントとローカルサーバーポートは引き続き動作しました。また、サンクトペテルブルクにあるDNS（ns1.selectel.orgおよびns2.selectel.org）は利用できませんでしたが、モスクワDNS（ns3.selectel.org）はこの失敗を害しませんでした。接続性の欠如、サイトへのアクセス、およびコントロールパネルの消失により、電話に大きな負荷がかかり、多くのお客様が回答を待つことができませんでした。

状況を分析するとき、2つのJuniper EX4500を1つの仮想シャーシに結合した集約レベルスイッチの誤動作が原因であることがすぐに判明しました。視覚的にはすべてが機能しているように見えましたが、コンソールに接続すると多くのメッセージが見つかりましたが、問題の正確な原因を特定することはできませんでした。

 9月24日22:02:02 chassism [903]：CM_TSUNAMI：i2cのレジスタ（56）の読み取りに失敗しました
 9月24日22:02:02 chassism [903]：cm_read_i2c errno：16、デバイス：292

実際、アグリゲーションレベルスイッチシャーシのすべての光10Gイーサネットポートは動作を停止しました。

 9月24日22:01:49シャーシ[952]：CHASSISD_IFDEV_DETACH_PIC：ifdev_detach_pic（0/3）
 9月24日22:01:49作成[954]：マイナーアラームセット、FPC 0 PEM 0削除
 9月24日22:01:49作成[954]：マイナーアラームセット、FPC 0 PEM 1削除

再起動後、すべてが安定して動作しました。ネットワーク構成は長い間変更されておらず、事故前に作業が行われていなかったため、これは1回限りの問題であると考えました。残念ながら、わずか45分後に、これらの同じスイッチは再び応答を停止し、再度リブートされました（ 23:55-00:05 ）。

仮想シャーシの低いスイッチプライオリティ

どちらの場合も、仮想シャーシ内の2つのスイッチの1つが最初に故障し、2番目のスイッチの後に2つ目のスイッチが機能しなくなったため、問題が発生したと想定されました。仮想シャーシは、2番目のスイッチがメインスイッチになり、もう1つのスイッチが予備としてのみ残るように再構成されました。操作の合間に、スイッチが再度リブートされました（ 00 : 40-00:55 ）

仮想シャーシが解体され、すべてのリンクが1つのスイッチに転送されます

約1時間後、別の障害により、実行されたアクションでは不十分であることが示されました。ポート容量の一部を解放して封印した後、故障したデバイスを仮想シャーシから完全に切断し、すべてのリンクを「正常な」スイッチに転送することにしました。午前4時30分頃までに、これは完了しました（ 02 : 28-03:01、03:51-04:30 ）。

スイッチをスペアと交換する

ただし、1時間後、このスイッチも機能しなくなりました。彼がまだ働いている間に、まったく同じまったく新しいスイッチが予備から取られ、インストールされ、構成されました。すべてのトラフィックがそこに転送されました。接続性が現れました-ネットワークが獲得しました（ 05:30-06 : 05 ）

JunOSアップデート

3時間後、午前9時頃、すべてが再び繰り返されました。スイッチに異なるバージョンのオペレーティングシステム（JunOS）をインストールすることにしました。更新後、すべてが機能しました（ 08 : 44-09 : 01 ）

データセンター間のファイバーの破損

12:00近くにすべてのクラウドサーバーが開始されました。しかし、12時45分に、ケーブル内の光信号が損傷し、異なるデータセンターのネットワークセグメントを接続しました。この時点で、2つのバックボーンスイッチの1つが廃止されたため、ネットワークは1つのメインルートのみで機能し、バックアップは切断されました。これにより、クラウド内のホストマシンとストレージシステム（データストレージネットワーク）間の接続が失われ、サンクトペテルブルクのデータセンターの1つにあるサーバーにアクセスできなくなりました。

緊急旅団がケーブル損傷現場に向けて出発した後、ケーブルがフーリガンによってエアライフルから発射されたことが判明しました。フーリガンは拘留され、警察に移送されました。

私たちの明白なアクションは、最初のチャネルを介したファイバの回復を待たずに、2番目のチャネルに切り替えることでした。これは十分に迅速に行われましたが、スイッチが再びハングしたため、うまくいきました。（ 12 : 45-13:05 ）

光SFP +トランシーバー

今回、JunOSの新しいバージョンでは、わかりやすいメッセージがログに表示され、SFP +モジュールのいずれかのサービス情報を読み取れないという苦情を見つけることができました。

 Sep 25 13:01:06 chassism [903]：CM_TSUNAMI [FPC：0 PIC：0ポート：18]：SFP + ID EEPROMの読み取りに失敗しました
 9月25日13:01:06 chassism [903]：xcvr_cache_eeprom：xcvr_read_eeprom失敗-リンク：18 pic_slot：0

このモジュールを削除すると、ネットワークが回復しました。このトランシーバは以前に連続して交換した3つのスイッチのそれぞれを訪れたため、問題はこのトランシーバとスイッチの側面からの反応にあると想定しました。

しかし、3時間後、状況は再び繰り返されました。今回は、メッセージは故障したモジュールを示していませんでした。すぐにすべてのトランスバーを予備のトランスバーと交換することにしましたが、これも助けにはなりませんでした。彼らはすべてのトランシーバーを順番に監視し始め、一度に1つずつプルし、新しいバッチから別の問題のトランシーバーがすでに発見されました。スイッチの問題が解決されたことを確認した後、内部ネットワーク接続をクロスルーティングしてメイン操作スキームに切り替えました（ 16 : 07-16:31、17:39-18:04、18:22-18:27 ）

クラウドサーバー復旧

問題の規模は最初は不明確だったため、クラウドサーバーを上げるために何度か試みました。新しいストレージ（SRのuuidの始まり：d7e ...およびe9f ...）にあるマシンは、インターネットへのアクセス不能としてのみ最初のクラッシュを乗り切りました。悲しいかな、古いストレージ上のクラウドサーバーは、ディスクのI / Oエラーを受け取りました。同時に、非常に古い仮想マシンは読み取り専用モードに切り替わりました。この場合、新しいマシンのfstabにはerror = panic設定があり、エラーが発生するとマシンを終了します。数回再起動した後、残念ながら、VM起動のためのホストの準備に許容できないほど長い時間がかかった状況がありました（LVMの大規模なIOエラーはかなり不快です;場合によっては、死にかけている仮想マシンがゾンビに変わり、そのキャプチャと完了には毎回手作業が必要です）。電源ホストを再起動することが決定されました。これにより、新しいリポジトリからの仮想マシンの再起動が発生しましたが、これは本当にしたくありませんでしたが、他のすべての起動時間を大幅に（少なくとも3倍）短縮できました。同時に、ストレージ自体にはネットワークアクティビティがなく、データは無傷でした。

実行されたアクション

データセンターに設備の予備があるという事実にもかかわらず、ネットワークは冗長性、および安定性と中断のない動作を保証する他の多くの要因で構築されましたが、現在の状況は予想外でした。

その結果、次の活動を実施することが決定されました。

テスト環境での光トランシーバーとネットワーク機器の強化された検証。
フーリガン動作の結果として損傷の危険がある場所の装甲ケブラー光ファイバーケーブル。
クラウドサーバーインフラストラクチャの近代化の完了を加速します。

補償

みんなの興味を引く質問。以下の表は、SLAに基づいて、その月に提供されたサービスのコストの割合として、さまざまなタイプのサービスの補償額を示しています。

正式にはサービスのダウンタイムが表に示されたものより短いという事実にもかかわらず（接続性は時々現れたり消えたりしました）、ダウンタイムをより大きな方向に丸めることが決定されました。

サービス	ダウンタイム	補償
仮想専用サーバー	11時間	30％
専用サーバー/任意の構成サーバー	11時間	30％
機器の配置	11時間	30％
CMSホスティング	11時間	30％
クラウドサーバー	24時間	50％
クラウドストレージ	11時間	50％

もう一度、私たちはこの事件で傷ついたすべての人に謝罪します。私たちは、顧客にとってネットワークにアクセスできないことのマイナスの影響を十分に認識していますが、状況が標準的ではなかったため、何らかの形で問題の解決をスピードアップできませんでした。問題を可能な限り迅速に解決するために可能な限りすべての手順を実行しましたが、残念ながら、正確な問題を分析的に確立することはできず、すべての可能なオプションを列挙することでそれを探す必要があり、その結果、多くの時間がかかりました。

サービスの仕事の問題9月24〜25日