Historique des pannes de Sirv

1. 6 août 2026 à 10:17 UTCinvestigating

   Les téléchargements vers certains comptes Sirv échouent, en raison d'un problème de serveur. Cela peut également empêcher les images d'afficher occasionnellement. Nous nous efforçons de résoudre le problème dès que possible.

2. 6 août 2026 à 15:22 UTCresolved

   La cause de la question a été identifiée et elle a maintenant été entièrement résolue. Au cours de la période, environ 25% des comptes Sirv ont peut-être connu une proportion de téléchargements de fichiers qui ont échoué. Il se peut que la réessayer un peu plus tard ait été une réussite parce que cela n'a eu qu'un faible nombre de demandes. Un examen est en cours et de plus amples informations seront fournies ici plus tard.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 27 juin 2026 à 18:34 UTCmonitoring

   Un petit nombre de téléchargements et de requêtes retournent des erreurs en raison de plusieurs pannes de commutateurs réseau dans le centre de données principal de Sirv. Les demandes CDN fonctionnent normalement. Nous suivons de près la situation et fournirons des mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 27 juin 2026 à 19:37 UTCresolved

   Tous les services sont de retour à la normale et les demandes sont complétées.

3. 28 juin 2026 à 09:03 UTCresolved

   Ce problème a été causé par une défaillance du routeur principal affectant le centre de données primaire de Sirv. Cela a provoqué de brèves pannes intermittentes sur le stockage et les téléchargements de fichiers, dans tous les types de transfert : API, S3 et FTP. Sirv est automatiquement passé à son service d'échec, de sorte que le traitement et la livraison des fichiers se sont poursuivis comme d'habitude. Les demandes du RNC se sont également poursuivies normalement. Tous les services ont été restaurés une fois que le datacentre a résolu la panne du routeur principal.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 30 janvier 2026 à 12:46 UTCinvestigating

   Le temps de réponse à certaines demandes en Allemagne est plus lent que la normale et un petit nombre de demandes sont à l'arrêt. La question fait l'objet d'une enquête.

2. 30 janvier 2026 à 14:28 UTCresolved

   La question a été réglée. L'un des serveurs desservant l'Allemagne a été surchargé et a réagi plus lentement que d'habitude. Le serveur est maintenant en bonne santé. Nous examinons les mesures à prendre pour réduire le risque que cela se reproduise.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 mars 2025 à 14:32 UTCinvestigating

   Certaines demandes de la Californie sont lentes et un petit nombre (moins de 2%) échoue. Ceci est en cours d'étude et probablement lié à de nouveaux serveurs CDN qui ont été déployés aujourd'hui à Los Angeles.

2. 31 mars 2025 à 15:16 UTCresolved

   La question a été réglée. Le problème a été causé par la perte de paquets affectant notre nouveau centre de données de Los Angeles. Le datacenter retraçait le problème à son fournisseur en amont, Arelion, qui connaissait l'instabilité du réseau. Le problème a été résolu lorsque Arelion a été temporairement désactivé en tant que fournisseur en amont et que le trafic a été réacheminé par d'autres fournisseurs. Nous exigeons que nos datacenters identifient et réacheminent le trafic automatiquement et rapidement dans de tels scénarios. Cependant, la résolution de cette question n'a pas été assez rapide et étant donné qu'elle s'est produite peu après l'adoption de ce nouveau datacenter, nous avons décidé de cesser de l'utiliser. Tout le trafic est maintenant acheminé depuis notre centre de données de Los Angeles (au 7 avril 2025).

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 mars 2025 à 17:56 UTCresolved

   Certains téléchargements de fichiers ne sont pas terminés en raison d'un problème de cluster de serveur. La cause est en cours d'enquête. La question touche un petit nombre de comptes. Si votre téléchargement de fichier échoue, veuillez attendre que ce problème ait été résolu.

2. 16 mars 2025 à 08:40 UTCidentified

   Cette question demeure en cours. La cause du problème a été identifiée et nous nous efforçons de le résoudre le plus rapidement possible.

