Habr postmortem raporto: ĝi falis sur gazeton

La fino de la unua kaj komenco de la dua monato de somero 2019 montriĝis malfacila kaj estis markita de pluraj gravaj faloj en tutmondaj IT-servoj. Inter la rimarkindaj: du gravaj okazaĵoj en la infrastrukturo CloudFlare (la unua - kun malrektaj manoj kaj nezorgema sinteno al BGP flanke de kelkaj ISP-oj el Usono; la dua - kun malrekta deplojo de CF mem, kiu tuŝis ĉiujn uzantajn CF). , kaj ĉi tiuj estas multaj rimarkindaj servoj) kaj malstabila funkciado de la Facebook CDN-infrastrukturo (tuŝita ĉiujn FB-produktojn, inkluzive de Instagram kaj WhatsApp). Ni ankaŭ devis fali sub la distribuo, kvankam nia malfunkcio estis multe malpli rimarkebla kontraŭ la tutmonda fono. Iu jam komencis treni en nigraj helikopteroj kaj "suverenaj" konspiroj, do ni publikigas publikan postmortan de nia okazaĵo.

Habr postmortem raporto: ĝi falis sur gazeton

03.07.2019, 16: 05
Problemoj kun resursoj komencis esti registritaj, simile al paneo en interna retkonektebleco. Ne plene kontrolinte ĉion, ili komencis fari erarojn pri la agado de la ekstera kanalo al DataLine, ĉar evidentiĝis, ke la problemo estis kun la aliro de la interna reto al Interreto (NAT), ĝis la punkto de meti la BGP-sesion al la interreto. DataLine.

03.07.2019, 16: 35
Evidentiĝis, ke la ekipaĵo provizanta retan tradukadon kaj aliron de la loka reto de la retejo al Interreto (NAT) malsukcesis. Provoj rekomenci la ekipaĵon ne kondukis al nenio la serĉado de alternativaj opcioj por organizi konekteblecon komenciĝis antaŭ ricevi respondon de teknika subteno, ĉar de sperto, tio plej verŝajne ne helpus;

La problemo estis iom pligravigita de la fakto, ke ĉi tiu ekipaĵo ankaŭ ĉesigis venontajn konektojn de klientaj VPN-dungitoj, kaj fora reakira laboro fariĝis pli malfacila por plenumi.

03.07.2019, 16: 40
Ni provis revivigi antaŭe ekzistantan rezervan NAT-skemon, kiu antaŭe bone funkciis. Sed evidentiĝis, ke kelkaj retaj renovigoj igis ĉi tiun skemon preskaŭ tute senfunkcia, ĉar ĝia restarigo povus, en la plej bona kazo, ne funkcii aŭ, plej malbone, rompi tion, kio jam funkciis.

Ni komencis labori pri kelkaj ideoj por transdoni trafikon al aro da novaj enkursigiloj servantaj la spinon, sed ili ŝajnis nefareblaj pro la proprecoj de la distribuado de itineroj en la kerna reto.

03.07.2019, 17: 05
Samtempe, problemo estis identigita en la nomsolva mekanismo sur nomserviloj, kio kaŭzis erarojn en solvado de finpunktoj en aplikoj, kaj ili komencis rapide plenigi gastigajn dosierojn kun rekordoj de kritikaj servoj.

03.07.2019, 17: 27
La limigita funkcieco de Habr estis reestigita.

03.07.2019, 17: 43
Sed finfine oni trovis relative sekuran solvon por organizi trafikon per unu el la landlimaj enkursigiloj, kiu estis rapide instalita. Interreta konektebleco estis restarigita.

Dum la sekvaj minutoj, multaj sciigoj venis de la monitoraj sistemoj pri la restarigo de la funkcieco de la monitoraj agentoj, sed kelkaj el la servoj montriĝis nefunkcieblaj ĉar la nomsolva mekanismo sur la nomserviloj (dns) estis rompita.

Habr postmortem raporto: ĝi falis sur gazeton

03.07.2019, 17: 52
NS estis rekomencita kaj la kaŝmemoro estis forigita. Solvado estis restarigita.

03.07.2019, 17: 55
Ĉiuj servoj ekfunkciis krom MK, Freelansim kaj Toaster.

03.07.2019, 18: 02
MK kaj Freelansim eklaboris.

03.07.2019, 18: 07
Revenis senkulpan BGP-sesion kun DataLine.

03.07.2019, 18: 25
Ili komencis registri problemojn kun rimedoj, kio estis pro ŝanĝo en la ekstera adreso de la NAT-naĝejo kaj ĝia foresto en la akl de kelkaj servoj, kiu estis rapide korektita. La Panrostilo ekfunkciis tuj.

03.07.2019, 20: 30
Ni rimarkis erarojn rilatajn al Telegram-rotoj. Montriĝis, ke ili forgesis registri la eksteran adreson en kelkaj acl (prokuraj serviloj), kiu estis tuj korektita.

Habr postmortem raporto: ĝi falis sur gazeton

trovoj

  • La ekipaĵo, kiu antaŭe semis dubojn pri ĝia taŭgeco, malsukcesis. Estis planoj forigi ĝin de laboro, ĉar ĝi malhelpis la disvolviĝon de la reto kaj havis kongruajn problemojn, sed samtempe ĝi plenumis kritikan funkcion, tial ajna anstataŭaĵo estis teknike malfacila sen interrompi servojn. Nun vi povas pluiri.
  • La DNS-afero povas esti evitita movante ilin pli proksime al la nova spina reto ekster la NAT-reto kaj ankoraŭ kun plena konektebleco al la griza reto sen traduko (kiu estis la plano antaŭ la okazaĵo).
  • Vi ne uzu domajnajn nomojn dum kunvenado de RDBMS-grupoj, ĉar la oportuno travideble ŝanĝi la IP-adreson ne estas precipe necesa, ĉar tiaj manipuladoj ankoraŭ postulas rekonstrui la areton. Ĉi tiu decido estis diktita de historiaj kialoj kaj, antaŭ ĉio, de la evidenteco de finpunktoj laŭnome en RDBMS-agordoj. Ĝenerale, klasika kaptilo.
  • En principo, ekzercoj kompareblaj al la "suverenigo de la Runet" estas io por pensi pri plifortigo de la kapabloj de aŭtonoma postvivado.

fonto: www.habr.com

Aldoni komenton