46 Sirv incidents · 2014年11月 — official updates, affected components, duration and resolution details.
サーバの問題により、いくつかのSirvアカウントへのアップロードが失敗しています。 また、画像が時折表示されないことがあります。 問題の解決にできるだけ早く取り組みます.
問題の原因が特定され、解決が完全になりました。 期間中、Sirvアカウントの約25%がファイルアップロードに失敗した割合を経験している可能性があります。 これは少数の要求にのみ影響を与えたため、後から短いアップロードを再試行することは成功しているかもしれません。 審査が行われるようになり、詳細は後日ご案内いたします.
公式のインシデント更新を自動翻訳しています。
アップロードやリクエストは、Sirv のプライマリ・データセンテージで複数のネットワーク・スイッチの失敗によりエラーが返されます。 CDN の要求は正常なように働きます。 状況を密接に監視し、より多くの情報が利用できるように更新を提供します.
すべてのサービスは、通常のサービスに戻り、リクエストは完了します.
この問題は、Sirv の主要データセンターに影響を及ぼすコアルータの障害によって引き起こされました。 これにより、API、S3、FTP のすべての転送タイプを渡る、ファイルストレージとアップロードの断続的な停止が発生しました。 Sirv は、自動的にフェイルオーバーサービスに切り替えるので、ファイル処理と配送が通常どおり継続されます。 CDN のリクエストは、通常どおり継続しています。 データセンタがコアルータの停電を解決したら、すべてのサービスが復元されました.
公式のインシデント更新を自動翻訳しています。
ドイツでのリクエストの応答時間は、通常よりも遅く、小数が切れる。 問題は調査されています.
問題は解決しました。 ドイツのサーバーの1つが過負荷し、より遅く応答していた。 サーバが再び健康になりました。 私たちは、この出来事のチャンスを減らすために取るべき行動を見直しています.
公式のインシデント更新を自動翻訳しています。
カリフォルニアからのリクエストは遅く、小数(2%未満)が失敗しています。 これは、ロサンゼルスで今日展開された新しいCDNサーバーに調査され、関連している可能性があります.
問題は解決しました。 問題は、新しいロサンゼルスデータセンターに影響を与えるパケットロスによって引き起こされました。 データセンターは、ネットワークの不安定性を経験していた、アップストリームプロバイダ、アレリオンに問題を追跡しました。 Arelion は、アップストリームプロバイダーとして一時的に無効化され、他のプロバイダーを通じてトラフィックが再ルートされたときに解決されました。 データセンターは、トラフィックを自動的に識別し、再ルートし、そのようなシナリオで迅速に要求します。 しかし、この問題の解決は十分ではありませんし、この新しいデータセンターを採用した後にすぐに発生したことを与えられた、我々はそれを使用して中止することを決定しました。 すべてのトラフィックは、オリジナルのロサンゼルスデータセンター(2025年4月7日現在)からルーティングされています.
公式のインシデント更新を自動翻訳しています。
サーバクラスターの問題により、アップロードがコンパイルされていないものもあります。 原因は調査されています。 問題は少数のアカウントに影響を与えます。 ファイルのアップロードが失敗した場合は、この問題が解決するまでお待ちください.
この問題は進行中です。 問題の原因は特定され、できるだけ早く解決するために取り組んでいます.
問題は解決しました。 1つのクラスターが同時に失敗する2つのサーバーによって問題が発生しました。 これは、Sirvアカウントの約20%に新しいファイルのアップロードに影響を与えました。 アップロードは、1つのサーバーがダウンしているが、2つのサーバーがダウンしたときに、アップロードが失敗するように設計されています。 1つのサーバーで実行を停止し、他のサーバーで実行を停止する輸出業者サービスのために失敗しました。 サービスの再起動を防ぐエラー。 その後、サーバーが再起動できないため、予想以上に長い解像度が発生した2番目の問題。 これは、古いBIOSのためにありました. BIOSが更新されたら、サーバーが再起動され、根本的な問題の原因が解決されました。 これを再び起こさないために、データセンターで新しいBIOS管理プロセスを実施しました。 また、ハードウェアのリフレッシュサイクルを短縮し、より頻繁なハードウェアのアップグレードも可能です。 再発による輸出業者サービスの故障の可能性を減らすため、プロセスを無効化し、サーバーメトリックを監視しています.
公式のインシデント更新を自動翻訳しています。
09:29〜0932 UTCの3分の間、一部のリクエストは返されません。 この問題は特定のリクエストのみに影響され、特定のアカウントのみに影響されます。 ほとんどのアカウントは影響を受けません.
問題は3分以内に解決しました。 原因は、複数のサーバーを同時に再起動していたが、1つのサーバーしか再起動されていない。 これは、当社の標準の動作手順で監督されました。 再発から自動的に保護し、防止する方法を調査しています.
公式のインシデント更新を自動翻訳しています。
サーバの障害は、限られた数のアカウントに失敗するファイルアップロードを引き起こしています。 問題は解決されています。 アップロードに失敗した場合は、後から一時停止して試してみてください.
問題は解決しました。 複数のサーバーが同時に失敗しました。 Sirv は、サーバーの停電時に正常な動作を続けるように設計されており、すべてのシステムが正常に続行したが、一部のファイルアップロードは失敗しました。 今後、このような状況で、どのような変化が起こるかを検討しています.
公式のインシデント更新を自動翻訳しています。
API ファイルのアップロードリクエストに対して 504 のタイムアウト数が返されます.
アップロードリクエストから API に重負荷が続いています。 貢献因子は、多くのAI画像のアップスケーリング要求であり、処理に時間がかかる。 リクエストのキューによる遅延は、504 応答で失敗する API ファイルのアップロードリクエストを引き起こします.
変更が行われ、問題はほぼ解決されます。 アップロードリクエストの大部分は成功しています.
API のアップロードオーバーロードはほぼ完全に解決されます.
問題は完全に解決しました。 重いイメージのアップスケーリング API リクエストがアップロード API をオーバーロードし、504 エラーを返す API リクエストがいくつか発生しました。 これは解決しましたが、502応答で失敗するAPI要求の約5%を引き起こしたノックオン効果でした。 この問題が再び起きるのを防ぐため、改善はイメージのアップスケーリングの負荷を減らし、負荷を分配するために使用されます。 変更は、そのようなシナリオのより速い識別のために、ログやアラートにするために作られています。 この問題の最大の影響は、Sirv WordPressプラグインにありました。 プラグインは、レスポンスが受信されるまでページの読み込みをブロックしたすべての管理者ページで API リクエストを送信しました。 通常は 300ms 以下でしたが、API リクエストがタイムアウトされたら最大 20 秒です。 これらの API リクエストは不要で、新しい WordPress プラグイン バージョン v7.3.3 が 1805 UTC (14 11月) でリリースされ、このようなリクエストを削除し、この問題が再発を防ぐようになりました。 https://wordpress.org/plugins/sirv/ ------ もし、Sirv API を使用する場合は、502 応答を受信するリクエストを再試行するためにスクリプトが書かれていることを推奨します。 502 などのエラー応答を処理するための推奨事項は次のとおりです。 https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide
公式のインシデント更新を自動翻訳しています。
一部のファイルは少数のアカウントで返されません。 この問題は緊急に対処されています.
問題は解決しました。 1052 UTCでは、200件の応答(OK)を返した際に、40の応答(ファイルが見つからない場合)を返し、少な数のアカウントに対するリクエストの約11%が返された。 シエフチームが問題を識別したとき, 彼らはすぐにそれを解決するために働いたし、 1206 UTC すべてのそのような要求は、通常の200応答を返します. これらの問題は、Sirv エンジニアが新しいストレージクラスターシャードを設定している間、Sirv エンジニアによるミスコンフィギュレーションが原因で発生しました。 いくつかのリクエストは、それらを受け取る準備ができていた前に、新しいシャードに行きました。 重度レベル3に分類:マイナーインパクト.
公式のインシデント更新を自動翻訳しています。
「Sirv's 25 CDN」へのリクエスト数が多いとエラーが返されます。 当社のエンジニアは、問題を特定し、解決するために迅速に取り組んでいます.
問題は解決しました。 複数のサーバーで同時にソフトウェアデーモンの失敗によって引き起こされました。 これは、過去に失敗したことのない軽量で高効率なサービスマネージャです。 期間中、HTTPS リクエストの 3% と 58% の間では、リクエストが受け取られた 25 の CDN の場所に応じて、エラーが返されます。 今後、サービスの可用性に影響を及ぼすのを防ぐため、これが起こった理由を調査し、行動をとります。 重症度レベル2に分類:意味のある影響.
公式のインシデント更新を自動翻訳しています。
CDN に 415 個のエラーが発生しているのが高まっています。 当社のエンジニアは、原因を調査しています.
この問題の原因を調査し続けています。 その性質は複雑です。 これは、ゼロバイトのファイルから415のエラーとしてそれ自体を表します。 誤差が500未満の場合でも、上昇しています。 リクエストの大部分は200の応答が成功しています。 当社のエンジニアは、これを理解し、解決するために努力しています.
415 エラーの問題は、あるファイルが誤って発生したことによって引き起こされました。つまり、その内容の一部が失われました。 これらのファイルは0バイトを持っているようにmy.sirv.comでコントロールパネルに表示されます。 今日にアップロードされたファイルは、過度にファイルに変容が起こっているようですが、捨てられた可能性は高まりました。 これは、実行されていないバージョンのキャッシュのために、完全に通常どおりに実行されたため、特定されていませんでした。 truncatedファイルの問題は、インフラストラクチャのアップグレード後に、今日のみ通知できるようになりました。 サーバーのキャッシュはクリアされ、トランケートされたバージョンが明らかになりました。 トランケーションの原因は、現在解決してきたソフトウェアのバグであると考えられています。 現在、破損したファイルを復元しています。 - 数時間から数日間かかるプロセス。 現在ロードされていないファイルを再アップロードできる場合は、今すぐお試しください。 問題は、ファイルの約〜0.2%に影響を与えると推定されます.
破損したファイルの約80%が回復しました。 415 個のエラーが大幅に減少しましたが、上昇しています。 問題を完全に解決するには、残りのゴミ箱ファイルは元のファイルと交換する必要があります。 残りのファイルを回復する方法は、それらを取得するのが難しいですが、時間や日を取ることがあります。 最速の解像度では、ファイルを再アップロードすることをお勧めします。 そのようなファイルは0バイトを持っているようにあなたのアカウントに表示されます。 次のURLから、過去30日間にアップロードされたすべてのファイルの一覧が表示されます。https://my.sirv.com/#/search/?created=30d サイズ、昇順で結果をソートすることにより、ゼロバイトファイルを見つけます。 別のアップデートは、残りのファイルに関するニュースを持っているとここに掲示されます.
残り数が少ないファイルを回復し続けています。 さらに12〜24時間かかると予想されます。 提供されていないファイルがある場合、それらを再アップロードすることにより、すぐにこの問題を解決することができます。 ゼロバイトファイルのリストを生成するツールを作成します。 アカウント内のゼロバイトファイルのリストをお気に入りにしたい場合は、https://sirv.com/help/support/#support にリクエストを送信し、ツールが準備完了したらリストを用意します。 限り、私たちはすべてのファイルを回復するために働き続けます。 Sirv の Autofetch 機能を使用してファイルをアップロードする場合、ゼロバイトファイルを削除するだけで、次のリクエストでリモート位置から再取得できます.
ファイルを復元しました。 415エラーのレートは下がります。 このページでは、https://my.sirv.com/#/analytics/errors/415?from=20231206&to=20231206 ファイルをアップロードして、ファイル内の415個のエラーを解決できます。 必要な場合は、ゼロバイトファイルのリストを提供できます。このフォームからServサポートチームに尋ねてください。https://sirv.com/help/support/#support できるだけ多くのファイルを復元し続ける.
415エラーの上昇率が解消された問題 truncatedファイルは、ゼロバイトでファイルを書いたソフトウェアの問題によって引き起こされました。 ソフトウェアとして、すべてのバージョンのマスターファイル全体で、トランケートされたファイルを再現しました。 Sirvは、ハードウェアの問題(サーバーまたはハードドライブの故障)から保護するためにすべてのファイルをトリプレックスしますが、更新されたファイルはすべてのチェックを通過し、ファイルを忠実にトリップしました。 ファイルのキャッシュされたバージョンが処理および配信に使用されていたため、検出せずに存在します。 キャッシュされたファイルがクリアされたら、昨日のインフラのアップグレードまで、すべてのシステムが完全に機能しました。 根本原因は、ソフトウェアの問題を特定し、修正することによって解決されました。 12月5日(金)に1500 UTCが完成しました。 その後、タスクは中断されたファイルを復元することだった。 プラットフォーム全体で、約0.2%のファイルが影響されました。 それらのファイルのうち、アカウントに応じて95%と100%の間で復元できました。 100%の復元がなかったアカウントは、再びファイルをアップロードすることによって復元すべきゼロバイトファイルのリストを送信します。 ファイルの一覧を記載して、Eメールでご確認ください。 ご不明な点がございましたら、下記URLよりご連絡ください。https://sirv.com/help/support/#support 問題の徹底的な調査は、電子メールで詳細に報告される進行中です。 レポート内では、この問題のいかなるリピートを防止するために取られた行動のリストであり、既に設計されている改善と新機能を備えています。 私たちは、この問題に影響を与えたすべての顧客に報じています。 マスターデータが失われたのは初めてです。 レッスンのレッスンを通して、Sirvをより強く、信頼性のあるレッスンを行います.
残り切り込みファイルの99%以上が復元されました。 影響を受けたユーザーは、影響を受けたファイルの正確なリストが提供されます。 この問題から残った残留衝撃はありません。 重症度レベル1:重大な影響として分類される.
公式のインシデント更新を自動翻訳しています。
0419 UTCから、シドニーのCDNの場所から429個のエラーが返されました.
問題は1031 UTCで解決しました。 原因は、シドニーのCDNの場所を作ったサーバーの不正設定で、真のクライアントIPアドレスではなく、同じIPアドレスから来るすべての要求が表示されます。 このトリガーされた DDOS 保護, 同じ IP からのリクエストの過度の数をレート制限します。. リクエストの多くで429件の回答が返されました。 問題は、シドニーのデータセンターネットワークが利用できなくなったときに非常に短い問題を抱えていました。 その問題は、約1分続く。 しかし、実際の事故は、当社のチームがシドニーのCDNの場所を復元した直後に始まり、サーバーのミスコンフィギュレーションが適用されるときです。 ミスコンフィギュレーションを発見し、修正したら問題が解決しました。 この問題が再発し、同様の問題の影響を減らすために、複数のアクションが取られる: - 追加監視と警告 - 新規案件提出フォーム - コンテキストの敏感な決断の助言 - シドニーのCDNの場所だけを警告する広い内部は影響されました。 重度レベル3に分類:マイナーインパクト.
公式のインシデント更新を自動翻訳しています。
11月22日に約1830 UTCで、プライマリファイルデータベースにアップグレードし、より強力なクラスターになりました。 アップグレードが行われた間、API検索クエリは失敗しました.
11月23日に1035 UTCでアップグレードが完了し、通常の動作を再開しました。 API検索リクエストがエラー応答を返すことを除いて、ダウンタイムとシステムが正常に機能しませんでした。 他の API リクエストが正常として返されたため、問題は特定されていませんでした。そのため、API のエラー応答はわずかに増加し、アラートがトリガーされていないためです。 問題は、ユーザーが調査を促したレポートの後、イベント後に識別されました。 今後、このような問題を自動的に特定するため、具体的に検索APIを監視する方法を評価しています。 また、Sirv WordPressプラグインをアップデートして、失敗した検索の場合に明確に説明されたメッセージが表示されます。 重度レベル4に分類:最小の影響.
公式のインシデント更新を自動翻訳しています。
My.sirv.com のファイル管理ツールは、サーバーが失敗したため、ゆっくりと読み込みます。 ファイルリストとファイル検索は、2〜20秒かかります。 故障したサーバーが交換され、72時間以内に通常に戻る速度が期待されます。 続いて、コントロールパネルサーバークラスタ全体が次の3ヶ月にわたって大きなアップグレードが続きます.
新規サーバーのプロビジョニングを待ち受け、クラスターに追加し、UIナビゲーション速度がはるかに高速になります.
新しいサーバーは11月14日の夕方に展開され、徐々にキャッシュを埋めました。 コントロールパネルは、元の高速性能に戻りました。 追加のサーバーがアップグレードされるので、コントロールパネルは2週間以上も読み込みます。 重度レベル4に分類:最小の影響.
公式のインシデント更新を自動翻訳しています。
10月23日、ワシントンD.C. CDNの場所への要求の劇的な増加は14:10 UTCで発生し、リクエストのわずかな割合がゆっくりと戻ってくる - 2秒を超える。 平均応答時間が高まっているが、次の3時間以内の問題。 問題は、10月24日に14: 32 UTCで翌日に返し、要求の17%がゆっくりとロードするよりも厳しくなります - 2秒以上、30秒以上。 問題は、Sirvの25 CDNの場所の2つに影響を与えました.
問題は10月25日、0648 UTCによって解決されました。 2つの原因に対する調査ポイント - スパイクは、代わりに、SirvのDNSプロバイダルーティングロサンゼルスPOPリクエストによって引き起こされました。 これは分離で罰金が科されるが、データセントレは受信サーバーの帯域幅をスロットルし、低応答を引き起こしているようです。 調査は進行中ですが、まだ決定的な結論に達していないため、DNSおよびデータセンタリープロバイダーとのコラボレーションが必要です。 すでにこの問題の繰り返しを防止するために行動をとっています。 詳細は後日ご案内いたします.
この問題への詳細な調査では、2つの貢献因子が発見されました。 AWS が 10 月 17 日に AWS で実装されているように見える AWS Route53 へのアップデートが始まりました。 この変更は、Sirv が Route53 ルールではなく、Route53 のサービス自体の変更を行わない。 ロサンゼルス POP は、他の POP と AWS の更新に若干異なるルーティングロジックが異なるため、 トラフィックがワシントン DC フォールバックにルーティングされるようになりました。 これは、その容量と要求が正常に返されたまま、より高い負荷が残っていたので、これはワシントンDCが追加の負荷を処理することができたので、未知になりました。 第二のコントリビュート要因は、10月23日と24日の米国取引時間のピーク時に通常のトラフィックよりも高くなりました。 2つの要因は、ワシントンDCハードディスクが正常によりも大幅に遅く要求を返すようにまとめました。 問題が発生したので、繰り返しを防ぐための複数のアクションを講じ、同様の可能性のあるインシデントを緩和し、インシデントが発生した場合の解像度時間を加速します。 アクションには: - 新しいルーティングロジックが適用される。 - ワシントンDCの容量が増加しました。 - 他のすべてのCDNの場所で予約容量が増加しました。 - ルーティングから削除されるCDNの場所のために導入された新しい許容。 - 追加のディスク監視、容量アップグレードの早期準備を支援します。 - HDDはSSDと交換されます。 - サポートチームにSOPをアップデートし、同様の課題を調査・解決します。 重度レベル3に分類:マイナーインパクト.
公式のインシデント更新を自動翻訳しています。
大量のAPIアップロード失敗で、高アップロード使用量が返された初期の問題.
問題は、ボリュームを正規化して9分以内に解決しました。 期間中、約98%のアップロードが成功し、2%が失敗しました。 REST API のアップロードは、Sirv アカウント https://my.sirv.com/#/account/usage の使用法ページで指定された金額に1時間あたりの制限されます。 REST API を使用して画像をアップロードする場合は、アップロードリクエストごとに応答をチェックし、エラー応答(400, 401, 429 など)を受信すると、アップロードを一時停止し、後で再試行します。 ドキュメントを参照してください。https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide 重度レベル4に分類:最小の影響.
公式のインシデント更新を自動翻訳しています。
REST API のアップロードリクエストは、非常に高い負荷で失敗します.
この問題は、アップロード API の読み込みが落ち始めたときに解決しました。 期間中、約97%のアップロードが成功し、3%が失敗しました。 REST API のアップロードは、Sirv アカウント https://my.sirv.com/#/account/usage の使用法ページで指定された金額に1時間あたりの制限されます。 REST API を使用して画像をアップロードする場合は、アップロードリクエストごとに応答をチェックし、エラー応答(400, 401, 429 など)を受信すると、アップロードを一時停止し、後で再試行します。 ドキュメントを参照してください。https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide 重度レベル4に分類:最小の影響.
公式のインシデント更新を自動翻訳しています。
ロサンゼルスのCDNサーバーの1つが不健康なようになり、000 UTCで4xxエラーが返りました。 90秒後にルーティングから削除され、さらに60秒以内に、すべてのトラフィックは健康なサーバーにルーティングされています.
問題は3分以内に自動的に解決されました。 重度レベル4に分類:最小の影響.
公式のインシデント更新を自動翻訳しています。
ロンドンPOPのSirv CDNへのリクエストは、高負荷によるエラーを返します。 このPOP は、イギリスとアイルランドにサービスを提供しています。 解決に取り組んでいます.
問題は解決され、監視されています.
ローカルDNSの解像度とネットワークのタイムアウトの組み合わせにより、ロンドンのCDNサーバーの1つから受け取ったリクエストがいくつか失敗しました。 問題は1215 UTCで始まり、1332 UTCで解決しました。 この期間中、英国とアイルランドからのリクエストの25%が404または500エラーを返します。 問題はより早く解決されたが、非関連 SSL 証明書の検証の失敗は、数時間前にブロックされたアラートが当社の監視システムによって受信されていることをブロックしました。 再発防止のため、既に変更が展開されています。 SSL証明書の問題が解決されました。独立した監視の2番目のレベルが構成されています。追加の健康自動化は、そのような問題を自動的に解決する可能性があることを試しています。 重度レベル3に分類:マイナーインパクト.
公式のインシデント更新を自動翻訳しています。
問題は0755 UTCで解決しました。 0625 UTC では、インドの Indore CDN POP へのリクエストは、200 応答ではなく、404 応答(ファイルが見つかりません)を返すようになりました。 この問題は、世界中のすべてのCDNサーバーへのアップデートから14時間後に発生しました。 すべてのPOPは、インドPOPを含む健康的に振る舞うが、Indore POPは正常に更新されず、最終的にエラーを返すようになりました。 問題が確認されたら、インドPOPへのアップデートを再デプロイすることで解決しました。 インシデント中、リクエストの94%はエラーを返します。 その他の国へのリクエストは、通常どおり返送されます。 この問題が再発を阻止するために、新しい自動展開ルールは、人間のチェックだけがあった展開プロセスの一部のために作成されます。 追加のアラートメトリックも作成され、展開が失敗した状況を識別します。 この事件に影響を受けたお客様全員に報じ、問題の如何なる反復を防止するその他の変化を評価します。 CDN がこのような問題が発生した場合は、Sirv の設定で CDN を一時的に無効化することです。 https://my.sirv.com/#/account/settings/domains 重症度レベル2に分類:意味のある影響.
公式のインシデント更新を自動翻訳しています。