3. 16 mars 2025 à 15:25 UTCresolved

   La question a été réglée. Le problème a été causé par deux serveurs dans un cluster qui ont échoué simultanément. Cela a eu une incidence sur le téléchargement de nouveaux fichiers dans environ 20% des comptes Sirv. Les chargements sont conçus pour continuer normalement lorsqu'un serveur est en panne, mais lorsque deux serveurs sont en panne, certains chargements peuvent échouer, ce qui est arrivé. Ils ont échoué en raison d'un service exportateur qui a cessé de fonctionner sur un serveur, puis sur l'autre serveur. Les erreurs ont empêché les services de redémarrer. Puis un deuxième problème a causé la résolution de prendre beaucoup plus de temps que prévu parce que les serveurs ne pouvaient pas être redémarrés. Cela était dû à un BIOS dépassé. Une fois le BIOS mis à jour, les serveurs ont été redémarrés et la cause du problème sous-jacent a été résolue. Pour éviter que cela ne se reproduise, nous avons mis en place un nouveau processus de gestion BIOS avec notre datacenter. Nous raccourcissons également notre cycle de rafraîchissement du matériel, pour des mises à niveau plus fréquentes. Afin de réduire les risques de défaillance du service exportateur, nous avons désactivé un processus et sommes en train de surveiller les paramètres du serveur.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 26 février 2025 à 09:29 UTCinvestigating

   Pendant une période de 3 minutes entre 09:29 et 09:32 UTC, certaines demandes n'ont pas été retournées. Cette question ne concerne que certaines demandes et seulement certains comptes. La plupart des comptes n'étaient pas affectés.

2. 26 février 2025 à 09:32 UTCresolved

   La question a été réglée dans les 3 minutes. La cause était le redémarrage de plusieurs serveurs en même temps, alors que seul un serveur aurait dû être redémarré. C'était une surveillance dans nos procédures opérationnelles normalisées. Nous étudions les moyens de protéger automatiquement et d'éviter que cela ne se reproduise.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 décembre 2024 à 14:20 UTCresolved

   Une défaillance du serveur provoque l'échec de certains chargements de fichiers pour un nombre limité de comptes. La question est en cours de résolution. Si vous rencontrez des téléchargements échoués, veuillez arrêter et essayer de nouveau plus tard.

2. 19 décembre 2024 à 18:09 UTCresolved

   La question a été réglée. Un nombre exceptionnellement important de serveurs a échoué en même temps. Sirv est conçu pour continuer le fonctionnement normal pendant une panne de serveur et tous les systèmes ont continué comme normal, mais certains téléchargements de fichiers ont échoué. Nous examinons les changements qui pourraient être apportés à l'avenir pour aider à de telles situations.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 novembre 2024 à 09:52 UTCinvestigating

   Un nombre élevé de 504 timeouts sont retournés pour les demandes de téléchargement de fichiers API.

2. 14 novembre 2024 à 13:19 UTCinvestigating

   Il continue d'y avoir une lourde charge sur l'API à partir des requêtes de téléchargement. Un facteur contributif est le grand nombre de demandes d'augmentation d'image d'IA, qui prennent plus de temps que d'habitude à traiter. Le retard causé par la file d'attente des requêtes fait échouer certaines requêtes de téléchargement de fichiers API avec une réponse 504.

3. 14 novembre 2024 à 15:23 UTCresolved

   Des changements ont été apportés et la question est presque réglée. La majorité des demandes de téléchargement sont acceptées.

4. 14 novembre 2024 à 19:06 UTCresolved

   La surcharge de téléchargement de l'API est presque complètement résolue.

5. 15 novembre 2024 à 04:42 UTCresolved

   La question a été entièrement réglée. Le problème a commencé lorsque les requêtes de l'API upscaling d'image lourde ont surchargé l'API de téléchargement, ce qui a amené certaines requêtes de l'API à retourner 504 erreurs. Ceci a été résolu, mais un effet de frappe a causé environ 5% des demandes d'API à échouer avec une réponse 502. Pour éviter que ce problème ne se reproduise, des améliorations ont été apportées afin de réduire la charge d'augmentation de l'image et de mieux répartir la charge. Des changements sont également apportés à l'enregistrement et à l'alerte afin d'accélérer l'identification de ces scénarios. Le plus grand impact de cette question a été sur le plugin WordPress Sirv. Le plugin envoyait une demande d'API sur toutes les pages d'administration, ce qui a bloqué le chargement de la page jusqu'à ce que la réponse ait été reçue - généralement moins de 300ms mais jusqu'à 20 secondes si les demandes d'API ont été chronométrées. Ces demandes d'API n'étaient pas requises, de sorte qu'une nouvelle version de plugin WordPress v7.3.3 a été publiée à 1805 UTC (14 novembre) pour supprimer ces demandes et empêcher ce problème de se reproduire: https://wordpress.org/plugins/sirv/ ----- Si vous utilisez l'API Sirv, nous recommandons que vos scripts soient écrits pour réessayer les requêtes qui reçoivent une réponse 502. Les recommandations pour le traitement de 502 et d'autres réponses aux erreurs sont présentées ici: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 février 2024 à 10:52 UTCinvestigating

   Certains fichiers ne sont pas retournés pour un petit nombre de comptes. Cette question est traitée de toute urgence.

