Saluton al ĉiuj! Mia nomo estas Dmitry Samsonov, mi laboras kiel gvida administranto de la sistemo ĉe Odnoklassniki. Ni havas pli ol 7 mil fizikajn servilojn, 11 mil ujojn en nia nubo kaj 200 aplikaĵojn, kiuj en diversaj agordoj formas 700 malsamajn aretojn. La granda plimulto de serviloj funkcias CentOS 7.
La 14-an de aŭgusto 2018, informoj pri la vundebleco FragmentSmack estis publikigitaj
() kaj SegmentSmack (). Ĉi tiuj estas vundeblecoj kun reta atakvektoro kaj sufiĉe alta poentaro (7.5), kiu minacas neon de servo (DoS) pro resursa elĉerpiĝo (CPU). Kerna solvo por FragmentSmack ne estis proponita tiutempe; krome, ĝi aperis multe pli malfrue ol la publikigo de informoj pri la vundebleco. Por forigi SegmentSmack, oni sugestis ĝisdatigi la kernon. La ĝisdatiga pako mem estis liberigita en la sama tago, restis nur instali ĝin.
Ne, ni tute ne kontraŭas ĝisdatigi la kernon! Tamen estas nuancoj...
Kiel ni ĝisdatigas la kernon pri produktado
Ĝenerale, nenio komplika:
- Elŝutu pakaĵojn;
- Instalu ilin sur kelkaj serviloj (inkluzive de serviloj gastigantaj nian nubon);
- Certiĝu, ke nenio estas rompita;
- Certigu, ke ĉiuj normaj kernaj agordoj estas aplikataj sen eraroj;
- Atendu kelkajn tagojn;
- Kontrolu la rendimenton de la servilo;
- Ŝaltu disfaldiĝon de novaj serviloj al la nova kerno;
- Ĝisdatigu ĉiujn servilojn per datumcentro (unu datumcentro samtempe por minimumigi la efikon al uzantoj en kazo de problemoj);
- Rekomencu ĉiujn servilojn.
Ripeti por ĉiuj branĉoj de la kernoj, kiujn ni havas. Nuntempe ĝi estas:
- Stock CentOS 7 3.10 - por la plej multaj regulaj serviloj;
- Vanilo 4.19 - por la nia , ĉar ni bezonas BFQ, BBR, ktp.;
- Elrepo kernel-ml 5.2 - por , ĉar 4.19 kutimis konduti malstabile, sed la samaj trajtoj estas bezonataj.
Kiel vi eble divenis, rekomenci milojn da serviloj prenas la plej longan tempon. Ĉar ne ĉiuj vundeblecoj estas kritikaj por ĉiuj serviloj, ni nur rekomencas tiujn, kiuj estas rekte alireblaj de la Interreto. En la nubo, por ne limigi flekseblecon, ni ne ligas ekstere alireblajn ujojn al individuaj serviloj kun nova kerno, sed rekomencas ĉiujn gastigantojn sen escepto. Feliĉe, la procedo tie estas pli simpla ol ĉe regulaj serviloj. Ekzemple, sennaciaj ujoj povas simple moviĝi al alia servilo dum rekomenco.
Tamen, estas ankoraŭ multe da laboro, kaj ĝi povas daŭri plurajn semajnojn, kaj se estas problemoj kun la nova versio, ĝis pluraj monatoj. Atakantoj komprenas ĉi tion tre bone, do ili bezonas planon B.
FragmentSmack/SegmentSmack. Solvaĵo
Feliĉe, por iuj vundeblecoj tia plano B ekzistas, kaj ĝi nomiĝas Workaround. Plej ofte, ĉi tio estas ŝanĝo en kerno/aplikaj agordoj, kiu povas minimumigi la eblan efikon aŭ tute forigi la ekspluaton de vundeblecoj.
En la kazo de FragmentSmack/SegmentSmack ĉi tiu solvo:
«Vi povas ŝanĝi la defaŭltajn valorojn de 4MB kaj 3MB en net.ipv4.ipfrag_high_thresh kaj net.ipv4.ipfrag_low_thresh (kaj iliaj ekvivalentoj por ipv6 net.ipv6.ipfrag_high_thresh kaj net.ipv6.ipfrag_low_thresh) al 256 kB kaj respektive. pli malalta. Testoj montras malgrandajn ĝis signifajn falojn en CPU-uzado dum atako depende de aparataro, agordoj kaj kondiĉoj. Tamen, povas esti iom da agado-efiko pro ipfrag_high_thresh=192 bajtoj, ĉar nur du 262144K fragmentoj povas konveni en la remuntadovico samtempe. Ekzemple, ekzistas risko, ke aplikaĵoj, kiuj funkcias kun grandaj UDP-pakoj, rompiĝos".
La parametroj mem priskribite jene:
ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
Ni ne havas grandajn UDP-ojn pri produktadservoj. Ekzistas neniu fragmenta trafiko sur la LAN; ekzistas fragmenta trafiko sur la WAN, sed ne signifa. Ne estas signoj - vi povas elŝuti Solucion!
FragmentSmack/SegmentSmack. Unua sango
La unua problemo, kiun ni renkontis, estis, ke nubaj ujoj foje aplikis la novajn agordojn nur parte (nur ipfrag_low_thresh), kaj foje tute ne aplikis ilin - ili simple kraŝis ĉe la komenco. Ne eblis stabile reprodukti la problemon (ĉiuj agordoj estis aplikataj permane sen malfacilaĵoj). Kompreni kial la ujo kraŝas ĉe la komenco ankaŭ ne estas tiel facila: neniuj eraroj estis trovitaj. Unu afero estis certa: refari la agordojn solvas la problemon pri ujkraŝoj.
Kial ne sufiĉas apliki Sysctl sur la gastiganto? La ujo loĝas en sia propra diligenta reto Nomspaco, do almenaŭ en la ujo povas diferenci de la gastiganto.
Kiel ĝuste Sysctl-agordoj estas aplikataj en la ujo? Ĉar niaj ujoj estas senprivilegiaj, vi ne povos ŝanĝi ajnan Sysctl-agordon enirante la ujon mem - vi simple ne havas sufiĉajn rajtojn. Por funkciigi ujojn, nia nubo tiutempe uzis Docker (nun ). La parametroj de la nova ujo estis transdonitaj al Docker per la API, inkluzive de la necesaj Sysctl-agordoj.
Dum serĉado tra la versioj, montriĝis, ke la Docker API ne resendis ĉiujn erarojn (almenaŭ en la versio 1.10). Kiam ni provis lanĉi la ujon per "docker run", ni finfine vidis almenaŭ ion:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.
La parametrovaloro ne validas. Sed kial? Kaj kial ĝi ne validas nur kelkfoje? Montriĝis, ke Docker ne garantias la ordon en kiu Sysctl-parametroj estas aplikataj (la plej nova provita versio estas 1.13.1), do foje ipfrag_high_thresh provis esti agordita al 256K kiam ipfrag_low_thresh ankoraŭ estis 3M, tio estas, la supra limo estis pli malalta. ol la malsupra limo, kiu kondukis al la eraro.
En tiu tempo, ni jam uzis nian propran mekanismon por reagordi la ujon post komenco (frosti la ujon post kaj ekzekuti komandojn en la nomspaco de la ujo per ), kaj ni ankaŭ aldonis skribajn Sysctl-parametrojn al ĉi tiu parto. La problemo estis solvita.
FragmentSmack/SegmentSmack. Unua Sango 2
Antaŭ ol ni havis tempon kompreni la uzon de Workaround en la nubo, la unuaj maloftaj plendoj de uzantoj komencis alveni. En tiu tempo, pluraj semajnoj pasis ekde la komenco de uzado de Workaround sur la unuaj serviloj. La komenca enketo montris, ke plendoj estis ricevitaj kontraŭ individuaj servoj, kaj ne ĉiuj serviloj de ĉi tiuj servoj. La problemo denove fariĝis ege necerta.
Antaŭ ĉio, ni kompreneble provis refari la Sysctl-agordojn, sed ĉi tio ne efikis. Diversaj manipuladoj kun la servilo kaj aplikaĵagordoj ankaŭ ne helpis. Reboot helpis. Rekomenci Linukso estas tiel nenatura kiel ĝi estis normala por Vindozo en la malnovaj tempoj. Tamen, ĝi helpis, kaj ni kalkulis ĝin al "kernelproblemo" kiam aplikante la novajn agordojn en Sysctl. Kiel frivola ĝi estis...
Tri semajnojn poste la problemo ripetiĝis. La agordo de ĉi tiuj serviloj estis sufiĉe simpla: Nginx en prokura/balancilo. Ne multe da trafiko. Nova enkonduka noto: la nombro de 504 eraroj ĉe klientoj pliiĝas ĉiutage (). La grafikaĵo montras la nombron da 504 eraroj tage por ĉi tiu servo:
Ĉiuj eraroj temas pri la sama backend - pri tiu, kiu estas en la nubo. La memorkonsuma grafiko por pakaj fragmentoj sur ĉi tiu backend aspektis jene:
Ĉi tiu estas unu el la plej evidentaj manifestiĝoj de la problemo en operaciumaj grafikaĵoj. En la nubo, samtempe, alia reto problemo kun QoS (Trafika Kontrolo) agordoj estis riparita. Sur la grafeo de memorkonsumo por pakaĵetaj fragmentoj, ĝi aspektis precize same:
La supozo estis simpla: se ili aspektas same sur la grafikaĵoj, tiam ili havas la saman kialon. Krome, ajnaj problemoj kun ĉi tiu tipo de memoro estas ekstreme maloftaj.
La esenco de la fiksita problemo estis, ke ni uzis la fq-paketplanilon kun defaŭltaj agordoj en QoS. Defaŭlte, por unu konekto, ĝi permesas vin aldoni 100 pakojn al la atendovico, kaj kelkaj ligoj, en situacioj de kanala manko, komencis ŝtopi la atendovicon al kapablo. En ĉi tiu kazo, pakoj estas faligitaj. En tc-statistiko (tc -s qdisc) ĝi povas esti vidita jene:
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
"464545 flows_plimit" estas la pakaĵoj faligitaj pro superado de la vostolimo de unu konekto, kaj "dropped 464545" estas la sumo de ĉiuj faligitaj pakaĵetoj de ĉi tiu planilo. Post pliigo de la vico-longo al 1 mil kaj rekomencado de la ujoj, la problemo ĉesis okazi. Vi povas sidiĝi kaj trinki smoothie.
FragmentSmack/SegmentSmack. Lasta Sango
Unue, kelkajn monatojn post la anonco de vundeblecoj en la kerno, finfine aperis solvo por FragmentSmack (mi memorigu vin, ke kune kun la anonco en aŭgusto, estis publikigita solvo nur por SegmentSmack), kiu donis al ni ŝancon forlasi Workaround, kio kaŭzis al ni sufiĉe multajn problemojn. Dum ĉi tiu tempo, ni jam sukcesis translokigi kelkajn el la serviloj al la nova kerno, kaj nun ni devis komenci de la komenco. Kial ni ĝisdatigis la kernon sen atendi la solvon de FragmentSmack? La fakto estas, ke la procezo de protekto kontraŭ ĉi tiuj vundeblecoj koincidis (kaj kunfandis) kun la procezo de ĝisdatigo de CentOS mem (kiu prenas eĉ pli da tempo ol ĝisdatigi nur la kernon). Krome, SegmentSmack estas pli danĝera vundebleco, kaj riparo por ĝi tuj aperis, do ĝi havis sencon ĉiukaze. Tamen ni ne povis simple ĝisdatigi la kernon en CentOS ĉar la vundebleco FragmentSmack, kiu aperis dum CentOS 7.5, estis nur riparita en versio 7.6, do ni devis ĉesigi la ĝisdatigon al 7.5 kaj rekomenci kun la ĝisdatigo al 7.6. Kaj ĉi tio ankaŭ okazas.
Due, maloftaj plendoj de uzantoj pri problemoj revenis al ni. Nun ni jam certe scias, ke ili ĉiuj rilatas al la alŝuto de dosieroj de klientoj al iuj el niaj serviloj. Krome, tre malgranda nombro da alŝutoj de la tuta amaso trapasis ĉi tiujn servilojn.
Kiel ni memoras de la ĉi-supra rakonto, refunkciigi Sysctl ne helpis. Reboot helpis, sed provizore.
Suspektoj pri Sysctl ne estis forigitaj, sed ĉi-foje necesis kolekti kiel eble plej multe da informoj. Estis ankaŭ grandega manko de kapablo reprodukti la alŝutan problemon ĉe la kliento por studi pli precize kio okazis.
Analizo de ĉiuj disponeblaj statistikoj kaj protokoloj ne proksimigis nin al kompreni kio okazis. Ekzistis akra manko de kapablo reprodukti la problemon por "senti" specifan ligon. Fine, la programistoj, uzante specialan version de la aplikaĵo, sukcesis atingi stabilan reproduktadon de problemoj sur testa aparato kiam li estis konektita per Wi-Fi. Ĉi tio estis sukceso en la enketo. La kliento konektita al Nginx, kiu prokuris al la backend, kiu estis nia Java-aplikaĵo.
La dialogo por problemoj estis tia (fiksita ĉe la prokurilo Nginx):
- Kliento: peto ricevi informojn pri elŝutado de dosiero.
- Java servilo: respondo.
- Kliento: POST kun dosiero.
- Java servilo: eraro.
Samtempe, la Java-servilo skribas al la protokolo, ke 0 bajtoj da datumoj estis ricevitaj de la kliento, kaj la prokurilo Nginx skribas, ke la peto daŭris pli ol 30 sekundojn (30 sekundoj estas la tempodaŭro de la klienta aplikaĵo). Kial la tempo-tempo kaj kial 0 bajtoj? El HTTP-perspektivo, ĉio funkcias kiel ĝi devus, sed la POST kun la dosiero ŝajnas malaperi de la reto. Plie, ĝi malaperas inter la kliento kaj Nginx. Estas tempo armi vin per Tcpdump! Sed unue vi devas kompreni la retan agordon. Nginx-prokurilo estas malantaŭ la L3-balancilo . Tunelado estas uzata por liveri pakaĵetojn de la L3-balancilo al la servilo, kiu aldonas siajn titolojn al la pakaĵetoj:
En ĉi tiu kazo, la reto venas al ĉi tiu servilo en la formo de Vlan-etikedita trafiko, kiu ankaŭ aldonas siajn proprajn kampojn al la pakaĵoj:
Kaj ĉi tiu trafiko ankaŭ povas esti fragmenta (tiu sama malgranda procento de envenanta fragmenta trafiko, pri kiu ni parolis kiam ni taksas la riskojn de Workaround), kiu ankaŭ ŝanĝas la enhavon de la kaplinioj:
Denove: pakaĵetoj estas enkapsuligitaj per Vlan-etikedo, enkapsuligitaj per tunelo, fragmentitaj. Por pli bone kompreni kiel ĉi tio okazas, ni spuru la pakvojon de la kliento al la prokurilo Nginx.
- La pako atingas la L3-balancilon. Por ĝusta vojigo ene de la datencentro, la pakaĵeto estas enkapsuligita en tunelo kaj sendita al la retkarto.
- Ĉar la pakaĵeto + tunelaj kaplinioj ne konvenas en la MTU, la pakaĵeto estas tranĉita en fragmentojn kaj sendita al la reto.
- La ŝaltilo post la L3-balancilo, kiam ili ricevas pakaĵon, aldonas Vlan-etikedon al ĝi kaj sendas ĝin.
- La ŝaltilo antaŭ la prokurilo Nginx vidas (surbaze de la havenaj agordoj) ke la servilo atendas pakaĵeton enkapsuligitan de Vlan, do ĝi sendas ĝin tia, sen forigi la Vlan-etikedon.
- Linukso prenas fragmentojn de individuaj pakaĵoj kaj kunfandas ilin en unu grandan pakaĵon.
- Poste, la pakaĵeto atingas la Vlan-interfacon, kie la unua tavolo estas forigita de ĝi - Vlan-enkapsuligo.
- Linukso tiam sendas ĝin al la Tunnel-interfaco, kie alia tavolo estas forigita de ĝi - Tunnel encapsulation.
La malfacileco estas pasi ĉion ĉi kiel parametrojn al tcpdump.
Ni komencu de la fino: ĉu ekzistas puraj (sen nenecesaj kaplinioj) IP-pakoj de klientoj, kun vlan kaj tunela enkapsuligo forigita?
tcpdump host <ip клиента>
Ne, tiaj pakoj ne estis en la servilo. Do la problemo devas esti tie pli frue. Ĉu ekzistas pakaĵetoj kun nur Vlan-enkapsuligo forigita?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx estas la IP-adreso de la kliento en deksformato.
32:4 — adreso kaj longeco de la kampo en kiu la SCR-IP estas skribita en la Tunnel-pako.
La kampadreso devis esti elektita per krudforto, ĉar en la Interreto oni skribas ĉirkaŭ 40, 44, 50, 54, sed tie ne estis IP-adreso. Vi ankaŭ povas rigardi unu el la pakaĵetoj en hex (la parametro -xx aŭ -XX en tcpdump) kaj kalkuli la IP-adreson, kiun vi konas.
Ĉu estas pakaj fragmentoj sen Vlan kaj Tunnel-enkapsuligo forigitaj?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Ĉi tiu magio montros al ni ĉiujn fragmentojn, inkluzive de la lasta. Verŝajne, la sama afero estas filtrita per IP, sed mi ne provis, ĉar tiaj pakoj ne estas tre multaj, kaj tiuj, kiujn mi bezonis, facile troveblas en la ĝenerala fluo. Ĉi tie ili estas:
14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........
14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
Temas pri du fragmentoj de unu pakaĵo (sama ID 53652) kun foto (la vorto Exif estas videbla en la unua pakaĵo). Pro la fakto, ke ekzistas pakaĵoj ĉe ĉi tiu nivelo, sed ne en la kunfandita formo en la rubejoj, la problemo estas klare kun la asembleo. Finfine estas dokumenta pruvo pri tio!
La pakaĵmalĉifrilo ne malkaŝis iujn ajn problemojn, kiuj malhelpus la konstruon. Provu ĝin ĉi tie: . Komence, kiam vi provas plenigi ion tie, la malĉifrilo ne ŝatas la pakformaton. Montriĝis, ke estis kelkaj kromaj du oktetoj inter Srcmac kaj Ethertype (ne rilataj al fragmentaj informoj). Post forigo de ili, la malĉifrilo ekfunkciis. Tamen ĝi ne montris problemojn.
Kion ajn oni povas diri, nenio alia estis trovita krom tiuj Sysctl. Restis nur trovi manieron identigi problemservilojn por kompreni la skalon kaj decidi pri pliaj agoj. La postulata nombrilo estis trovita sufiĉe rapide:
netstat -s | grep "packet reassembles failed”
Ĝi ankaŭ estas en snmpd sub OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"La nombro da misfunkciadoj detektitaj de la IP-rekunigo-algoritmo (pro kia ajn kialo: elĉerpita, eraroj, ktp.)."
Inter la grupo de serviloj, sur kiuj la problemo estis studita, sur du ĉi tiu nombrilo plirapidiĝis, sur du pli malrapide, kaj sur du pliaj ĝi tute ne pliiĝis. Komparante la dinamikon de ĉi tiu nombrilo kun la dinamiko de HTTP-eraroj sur la Java-servilo malkaŝis korelacion. Tio estas, la mezurilo povus esti monitorita.
Havi fidindan indikilon de problemoj estas tre grava por ke vi povu precize determini ĉu refunkciigi Sysctl helpas, ĉar de la antaŭa rakonto ni scias, ke tio ne povas esti tuj komprenita de la aplikaĵo. Ĉi tiu indikilo permesus al ni identigi ĉiujn problemajn areojn en produktado antaŭ ol uzantoj malkovros ĝin.
Post refunkciigo de Sysctl, la monitoraj eraroj ĉesis, tiel la kaŭzo de la problemoj estis pruvita, same kiel la fakto, ke la malfunkciigo helpas.
Ni forigis la fragmentajn agordojn en aliaj serviloj, kie nova monitorado ekludis, kaj ie ni asignis eĉ pli da memoro por fragmentoj ol antaŭe estis la defaŭlta (ĉi tio estis UDP-statistiko, kies parta perdo ne estis videbla sur la ĝenerala fono) .
La plej gravaj demandoj
Kial pakoj estas fragmentigitaj sur nia L3-balancilo? La plej multaj el la pakoj kiuj alvenas de uzantoj al ekvilibristoj estas SYN kaj ACK. La grandecoj de ĉi tiuj pakoj estas malgrandaj. Sed ĉar la parto de tiaj pakoj estas tre granda, kontraŭ ilia fono ni ne rimarkis la ĉeeston de grandaj pakoj, kiuj komencis fragmentiĝi.
La kialo estis rompita agorda skripto sur serviloj kun Vlan-interfacoj (estis tre malmultaj serviloj kun etikedita trafiko en produktado tiutempe). Advmss permesas al ni transdoni al la kliento la informon, ke pakaĵetoj en nia direkto devus esti pli malgrandaj en grandeco, por ke post alfiksado de tunelaj kaplinioj al ili ili ne devas esti fragmentigitaj.
Kial Sysctl-malfunkciigo ne helpis, sed rekomenco faris? Refari Sysctl ŝanĝis la kvanton de disponebla memoro por kunfandi pakaĵojn. Samtempe, ŝajne la fakto mem de memoro superfluo por fragmentoj kondukis al malrapidiĝo de konektoj, kio kondukis al fragmentoj prokrastitaj dum longa tempo en la atendovico. Tio estas, la procezo iris en cikloj.
La rekomenco malplenigis la memoron kaj ĉio revenis al ordo.
Ĉu eblis fari sen Workaround? Jes, sed estas alta risko lasi uzantojn sen servo okaze de atako. Kompreneble, la uzo de Workaround rezultigis diversajn problemojn, inkluzive de malrapidigo de unu el la servoj por uzantoj, sed tamen ni kredas, ke la agoj estis pravigitaj.
Koran dankon al Andrey Timofeev () por asistado en farado de la enketo, same kiel Alexey Krenev () - por la titana laboro de ĝisdatigo de Centoj kaj kernoj sur serviloj. Procezo, kiu ĉi-kaze devis esti komencita de la komenco plurfoje, tial ĝi daŭris multajn monatojn.
fonto: www.habr.com