50 parimat Nginxi intervjuu küsimust ja vastust (2026)

Autor: Bryce Leo Bryce Leo
Hours Ajakohastatud

Nginxi intervjuu parimad küsimused ja vastused

Nginxi intervjuuks ettevalmistumine nõuab ettenägelikkust, selgust ja teadlikkust sellest, kuidas intervjueerijad tänapäeval tegelikke operatiivseid teadmisi hindavad. Nginxi intervjuuküsimused näitavad sügavust, otsustusvõimet, tõrkeotsingu võimet ja tootmisvalmidust.

Need rollid avavad teid pilveinfrastruktuuri, jõudluse inseneritöö ja turvalisuse valdkonnas, kus praktilised konfiguratsioonid on olulised. Tööandjad hindavad tehnilist kogemust, valdkonnaalaseid teadmisi ja valdkonnas töötamise käigus omandatud analüüsivõimet, aidates algajatel, keskastme inseneridel ja vanemspetsialistidel rakendada meeskondades nii põhi- kui ka edasijõudnutele mõeldud oskusi juhtide ja meeskonnajuhtide juhendamisel. Loe rohkem…

👉 Tasuta PDF-i allalaadimine: Nginxi intervjuuküsimused ja vastused

Nginxi intervjuu parimad küsimused ja vastused

1) Selgitage, mis on NGINX ja miks seda veebitaristus laialdaselt kasutatakse.

NGINX on suure jõudlusega avatud lähtekoodiga veebiserver, mis toimib ka pöördproksi, koormuse tasakaalustaja ja HTTP-vahemäluna. See toetab HTTP, HTTPS, SMTP, POP3 ja IMAP protokolle. Arhitektuur kasutab event-driven, asynchronous model mis võimaldab tal hallata kümneid tuhandeid samaaegseid ühendusi vähese mälu ja protsessori kasutusega. See skaleeritavus muudab NGINX-i eriti sobivaks suure liiklusega veebirakenduste, mikroteenuste ja hajutatud arhitektuuride jaoks. Näiteks eelistavad ettevõtted, millel on suur liikluskoormus (nt sisuplatvormid või API-lüüsid), sageli NGINX-i samaaegsete ühenduste ja staatilise sisu tõhusaks haldamiseks.

2) Kuidas NGINX HTTP-päringuid sisemiselt käsitleb (sündmuspõhine arhitektuur)?

NGINX-i peamine tugevus seisneb selles event-driven, non-blocking architectureSelle asemel, et iga päringu jaoks eraldi lõime või protsessi käivitada (nagu traditsiooniliste serverite puhul), kasutab NGINX väikest hulka töötajaprotsesse, mis kasutavad asünkroonseid sündmuste tsükleid. Iga töötaja saab hallata tuhandeid ühendusi, oodates operatsioonisüsteemi valmisoleku teateid ja töödeldes sündmusi nende toimumise ajal. Kuna see ei blokeeri sisend-/väljundoperatsioone, saab NGINX minimaalsete ressurssidega pakkuda staatilisi ja puhverserveripõhiseid sisusid. See mudel sobib ideaalselt suure samaaegsuse korral, muutes selle suure koormuse korral tõhusamaks kui protsessipõhised serverid.

3) Millised on NGINX-i ja Apache'i peamised erinevused?

Kuigi nii NGINX kui ka Apache on populaarsed veebiserverid, erinevad nad arhitektuuri, jõudluse ja disainieesmärkide poolest:

Aspekt nginx Apache
Samaaegsusmudel Sündmuspõhine (asünkroonne, mitteblokeeriv) Protsessi-/lõimepõhine (blokeerimine)
Memory Usage Madal ühenduse kohta Kõrgem ühenduse kohta
Parim kasutuskohver Suur liiklus, staatiline sisu, koormuse tasakaalustamine Dünaamiline sisu ja rikkalik moodulite ökosüsteem
Skaalautuvus Skaala vähemate ressurssidega Nõuab protsesside tõttu rohkem riistvara
Moodulite käsitsemine Kompileerimise ajal valitud moodulid Dünaamiline käitusajal

NGINX-i disain optimeerib jõudlust koormuse all, samas kui Apache pakub suuremat paindlikkust dünaamiliste moodulite ja laia keeletoe abil.

4) Millised on NGINX-i konfiguratsioonifaili põhikomponendid?

NGINX-i konfiguratsioonifail (vaikimisi tee: /etc/nginx/nginx.conf) koosneb struktureeritud direktiiviplokkidest, mis määravad NGINX-i käitumise:

  • Peamine kontekst: globaalsed seaded, näiteks worker_processes, error_logja pid
  • Sündmuste blokk: haldab töötajate ühendusi ja mitmeprotsessorilist töötlemist
  • HTTP-blokk: sisaldab HTTP käitlemise konfiguratsioone (tihendamine, vahemällu salvestamine, gzip jne)
    • Serveri blokk: defineerib virtuaalsed hostid (domeenid ja pordid)
    • Asukohaplokk: määratleb marsruutimisreeglid ja kuidas konkreetseid URI-sid käsitletakse

Need plokid töötavad koos päringute marsruutimiseks, puhverserveri sätete määratlemiseks ning SSL/TLS-i ja vahemällu salvestamise konfigureerimiseks.

5) Kuidas NGINX-i konfiguratsiooni ohutult ja seisakuid vältides uuesti laadida?

NGINX-i uuesti laadimiseks värskendatud konfiguratsioonidega without interrupting active connections, kasutate järgmist käsku:

nginx -s reload

või süsteemides, mis kasutavad systemd:

sudo systemctl reload nginx

See käsk annab põhiprotsessile märku konfiguratsioonifailide uuesti lugemiseks ja töötajate sujuvaks taaskäivitamiseks ilma olemasolevaid ühendusi katkestamata. Selliste sujuvate taaskäivituste tegemise oskus on oluline keskkondades, mis nõuavad suurt kättesaadavust.

6) Kirjeldage, kuidas seadistada NGINX pöördproksiks.

Pöördproksi edastab kliendi päringud taustserveritele (ülesvoolu grupp) ja tagastab seejärel vastuse. Allpool on tüüpiline NGINX-i pöördproksi plokk:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
        }
    }
}