2. 22 février 2024 à 12:06 UTCresolved

   La question a été réglée. À 10 h 52 UTC, environ 11 % des demandes à un petit nombre de comptes (12 comptes, sur 50 000+) renvoyaient 404 réponses (dossier non trouvé) lorsqu'elles auraient dû retourner 200 réponses (OK). Lorsque l'équipe Sirv a identifié le problème, elle a rapidement travaillé pour le résoudre et, en 1206 UTC, toutes ces demandes étaient en train de renvoyer la réponse normale de 200. Le problème est survenu en raison d'une mauvaise configuration par les ingénieurs de Sirv pendant qu'ils configuraient un nouveau groupe de stockage shard. Certaines demandes allaient au nouveau shard avant qu'il ne soit prêt à les recevoir. Classé comme niveau de gravité 3: Impact mineur.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 5 janvier 2024 à 20:21 UTCinvestigating

   Un grand nombre de demandes aux 25 emplacements CDN de Sirv renvoient une erreur. Nos ingénieurs travaillent rapidement pour identifier et résoudre le problème.

2. 5 janvier 2024 à 21:07 UTCresolved

   La question a été réglée. Il a été causé par l'échec d'un démon logiciel simultanément sur plusieurs serveurs. C'est un gestionnaire de service léger et très efficace qui n'a jamais échoué dans le passé. Au cours de la période, entre 3% et 58% des requêtes HTTPS ont retourné une erreur, en fonction de laquelle des 25 emplacements CDN a reçu la requête. Nous enquêtons maintenant sur la raison pour laquelle cela s'est produit et nous prendrons des mesures pour éviter que cela n'ait une incidence sur la disponibilité des services à l'avenir. Catégorie de gravité 2: Impact significatif.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 5 décembre 2023 à 15:03 UTCinvestigating

   Un niveau élevé de 415 erreurs se produit sur le CDN. Nos ingénieurs enquêtent sur la cause.

2. 5 décembre 2023 à 18:32 UTCinvestigating

   Nous continuons d'enquêter sur la cause de cette question. Sa nature est complexe. Il se représente comme une erreur 415, à partir de fichiers de zéro octets. Il y a aussi un taux élevé mais inférieur de 500 erreurs. La majorité des demandes ont reçu 200 réponses. Nos ingénieurs travaillent dur pour comprendre et résoudre cela.

3. 5 décembre 2023 à 22:56 UTCresolved

   Le problème d'erreur 415 a été causé par certains fichiers devenant tronqués, ce qui signifie qu'ils ont perdu une partie de leur contenu. Ces fichiers apparaissent dans le panneau de contrôle de my.sirv.com comme ayant 0 octets. Les fichiers téléchargés aujourd'hui étaient plus susceptibles de devenir tronqués, bien qu'il semble que la troncation se soit produite dans les fichiers depuis longtemps. Ceci n'a pas été identifié parce qu'ils se sont déroulés entièrement comme normaux, en raison de la mise en cache de versions non tronquées. Le problème de fichier tronqué n'est devenu visible qu'aujourd'hui, après une mise à niveau de l'infrastructure. Les caches du serveur ont été effacés et les versions tronquées sont devenues apparentes. On pense que la cause de la troncation a été un bug logiciel qui a maintenant été résolu. Nous travaillons actuellement à restaurer les fichiers tronqués - un processus qui peut prendre des heures à des jours. Si vous êtes en mesure de recharger des fichiers qui ne sont pas en cours de chargement, veuillez le faire maintenant. On estime que la question touche environ 0,2% des dossiers.

