mboost-dp1

Shutterstock

Fejl hos Fastly forårsager nedbrud på store hjemmesider

- Via Computerworld - , indsendt af arne_v

Som konsekvens af et globalt omfattende nedbrud oplevede brugere af en række hjemmesider at blive nægtet adgang på grund af en fejl hos Fastly.

TV 2, New York Times, Amazon, YouTube, Twitter mfl. – listen over nedbrudsramte hjemmesider er lang og omfangsrig.

Ifølge Computerworld findes fejlen formentlig hos Fastly, som er en amerikansk udbyder af cloud computing-tjenester. Dette fremgår ligeledes af Fastlys egen hjemmeside, hvor fejlen meldes identificeret og udbedret. Den egentlige årsag til nedbruddet oplyses imidlertid ikke af selskabet.

Der gik dog ikke mere end time, før fejlen blev fundet og løst, skriver Fastly.

TV 2 er blandt de hjemmesider, der gører brug af Fastlys tjenester til optimering af indhold på siden.

Nedbruddet kunne især ses hos downdoctor.com, hvor internetbrugere kan melde om nedbrud eller fejl på hjemmesider. Her havde op mod 20.000 brugere indberettet om fejl på reddit.com, som er en social nyheds- og underholdningshjemmeside.





Gå til bund
Gravatar #1 - arne_v
9. jun. 2021 13:37
De har offentliggjordt så meget som de nok vil gøre.

https://www.fastly.com/blog/summary-of-june-8-outa...


What happened?

On May 12, we began a software deployment that introduced a bug that could be triggered by a specific customer configuration under specific circumstances.

Early June 8, a customer pushed a valid configuration change that included the specific circumstances that triggered the bug, which caused 85% of our network to return errors.

Here’s a timeline of the day’s activity (all times are in UTC):

09:47 Initial onset of global disruption
09:48 Global disruption identified by Fastly monitoring
09:58 Status post is published
10:27 Fastly Engineering identified the customer configuration
10:36 Impacted services began to recover
11:00 Majority of services recovered
12:35 Incident mitigated
12:44 Status post resolved
17:25 Bug fix deployment began

Once the immediate effects were mitigated, we turned our attention to fixing the bug and communicating with our customers. We created a permanent fix for the bug and began deploying it at 17:25.

Gravatar #2 - Claus Jørgensen
9. jun. 2021 15:56
Ja, det var en sjov dag på arbejde i går...
Gravatar #3 - DrHouseDK
10. jun. 2021 07:08
Early June 8, a customer pushed a valid configuration change that included the specific circumstances that triggered the bug, which caused 85% of our network to return errors.

Av, av, av... Der må være flere røde ører rundt omkring. :-)
Gravatar #4 - arne_v
10. jun. 2021 13:22
#3

Ja.

Men det er ikke helt nemt at gardere sig mod.

Chef til udviklere: I må ikke lave fejl
Udviklere tænker: idiot - tror han at vi laver fejl med vilje

Chef til testere: I skal sikre jer at intet input kan ligge systemet ned
Testere til chef: umuligt - der er et uendeligt antal forkerte input og det vil tage uendeligt tid at teste dem alle

Chef til udviklere: jeg ønsker alle kritiske kode ændringer reviewet af 2 uafhængige teams, hvis der er 80% change for at sådanne fejl bliver fundet af et review så vil 2 reviews finde 96%
Udviklere: det er nok nødvendigt men suk

Chef til udviklere: vi køber dette her avancerede statiske kode analyse værktøj og vi forventer at det vil fange 95% af sådanne fejl
Udviklere til chef: OK

Gravatar #5 - DrHouseDK
11. jun. 2021 09:09
On May 12, we began a software deployment that introduced a bug that could be triggered by a specific customer configuration under specific circumstances.

Early June 8, a customer pushed a valid configuration change that included the specific circumstances that triggered the bug, which caused 85% of our network to return errors.

Det lyder jo næsten som om de var bevidst om der var et hul...

CSR CI kontrol siger jo intet om bugs en bruger kan introducere - kun om man overholder en kodestandard. Og hvis de 2 teams så endelig laver manuelt review, har de formenligt ikke forudsætninger for at forstå præcis hvad der skal foregå, og hvad deres change request har rødder i.

Men igen, lur mig om ikke det har været en fejl der været virkelig uheldig ikke at spotte.
Gravatar #6 - larsp
11. jun. 2021 10:04
En logisk fejl i noget kode som ellers lever op til alle kvalitetscheck, og som kun viser sig i under særlige omstændigheder/konfigurationer, er nok blandt de sværeste typer af fejl at gardere sig imod. Det kunne være flere komponenter der hver især opfører sig som planlagt, men som tilsammen ender med at gøre noget utilsigtet pga. en fejl i systemdesignet.

Jeg er ikke overrasket over at problemet var i denne kategori. Tvivler stærkt på at de allerede var bekendt med det.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login