30. juunist jõustub e-kaubanduse jaoks oluline HTTPS nõue

Käesolev blogipostitus on peatähtis läbi lugeda neil, kes tegelevad oma kodulehe vahendusel kaubandusega, kuid see on kindlasti oluline teadmiseks võtta ka teistele.

30. juunist ei luba Payment Card Industry Data Security Standard (PCI DSS) makseandmeid käsitlevate veebilehtede omanikel enam kasutada aegunud SSL/TLS turvastandardeid.

Selliste lehtede haldajad peaksid 30. juuniks veenduma, et nende HTTPS ühendused oleksid seadistatud järgmiselt:

1) SSL standardi kasutus peab olema täielikult keelatud;
2) kasutusel olev TLS protokoll peab olema vähemalt 1.1 või uuem.

Zone klientidel on hetkel seis selline:

1) SSL standardi kasutus on täielikult keelatud;
2) vaikimisi kasutusel olev TLS protokoll on 1.0 või uuem.

Rõhutan, jutt on konkreetselt SSL standardist! SSL-i terminit kasutatakse nii meil kui mujal (valesti) iseloomustamaks paljusid turvatud ühendusi, kuigi enamik neist põhineb tänapäeval juba TLS standardil.

Meie hoolsatel, turvateadlikel ja standardiga ühilduvust soovivatel klientidel on aga võimalus haldusliideses paari klikiga keelata vanemate TLS versioonide kasutamine. Selleks tuleb Virtuaalserveri haldusliideses Veebiserveri seadete alt muuta sätet “Luba aegunud TLS versioonide kasutamine”.

Võib kerkida küsimus, miks me TLS 1.0 kasutust üldiselt ära ei keela? Põhjus peitub selles, et interneti sügavustes eksisteerib veel mitu kihti internetti, üks neist on nö “asjade internet” ja teine “skriptide internet”. Need on internetikihid, millel püsib hoomamatu hulk meid ümbritsevaid protsesse ja milles iga suurem muudatus tähendab meie klientide jaoks ettearvamatuid tagajärgi.

Asjad, mis TLS 1.0 keelamisega võivad näiteks veebile ligipääsu kaotada:

* vanemad mobiiltelefonid;
* vanemad või odavamad käsiterminalid;
* vanemad või odavamad multimeediakeskused;
* vanemad operatsioonisüsteemid ja nende veebilehitsejad;
* vanemad skriptid ja programmid.

Ülevaatlikku tabelit erinevate seadmete TLS ühilduvusest üritab pakkuda muuhulgas GlobalSign.

Üks sarnane varasem iidvana protokolli toe lõpetamine on meie jaoks  näiteks lõppenud kõnega ühest logistikafirmast, mille käsiterminalid lõpetasid lennujaamas töö.

Erinevatel andmetel moodustab TLS 1.0 liiklus hetkel 5-11% kogu HTTPS-i abil turvatud ühenduste mahust.

Seetõttu oleme otsustanud, et jätame vanema TLS versiooni (TLS 1.0) kasutamise keelamise esialgu kliendi otsustada ning lükkame selle vaikimisi välja lülitamise veidi edasi, kuni teadlikkus on klientide hulgas veidi kasvanud.

Põhjus, miks PCI on otsustanud vanemate turvastandardite toetamise keelata peitub nende vanuses.