4. 5 décembre 2023 à 23:33 UTCresolved

   Environ 80 % des fichiers tronqués ont été récupérés. Le nombre de 415 erreurs a considérablement diminué, bien qu'elles demeurent élevées. Pour résoudre complètement le problème, les fichiers tronqués restants doivent être remplacés par le fichier original. Nous travaillons sur les moyens de récupérer ces fichiers restants, bien qu'ils soient difficiles à obtenir et cela peut prendre des heures ou des jours. Pour la résolution la plus rapide possible, il est recommandé de recharger les fichiers. De tels fichiers afficheront dans votre compte comme ayant 0 octets. Commencez par l'URL suivante, pour voir la liste de tous les fichiers téléchargés au cours des 30 derniers jours : https://my.sirv.com/#/search/?created=30d Trouvez les fichiers zéro octet en triant les résultats par Taille, Ascendance. Une autre mise à jour sera publiée ici une fois que nous aurons des nouvelles sur les fichiers restants.

5. 6 décembre 2023 à 01:48 UTCinvestigating

   Nous continuons à récupérer le petit nombre de fichiers tronqués restants. On estime que cela nécessite 12 à 24 heures de plus. Si vous avez des fichiers qui ne sont pas servis, vous pouvez résoudre cela tout de suite en les rechargeant. Nous créons un outil pour générer une liste de fichiers zéro octet. Si vous souhaitez une liste de fichiers à octets zéro dans votre compte, veuillez soumettre une demande à https://sirv.com/help/support/#support et nous préparerons une liste une fois l'outil prêt. Quoi qu'il en soit, nous continuerons à travailler pour récupérer tous les fichiers. Si vous téléchargez des fichiers en utilisant la fonction Autofetch de Sirv, vous pouvez simplement supprimer les fichiers zéro octet et ils seront re-fessés à partir de votre emplacement distant à la prochaine demande.

6. 6 décembre 2023 à 12:12 UTCresolved

   D'autres fichiers ont été restaurés. Le taux de 415 erreurs continue de baisser. Vous pouvez voir une liste de 415 erreurs sur cette page de votre compte : https://my.sirv.com/#/analytics/errors/415?from=20231206&to=20231206 Vous pouvez télécharger des fichiers pour résoudre toute erreur 415 dans vos fichiers. Nous pouvons fournir une liste de fichiers à octet zéro si vous avez besoin - veuillez demander à l'équipe de soutien Sirv via ce formulaire: https://sirv.com/help/support/#support Nous continuons à restaurer autant de fichiers que possible.

7. 6 décembre 2023 à 19:47 UTCresolved

   La question qui a causé le taux élevé de 415 erreurs a été résolue. Les fichiers tronqués ont été causés par un problème logiciel qui a écrit certains fichiers avec zéro octets. Comme c'était un logiciel, cela a provoqué la reproduction des fichiers tronqués dans toutes les versions du fichier maître. Sirv triplie chaque fichier pour protéger contre les problèmes matériels (défauts de serveur ou de disque dur), cependant, les fichiers mis à jour ont passé toutes les vérifications et tripliqué fidèlement les fichiers. Il existait sans détection parce que les versions en cache des fichiers étaient utilisées pour le traitement et la livraison. Tous les systèmes ont parfaitement fonctionné, jusqu'à la mise à niveau de l'infrastructure d'hier quand les fichiers en cache ont été effacés. La cause fondamentale a été résolue en identifiant et en corrigeant le problème logiciel qui a causé la troncation. Cela a été complété par 1500 UTC le 5 décembre. Puis la tâche était de restaurer les fichiers qui avaient été tronqués. Sur l'ensemble de la plateforme, environ 0,2% des dossiers avaient été touchés. Parmi ces fichiers, nous avons pu restaurer entre 95% et 100%, selon le compte. Tout compte ayant une restauration inférieure à 100% est envoyé une liste de fichiers zéro octet qui devraient être restaurés en téléchargeant les fichiers à nouveau. Veuillez consulter notre courriel avec une liste de fichiers. Veuillez nous envoyer un message via l'URL suivante si vous avez besoin d'aide : https://sirv.com/help/support/#support Une enquête approfondie sur la question est en cours, qui sera présentée en détail par courriel. Le rapport contiendra une liste des mesures prises pour éviter toute répétition éventuelle de cette question, ainsi que des améliorations et des nouvelles caractéristiques qui sont déjà en cours de conception. Nous nous excusons auprès de tous les clients qui ont été touchés par ce problème. C'est la première fois que des données maîtresses sont perdues. Nous allons en tirer toutes les leçons possibles et rendre Sirv encore plus fort et fiable qu'auparavant.