See seadistus parandab turvalisust, tagab koormuse jaotamise ning võimaldab klientide ja rakendusserverite vahel vahemällu salvestamise või kiiruse piiramise poliitikaid.

7) Selgitage NGINX Master ja Worker protsesse.

NGINX-is:

  • . Põhiprotsess haldab konfiguratsiooni, käivitab tööprotsesse ja tegeleb privilegeeritud toimingutega, näiteks portidega sidumisega.
  • Tööprotsessid tegeleb tegeliku päringute käsitlemisega – sissetulevate ühenduste töötlemise ja konfigureeritud reeglite täitmisega.

Mitme töötaja kasutamine parandab samaaegsust ja neid saab häälestada vastavalt saadaolevatele protsessori tuumadele ja liiklusnõuetele. Rollide jagamine parandab jõudlust ja stabiilsust.

SEOTUD ARTIKLID

8) Kuidas saab NGINX-is piirata määratlemata serverinimede töötlemist?

Kehtiva koodita päringute tühistamiseks Host päis NGINX-is:

server {
    listen 80;
    server_name "";
    return 444;
}

See konfiguratsioon tagastab koodi 444, mittestandardne NGINX-i olek, mis sulgeb ühenduse ilma vastuseta, lükates sisuliselt tagasi määratlemata hostid ja parandades turvalisust.

9) Milleks kasutatakse ngx_http_upstream_module'i?

. ngx_http_upstream_module määratleb groups of backend servers (ülesvoolud), millele NGINX saab päringuid edastada, kasutades selliseid direktiive nagu proxy_pass, fastcgi_passvõi uwsgi_passSee võimaldab rakenduste skaleerimist koormusega tasakaalustatud keskkondades. Kui mitu serverit on rühmitatud, saab NGINX liiklust jaotada määratletud poliitikate alusel, toetades ringjaotust ja muid strateegiaid.

10) Kirjeldage, kuidas NGINX-i kasutatakse staatilise ja dünaamilise sisu edastamiseks.

NGINX on teenindamisel väga tõhus staatilised failid (HTML, CSS, pildid) otse optimeeritud sündmuste tsükli ja faili sisend-/väljundmehhanismide abil. dünaamiline sisu, NGINX edastab päringud taustprotsessoritele, näiteks PHP-FPM-ile, Python WSGI serverid või rakendusraamistikud FastCGI/puhverserveri mehhanismide kaudu. See eraldamine võimaldab NGINX-il toimida staatilise failiserverina, kasutades samal ajal taustteenuseid dünaamiliseks genereerimiseks, tagades optimaalse jõudluse ja skaleeritavuse.

11) Kuidas koormuse tasakaalustamine NGINX-is töötab ja millised on selleks saadaolevad meetodid?

NGINX pakub töökindlat koormuse tasakaalustamine läbi upstream direktiiv, mis jaotab liikluse mitme serveri vahel, et optimeerida jõudlust ja tagada kõrge käideolek. See toetab mitut meetodit:

Meetod Kirjeldus Parim kasutuskohver
Round Robini Vaikimisi meetod, mis vahetab päringuid serverite vahel järjestikku. Ühtlaselt jaotatud töökoormused.
Vähem ühendused Saadab päringud serverile, millel on kõige vähem aktiivseid ühendusi. Pikad seansid.
IP-räsi Kasutab serveri valiku määramiseks kliendi IP-aadressi. Seansi püsivus.
Vähim aeg Saldo põhineb reageerimisajal ja ühenduste arvul. Latentsusaja suhtes tundlikud rakendused.

NGINX saab ka täita tervisekontrolli ebatervislike serverite dünaamiliseks eemaldamiseks, tagades sujuva liiklusvoo ja vastupidavuse.

12) Mis vahe on NGINX avatud lähtekoodiga ja NGINX Plus'il?

nginx Open Source on kogukonnaversioon, mis pakub olulisi veebiserveri, puhverserveri ja koormuse tasakaalustamise võimalusi. NGINX Plus on kommertsväljaanne, mis laiendab neid funktsioone ettevõttetasemel täiustustega, nagu täiustatud jälgimine, seansi püsivus, dünaamiline ümberkonfigureerimine ja aktiivsed tervisekontrollid.

tunnusjoon NGINX avatud lähtekoodiga NGINX Plus
Koormuse tasakaalustamine Põhiline (ringtestimine, IP-räsi) Täpsem (kõige lühem aeg, dünaamiline ümberkonfigureerimine)
Järelevalve Manuaalsed/välised tööriistad Sisseehitatud armatuurlaud ja API
Vahemällu salvestamine Põhi- Täiustatud puhastuskontrolliga
Kasutajatugi ainult kogukond Ettevõtte tugi ja värskendused

Kriitilise töökoormusega organisatsioonid valivad sageli NGINX Plusi selle parema töökindluse ja jälgitavuse tõttu.

13) Kuidas NGINX-is vahemällu salvestamist rakendada?

NGINX-i vahemällu salvestamine parandab reageerimiskiirust ja vähendab taustsüsteemi koormust, salvestades sageli kasutatavat sisu lokaalselt. See on lubatud, kasutades proxy_cache direktiiv. Näidiskonfiguratsioon:

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g;
server {
    location / {
        proxy_cache my_cache;
        proxy_pass http://backend;
    }
}

Vahemällu salvestatud vastused edastatakse otse kettalt, kui saabub sobiv päring, jättes vahele ülesvoolu töötlemise. Vahemälu aegumist saate kontrollida järgmiselt: proxy_cache_valid ja välistage konkreetsed URI-d koos proxy_no_cacheSee mehhanism on ülioluline suure liiklusega keskkondades, näiteks uudiste- või e-kaubanduse saitidel.

14) Selgitage direktiivi „try_files” eesmärki ja kasutamist.

. try_files direktiiv kontrollib enne päringu edastamist varuasukohta failide olemasolu kindlaksmääratud järjekorras. Seda kasutatakse tavaliselt staatiline saidi marsruutimine or üheleheküljelised taotlused (SPA-d).