SSL (Secure Sockets Layer) on standardina olnud maha kantud juba tükk aega tagasi, kuid lühend ise elab turvatud ühendusi sümboliseeriva terminina inimeste teadvuses veel edasi. Reaalsuses lasti selle standardi viimane suurem versioon välja 1996. aastal ning aastast 2015 on selle kasutus sisuliselt keelatud (https://tools.ietf.org/html/rfc7568).

SSL-i asendas 1999. aastal standard TLS (Transport Layer Security) versiooniga 1.0 ning sellele on järgnenud versiooniuuendused 1.1 (2006 aastal) ja 1.2 (2008 aastal). 2018. aasta märtsist eksisteerib, peale pikka ja vaidlusterohket arendustööd, standardi mustandina ka TLS versioon 1.3, kuid selle laiemasse kasutusse jõudmine võtab veel veidi aega.

Mõlemad on olnud haavatavad tänu mitmetele nõrkustele, mis kandnud vahvaid nimesid nagu POODLE, BEAST, FREAK, BREACH, CRIME jt ning nende ja muude selliste aukude lappimine ei ole lihtsalt jätkusuutlik.

Sinu, minu, meie andmed ehk vastutav ja volitatud töötleja

Postkaste tabanud kirjadelaviin hakkab vaibuma ning kõik, kes seni ilma mõistliku aluseta andmeid töötlesid, on loodetavasti vastuse küsimusele “Kas me oleme ikka päriselt sõbrad, ütle jah?” kätte saanud või andmed hoolsasti ära kustutanud. Projektiplaani on joonistatud suur roheline linnuke “GDPR – tehtud!” ning elu läheb vanamoodi edasi.

Oleks vaid asi meie suhtega niisama lihtne… sest meil on ju andmed! Minu andmed, Sinu andmed, meie andmed ning lisaks nendega seotud ootused, lootused ja lubadused. Kes vastutab, kes kamandab, kes otsustab, keda volitab andmetega tegelema? Me peame sellest rääkima!

Kui lugemine tundub igav, siis võid vaadata ka ettekannet, mille tegin 22. mail toimunud Andmekaitseinpsektsiooni ja TTÜ teabepäeval ja kus räägin enam-vähem sama juttu.

Mis andmetest Sa räägid?

Peamiselt isikuandmetest. Zone teenustega seoses võiks need jagada kolmeks:

  • kliendiandmed (üks sõna) – enamasti seotud kliendikonto ja registreeritud domeenidega ning vajalikud teenuste osutamiseks (nt kontaktisiku andmed ja kontoga seotud tegevused); Zone on vastutav töötleja;
  • kliendi andmed (kaks sõna, laiema mõistena kliendi infovarad) – kõik see, mille Zone klient on teenuste kasutamise käigus serveri(te)sse üles laadinud või mis on tekkinud serveri(te) kasutamise käigus, näiteks registreerunud kasutajad ja e-poe tellimused, suhtlus ja logid; klient on vastutav töötleja, Zone on volitatud töötleja;
  • kasutusandmed – Zone infrastruktuuri ja teenuste turvalisuse tagamiseks, analüüsiks või arenduseks kogutavad andmed, nt erinevad logid ja analüütikalahendused, mis võivad sisaldada andmeid kasutajate ehk otseselt või kaudselt tuvastatavate füüsiliste isikute kohta; Zone on vastutav töötleja.

Kliendiandmete ja kasutusandmetega on lihtne: Zone on vastutav töötleja, need käivad meie privaatsuspoliitika alla, meil on paigas infoturbe juhtimissüsteemi põhimõtted ning protsessid privaatsuse ja eraelu puutumatuse tagamiseks (nt ligipääs andmetele on rangelt piiratud töökohustuste täitmisega, iganenud andmed kustutatakse jne), meie poolt kasutatavad volitatud töötlejad on hoolega valitud ja nimekiri veebis näha ning keskkasutajalepingu ja teenuste üldtingimuste punktid 9 ja 10 on senisest veidi põhjalikumalt lahti kirjutatud kasutades üldmäärusega sobituvat sõnastust. Kui on mingi mure, võid kirjutada andmekaitse@zone.ee, see jõuab joonelt Peeter Marveti (andmekaitsespetsialisti rollis) ja Ardi Jürgensi (infoturbejuhi rollis) postkasti. Kõik asjassepuutuvad viited leiab zone.ee veebi jaluses viidatud Isikuandmete kaitse (s.h GDPR) lehelt, sealt asub ka mõnede suuremate organisatsioonide poolt vajalikuks peetava isikuandmete lisakokkuleppe vorm (meie hinnangul täidab ka keskkasutajaleping kõik nõudmised ning see pole tegelikult vajalik).

Kliendi andmete osas on lugu aga keerulisem – kuna andmed on salvestatud meie serverisse ja liiguvad meie võrgus, siis oleme paratamatult volitatud töötlejaks. Serveriteenuse olemusest lähtuvalt me aga ei tea, mis andmeid klient meie serveris töötleb ja käsitleme neid kui “potentsiaalselt isikuandmeid” (ehk ülima ettevaatlikkusega). Ja klient on vastutav töötleja.

Vastutav… mille eest?

Vastutav töötleja on see, kes “määrab kindlaks isikuandmete töötlemise eesmärgid ja vahendid” ning “rakendab […] asjakohaseid tehnilisi ja korralduslikke meetmeid, et tagada ja suuta tõendada isikuandmete töötlemist kooskõlas [isikuandmete kaitse üld]määrusega” (ehk GDPR-iga).

Kes tahab põhjalikumat ülevaadet, see vaatab AKI Isikuandmete töötleja üldjuhendit

Praktikas tähendab see ennekõike seda, et klient:

  • omab ülevaadet töödeldavatest andmetest: mida täpselt kogutakse, mis eesmärgil, millisel alusel, kaua säilitatakse, kuidas turvatakse ja kellele edastatakse;
  • paneb selle kõik “mehele Kopli trammis” arusaadavalt andmekaitsetingimustesse (“privaatsusteade”) kirja;
  • oskab vastata küsimusele “mis andmeid te minu kohta töötlete?” ning suudab need soovi korral masinloetavalt väljastada või ära kustutada;
  • on volitatud töötlejate valikul olnud hoolas ning nendega töötlemise tingimustes kokku leppinud (kirjalikult);
  • teab mida teha juhul, kui peaks juhtuma andmeleke.

Praktika läks vist ikka veidi teoreetiliseks – proovime veelkord…

Praktiline näide: WordPress ja kontaktivorm

Üldistame ühe reaalse kliendiküsimuse, mis puudutas enam-vähem sellist olukorda:

  • Zone Virtuaalserver
  • paigaldatud WordPress
  • kontaktivorm: Gravity Forms (või Contact Form 7)
  • privaatsuspoliitika veebis olemas
  • kogutud kontaktid eksporditakse perioodiliselt turundus-assistendi poolt ja imporditakse kliendihaldustarkvarasse (nt Pipedrive) ja nõusoleku-linnukese olemasolul ka e-posti-turundus-lahendusse (nt Mailchimp)
  • samas Virtuaalserveris on ka üks vana kampaania-maandumisleht (Drupal, misiganes põhjusel)

Hakkame ülevalt pihta:

  • kasutajakonto loomisel nõustus klient Zone teenuste üldtingimustega ja sõlmis keskkasutajalepingu, see on kirjalik leping volitatud töötlejaga, milles on alati olnud punktid isikuandmete kaitse ning konfidentsiaalsuse kohta, uues versioonis oleme need ka täpsemalt lahti kirjutanud;
  • lepingu ja teenuse (eri)tingimuste alusel Zone poolt turvatav ja hallatav osa ulatub Virtuaalserveri puhul tarkvaraplatvormi ehk veebi- ja andmebaasiserverini ehk see “punane ala” on kaetud:

  • “halli ala” ehk WordPressi haldamine ja turvamine on aga tavapäraselt kliendi vastutus, loodetavasti on selleks tööks palgatud veebiagentuur või -meister ning vastutuse ja igakuise töömahu kohta leping sõlmitud;
  • ülejäänud teenused: Pipedrive kasutustingimused katavad üldmääruse nõuded kenasti ära ja tegu on EL ettevõttega, MailChimp on aga USAst ning nende puhul tasub veenduda Privacy Shield sertifikaadi olemasolus ning sõlmida andmetöötlust puudutava lisakokkulepe ehk data processing amendement.

Juriidiliselt peaks nüüd kõik korras olema, aga vaatame igaks juhuks ka sisulise/tehnilise poole üle:

Kuidas andmed liiguvad?

Kontaktivorm salvestab andmeid veebiga samasse andmebaasiserverisse:

  • andmed on näha WordPressis haldusliideses – kas sellele pääsevad ligi kõik kasutajad või ainult need, kellel on vaja?
  • andmed on WordPressiga samas andmebaasis – kas on kindel, et arendustööks WordPressi kopeerides ei satu need veebimeistri arvutisse?

Kontaktivorm saadab e-posti iga uue kontakti kohta:

  • kas e-postis sisaldub isikuandmeid või ainult teave uue kontakti kohta?
  • kas teavitus läheb ainult asjakohase töötaja e-postile või üldaadressile?

Kontaktid eksporditakse .csv faili ja imporditakse CRMi ja otseturunduslahendusse:

  • kas see tegevus on turvaline, mh assistendi arvutis viirusetõrje ja tugev parool?
  • kas allalaetud fail saab pärast importi kustutatud?
  • kas kontaktid kustutatakse pärast eksporti WordPressist (lõplikult, mitte ei satu “prügikasti”)?
  • kuidas on tagatud, et nt uudiskirjast loobumisel kajastub “nõusoleku tagasivõtmine” ka CRMis ja aadress nt mõne segmendi alusel uuesti otseturundust saama ei hakka?

Need sammud on hea meeles pidada, sest varem või hiljem tekib kellelgi küsimus:

Aga mis siis saab, kui juhtub andmeleke?

Tõepoolest, meil on ju varuks “must luik” ehk üks vana Drupal. Ilmselt on selles paikamata Drupalgeddon nime all tuntud haavatavus, see veeb häkitakse ühel päeval maha ja esilehele riputatakse ISISe lipp.

Kuna isikuandmed on sisuliselt “kõrvalkataloogis”, siis võib tegu olla ka isikuandmete lekkega ning tuleks hinnata selle mõju ning vajadusel teavitada Andmekaitseinspektsiooni ja lekkest puudutatud isikuid.

Veebiserveri puhul on seejuures üsna raske tuvastada, kas sissetungija midagi peale näotustamise veel tegi, aga üldmääruse kontekstis võiks kliendiandmete kopeerimine ja “tagasimüümine” olla kurjategijatele heaks lisateenistuseks.

Kuidas paremini teha?

Võimalusi on mitmeid – aga need kõik sisaldavad mingil moel avaliku veebi ja isikuandmete lahus hoidmist ning lepingut kellegagi, kes tagab turvalisuse:

  • alustame sellest, et levinud soov “paneme ühte Virtuaalserverisse kõik veebid kokku” ei ole riskide maandamise seisukohalt üldse hea mõte – kui häkitakse maha üks veeb on sisuliselt kompromiteeritud ka kõik ülejäänud ning nende puhastamine tükk tööd mille hind saab olema oluliselt suurem, kui eraldi Virtuaalserverite aastamaks;
  • kontaktide registreerimise saaks teostada ka nii, et veebilehel kuvatakse Pipedrive veebivormi (või Mailchimp’i oma) ning andmed lähevad otse nende vastutuse all olevasse serverisse – siis kaob kogu WordPressi ja veebiserveri probleem üldse ära;
  • … ning Pipedrive ning Mailchimpi ühendamisega tegeleb uus startup Outfunnel, mis on võtnud eesmärgiks lahendada ühelt poolt turunduse ja teiselt poolt andmekaitse küsimused.

Lisaks võib ka Zonega rääkida WordPressi (ja teiste veebirakenduste) haldamisest, aga selleks saab olema üks teine leping ning see on alles tegemisel 🙂

Küsida saab kommentaariumis – kui oskame, siis vastame (kui ei oska, siis õpime ja seejärel vastame).

Gitea – Alternatiiv GitHubile, mis töötab Zone Virtuaalserveris

See blogipostitus täidab kaht eesmärki: ühelt poolt on see ajendatud GitHubi ümber toimuvast, mis on pannud paljusid mõtlema võimalustele, kuidas oma lähtekoodi üle suuremat kontrolli omada; teiselt poolt demonstreerib see taas Zone Virtuaalserveri kasutusvõimalusi väljaspool sisseharjunud mustreid (antud juhul siis Go’s kirjutatud rakenduse majutamisel).

Mis on Gitea?

Gitea on GO’s kirjutatud avatud lähtekoodiga alternatiiv populaarsetele versioonihaldusteenustele Github ja Gitlab. Täpsemat infot Gitea kohta leiad aadressilt https://gitea.io/ ning põhjaliku dokumentatsiooniga saab tutvuda siin: https://docs.gitea.io/en-US/

 

Gitea logo

Nõuded Zone teenusele

Kasutusel peab olema Zone tarkvaraplatvormi kasutav server (kõlbab nii Virtuaalserver, Nutikas Pilveserver kui ka Nutikas Privaatserver). Käesolevas õpetuses on virtuaalserveri nimeks git.miljonivaade.eu

Virtuaalserveril peab olema eraldatud IP aadress portide suunamise tarvis. Pakett III sisaldab ühte tasuta eraldatud IP aadressi. Kui see aktiveeritud pole, tuleb ühendust võtta Zone klienditoega, kes selle tasuta aktiveerib.

1. Seadistame Zone virtuaalserveri

1.1 SSH

Kui teil on juba SSH ligipääs virtuaalserverile seadistatud võib jätkata punktist 1.2

Virtuaalserveri Haldus -> SSH -> Ligipääs

  • Lisame oma avaliku SSH võtme
  • Lubame ligipääsu oma IP aadressilt (või kõikjalt)

1.2 MySQL

Virtuaalserveri Haldus -> Andmebaasid -> MySQL

  • Lisame uue andmebaasi nimega d73643_gitea. Collation väljale valime utf8mb4_general_ci
  • Lisame uue kasutaja nimega d73643_gitea
  • Anname kasutajale d73643_gitea kõik õigused andmebaasis d73643_gitea

1.3 HTTP ligipääsu seadistamine (http proxy)

Virtuaalserveri Haldus -> Veebiserver -> Seaded HTTPS seadete all vajutame nuppu muuda

  • SSL/VHosti IP: XXX.XXX.XXX.XXX, mille väätuseks on virtuaalserverile eraldatud IP aadress.
  • Määrame mod_proxy sihtpordiks 3000
  • Ning vajutame Salvesta muudatused nuppu

 

1.4 Gitea SSH ligipääsu seadistamine GITile (portide suunamine)

Gitea kasutab oma sisest SSH serverit, mis annab võimaluse git repositooriumite ning kasutajate ligipääse Giteas endas hallata.

Virtuaalserveri Haldus -> Veebiserver -> Portide Suunamine

  • Lisa uus portide suunamine all tuleb täita väljad
    • IP: Valime Zone poolt eraldatud IP aadressi
    • Port: 2222
    • Kommentaar: gitea-ssh (vabalt valitud näidis)
    • Ning vajutan nuppu Lisa

HTTP proxy ja portide suunamise muudatused jõuavad serverisse umbes 10 minuti jooksul, aga DNS A kirje levimine eraldatud IP aadressile võib võtta ka üle tunni. Kui on soov rakendus enne kirjete levimist seadistada, siis võib IP enda tööjaama hosts faili lisada.

2. Paigaldame Gitea

2.1 Laadime alla ning paigaldame Gitea binaarfaili

Siseneme virtuaalserverisse SSH abil ning käivitame järgmised read:

mkdir domeenid/www.git.miljonivaade.eu/gitea
cd domeenid/www.git.miljonivaade.eu/gitea
wget -O gitea https://dl.gitea.io/gitea/1.4.2/gitea-1.4.2-linux-amd64
chmod +x gitea

Et Gitea esialgse konfiguratsioonifaili genereeriks, tuleb gitea korraks käivitada. Antud juhul see ebaõnnestub, aga tekitatakse custom/conf/app.ini fail.

Käivitame käsu:

./gitea web

Tulemus peaks olema järgmine:

2.2 Seadistame rakenduse konfiguratsioonid

Avame konfiguratsioonifaili

nano custom/conf/app.ini

Kogu sisu tuleb üle kirjutada järgnevaga:

RUN_USER = virt73403
RUN_MODE = prod

[database]
DB_TYPE = mysql
HOST = d73643.mysql.zonevs.eu:3306
USER = d73643_gitea
NAME = d73643_gitea

[repository]
ROOT = /data03/virt73403/domeenid/www.git.miljonivaade.eu/gitea/repositories

[server]
PROTOCOL = http
DOMAIN = git.miljonivaade.eu
HTTP_ADDR = 127.1.69.203
HTTP_PORT = 3000
DISABLE_SSH      = false
START_SSH_SERVER = true
SSH_PORT = 2222
SSH_LISTEN_HOST = 127.1.69.203

[log]
MODE      = file
LEVEL     = Info
ROOT_PATH = /data03/virt73403/domeenid/www.git.miljonivaade.eu/gitea/log

Virtuaalserveri põhised muutujad konfiguratsioonis:

  • RUN_USER – kasutaja, kelle õigustes rakendus käivitatakse. Selleks on virtuaalserveri SSH kasutajanimi.
  • database.HOST – andmebaasi hosti nimi, mille leiab Virtuaalserver Haldus -> Andmebaasid -> MySQL alampunktist. Lisaks tuleb määrata port, milleks on 3306.
  • database.USER – loodud MySQL kasutaja kasutajanimi.
  • database.NAME – loodud andmebaasi nimi.
  • repository.ROOT – asukoht, kuhu pannakse loodud repositooriumite andmed. Selle peaks määrama kujul: /dataXX/{ssh-kasutaja}/domeenid/www.{domeen}/vabalt/valitud/asukoht
  • server.PROTOCOL – konfiguratsioonis määrame protokoliks “http”, kuna HTTPS eest hoolitseb Zone seadistatud proxy.
  • server.DOMAIN – virtuaalserveri nimi ehk domeen.
  • server.HTTP_ADDR – virtuaalserveri loopback IP, mille saab teada kui käivitada virtuaalserveris SSH konsoolis käsk vs-loopback-ip -4.
  • server.HTTP_PORT – port, mille määrasime mod_proxy pordiks serveri seadetes.
  • server.SSH_PORT – port, mille määrasime portide suunamisel.
  • server.SSH_LISTEN_HOST – sama mis server.HTTP_ADDR.
  • log.ROOT_PATH – logifailide kataloog, mille võib määrata järgmiselt: /dataXX/{ssh-kasutaja}/domeenid/www.{domeen}/vabalt/valitud/asukoht

2.3 Paigaldame ning käivitame rakenduse

Pärast seda käivitame rakenduse uuesti

./gitea web

Ning kui kõik õnnestub, peaks pilt välja selline:

Veebiliides peaks tööle hakkama minnes aadressile: https://git.miljonivaade.eu ning avanema peaks järgmine pilt:

Põhikonfiguratsioon on sellega paigas. Antud lehel tuleb siis lisaks

  • sisestada MySQL kasutaja parool
  • kustutada pordi number Application URL väärtusest ning scheme määrata HTTPS. Antud juhul on lõppväärtus https://git.miljonivaade.eu/

Lõplikuks paigaldamiseks vajutame nuppu Install Gitea.

Õnnestunud paigalduse korral peaks avanema järgmine pilt:

Selles vaates tuleb teha endale konto. Esimesena registreeritud kontole antakse ka administraatori õigused.

Selle alampunkti lõpuks on meil olemas täisväärtuslik töötav Gitea rakendus. Nüüd on vaja lisada seaded, et Zone oskaks seda vajadusel automaatselt käivitada ja/või restartida

3. Seadistame Zone virtuaalserveri töötamaks Giteaga

3.1 Seadistame Gitea teenuse PM2’s

Kui Gitea töötab, peatame rakenduse klahvikombinatsiooniga ctrl + c.

Järgmiseks tuleb seadistada PM2, et Gitea jätkaks tööd ka pärast SSH’st välja logimist ning pärast Zone poolset serveri taaskäivitust. Selleks lisame PM2 teenuse. Samuti aitab PM2 rakendust automaatselt taaskäivitada, kui mingi probleemi tõttu peaks see “maha surema”.

Tekitame PM2 konfiguratisoonifaili:

nano /data03/virt73403/domeenid/www.git.miljonivaade.eu/gitea/gitea-pm2.json

Faili sisu peab olema selline:

{
 "apps" : [{
 "name" : "gitea-service",
 "script" : "gitea",
 "cwd" : "/data03/virt73403/domeenid/www.git.miljonivaade.eu/gitea",
 "args" : "web"
 }]
}

Salvestame faili ning Virtuaalserveri haldusliideses lisame rakenduse:

Virtuaalserveri Haldus -> Veebiserver -> Node.js ja PM2

  • Vajutame nuppu “Lisa uus Node.js rakendus”
  • Täidame väljad
    • Rakenduse nimi: gitea-service (vabalt valitud näids)
    • Skript või pm2.json: domeenid/www.git.miljonivaade.eu/gitea/gitea-pm2.json
    • Maksimaalne mälukasutus: kuna .json faili puhul see seade mõju ei avalda, võib see jääda 1MB peale.
  • Vajutame Lisa nuppu

Rakenduse käivitamiseks läbi PM2 peame ootama paar minutit. Veendumaks, et rakendus toimib, proovime selle aja möödudes minna brauseris rakenduse vaatesse – https://git.miljonivaade.eu/.

Kui antud aadressil avaneb Gitea rakendus, võib kontrollida, et rakendus sai ikka PM2 poolt käivitatud. Seda saab teha SSH konsoolis käsuga

pm2 status

Avaneda võiks järgmine pilt:

4. Hakkame rakendust kasutama ja/või testima

Järgnev tekst on juba töötava rakenduse näide, kui esimene kasutajakonto on loodud. Gitea on Zone virtuaalserveris paigaldatud, seadistatud õigesti käivituma ning järgnev on pigem väga lühike sissejuhatus rakendusse esimese repositooriumi loomiseks ning giti SSH ligipääsu seadistamiseks.

4.1 Sisestame SSH avaliku võtme git ligipääsuks

  • Klikime paremal üleval ikoonil ning avame menüüpunkti Your Settings
  • Avanenud lehel avame kaardi SSH / GPG Keys
  • SSH võtme all vajutame nuppu Add key

4.2 Loome uue respositooriumi

Siseneme Dashboard vaatesse. Visuaalne pilt on sarnane Githubi ja Gitlabiga ning neid kasutanud ei tohiks ka siin repositooriumi seadistamisega hätta jääda.

4.3 Hakkame kasutama

Repositooriumi vaates Clone this repository alt tuleb valida SSH ning kopeerida vastav URL.

Näiteks

git clone ssh://virt73403@git.miljonivaade.eu:2222/ingmar/zone-test.git
touch README.md
git add .
git commit -m "added readme"
git push

Ning giti kasutanud inimesel ei tohiks olla raske veenduda, et kõik töötab.

Edasi tuleb vaid Giteaga lähemat tutvust sobitada ning see enda vajaduste järgi ära seadistada.

Seitse nippi kiire e-poeni

Raske on leida e-kaubandusest rääkivat üritust, millel mõni ettekandja ei tooks neid näiteid:

Google: kui otsitulemuste kuvamine muutus 0,5 sekundit aeglasemaks, kaotasid nad 20% liiklusest

Amazon: kui lehe laadimine võtaks 1 sekundi kauem, kaotaksid nad aastas 1,6 miljardit dollarit käivet

Esimene uudis on aastast 2006, teine 2012. Ja Google uuris lehelaadimise kiiruseid 0,4 vs 0,9 sekundit. Meil on aasta 2017 ning e-poe esilehe laadimine 5 sekundiga kvalifitseerub juba heaks tulemuseks.

Et soola veelgi sügavamale haava hõõruda läheks ajas veidi tagasi, aastasse 1968, kui R.B Miller avaldas teadusartikli ”Response Time in Man-Computer Conversation Transactions”, milles ta kirjeldas kasutuskogemuse seisukohalt olulisi viivitusi nii:

  • 0,1 sekundit – süsteem tundub töötavat viivituseta;
  • 1 sekund – kasutaja mõttelõime katkemise piir, vaevutajutav viivitus;
  • 10 sekundit – kasutaja tähelepanu kadumise piir, tekib soov tegeleda muude asjadega.

Kuidas jõuda aasta ‘68 ideaali, alla 1 sekundi avaneva leheni?

Seitse nippi kiire e-poeni

E-poes eduka müügini viiv sekundi-suurusjärgus olev kiirus koosneb hulgast komponentidest ja need kõik nõuavad tööd. Panemaks paika tegevuskava arendajale ja serveri­haldajale võtame ette fiktiivse e-poe, mille probleemide näited pärinevad hulgalt meie käest abi saanud päris-e-poodidelt.

  • Pood aeglane – esileht, kategoorialeht või tooteleht avaneb üle 3 sekundi
  • Ebastabiilne – esineb hetki, kui server vastab oluliselt aeglasemalt või annab veateate
  • Ei kannata koormust – üldiselt on kiire, aga kui tuleb kampaania laeb lehte üle 10 sekundi ja hakkab andma Error 500 veateateid

Järgmistel lehtedel jutustan lahti selle, kuidas mina probleemseid veebe lahkan ja kiiremaks teen. Kui see liiga keeruline tundub, siis lappa ruttu lõpuni, sealt leiad 7-punktise investeerimis-soovituste nimekirja, millega oma veebiarendaja jutule minna.

Google PageSpeed

Google PageSpeed on kõige lihtsam koht alustamiseks ja tulemuse saad kätte kasvõi nutitelefonist (PageSpeed’i leiad googeldades, mõistagi :-). Google hindab serverist veebilehe HTMLi kättesaamise kiirust, aga lisaks ka selle kuvamiseks vajalikke komponente, nagu pildid, .css stiilifailid, .js skriptid jne.

Üsna tavapärane on kohata e-poe esilehte, mille kuvamiseks on brauseril vaja teha 100+ päringut kümnekonna erineva serveri suunal ning laadida alla üle 1,5 megabaidi. Sellest vahest kolmandik on pildid ja ülejäänu moodustavad veebilehe HTML ja stiilid-skriptid ehk sisuliselt tekst.

Minify JavaScript, CSS & HTML, Enable compression: Olukorra saab kiiresti paremaks liites hulga väikeseid .js ja .css faile suuremateks kokku, eemaldades neist (ja lehe HTMList) liigsed tühikud ja kommentaarid ning lastes need serveril transpordi ajaks ZIPiga kokku pakkida. Kohati saab seda teha veebirakenduste seadistuse või lisaplugina abil, kuid parima tulemuse annab arendaja läbimõeldud tegevus. Lehe maht ja päringute arv väheneb kordades ja see annab eriti hästi tunda mobiilseadmete kasutamisel. Testpoel saime esilehe 1,6 megabaidi pealt alla 690 kilobaidi peale, ainuüksi esilehe HTML vähenes 150 > 25kB ehk 6 korda! Suurima efekti andis pakkimine, mis on juba mõnda aega kõigil Zone serveritel vaikimisi sisse lülitatud.

Leverage browser caching: Väga lihtne on teha ka seadistus mis annab brauserile teada, et need failid – ja samuti pildid, lähema kuu aja jooksul ei muutu ning puudub vajadus igal järgneval lehekuvamisel nende värskust kontrollida. Tasub meeles pidada, et see võib tekitada olukorra, kus kujunduse- või sisumuudatus klientide (ja ka iseenda) brauseris niipea ei kajastu.

Optimize images: Enamuse veebipiltide nähtav kvaliteet ei lange, kui neid veidi jõudsamalt kokku pakkida. Pole aga harv ka juhus, kui lehe päise- või taustapilt on lihtsalt üle mõistuse suur (nähtud rekord: 8,6 mega) või loetelus kuvatavate väikeste tootepiltide jaoks laetakse alla täis-suuruses failid. Siin aitab läbimõeldud pildipoliitika reklaamide ja tootefotode üleslaadimisel, kvaliteetne kujundusteema ning veidike maagiat serveris toimuva pilditöötluse seadistamisel.

GTmetrix.com

Kui üldine pilt ees – ja korrastatud – siis võib järgmiseks ette võtta GTmetrix.com, mis kuvab PageSpeed reeglite alusel tuvastatud probleeme detailsemalt ja lisaks ka “konkureeriva” testimislahenduse Yslow! näitajad. Seal tulevad mõned mõisted lisaks – näiteks CDN (content delivery network) kasutamine ja ilma küpsisteta domeenid… aga ma soovitaks neid hetkel mitte liiga tõsiselt võtma hakata, sest enamasti on probleemiks veebirakendus ise.

Selle mõistmiseks tuleks lahti võtta sakk “Waterfall” ehk lehe kuvamiseks vajalike päringute kaskaad aja-teljel. Nimekirjas esimene on veebilehe “lehe enda” laadimine ning selle kohal hiirega peatudes kuvatakse info, kui kaua kulus serveril päringule vastuse koostamiseks (Waiting), kaua selle saatmiseks kliendi arvutisse (Receiving), kui kaua läks brauseril esimese näha oleva (above-the-fold) pildi joonistamiseks (First Paint) ja kui kaua lõplikuks laadimiseks (Fully Loaded).

Esimene ajakulu – lehe enda laadimine – on näidisel 1,17 sekundit.

Kui veebileht kohal, hakkab brauser seda jupp-haaval tõlgendama. Leides viite .css failile tuleb teha järgmine päring, sellest leitud taustapildi kuvamiseks järgmine jne. Sõltuvalt brauserist ja veebiserveriga suhtlemise protokollist (HTTP 1.1 või HTTP/2) käivitub korraga 8 kuni mõnikümmend päringut, seejärel lähevad teele järgmised. Kui osa pilti on valmis joonistatud ja midagi olulist muutub, hakkab joonistamine uuesti otsast peale – jne jne jne

Esimene kujutis – on näidisel 2,44 sekundit

Kui pilt enam-vähem olemas võib aga laadimine jätkuda – täiendavad skriptid, animatsioonid jne., võtavad igaüks aega.

Kui tuleme korraks tagasi PageSpeed’i näitajate juurde, siis võib siinkohal rääkida lahti ka järgmise mõiste: Eliminate render-blocking JavaScript and CSS in above-the-fold content. Ideaalselt optimeeritud veebilehel tuleb esimese vaate kuvamiseks vajalik JavaScript ja CSS kaasa juba lehe HTMLiga (vt: smashingmagazine.com lehe lähtekoodi) või laetakse “laisalt” ehk alles siis, kui kasutaja nii kaugele jõuab (vt: postimees.ee esilehe pildid, mis ilmuvad alles alla kerimisel). Ära hakka selle pärast veel muretsema – aga pea seda meeles, kui proovid endale veebilehe kuvamist vaimusilmas ette kujutada.

Leht valmis – 5 sekundit.

Inspector

Läheme aga veel sammukese edasi – eelnevalt nähtud tööriistad on olemas ka igas tänapäevases brauseris ja need leiab, kui parem-klõpsuga avanevast menüüst valida Inspect või Inspect Element (Safaril tuleb enne seadetest lubada Developer Tools).

Kui avada Network sakk ning paluda brauseril leht uuesti laadida unustades kõik varem puhvrisse kogutu, hoides Reload-nupu vajutamise ajal all Shift-klahvi, siis näed seda protsessi täies võlus ja valus.

Kiire netiühenduse taga pole ilmselt vahet, kas alla on vaja laadida 1 või 10 mega. Selleks, et panna ennast “kliendi papudesse”, on Inspektoris võimalus lülitada sisse throttling ehk piirata testimiseks ühenduse kiirust. Näiteks Slow 3G annab tulemuseks esimese pildi üheksandal sekundil.

Juuresoleva pildi tarbeks tekitasin olukorra, kus paar tootefotot on puudu ehk annavad Error 404 viga. Pildi serveerinuks meile veebiserver suurema jõupingutuseta, puuduva faili puhul käivitub aga kogu poe-rakendus, võetakse ühendust andmebaasiga … ja siis väljastatakse kenasti kujundatud ja menüüdega leht mis sisaldab ainult veateadet.

Brauserit ühe pildi puudumine ei sega. Küll aga on protsessorit ja andmebaasi koormava päringuga tekitatud olukord, kus ühe kasutaja teenindamiseks kulutatakse kahe jagu ressursse. Kuniks veebis on 1-2 külastajat, pole sellest ilmselt suurt lugu. Kui aga puuduvaid pilte on rohkem kui üks ning 10st külastajast saab seeläbi näiteks 40, siis on täiesti võimalik, et veebilehe genereerimine hakkab ca 1 sekundi asemel võtma 2 või 5. Ja sinna otsa tuleb siis kogu see muu aja-kaskaadis nähtav liiklus. Brrr…

Aga serveris?

Need kõik olid probleemid kliendi vaatest. Miks aga selle selle lehekülje genereerimine aega võtab ja koormuse tekkimisel veel aeglasemaks läheb? Lehe kuvamiseks on vaja teha hulk andmebaasipäringuid: veebipoe seaded, tootekategooriad menüü jaoks, sisutekstid, nuppude tõlked, reklaampinnad, kolme sorti esile tõstetud tooted, filtritega navigatsioon (“punased, naiste, põlvikud, mummudega, maavillased, tootja: Suva”) koos valikule vastava toodete arvuga… jne

Magentos on kõige selle info hoidmiseks umbes 200 tabelit ning päringuid kiirendavate indeksite loomine võtab niikaua aega, et seda iga toote muutmise järel teha pole mõtet, vaid indekseerimiseks on kasutusel perioodiliselt serveris käivitatavad nn cron-tööd. Kui soovid indeksit ette kujutada, siis mõtle raamatukogu tähestikulise kataloogi peale… ja siis mõtle, võrdluseks, kuidas oleks lihtsalt suvalisest hunnikust raamatut otsida. Samuti on seal üsna hästi läbi mõeldud vahepuhvrid ja palju muid nippe. Aga see kõik peab olema asjatundlikult seadistatud ning tulemus reaalse toodete ja kategooriate hulgaga koormuse all läbi testitud.

WordPress + WooCommerce puhul on olukord nadim, sest enamus tooteinfost elab ühe “postituste metainfo” tabeli tekstiväljades ja ei ole indekseeritud. Kategooriate ja siltide abil navigeerimine toimib rahuldavalt, kõik keerulisemad liigutused lähevad aga väääääga aeglaseks niipea, kui toodete arv läheb … ütleme, et üle mõnesaja.

Vahel on aga väga aeglane ka Magento – või lihtne WordPress. Siis on probleem enamasti kujundusteema või lisapluginate koodis ning ainus lahendus on lasta arendajal veebile “andurid” külge panna ja välja uurida, kust kohast täpselt king pigistab.

Zones on Virtuaalserverile lihtne lisada kahe erineva otstarbega analüüsi-tööriista litsentse. Ülimalt lihtsustatuna teevad need järgmist:

New Relic (75-150$/kuu) – jälgib veebilehe reaalset koormust, toob esile aeglased päringud ja aitab neist leida probleemse funktsiooni või andmebaasipäringu rakenduse koodis. Kasutame ise Zone teenuse monitooringuks ja oleme väga rahul. Kiire kogemuse saab 14p prooviversiooniga, aga mõistlik oleks vähemalt uue poe puhul esimeseks aastaks peale panna.

BlackFire (20-83$/kuu) – võimaldab profileerida üksikpäringuid, leida ressursimahukaid funktsioone ja andmebaasipäringuid. Sobib arendaja tööriistaks mitte reaalajas jälgimiseks. Oleme katsetamas võimalust pakkuda selle abil klientidele kiiret hinnangut veebirakenduse kitsaskohtade osas. BlackFire kasutamisest on pikemalt ja sisulisemalt juttu blogipostis Miks mu veeb aeglane on? Vaata BlackFire abil järgi!

Serveri jõudlus

Oled käinud läbi kõik eelnevad soovitused – esilehe laadimiseks on vaja alla 50 faili, selle suurus on alla 500kB, “leht ise” saabub brauserisse alla 0,5 sekundi ning joonistatakse valmis hetkega – ning siis teatad Facebook’is välk-kampaaniast.. ja leht muutub hetkega tigu-aeglaseks (esilehe laadimine 10+ sekundit) ning osa kasutajaid saab veateate Error 500. Mis toimub?!?!?

Ülimalt lihtsustatult öeldus suudab protsessor ajaühikus täita kindla hulga käske – ja kuigi mitme tuumaga protsessor toimib nagu mitu protsessorit paralleelis, tekib varem või hiljem ikkagi olukord, kus osad päringud jäävad lihtsalt eelmise lõppemist ootama.

Kuna ükski ressurss ei ole kummist on serveris seatud rida piiranguid – ning jagatud ehk tavapärases veebimajutuseks kasutatavas virtuaalserveris peavad need tagama ka selle, et ühe kliendi koormus teiste veebide tööd ei segaks. Kui samaaegsete päringute arv jõuab seatud piirini, siis ei jää serveril muud üle kui anda veateade – sorry, aga hetkel rohkem ei mahu!

Zone Virtuaalserverites on see piir paketist sõltuvalt 50-200 “paralleeltööühikut” ehk korraga teenindatavat ühendust veebiserveriga (Nutika Pilveserveri ja Nutika Privaatserveri puhul seab piiri pigem protsessori tuumade arv). Kui kliendile veebilehe serveerimine – koos kõigi piltide ja lisadega – võtaks täpselt ühe sekundi, siis võiksime rääkida ka sarnasest numbrist sama-aegsetest kasutajatest.

Nagu me varasematel lehtedel nägime, siis võtab see aga pigem 5 sekundit ning sõltub lisaks Sinu kontrolli all olevatele teguritele ka näiteks klientide internetiühenduse kiirusest. Kuniks esimesed saabujad avalehel olevat 7MB videotausta alla laevad ootavad teised järjekorras või saavad veateate.

See on 12 kuu koormusgraafik. Mis võivad olla muutused, mis on põhjustanud koormuse kasvu? Edukas turundustöö? Uus tarkvaraversioon? Vale seadistus? (pilt & küsimused kliendile saadetud kirjast)
Nüüd on veidi tööd tehtud, nagu alumisest ehk nädala-vaatest näha on pidev koormus langenud. Silma hakkavad aga korrapärased piigid, nende aja paremaks hindamiseks võib vaadata 24h graafikut . Uudiskiri? Varukoopia? Cron tühejendas cache? (vastused monitooringu peatüki lõpus 🙂

Tuleb välja, et veebipoe koormustaluvust võivad disaini osas tehtud otsused mõjutada isegi rohkem, kui arendaja poolt optimeeritud kood! Mida lihtsam kujundus, seda kergem on tagada suurele hulgale klientidele eeskujulik kasutuskogemus – ja pood reaalselt müüma panna.

Või mis see eesmärk meil oligi?

Koormustestimine

Suure hulga paralleelsete päringute tekitamiseks on vaja “robotit” ning kõige lihtsam on alustada mõne selleks mõeldud teenusega. Lihtsamad, nagu näiteks loader.io, saadavad korraga teele tellitud koguse päringuid ühe või mitme lehekülje vastu, simuleerides nii kasutaja liikumist veebis – ja joonistavad tulemuse kohta graafiku, millest näeb kasutajate paralleelselt teenindatavate päringute arvu.

Nende tasuta prooviversioon võimaldab katsetada üheminutist koormust ja kuni 50 sama-aegset päringut. Minu esimene test ongi saata ilma cache’ta esilehe pihta minuti jooksul ühest 50ni kasvav koormus ning vaadata, kui palju päringuid sekundis teenindada jõutakse. Kui tulemus ei rahulda, siis tuleb võtta suuremate limiitidega virtuaalserver või kolida privaatserverisse.

Mõlemal puhul tuleks aga lisaks üle vaadata kõigi rakenduse komponentide toimimine ning serveri seaded: näiteks üleminek PHP värskeimale versioonile võib anda kiirust juurde üle 2 korra, samuti annab sageli võitu, kui loobud esilehel olevatest erinevatest automaatselt genereeritavatest „soodukad-enimostetud-uued” pakkumistest või filtrite juures leitud toodete arvu kuvamisest. Need kõik on vajalikud komponendid, aga kui ilma nendeta on veeb oluliselt kiirem siis on see selge märk, et nende kasutamine maksab raha kas suurema serveri või arendaja poolt tehtava optimeerimise näol.

Ülemine graafik: 3 minuti jooksul kasvab sama-aegsete päringute arv (1-50), sellest tulenevalt muutub aeglasemaks ka serveri vastus.
Alumine graafik: sekundis teenindatud päringute arv kasvab koos koormuse kasvuga, umbes 80 päringut sekundis tundub olema selle serveri ja tarkvara piir. Kui on vaja rohkem tuleb investeerida suuremasse serverisse või optimeerimisse.

NB: Jagatud ehk virtuaalserveri puhul tuleks selliste testidega olla eriti ettevaatlik ning arvestada ka naabritega!

Veebi pidev monitooring

Siiamaani oleme tegelenud üksikute päringutega või vaadanud mõnda minutit veebipoe elutsüklist. Pood peab aga töötama 24/7 ning selle kiirust mõjutab suur hulk tegureid. Alloleval pildil on ühe saidi monitooringu-graafik Pingdom.com teenuses – selle odavaim pakett maksab 12$/kuus ja võiks olla kasutusel igas e-poes. Suurema poe puhul võib olla aga mõistlikum näiteks New Relic, mis annab lisaks detailset infot tarkvara toimimise kohta.

Tuvastatavate probleemide kohta mõned näited reaalsetest poodidest:

Väline teenus – pood laeb oma tootekataloogi välisest teenusest; seda tehakse öösel, aga kella 3 ja 6 vahel on sellega pidevalt koormatud 10% protsessori võimsusest. Päringute aeglustumine on minimaalne, aga graafikult siiski näha. Lahendus: koodi optimeerimine.

Hullunud Google – nädalate lõikes muutub sait üha aeglasemaks. Proovides probleemi mõista, avastame logidest, et enamus päringuid teeb otsimootori robot, mis lappab läbi toote-filtreid. Lahendus: Google Webmaster Tools või robots.txt abil keelame filtrite indekseerimise: koormus langeb ja kaob SEO jaoks ülioluline duplikaatsisu probleem.

Andmebaasi varukoopia – keegi on unustanud peale sätte, mis talletab andmebaasi kõigi külastajate (sh otsirobotid) poolt vaadatud tooted. Tulemus: baas on 8GB. Sellest tehakse igal öösel varukoopia, mis põhjustab täiendava koormuse serverile. Lahendus: puhastame andmebaasi liigsest tränist ja keelame tarbetu salvestamise.

SEO-skänn – veeb on öösel ja päeval tunnikese aeglasem. Logisid analüüsides avastame, et tegemist on AHREFS nimelise tööriistaga, mis kogu toote-kataloogi läbi lappab ning selle kõrval on väiksemaks probleemiks kolm (ilmselt) konkurenti, kes hinnavõrdlust teevad. Lahendus: kui võimalik, siis piirame robots.txt abil tarbetute bottide ligipääsu.

Boonus: kõik siinsed näited peale andmebaasi varukoopia on näha Serveri jõudluse peatüki graafikutel. Pidev koormus oli “hullunud google”, pidev kasv tõenäoliselt tingitud sellest, et otsimootor ennast sügavamasse auku kaevas filtreid mööda mütates. Järgi jäänud piigid on SEO-skänn või tootehindade võrdleja, ilmselt mõni konkurent. Ja kui täpselt vaadata… siis toimub öösel kella 1-2 vahel mingi andmebaasi koormav asi veel.

Mis ei tööta?

Nutikas lugeja on kindlasti taibanud, et kõige eelneva mõte on aidata e-poodnik lähemale arusaamisele: veebirakenduse kiirus ja töökindlus on investeering ning sellega tuleb arvestada nii uue poega alustades ja disainiotsuseid tehes kui ka igapäevaselt.

Kirjeldatud lahenduste hinnasilt algab ühest arendaja või veebihalduri töötunnist (odavaim pakkumine ca 50€+km/h) esmaste PageSpeed’i poolt esile toodud vigade kõrvaldamisel ja jõuab sisulisemate koodist kitsaskohade otsimisel kiirest 4-8 tunnini. Suuremad muudatused ja optimeerimine võivad vabalt võtta nädalaid. Ka lihtne küsimus Zone klienditoele: “Miks mu veeb aeglane on?”, tähendab tehnikutele minimaalselt ühte töötundi.

Selle kõige juures on loomulik, et tekib soov leida lihtsamaid ja kiiremaid lahendusi – seda nii tellija kui ka teostaja vaatevinklist. Äkki on olemas mõni plugin või laiendus, mis teeb poe kiiremaks?

Täpselt samuti, nagu ma igast mahahäkitud veebist leian hulga turvapluginaid – mis ilmselgelt ei ole oma tööga hakkama saanud, leian ma igast aeglasest poest ka hulga midagi “optimeerivaid” pluginaid. Kindlasti on igaühel neist oma roll, aga läbimõtlemata kasutus lisab sageli lihtsalt protsessorile tööd juurde ning tekitab täiendava komponendi, mis saab mingis ettearvamatus olukorras katki minna.

Üks selline näide on cache. Iseenesest väga hea abivahend, mis puhverdab päringute teenindamiseks vajalikku infot ja paremal juhul terveid veebilehti, aidates sellega tagada suurele hulgale sama-aegsetele külastajatele < 1 sekundilist esilehekuvamist. Lihtsalt super!

Aga kui selle taha on peidetud optimeerimata kood ja tõsiasi, et tootelehe genereerimine võtab 5 sekundit… Siis on see pood ikkagi käpuli niipea, kui seda külastab uudishimulik otsirobot, mis asub indekseerima kõiki lehti. Ka cache efektiivne töö vajab optimeerimist ja monitoorimist ning kuniks seda tehtud pole, kehtib Zone sysadminnide elutarkus: võttes cache-plugina maha, läheb veeb kiiremaks.

Millest pihta hakata ehk checklist

1. monitooring – lisa vähemalt odavaim Pingdom’i monitooring (soovitavalt koos RUM ehk real user monitooring koodiga veebilehel). See annab tagasisidet järgmiste sammude õnnestumisest. Investeering: ca 12$ kuus.

2. PageSpeed – lase veebiarendajal või -halduril tuvastada ja lahendada peamised esiletoodud probleemid ning põhjendada, miks osad GTmetrix.com põhjalikuma raporti leiud selles faasis reageerimist ei vaja. Investeering: mõned töötunnid.

3. Koormustest – proovi vähemalt loader.io tasuta testiga järgi, kuidas veeb koormuse all käitub. Lähtu tänasest reaalsest külastatavusest, aga plaani tulevikule mõeldes. Investeering: mõni töötund.

4. Esilehe genereerimine jõudeolekus alla 1 sekundi, selleks tehakse alla 50 päringu, lehe maht soovitavalt alla 1MB. Investeering: küsi arendajalt ennustatavat töömahtu.

5. Rakenduse monitooring – võta kasutusele New Relic või mõni teine rakenduse töö analüüsiks mõeldud lahendus. Pane paika soovitud kvaliteedikriteeriumid ja arenguplaan, seo jõudlusnäitajad müüginumbrite või kasutajate rahuloluga. Investeering: min 80$/kuus monitooring + tööaeg (seadistamine, jälgimine, järelduste tegemine, parandamine).

6. Vali oma raskusklassi sobilik serverilahendus. Investeering: jagatud Virtuaalserver 5-20€/kuu » hallatud Nutikas Pilveserver alates 100€/kuu » Nutikas Privaatserver alates 215/kuu » võimsamad serverid, mitmest serverist koosnevad klastrid, kõrgem töökindlus läbi erinevate andmekeskuste kasutamise…

7. Hea arendaja ei pruugi olla parim sysadminn – küsi meilt või mõnelt teiselt sellele spetsialiseerunud ettevõttelt “veebirakenduse täishaldust”. Võibolla ei peaks kõige selle monitoorimisega ise tegelema ning efektiivsem lahendus oleks, kui ops (operations) suhtleks dev’iga (developers) ning Sulle vaid executive level info ja investeeringuvajadused ette kannaksid?

Väike vihje: kui koodi optimeerimine välja arvata (ja koormustesti natuke teisiti korraldada), siis on enamus siin kirjeldatud kitsaskohtade tuvastamise meetoditest rakendatavad ka konkurendi veebi peal – ära unusta jälgida nende tegevust ja arengut! 😉

Nüüd saadaval kauaoodatud .APP domeenid

Maailmas laineid lööv .APP tippdomeen on saadaval ka Zone.ee klientidele.

.APP (loe: äpp) tippdomeeni nimeruum on eelkõige suunatud veebi-, mobiili- või töölauarakenduste pakkujatele ja arendajatele. APP-lõpuliste domeenide registrit pidav Google loodab, et selline veebiaadress aitab inimestel lihtsamini ja kiiremini leida neile olulisi rakendusi ning saada nende kohta infot.

Ühtlasi on .APP üks esimestest tippdomeenidest, mis tunnistab vaikimisi vaid HTTPS (HTTP+TLS) tehnoloogia abil turvatud veebiühendusi. Nimelt on kogu tippdomeen kantud kõikidesse populaarsematesse veebilehtisejatesse eellaetud HSTS (HTTPS Strict Transport Security) poliitika nimekirja. Krüpteerimata veebiteenuseid ei ole sellises tippdomeenis sisuliselt võimalik avalikult pakkuda.

Eelnev teeb muuseas .APP tippdomeenist hea partneri meie Virtuaalserverile, mille puhul on turvalised ja krüpteeritud HTTPS ühendused juba pikemat aega teenuse vaikesätteks ning tasuta Let’s Encrypt TLS sertifikaat olemas igale veebisaidile.

Üleilmselt on .APP tippdomeen hästi vastu võetud, avalikule registreerimisperioodile eelneval piiratud ja kallil eelregistreerimiste etapil on juba registreeritud üle 8000 uue .APP domeeni. Lähipäevadel on ilmselt oodata kümneid tuhandeid uusi registreerimisi.

TÄHELEPANU! .APP domeenid on nüüd vabalt registreeritavad, kuid tulenevalt regulatsioonist peab registreerija oma domeenisoovi peale Zone lehe kaudu tellimuse esitamist ka täiendavalt kinnitama. Selleks jõuab registreerija postkasti Zone nimel inglisekeelne sõnum pealkirjaga “Authorization needed for application of the domain name”, millele tuleb kindlasti reageerida. Vastasel korral taotlus tühistatakse.