8. 21 décembre 2023 à 10:05 UTCresolved

   Plus de 99 % des fichiers tronqués restants ont également été restaurés. Tout utilisateur touché a reçu une liste exacte des fichiers qui ont été touchés. Il ne reste aucun impact résiduel de cette question. Catégorie de gravité 1: Impact critique.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 2 décembre 2023 à 04:19 UTCinvestigating

   À partir de 0419 UTC, un niveau élevé de 429 erreurs a été retourné de l'emplacement du RNC de Sydney.

2. 2 décembre 2023 à 10:31 UTCresolved

   La question a été réglée à 1031 UTC. La cause était une erreur de configuration du serveur qui a fait que l'emplacement du CDN de Sydney voit toutes les requêtes provenant de la même adresse IP, au lieu de la véritable adresse IP client. Cela a déclenché la protection DSOS, afin de limiter le nombre excessif de requêtes provenant de la même IP. 429 réponses ont été retournées pour un grand nombre de demandes. Le problème semblait être extrêmement court lorsque le réseau de datacentres de Sydney est devenu indisponible. Ce numéro a duré environ 1 minute seulement. Cependant, l'incident réel a commencé immédiatement après que notre équipe ait rétabli l'emplacement du CDN de Sydney, c'est-à-dire lorsque le serveur a été mal configuré. Le problème a été résolu une fois que nous avons découvert la mauvaise configuration et corrigé. Plusieurs mesures sont prises pour éviter que cette question ne se répète et pour réduire l'impact de questions similaires mais différentes à l'avenir : - Surveillance et alerte supplémentaires - Nouveau formulaire de soumission - Conseils de résolution sensibles au contexte - Alerte interne plus large Seul l'emplacement du RNC de Sydney a été touché. Classé comme niveau de gravité 3: Impact mineur.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 novembre 2023 à 18:30 UTCinvestigating

   Vers 18h30 UTC, le 22 novembre, nous avons commencé à mettre à niveau la base de données de fichiers primaires pour créer un nouveau groupe plus puissant. Alors que la mise à jour a eu lieu, les requêtes de recherche d'API ont échoué.

2. 23 novembre 2023 à 10:35 UTCresolved

   À 10 h 35 UTC, le 23 novembre, la mise à niveau était terminée et les recherches ont repris leur cours normal. Il n'y avait pas de temps d'arrêt et tous les systèmes fonctionnaient normalement, sauf que les requêtes de recherche d'API avaient retourné des réponses d'erreur. Le problème n'a pas été relevé parce que d'autres demandes d'API étaient retournées comme normale, de sorte que les réponses d'erreurs totales d'API n'étaient que légèrement élevées et qu'aucune alerte n'a été déclenchée. Le problème a été identifié après l'événement, après qu'un rapport d'un utilisateur ait déclenché une enquête. Pour identifier automatiquement ces problèmes à l'avenir, nous évaluons les moyens de surveiller spécifiquement l'API de recherche. Nous allons également mettre à jour le plugin WordPress Sirv pour montrer un message clairement décrit en cas d'échec de la recherche. Classé comme niveau de gravité 4: Impact minimal.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 novembre 2023 à 20:47 UTCinvestigating

   Les outils de gestion de fichiers de my.sirv.com sont chargés lentement en raison d'un serveur défaillant. Listing de fichiers et la recherche de fichiers prend de 2 à 20 secondes, alors qu'il faut normalement 1 à 4 secondes. Le serveur défaillant est remplacé et nous nous attendons à ce que la vitesse revienne à la normale dans les 72 heures. Cela sera suivi d'une mise à niveau majeure de l'ensemble du groupe de serveurs de panneau de contrôle au cours des 3 prochains mois.

2. 14 novembre 2023 à 21:33 UTCinvestigating

   Nous attendons la fourniture d'un nouveau serveur à ajouter au cluster, alors la vitesse de navigation de l'interface utilisateur deviendra beaucoup plus rapide.

