Tarsnapサービス停止の事後分析

• Tarsnapの障害により、サービスがオフラインになりました。
• 障害は、AmazonのEC2 us-east-1リージョンでホストされていた中央Tarsnapサーバーのシステムステータスチェック失敗によって発生しました。
• 故障の正確な原因は不明ですが、孤立したハードウェア障害と推定されています。
• Tarsnapの監視システムは故障を検知し、運用者に通知を送りました。
• 代替のEC2インスタンスは作成されましたが、データ損失を防ぐため、Tarsnapサーバーのコードは自動的には再起動されませんでした。
• サーバー再起動後、ログにはファイルシステムの破損が示されており、以前のサーバーを復旧する代わりに新しいサーバーを設定することが決定されました。
• 復旧プロセスには、Amazon S3からメタデータヘッダーを読み取り、処理をローカルで再実行することが含まれていました。
• 復旧プロセスでは、マシン登録ログエントリおよび未初期化のログエントリ順序に関連するエラーが発生しました。
• 復旧プロセスは予想よりも遅く進み、より高速な性能のために最適化できる余地がありました。
• 状態復元プロセスは7月3日に完了し、サーバーは再びオンラインに戻りました。
• 障害後のトラフィックは、障害開始から約26時間16分後に再開されました。
• Tarsnapは障害に対する補償として、ユーザーアカウントに1か月分の保存料金の50%を提供しました。
• ユーザーは、質問や懸念がある場合はTarsnapの創業者であるColin Percivalに問い合わせるよう案内されています。

[GN⁺]

Hacker Newsの意見

• この記事の編集者は、障害後にTarsnapの全利用者のアカウントへ1か月分の保存料金の50%を支払いました。
• この編集者は、状況への対処において寛大で顧客本位なアプローチを取ったとして称賛されています。
• この編集者は、記事の人気に驚きを示すとともに、個人的な理由から質問への回答には制限があると述べています。
• あるコメント投稿者は、追加の障害時間を休息と引き換えにすることが問題解決に役立つかもしれないと提案しています。
• 定期的に復旧プロセスをテストすることは、バグや問題の特定と解決に役立ちます。
• この事後分析は、その専門性、礼儀正しさ、誠実さについて感謝されています。
• コメント投稿者は、将来のダウンタイムを最小限に抑えるため、障害復旧の手順を整備してテストすることを勧めています。
• 類似の事案においてビジネスの回復力を高めるため、パートタイマーの雇用が提案されています。
• 潜在的な利用者に対しては、単独の個人、この場合はColin Percivalに依存するリスクが指摘されています。
• 2014年のコードの誤りが障害の原因として特定されており、このような問題を捉えるためにTLA+モデリングの利用が勧められています。
• Tarsnapウェブサイトのインフラページは、障害を反映するために更新されるべきです。
• Tarsnapの暗号化ソフトウェアをDropboxと統合して、安全なデータ保存ができるのかという質問が提起されています。