Näide:

location / {
    try_files $uri $uri/ /index.html;
}

Siin kontrollib NGINX kõigepealt, kas taotletud URI vastab failile, seejärel kataloogile ja lõpuks suunab sobimatud päringud aadressile /index.htmlSee parandab tõhusust ja kasutajakogemust, pakkudes vahemällu salvestatud või staatilisi faile otse, vältides tarbetuid taustakõnesid.

15) Kuidas saab NGINX hakkama HTTPS-i ja SSL/TLS-i lõpetamisega?

NGINX toimib SSL/TLS-i lõpetamise puhverserverina, käsitledes krüpteerimist ja dekrüpteerimist serverikihis enne krüpteerimata päringute edastamist ülesvoolu teenustele. Näidiskonfiguratsioon:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;
    location / {
        proxy_pass http://backend;
    }
}

Ta toetab HTTP / 2, OCSP klammerdamine, HSTSja kaasaegsed šifrikomplektid, võimaldades turvalist ja suure jõudlusega sidet. SSL-i lõpetamine NGINX-is vähendab krüpteerimiskoormust taustserverites ja lihtsustab sertifikaatide haldamist.

16) Mis vahe on NGINX-is ümberkirjutamisel ja ümbersuunamisel?

Mõlemad ümber kirjutama ja suunata muuta päringute marsruutimist, kuid need erinevad põhimõtteliselt:

Aspekt Ümber kirjutama Ümbersuunamine
KASUTUSALA Sisemine URL-i ümberkirjutamine Välise kliendi ümbersuunamine
Vastuse kood 200 (sisemine) 301/302 (HTTP ümbersuunamine)
Nähtavus Kasutaja jaoks läbipaistev Klient näeb uut URL-i
Kasuta Case'it SEO-sõbralikud URL-id, marsruutimine Domeeni migreerimine, HTTPS-i jõustamine

Näide:

rewrite ^/oldpage$ /newpage permanent;  # Redirect
rewrite ^/img/(.*)$ /assets/$1 break;   # Rewrite

Selle eristuse mõistmine on SEO ja marsruutimisloogika tõhusaks optimeerimiseks võtmetähtsusega.

17) Kuidas kaitsta NGINX-i levinud haavatavuste eest?

Turvalisuse tugevdamine hõlmab parimate tavade kombinatsiooni:

  • Serveri tunnuste keelamine: server_tokens off;
  • Piiratud päringumeetodid: Lubatud on ainult GET, POST ja HEAD.
  • Puhvri ületäitumise piiramine: Seadistamine client_max_body_size ja client_body_buffer_size.
  • Kasutage HTTPS-i koos kaasaegsete šifritega.
  • Luba kiirusepiirang kaudu limit_req_zone.
  • Peida versiooniteave ja keela kataloogide loetlemine.

Lisaks kasutades a Veebirakenduste tulemüür (WAF) nagu ModSecurity with NGINX suudab filtreerida pahatahtlikku liiklust. NGINX-i regulaarne värskendamine ja turvapaikade paigaldamine on nullpäevarünnakute vältimiseks hädavajalik.

18) Mis on NGINX muutujad ja kuidas neid konfiguratsioonides kasutatakse?

NGINX-i muutujad salvestavad dünaamilisi andmeid, mida kasutatakse konfiguratsioonides ja logide töötlemisel. Need võivad esindada päringute päiseid, klientide IP-sid või arvutatud väärtusi. Näited hõlmavad järgmist $remote_addr, $host, $uri, $request_methodja $upstream_addr.

Näiteks:

log_format custom '$remote_addr - $host - $uri';

Muutujad lisavad paindlikkust, võimaldades tingimuslikku marsruutimist ja kohandatud logimist. Samuti saate kohandatud muutujaid määratleda, kasutades set direktiiv, mis aitab kaasa modulaarse konfiguratsiooni kujundamisele.

19) Kuidas saab NGINX-is kiirusepiirangut seadistada?

Kiiruse piiramine kontrollib, kui sageli kasutajad saavad päringuid saata, kaitstes jõuvõtete ja DDoS-rünnakute eest. See on konfigureeritud, kasutades limit_req_zone direktiiv:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
server {
    location / {
        limit_req zone=mylimit burst=5;
    }
}

See lubab ühe päringu sekundis, viie päringupurskega. NGINX loobub liigsetest päringutest või lükkab neid edasi vastavalt konfiguratsioonile. Kiiruse piiramine tagab õiglase ressursikasutuse ja hoiab ära serveri ülekoormuse.

20) Millised on NGINX-i kasutamise eelised ja puudused pöördproksina?

NGINX-il kui pöördproksil on arvukalt eeliseid, aga ka mõningaid kompromisse:

Eelised Puudused
Suur jõudlus ja samaaegsuse käsitlemine Nõuab suuremahuliste juurutuste jaoks käsitsi häälestamist
SSL-i lõpetamine ja tsentraliseeritud turvalisus Piiratud dünaamiliste moodulite tugi (kompileerimise ajal)
Koormuse tasakaalustamine ja vahemällu salvestamise tugi Uutele kasutajatele mõeldud keerukas konfiguratsioon
Rakenduskihi filtreerimine Natiivse dünaamilise sisu teostamise puudumine

Selle eelised kaaluvad enamikus ettevõtte stsenaariumides üles piirangud, muutes NGINX-i tänapäevase veebiinfrastruktuuri asendamatuks komponendiks.

21) Kuidas saate jälgida NGINX-i jõudlust ja tervist tootmises?

NGINX-i jälgimine on ülioluline kitsaskohtade, tõrgete ja ebanormaalse liikluskäitumise tuvastamiseks. Kasutada saab mitut lähenemisviisi:

  1. Sisseehitatud olekumoodul (stub_status):

    Kuvab aktiivseid ühendusi, käsitletud päringuid ja lugemis-/kirjutamisolekuid. Näide:

    location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
  2. NGINX Plus armatuurlaud: Pakub reaalajas mõõdikuid REST API ja GUI kaudu.
  3. Kolmandate osapoolte integratsioonid: Tööriistad nagu Prometheus, Grafana, Datadog või ELK saavad koguda mõõdikuid ja logisid.
  4. Juurdepääsu ja vealogid: Regulaarne logide rotatsioon ja analüüs selliste tööriistadega nagu GoAccess või AWStats parandavad jälgitavust.