3. 15 novembre 2023 à 14:09 UTCresolved

   Le nouveau serveur a été déployé dans la soirée du 14 novembre et a progressivement rempli ses caches. Le panneau de commande est maintenant revenu à ses performances rapides originales. D'autres serveurs sont maintenant mis à niveau, de sorte que le panneau de contrôle va charger plus rapidement encore au cours des 2 prochaines semaines. Classé comme niveau de gravité 4: Impact minimal.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 octobre 2023 à 13:10 UTCinvestigating

   Une augmentation spectaculaire des demandes à l'emplacement du CDN de Washington D.C. s'est produite le 23 octobre à 14 h 10 UTC, ce qui a entraîné le retour d'une petite proportion des demandes lentement - plus de 2 secondes. La question s'est apaisée au cours des trois prochaines heures, bien que le temps de réponse moyen soit demeuré élevé. La question est revenue le jour suivant à 14:32 UTC le 24 octobre, plus sévèrement qu'avant, entraînant 17% des demandes à charger lentement - plus de 2 secondes et certains aussi longtemps que 30 secondes. Le problème a touché deux des 25 emplacements du CDN de Sirv.

2. 25 octobre 2023 à 05:48 UTCresolved

   La question a été réglée par 06:48 UTC le 25 octobre. L'enquête pointe vers deux causes - la pointe a été causée par le fournisseur DNS de Sirv acheminant les demandes POP de Los Angeles vers le POP de Washington D.C. à la place. Cela aurait été très bien isolément, mais le datacenter semble avoir réduit la bande passante des serveurs récepteurs, provoquant des réponses lentes. L'enquête est en cours, n'a pas encore abouti à des conclusions définitives et nécessite une collaboration avec nos fournisseurs de DNS et de datacenters. Des mesures sont déjà prises pour éviter toute répétition de cette question. Un rapport détaillé sera présenté ici plus tard.

3. 14 novembre 2023 à 13:37 UTCresolved

   L'enquête détaillée sur cette question a révélé deux facteurs contributifs. La première était une mise à jour de la route53 du SSFE, qui semble avoir été mise en œuvre par le SSFE le 17 octobre. Ce changement n'a pas été apporté par Sirv à ses règles Route53, mais à un changement au sein du service Route53 lui-même. Le POP de Los Angeles avait une logique de routage légèrement différente pour les autres POP et la mise à jour du système AWS a entraîné un routage différent, le trafic étant acheminé vers le retour à Washington DC. Cela n'a pas été remarqué car la charge plus élevée était encore dans sa capacité et les demandes ont été renvoyées avec succès, donc cela est passé inaperçu puisque Washington DC a pu gérer la charge supplémentaire. Le deuxième facteur contributif était plus élevé que la normale pendant les heures de pointe des États-Unis les 23 et 24 octobre. Les deux facteurs combinés ont causé le retour des demandes des disques durs Washington DC beaucoup plus lent que la normale. Depuis que la question s'est posée, nous avons pris de multiples mesures pour éviter qu'elle ne se répète, atténuer les risques d'incidents semblables et accélérer le délai de règlement en cas d'incident. Les actions comprennent : - Une nouvelle logique de routage a été appliquée. - La capacité de Washington DC a été augmentée. - La capacité de réserve a été accrue dans tous les autres sites du RNC. - Une nouvelle tolérance a été introduite pour qu'un emplacement du RNC soit retiré du routage. - Surveillance supplémentaire du disque, pour faciliter la préparation précoce des mises à niveau de capacité. - Les DDH sont remplacés par des SSD. - Mise à jour des PON pour notre équipe de soutien afin d'étudier et de répondre à des questions similaires. Classé comme niveau de gravité 3: Impact mineur.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 mai 2023 à 14:57 UTCinvestigating

   Le numéro précédent de l'utilisation de téléchargement élevé est retourné, avec un petit nombre de téléchargement API en panne.

2. 22 mai 2023 à 15:06 UTCresolved

   Le problème s'est résolu dans les 9 minutes une fois le volume de téléchargement normalisé. Au cours de la période, environ 98 % des téléchargements ont réussi et 2 % ont échoué. Les téléchargements de l'API REST sont limités par heure, à la quantité spécifiée sur la page d'utilisation de votre compte Sirv https://my.sirv.com/#/account/usage. Si vous utilisez l'API REST pour télécharger des images, la meilleure pratique est de vérifier la réponse pour chaque demande de téléchargement et si vous recevez une réponse d'erreur (400, 401, 429 etc.) puis de mettre en pause les téléchargements et de réessayer plus tard. Voir les documents ici: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Classé comme niveau de gravité 4: Impact minimal.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 mai 2023 à 11:31 UTCinvestigating

   Un petit nombre de demandes de téléchargement d'API REST échoue en raison de la charge très élevée.

2. 22 mai 2023 à 12:37 UTCresolved

   Ce problème s'est résolu une fois que la charge sur l'API de téléchargement a commencé à tomber. Au cours de la période, environ 97 % des téléchargements ont réussi et 3 % ont échoué. Les téléchargements de l'API REST sont limités par heure, à la quantité spécifiée sur la page d'utilisation de votre compte Sirv https://my.sirv.com/#/account/usage. Si vous utilisez l'API REST pour télécharger des images, la meilleure pratique est de vérifier la réponse pour chaque demande de téléchargement et si vous recevez une réponse d'erreur (400, 401, 429 etc.) puis de mettre en pause les téléchargements et de réessayer plus tard. Voir les documents ici: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Classé comme niveau de gravité 4: Impact minimal.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 27 avril 2023 à 23:00 UTCinvestigating

   Un des serveurs CDN de Los Angeles est devenu malsain et a commencé à renvoyer 4xx erreurs à 0000 UTC. Il a été retiré du routage après 90 secondes et en 60 secondes, tout le trafic était acheminé vers des serveurs sains.

2. 27 avril 2023 à 23:03 UTCresolved

   La question a été réglée automatiquement dans les 3 minutes. Classé comme niveau de gravité 4: Impact minimal.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 mars 2023 à 12:17 UTCinvestigating

   Certaines demandes au POP londonien de Sirv CDN renvoient des erreurs en raison d'une charge élevée. Ce POP sert le Royaume-Uni et l'Irlande. Nous travaillons sur une résolution.

2. 16 mars 2023 à 13:33 UTCresolved

   La question a été réglée et fait actuellement l'objet d'un suivi.

3. 16 mars 2023 à 16:22 UTCresolved

   Certaines demandes reçues par l'un des serveurs de CDN de Londres ont échoué en raison d'une combinaison de résolution DNS locale et de temps d'attente réseau pulsant. La question a commencé à 12h15 UTC et a été résolue à 13h32 UTC. Au cours de cette période, 25 % des demandes du Royaume-Uni et de l'Irlande ont répondu à une erreur 404 ou 500. Le problème aurait été résolu plus tôt, mais une défaillance non liée de validation de certificat SSL quelques heures plus tôt a bloqué les alertes d'être reçues par notre système de surveillance. Des changements ont déjà été apportés pour éviter que cette question ne se reproduise. La question du certificat SSL a été réglée; un deuxième niveau de surveillance indépendante a été configuré; une nouvelle automatisation de la santé est en cours d'essai qui pourrait résoudre ces problèmes automatiquement. Classé comme niveau de gravité 3: Impact mineur.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 février 2023 à 07:55 UTCresolved

   La question a été réglée à 0755 UTC. À 6 h 25 UTC, certaines demandes adressées au POP Indore CDN qui sert l'Inde ont commencé à renvoyer une réponse 404 (fichier non trouvé), au lieu d'une réponse 200 (OK). Le problème s'est produit 14 heures après une mise à jour de tous les serveurs CDN dans le monde. Tous les POP se sont comportés sainement, y compris les POP de l'Inde, mais les POP d'Indore n'avaient pas été mis à jour avec succès et ont finalement commencé à renvoyer des erreurs. Une fois le problème identifié, il a été résolu en redéployant la mise à jour au POP indien. Au cours de l'incident, 94 % des demandes ont retourné une erreur. Les demandes adressées à tous les autres pays ont été renvoyées normalement. Pour éviter que cette question ne se répète, une nouvelle règle de déploiement automatisé est en cours d'élaboration pour une partie du processus de déploiement où il n'y a eu qu'un contrôle humain. Une mesure d'alerte supplémentaire est également en cours d'élaboration, afin d'identifier une situation dans laquelle un déploiement a échoué. Nous nous excusons auprès de tous les clients qui ont été touchés par cet incident et nous évaluons d'autres changements qui pourraient aider à prévenir toute répétition possible du problème. Si un problème de CDN comme celui-ci se produit, une solution immédiate sous votre contrôle est de désactiver temporairement le CDN dans vos paramètres Sirv ici: https://my.sirv.com/#/account/settings/domaines Catégorie de gravité 2: Impact significatif.

Traduit automatiquement depuis la mise à jour officielle de l'incident.