Jälgimine aitab tagada tööaja, rikete kiire avastamise ja võimsuse planeerimise.

22) Mis vahe on proxy_pass ja fastcgi_pass direktiividel?

Mõlemad direktiivid edastavad päringud taustteenustele, kuid on loodud erinevate protokollide jaoks:

Direktiivi Eesmärk Tagaserveri protokoll Kasutamise näide
proxy_pass Edastab HTTP- või HTTPS-päringud taustserveritele HTTP Revmuud veebi-API-de või mikroteenuste puhverserverid
fastcgi_pass Saadab päringud FastCGI protsessorile FastCGI PHP-FPM, Python FastCGI rakendused

Näide:

location /api/ {
    proxy_pass http://backend;
}
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}

Kokkuvõttes kasutage puhverserveri_pääs üldiste HTTP-taustaprogrammide jaoks ja fastcgi_pass dünaamiliste keelekeskkondade, näiteks PHP, jaoks.

23) Kuidas saab NGINX-is gzip-tihendust seadistada ja millised on selle eelised?

Gzip-tihenduse lubamine NGINX-is vähendab ribalaiuse kasutamist ja parandab laadimisaega, tihendades tekstipõhiseid vastuseid enne klientidele saatmist.

Konfiguratsiooni näide:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 6;
gzip_vary on;

Eelised:

  • Vähendab failiedastusmahtu kuni 70%.
  • Parandab esimese baidi lugemise aega (TTFB) ja lehe jõudlusskoori.
  • Säästab ribalaiuse kulusid, mis on eriti kasulik mobiilikasutajatele.

Siiski ei tohiks seda rakendada juba tihendatud failidele (nt .zip, .jpg, .png), et vältida protsessori üldkulu.

24) Millised on NGINX-i häälestamise parimad tavad suure liikluse jaoks?

Suure liiklusega optimeerimine hõlmab ressursside ja konfiguratsiooniparameetrite hoolikat häälestamist:

Piirkond Direktiivi Soovitatav praktika
Töötajad worker_processes auto; Protsessori tuumade sobitamine
Side worker_connections 4096; Suurenda samaaegsust
Elus hoidma keepalive_timeout 65; Optimeeri kliendi taaskasutamist
Fail Descriptors OS ulimit -n Avatud soklite piirangute tõstmine
Vahemällu salvestamine proxy_cache_path Vähenda taustasüsteemi koormust
Gzip gzip on; Tekstivastuste tihendamine

Lisaks kasutades asünkroonse ketta sisend/väljund, koormuse tasakaalustamineja ülesvoolu tervisekontrollid tagab stabiilsuse ja kiiruse massiliste samaaegsete päringute korral.

25) Kuidas NGINX WebSocket-ühendusi haldab?

WebSocketid võimaldavad kliendi ja serveri vahel kahesuunalist suhtlust – see on reaalajas rakenduste jaoks ülioluline. NGINX toetab seda natiivselt korraliku päise edastamise kaudu.

Konfiguratsiooni näide:

location /ws/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Võtmepunktid:

  • . Upgrade ja Connection päised on kohustuslikud.
  • Veenduge, et NGINX kasutaks püsivate TCP-ühenduste jaoks HTTP/1.1 protokolli.
  • Koormuse tasakaalustamiseks mõeldud WebSocketid võivad vajada kleepuvaid seansse, kasutades ip_hash.

See konfiguratsioon toetab selliseid rakendusi nagu vestlus, aktsiatega kauplemine või mängimine.

26) Mis on direktiivi „worker_rlimit_nofile” eesmärk?

worker_rlimit_nofile määrab tööprotsessidele saadaolevate avatud failikirjeldajate maksimaalse arvu. See piirang mõjutab otseselt seda, kui palju samaaegseid ühendusi NGINX suudab käsitleda. Näide:

worker_rlimit_nofile 100000;

Selle piirangu tõstmine on ülioluline suure samaaegsusega süsteemide (nt API-lüüside või voogedastusplatvormide) jaoks. Siiski on operatsioonisüsteemi piirang (ulimit -n) tuleb järjepidevuse tagamiseks selle väärtusega vastavusse viia.

27) Kuidas saab NGINX-i kasutada URL-ide ümberkirjutamiseks või automaatseks HTTPS-ile suunamiseks?

HTTP ümbersuunamine HTTPS-ile tagab turvalise suhtluse. Näide:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

See konfiguratsioon annab välja 301 püsiv ümbersuunamine HTTP-lt HTTPS-ile. Täpsema kontrolli tagamiseks võivad ümberkirjutamisreeglid jõustada teekonnapõhise ümbersuunamise:

rewrite ^/oldpath$ /newpath permanent;

Automaatne HTTPS-i jõustamine parandab SEO edetabelit, hoiab ära vahemehe rünnakud ja säilitab ühtlase kasutuskogemuse.

28) Millised on NGINX-i vigade „502 Bad Gateway” levinumad põhjused?

„502 Vigane lüüs” näitab, et puhverserverina toimiv NGINX ei saanud ülesvoolu serverilt kehtivat vastust. Levinud põhjused on järgmised:

  • Tagaserveri krahh või kättesaamatus.
  • Vale proxy_pass URL või sokli tee.
  • Ülesvoolu ajalõpp (proxy_read_timeout liiga madal).
  • Tulemüür või SELinux blokeerib ülesvoolu ühendusi.
  • Valesti konfigureeritud FastCGI parameetrid (PHP jaoks).

Silumiseks kontrollige vealogisid (/var/log/nginx/error.log), kontrollige ülesvoolu kättesaadavust ja testige taustapõhiste vastuste otse curl.

29) Kuidas toetab NGINX mikroteenuseid ja konteinerpõhiseid arhitektuure (nt Docker, Kubernetes)?

NGINX sobib ideaalselt mikroteenuste keskkonnad tänu oma kergele disainile ja pöördproksi funktsionaalsusele. Dockeris või Kuberneteses toimib see järgmiselt:

  • Sissetuleva kontrolleri: Haldab välist HTTP/S liiklust sisemistele teenustele.
  • Teenuse värav: Teostab marsruutimist, koormuse tasakaalustamist ja autentimist.
  • Külgkorvi puhverserver: Suurendab teenusvõrkude (nt Istio) vastupidavust ja jälgitavust.

NGINX-i konfiguratsioone saab Kubernetes ConfigMapsi kaudu dünaamiliselt värskendada, mis võimaldab tsentraliseeritud liikluse juhtimist ja SSL-i haldamist. Selle modulaarne lähenemine sobib ideaalselt konteinerdatud ja pilvepõhiste juurutustega.

30) Millised on erinevad viisid NGINX-i turvalisuse parandamiseks tootmissüsteemides?

NGINX-i turvalisuse täiustamine nõuab mitmekihilist konfiguratsiooni:

  1. SSL/TLS-i tugevdamine: Kasutage tänapäevaseid šifreid, keelake SSLv3/TLSv1.0.
  2. Piira HTTP-meetodeid: Luba ainult turvaverbe (GET, POST, HEAD).
  3. Turvapäised: 
    add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
  4. Peida versiooniinfo: server_tokens off;
  5. Luba kiiruse piiramine ja juurdepääsu kontroll.
  6. WAF-i või Fail2Ban-i integreerimine toore jõu ennetamiseks.

Kokkuvõttes loovad need meetmed tugevdatud, tootmiskvaliteediga NGINX-i keskkonna, mis on vastupidav levinud ohtudele.

31) Kuidas saab NGINX-i probleeme tõhusalt siluda?

NGINX-i silumine hõlmab logide, konfiguratsioonifailide ja protsesside olekute süstemaatilist analüüsimist. Peamised sammud on järgmised:

  1. Kontrolli süntaksit:
    2. nginx -t
  2. Kinnitab konfiguratsiooni enne uuesti laadimist.

    3. Luba silumislogimine:

    error_log /var/log/nginx/error.log debug;
  3. Pakub üksikasjalikku käitusaja diagnostikat.

    4. Juurdepääsulogide analüüsimine: Tuvastage vastusekoode ja päringumustreid, kasutades:

    tail -f /var/log/nginx/access.log
  4. Testi ühenduvust: Kasutama curl -v or wget taustasüsteemi ligipääsetavuse kontrollimiseks.
  5. Aktiivsete ühenduste jälgimine: kaudu stub_status or netstat.

NGINX-i töötajate protsesside, puhverpiiride ja ülesvoolu vastuste mõistmine aitab tootmissüsteemides kitsaskohti kiiresti tuvastada.

32) Kuidas NGINX-i logimist konfigureerida ja millised on kohandatud logivormingud?

NGINX pakub paindlikke logimismehhanisme läbi access_log ja error_log direktiivid.

Konfiguratsiooni näide:

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$request_time"';

access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log warn;

Saate defineerida kohandatud vormingud et lisada selliseid mõõdikuid nagu $upstream_addr, $request_timevõi $bytes_sent.

Täiustatud jälgitavuse tagamiseks saadetakse logid sageli aadressile ELK, Loki või Splunk reaalajas analüüsi ja armatuurlaua jaoks.

33) Milline on proxy_buffering direktiivi roll NGINX-is?

proxy_buffering kontrollib, kas NGINX puhverdab vastuseid ülesvoolu serveritelt enne nende klientidele saatmist.

Kehtestamine Kirjeldus Kasuta Case'it
proxy_buffering on; Buffers kogu reageering optimeeritud läbilaskevõime saavutamiseks Vaikimisi; parandab jõudlust
proxy_buffering off; Edastab andmeid otse klientidele ilma puhverdamiseta Reaalajas voogedastus või API-d

Näiteks puhverdamise keelamiseks:

location /stream/ {
    proxy_buffering off;
}

Puhverdamise keelamine on ideaalne vestlus- või voogedastusteenuste jaoks, kuid tavalise veebiliikluse läbilaskevõimet võib vähendada.

34) Selgitage, kuidas NGINX-i vahemälu saab kehtetuks muuta või tühjendada.

NGINX avatud lähtekoodiga tarkvaral ei ole sisseehitatud vahemälu puhastamist, kuid seda saab saavutada mitmel viisil:

  1. Käsitsi puhastamine: Eemalda failid vahemälu kataloogist. 
    rm -rf /var/cache/nginx/*
  2. Kolmanda osapoole moodul: Kasutama ngx_cache_purge HTTP-päringu kaudu puhastamiseks: 
    location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
  3. NGINX Plus funktsioon: Võimaldab API-põhist vahemälu dünaamiliselt puhastada.

Eemaldamine tagab aegunud sisu kiire asendamise, säilitades sisu värskuse ja järjepidevuse CDN-is või mitmesõlmelistes juurutustes.

35) Kuidas NGINX ühenduse ajalõpudega toime tuleb?

NGINX pakub kliendi või ülesvoolu vastuste ootamise aja kontrollimiseks mitut ajalõpu direktiivi:

Direktiivi Eesmärk Vaikimisi
client_body_timeout Kliendi keha ooteaeg 60
client_header_timeout Kliendi päise ooteaeg 60
keepalive_timeout Jõudeolekus olevad ühendused elus 75
send_timeout Andmete kliendile saatmise aeg 60
proxy_read_timeout Ülesvoolu vastuse ooteaeg 60

Nõuetekohane häälestamine väldib tarbetuid ühenduse katkestusi ja tagab sujuvama kasutuskogemuse muutuvate võrgutingimuste korral.

36) Kuidas rakendada sinirohelist juurutamist NGINX-i abil?

Aastal sini-roheline kasutuselevõtt, kaks keskkonda (sinine = aktiivne, roheline = ooterežiim) töötavad samaaegselt. NGINX toimib nende vahel liikluse ruuterina.

Konfiguratsiooni näide:

upstream app_cluster {
    server blue.example.com;
    #server green.example.com; # Uncomment during switch
}
server {
    location / {
        proxy_pass http://app_cluster;
    }
}

Kui uus versioon (roheline) on testitud ja kinnitatud, lülitatakse liiklus ümber ülesvoolu definitsiooni värskendamise ja NGINX-i uuesti laadimisega (nginx -s reload).

See meetod tagab null seisakuid rakenduste värskendamise või tagasipööramise ajal.

37) Mis on kiirust piirav purske ja kuidas see parandab NGINX-i jõudlust?

. lõhkemist Kiiruse piiramise parameeter lubab lühikestel liiklushoogudel ajutiselt läbi minna ilma kohese tagasilükkamiseta.

Näide:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
location /api/ {
    limit_req zone=mylimit burst=5 nodelay;
}

Siin võetakse enne piiramise rakendamist koheselt vastu viis lisapäringut.

See tehnika sujutab liikluse järsku suurenemist, säilitades järjepideva kasutajakogemuse ilma taustsüsteeme üle koormamata.

38) Kuidas NGINX IPv6 ja kahekihiliste keskkondadega toime tuleb?

NGINX toetab täielikult IPv6-d nii serveri kui ka ülesvoolu konfiguratsioonides. Näide:

server {
    listen [::]:80 ipv6only=on;
    server_name example.com;
}

Kahekihilise protokolli (IPv4 + IPv6) tugi saavutatakse mõlema kaasamisega:

listen 80;
listen [::]:80;

IPv6-ühilduvus tagab laiema ligipääsetavuse, eriti mobiilsete ja rahvusvaheliste klientide jaoks, ning on kriitilise tähtsusega tänapäevaste internetistandardite järgimiseks.

39) Kuidas NGINX-i koormuse tasakaalustamises kleepuvaid seansse konfigureerida?

Kleepuvad seansid tagavad, et sama kliendi päringud suunatakse alati samale taustserverile.

  1. Kasutamine ip_hash: 
    upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
  2. NGINX Plus kleepuv küpsis:
    Täiustatud seansi püsivus konfigureeritavate küpsistega.

Kleepuvad seansid on üliolulised olekupõhiste rakenduste (nt kasutajate armatuurlauad või ostukorvid) jaoks, tagades seansiandmete järjepidevuse ilma jagatud salvestusruumita.

40) Millised on NGINX-i peamised logimistasemed ja mille poolest need erinevad?

NGINX toetab vealogi üksikasjalikkuse kontrollimiseks hierarhilisi logitasemeid.

Tase Kirjeldus
debug Üksikasjalik teave tõrkeotsingu kohta (väga pikalt)
info Üldine käitusaja teave
notice Olulised, kuid mitte kriitilised sündmused
warn Võimalikud probleemid või valekonfiguratsioonid
error Operatähelepanu vajavad funktsionaalsed vead
crit, alert, emerg Kriitilised tõrked ja süsteemihoiatused

Konfiguratsiooni näide:

error_log /var/log/nginx/error.log warn;

Logitasemete kohandamine vastavalt keskkonnale (silumine testimiskeskkonnas, hoiatus tootmiskeskkonnas) aitab säilitada tasakaalu nähtavuse ja jõudluse vahel.

41) Kuidas NGINX-i jõudlust võrreldakse?

NGINX-i võrdlusanalüüs hõlmab läbilaskevõime, latentsuse ja samaaegsuse mõõtmist konfiguratsiooni kitsaskohtade tuvastamiseks. Levinud tööriistad on järgmised:

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/
  • Testid nõuavad mahtu ja samaaegsust.
  • töö: Pakub üksikasjalikke latentsusaja protsentiile ja päringute määrasid.
  • piiramisrõngas / httperf: Simuleerib reaalse maailma liikluskoormust.
  • Grafana + Prometheus: Jälgib reaalajas esituse näitajaid.

Võrdlusanalüüs peaks mõõtma selliseid parameetreid nagu requests per second (RPS), time per requestja error rate.

Häälestusmuutujad nagu worker_processes, worker_connectionsja keepalive_timeout parandab märkimisväärselt vaadeldavat läbilaskevõimet.

42) Kuidas saab NGINX integreeruda CI/CD torujuhtmetega?

NGINX integreerub sujuvalt CI / CD automatiseeritud juurutamiseks, testimiseks ja konfiguratsiooni haldamiseks. Levinud lähenemisviisid hõlmavad järgmist:

  • Infrastruktuur koodina (IaC): Hallake konfiguratsioone Ansible'i, Terraformi või Helmi diagrammidega.
  • Dockeri konteinerid: Loo ja juuruta NGINX-kujutisi CI-tööriistade abil (Jenkins, GitLab CI või GitHub Actions).
  • Automatiseeritud testimine: Konfiguratsioonide valideerimine, kasutades nginx -t torujuhtme etappides.
  • Sinine-roheline / Canary Juurutamise automatiseerimine: Värskenda ülesvoolu servereid dünaamiliselt juurutamise ajal.

Näidis GitLabi CI koodilõigust:

deploy:
  script:
    - nginx -t
    - systemctl reload nginx

Automatiseeritud juurutamine tagab järjepideva, versioonikontrollitud ja usaldusväärse NGINX-i juurutamise.

43) Selgitage NGINX sisenemiskontrolleri rolli Kuberneteses.

. NGINX sisendkontroller haldab Kubernetes teenustesse sisenevat liiklust. See teisendab Kubernetes sisenemisressursid dünaamiliselt NGINX-i konfiguratsioonideks.

Põhifunktsioonid:

  • Suunab HTTP/S päringud õigele teenusele.
  • Pakub SSL-i lõpetamist, kiiruse piiramist ja URL-i ümberkirjutamist.
  • Toetab koormuse tasakaalustamist podide vahel.
  • Võimaldab täpsema juhtimise jaoks annotatsioone (nt rewrite-target, proxy-body-size).

Näide sisenevast YAML-ist:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

See arhitektuur eraldab liikluse marsruutimise loogika konteinerite juurutamisest paindliku skaleeritavuse tagamiseks.

44) Kuidas NGINX HTTP/2 protokolliga toime tuleb ja millised on selle eelised?

NGINX toetab täielikult HTTP / 2, HTTP/1.1 järeltulija, parandades tõhusust multipleksimise ja päiste tihendamise abil.

HTTP/2 lubamiseks:

server {
    listen 443 ssl http2;
    ...
}

Plussid:

tunnusjoon Kirjeldus
Multiplexing Mitu päringut TCP-ühenduse kohta
Päise tihendamine (HPACK) Vähendab ribalaiuse kasutamist
Server Push Saadab klientidele ennetavalt varasid
Kiirem TLS Sujuvamad ja turvalised käepigistused

HTTP/2 vähendab drastiliselt latentsusaega ja lehe laadimise aega, eriti tänapäevaste veebirakenduste puhul, millel on arvukalt ressursse.

45) Mis vahe on NGINX-is ülesvoolu keepalive'il ja ühenduste taaskasutamisel?

Ülesvoolu säilitamine Näide: säilitab püsivad ühendused taustserveritega, vähendades TCP käepigistuse lisakulusid.

upstream backend {
    server app1.example.com;
    keepalive 32;
}

Erinevus:

Aspekt Elus hoidma Ühenduse taaskasutamine
Ulatus NGINXi ja ülesvoolu vahel NGINXi ja klientide vahel
Eesmärk Taustaprogrammi optimeerimine Esiotsa jõudlus
konfiguratsioon keepalive sees upstream keepalive_timeout in server blokeerima

Mõlemad meetodid vähendavad latentsust, kuid teenindavad erinevaid kommunikatsioonikihte (kliendipoolne vs serveripoolne).

46) Kuidas saab NGINX-i dünaamiliselt ümber konfigureerida ilma seda taaskäivitamata?

Uute konfiguratsioonide dünaamiliseks rakendamiseks ilma seisakuta, kasuta reload mehhanism:

nginx -t && nginx -s reload

See annab märku põhiprotsess et luua uusi töötajaid uuendatud konfiguratsioonidega, samal ajal vanu sujuvalt sulgedes.

NGINX Plus'is saab muudatusi teha API kaudu (nt ülesvoolu serverite dünaamiline lisamine):

curl --request POST \
  --url http://localhost:8080/api/3/http/upstreams/backend/servers \
  --header 'Content-Type: application/json' \
  --data-raw '{"server":"10.0.0.12"}'

See funktsioon toetab tänapäevastes DevOpsi torujuhtmetes nullseisakuid tekitavaid juurutusi.

47) Millised on NGINX-is pöördproksi ja edasiproksi peamised erinevused?

Aspekt Reverse Puhverserver Edasta puhverserver
Kliendi nähtavus Kliendid ei ole taustserveritest teadlikud Serverid ei ole kliendi identiteedist teadlikud
Esmane kasutamine Koormuse tasakaalustamine, vahemällu salvestamine, SSL-i lõpetamine Filtreerimine, anonüümsus, juurdepääsu kontroll
Tavakasutuse juhtum Veebiliikluse jaotus Ettevõtte või turvaline väljaminev sirvimine
NGINX-i tugi Natiivne ja laialdaselt kasutatav Nõuab kohandatud konfiguratsiooni

Näide (edasisuunamisproksi):

location / {
    proxy_pass $scheme://$http_host$request_uri;
    proxy_set_header Host $http_host;
}

RevErse proksimine jääb domineerivaks kasutusjuhtumiks, eriti API-lüüside ja mikroteenuste arhitektuuride puhul.

48) Kuidas saab NGINX-i kasutada API kiiruse piiramiseks ja drosseldamiseks?

Kiiruse piiramine kaitseb API-sid kuritarvitamise eest ja tagab õiglase kasutamise. Näidiskonfiguratsioon:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        proxy_pass http://backend;
    }
}

Mehhanism:

  • limit_req_zone: Määrab jagatud mälu tsooni ja kiiruse.
  • burst: Lubab piiratud ajutisi tõuse.
  • nodelay: Jõustab piirangud kohe.

See konfiguratsioon tagab, et iga kliendi IP-aadress saab teha ainult 10 päringut sekundis, lubades samal ajal lühikesi päringupurskeid.

49) Millised on NGINX-i tüüpilised kasutusjuhud ettevõtte DevOps-keskkondades?

Ettevõtte DevOps ökosüsteemides täidab NGINX mitmeid olulisi rolle:

  1. Veebiserver: Suure jõudlusega staatiline sisu edastamine.
  2. Reverse puhverserver / koormuse tasakaalustaja: Liikluse haldamine mikroteenuste vahel.
  3. API lüüs: Autentimine, marsruutimine ja piiramine.
  4. Sissetuleva kontrolleri: Kubernetes klastrite jaoks.
  5. Sisu vahemällu salvestamise kiht: Vähendab taustaprogrammi koormust.
  6. SSL-i lõpetamise lõpp-punkt: Tsentraliseeritud sertifikaatide haldus.
  7. Jälgimise tulemusnäitaja: Mõõdikute ja jälgitavuse integreerimine.

Selle kerge jalajälg ja modulaarne disain muudavad NGINX-i asendamatuks CI/CD torujuhtmetes, hübriidpilvedes ja kõrge käideldavusega klastrites.

50) Millised on NGINX-i ja HAProxy peamised erinevused koormuse tasakaalustamisel?

Mõlemad on suure jõudlusega koormuse tasakaalustajad, kuid erinevad fookuse ja arhitektuuri poolest:

tunnusjoon nginx HAProxy
Esmane roll Veebiserver + pöördproksi Spetsiaalne TCP/HTTP koormuse tasakaalustaja
Konfiguratsiooni lihtsus Lihtsam veebipõhiste töökoormuste jaoks Kompleksne, kuid detailsem kontroll
Kihi tugi L7 (HTTP), osaline L4 L4 ja L7 täis
Dünaamiline ümberkonfigureerimine Piiratud (avatud lähtekoodiga) Natiivsed käitusaja värskendused
jõudlus Suurepärane segatud töökoormuste jaoks Suurepärane toore koormuse tasakaalustamiseks
Lisaomadused Vahemällu salvestamine, tihendamine, staatiline sisu Tervisekontrollid, pulgalauad

Ettevõtted ühinevad sageli NGINX (esiosa) ja HAProxy (taustaprogramm) optimaalse marsruutimise ja skaleeritavuse tagamiseks.

🔍 Parimad NGINX-i intervjuuküsimused koos reaalsete stsenaariumide ja strateegiliste vastustega

1) Mis on NGINX ja miks seda tavaliselt tootmiskeskkondades kasutatakse?

Kandidaadilt oodatakse: Intervjueerija soovib hinnata teie NGINX-i põhiteadmisi ja arusaama selle praktilisest väärtusest reaalsetes süsteemides.

Näite vastus: „NGINX on suure jõudlusega veebiserver ja pöördproksi, mis on tuntud oma sündmuspõhise arhitektuuri poolest. Seda kasutatakse tavaliselt tootmiskeskkondades, kuna see suudab tõhusalt hallata suurt hulka samaaegseid ühendusi, tarbides samal ajal vähem süsteemiressursse kui traditsioonilised veebiserverid.“

2) Kas saaksite selgitada NGINX-i ja Apache'i erinevust?

Kandidaadilt oodatakse: Intervjueerija hindab teie võimet tehnoloogiaid võrrelda ja valida kasutusjuhtude põhjal õige tööriist.

Näite vastus: „NGINX kasutab asünkroonset, mitteblokeerivat arhitektuuri, mis muudab selle suure liiklusega ja staatilise sisu haldamisel tõhusamaks. Apache kasutab protsessipõhist mudelit, mis võib dünaamiliste konfiguratsioonide puhul olla paindlikum, kuid suure koormuse korral võib see tarbida rohkem ressursse.“

3) Kuidas NGINX toimib pöördproksina?

Kandidaadilt oodatakse: Intervjueerija soovib kinnitada teie arusaama pöördproksi kontseptsioonidest ja sellest, kuidas NGINX sobitub tänapäevaste arhitektuuridega.

Näite vastus: „NGINX toimib pöördproksina, võttes vastu kliendipäringuid ja edastades need taustserveritele. Seejärel tagastab see serveri vastused kliendile, mis parandab turvalisust, koormuse jaotust ja üldist jõudlust.“

4) Kirjeldage olukorda, kus kasutasite koormuse tasakaalustamiseks NGINX-i.

Kandidaadilt oodatakse: Intervjueerija otsib praktilist kogemust ja teie võimet rakendada NGINX-i funktsioone reaalsetes olukordades.

Näite vastus: „Oma eelmises rollis konfigureerisin NGINX-i liiklust mitme rakendusserveri vahel jaotama, kasutades ringjada ja vähimühenduste algoritme. See lähenemisviis parandas rakenduste käideldavust ja takistas ühelgi serveril pudelikaelaks muutumist.“

5) Kuidas NGINX-is SSL-i ja HTTPS-i konfiguratsiooni hallata?

Kandidaadilt oodatakse: Intervjueerija soovib hinnata teie arusaamist turvalisuse parimatest tavadest ja konfiguratsioonihaldusest.

Näite vastus: „Eelmisel ametikohal konfigureerisin SSL-i sertifikaatide installimise, HTTPS-kuulajate lubamise ja tugevate šifrikomplektide jõustamise kaudu. Samuti rakendasin HTTP-lt HTTPS-ile ümbersuunamise, et tagada turvaline side kõigis lõpp-punktides.“

6) Milliseid samme astuksite NGINX-is 502 Bad Gateway vea tõrkeotsinguks?

Kandidaadilt oodatakse: Intervjueerija paneb proovile teie probleemide lahendamise oskused ja tõrkeotsingu metoodika.

Näite vastus: „Alustaksin NGINX-i vealogide kontrollimisega, et tuvastada taustsüsteemi ühenduvusprobleeme. Seejärel kontrolliksin, kas ülesvoolu serverid töötavad, kinnitaksin õiged puhverserveri sätted ja tagaksin, et ajalõpud on õigesti konfigureeritud.“

7) Kuidas optimeerida NGINX-i jõudlust suure liiklusega rakenduste jaoks?

Kandidaadilt oodatakse: Intervjueerija tahab teada, kuidas te lähenete tulemuslikkuse häälestamisele ja skaleeritavusele.

Näite vastus: „Eelmisel töökohal optimeerisin NGINX-i, lubades gzip-tihenduse, häälestades tööprotsesse ja konfigureerides staatilise sisu vahemällu salvestamise. Need muudatused vähendasid oluliselt reageerimisaega ja serveri koormust.“

8) Kas saate selgitada, kuidas NGINX staatilise ja dünaamilise sisuga võrreldes toime tuleb?

Kandidaadilt oodatakse: Intervjueerija hindab teie arusaamist päringute käsitlemisest ja jõudluse optimeerimisest.

Näite vastus: „NGINX pakub staatilist sisu otse ja väga tõhusalt failisüsteemist. Dünaamilise sisu puhul edastab see päringud rakendusserveritele või teenustele, näiteks PHP-FPM, võimaldades igal komponendil keskenduda sellele, mida ta kõige paremini oskab.“

9) Kuidas NGINX-i konfiguratsioonimuudatusi turvaliselt hallata ja testida?

Kandidaadilt oodatakse: Intervjueerija soovib mõista teie lähenemist usaldusväärsusele ja riskide vähendamisele.

Näite vastus: „Enne teenuse uuesti laadimist valideerin konfiguratsioonimuudatusi NGINX-i konfiguratsioonitesti käsuga. Rakendan muudatusi ka hooldusakende ajal ja jälgin logisid pärast juurutamist tähelepanelikult.“

10) Kirjeldage olukorda, kus pidite NGINX-iga seotud katkestuse kiiresti lahendama.

Kandidaadilt oodatakse: Intervjueerija hindab teie võimet surve all töötada ja intsidentide ajal tõhusalt suhelda.

Näite vastus: „Minu eelmises rollis tekkis valesti konfigureeritud ülesvooluteenuse tõttu katkestus. Tuvastasin probleemi kiiresti logide abil, tühistasin konfiguratsiooni ja edastasin sidusrühmadele olekuvärskendusi, kuni täielik teenus taastati.“

Võta see postitus kokku järgmiselt: