Sivusto ei yleensä kaadu siksi, että internet on hankala paikka. Se kaatuu, koska yksi ketjun osa ei kestä tilannetta, johon se joutuu. Kun mietit, miten vähentää sivuston kaatumisia, älä aloita kysymällä, mikä hosting-paketti on halvin. Aloita kysymällä, paljonko menetetty yhteydenotto, tarjouspyyntö tai verkkokauppaostos maksaa yrityksellesi.
Jos sivu ei aukea kampanjan, uutisjutun tai sesongin kiireisimmän tunnin aikana, ongelma ei ole tekninen kuriositeetti. Se on katkennut myyntiprosessi. Asiakas ei odota palvelimen toipumista kahvikupin ääressä, vaan siirtyy seuraavaan hakutulokseen.
Miten vähentää sivuston kaatumisia: tunnista todellinen syy
"Palvelin kaatui" on usein liian epätarkka selitys. Sivusto voi näyttää käyttäjälle rikkoutuneelta, vaikka itse palvelin toimisi. Taustalla voi olla esimerkiksi tietokannan hidastuminen, ulkopuolisen integraation aikakatkaisu, viallinen julkaisu, liian raskas lomake tai liikennepiikki, johon kapasiteettia ei ole mitoitettu.
Pienissä ja keskisuurissa yrityksissä tavallinen ongelma on kerrostunut tekniikka. Sivusto on rakennettu vuosien mittaan teeman, lisäosien, seuranta- ja markkinointiskriptien sekä ulkopuolisten palvelujen päälle. Jokainen osa voi olla perusteltu yksinään. Yhdessä niistä syntyy kuitenkin riippuvuuksien kasa, jossa yhden päivityksen sivuvaikutus voi rikkoa yhteydenottolomakkeen, hidastaa koko sivun tai aiheuttaa virheen vain mobiilikäyttäjille.
WordPress ei automaattisesti tarkoita epäluotettavaa sivustoa. Ongelma syntyy, kun ylläpidon vastuut ovat epäselviä ja lisäosia kasvaa kuin autotalliin varastoituja pahvilaatikoita: jokaiselle on joskus ollut käyttöä, mutta kukaan ei enää tiedä, mikä niistä on välttämätön. Kun päivitykset tehdään satunnaisesti, turvallisuus, suorituskyky ja toimintavarmuus alkavat kilpailla keskenään.
Teknisen selvityksen pitää vastata ainakin neljään kysymykseen:
- Mitä tapahtui juuri ennen häiriötä?
- Mihin palveluun tai komponenttiin häiriö rajautuu?
- Kuinka moni käyttäjä ja mikä liiketoimintakriittinen toiminto kärsi?
- Miten sama tilanne havaitaan ja korjataan ensi kerralla nopeammin?
Ilman lokitietoja, mittareita ja selkeää vastuuta vastaukseksi jää arvaus. Arvaaminen on kallista etenkin silloin, kun sivusto kerää liidejä ympäri vuorokauden.
Rakenna sivusto niin, ettei yksi ongelma pysäytä kaikkea
Luotettavuus ei tarkoita sitä, ettei mikään koskaan vikaannu. Se tarkoittaa, ettei yksittäinen vika pysäytä koko asiakashankintaa ja että häiriöstä palaudutaan hallitusti. Käytännössä tämä alkaa yksinkertaisesta arkkitehtuurista.
Kaikkea ei tarvitse ladata jokaisella sivulla. Keskustelubotti, ajanvaraus, kartta, evästetyökalu, videoupotus ja analytiikka voivat olla hyödyllisiä, mutta niiden pitäisi olla toisistaan mahdollisimman riippumattomia. Jos esimerkiksi chat-palvelu on hetkellisesti pois käytöstä, yrityksen palvelusivun, puhelinnumeron ja yhteydenottolomakkeen pitää silti toimia.
Staattisesti tuotetut ja tehokkaasti välimuistitetut sivut kestävät liikennettä usein huomattavasti paremmin kuin sivusto, joka rakentaa jokaisen näkymän uudelleen palvelimella. Tämä ei sovi aivan kaikkiin käyttötarkoituksiin. Verkkokaupan ostoskori, kirjautuneet käyttäjät ja reaaliaikainen varauskalenteri tarvitsevat dynaamista toimintaa. Julkisten sisältösivujen ei silti tarvitse kuormittaa tietokantaa jokaisella vierailulla vain tavan vuoksi.
Välimuisti, sisällönjakeluverkko ja oikein mitoitetut palvelinresurssit eivät ole teknistä hienostelua. Ne ovat puskuria kysyntäpiikkejä vastaan. Jos kampanja tuo kymmenkertaisen kävijämäärän, sivuston pitäisi skaalautua tai ainakin säilyttää tärkeimmät toiminnot. Pelkkä lupaus "rajattomasta liikenteestä" ei kerro tästä mitään. Ratkaisevaa on, kuinka monta samanaikaista pyyntöä ympäristö käsittelee, miten raskaita ne ovat ja mitä tapahtuu kuorman kasvaessa.
Älä tee ulkoisesta palvelusta yksittäistä vikapistettä
CRM-yhteys, maksupalvelu tai ajanvarausjärjestelmä voi olla myynnille välttämätön. Siksi niiden häiriöihin pitää varautua. Lomakkeen lähetys voidaan esimerkiksi tallentaa turvallisesti jonoon ja toimittaa eteenpäin, kun ulkoinen rajapinta taas vastaa. Vaihtoehtoisesti käyttäjälle voidaan näyttää selkeä varakanava, kuten puhelinnumero tai sähköpostiosoite.
Tavoite ei ole rakentaa jokaiselle toiminnolle avaruusohjelman tasoista varajärjestelmää. Se olisi monelle yritykselle ylimitoitettua. Tavoite on tunnistaa ne kaksi tai kolme toimintoa, joiden pysähtyminen katkaisee rahan liikkeen, ja suojata ne kunnolla.
Valvonta ratkaisee, huomataanko vika asiakkaalta vai järjestelmältä
Moni yritys saa tiedon sivuston häiriöstä asiakkaalta. Se on huono mittari, koska silloin joku on jo yrittänyt ostaa, varata tai ottaa yhteyttä ja epäonnistunut. Parempi malli on jatkuva valvonta, joka tarkistaa sivuston saatavuuden, vasteajan ja keskeisten toimintojen onnistumisen.
Pelkkä etusivun pingaus ei riitä. Sivusto voi palauttaa teknisesti onnistuneen vastauksen, vaikka lomake lähettää virheen tai verkkokaupan kassa ei lataudu. Siksi valvontaan kannattaa sisällyttää käyttäjän kannalta olennaisia testejä: avautuuko tärkeä sivu, toimiiko lomakkeen lähetys ja saadaanko kriittisestä integraatiosta vastaus.
Hälytys on myös suunniteltava. Jos ilmoitus lähtee väärälle henkilölle, joka on mökillä ilman yhteyttä, valvonnasta tulee lähinnä digitaalinen koriste. Vastuun pitää olla nimetty: kuka reagoi, missä ajassa, miten muutos perutaan ja kenelle asiakkaalle viestitään, jos häiriö pitkittyy.
Hyvä käytäntö on määrittää kaksi tavoitetta. Ensimmäinen on havaintoaika: kuinka nopeasti häiriö huomataan. Toinen on palautumisaika: kuinka nopeasti tärkein palvelu saadaan takaisin käyttöön. Yrityksen ei tarvitse tavoitella teoreettista 100 prosentin saatavuutta. Sen sijaan kannattaa sopia realistinen palvelutaso ja tehdä näkyväksi, mitä se käytännössä tarkoittaa.
Päivitykset ovat tarpeellisia, mutta tuotanto ei ole testilaboratorio
Sivuston jäädyttäminen ei ole ratkaisu. Käyttöjärjestelmiä, kirjastoja ja integraatioita pitää päivittää turvallisuuden ja yhteensopivuuden vuoksi. Riski syntyy siitä, että muutos viedään suoraan tuotantoon ilman testausta, varmuuskopiota tai palautussuunnitelmaa.
Ennen merkittävää päivitystä kannattaa käyttää testiympäristöä, joka vastaa tuotantosivustoa riittävän hyvin. Siellä tarkistetaan ainakin tärkeimmät sivut, lomakkeet, maksut, kieliversiot ja integraatiot. Julkaisun jälkeen seurataan virheitä ja suorituskykyä, koska osa ongelmista näkyy vasta oikealla liikenteellä.
Varmuuskopio on välttämätön, mutta se ei yksin ratkaise mitään. Jos palautusta ei ole koskaan testattu, kyse on enemmän toiveesta kuin suunnitelmasta. Tiedä, kuinka usein kopio otetaan, mitä siihen sisältyy, missä sitä säilytetään ja kuinka kauan palautus kestää. Verkkokaupalle tuntien vanha tietokantakopio voi tarkoittaa kadonneita tilauksia. Esittelysivustolle se voi olla täysin hyväksyttävä kompromissi.
Kapasiteetti mitoitetaan liiketoiminnan, ei keskiarvon mukaan
Hiljaisen keskiviikkoaamun liikenne ei kerro, kestääkö sivusto messukampanjan tai television jälkeen tulevan piikin. Tarkastele historiallista liikennettä, markkinointisuunnitelmaa ja sivuston raskaimpia toimintoja. Erityisen tarkasti kannattaa katsoa tilanteita, joissa kävijä lähettää lomakkeen, hakee tuotteita, kirjautuu tai maksaa.
Kuormitustestaus on hyödyllinen ennen suurta kampanjaa, verkkokaupan avaamista tai uuden integraation käyttöönottoa. Testissä ei haeta näyttävää teknistä raporttia, vaan vastausta käytännön kysymykseen: mitä tapahtuu, kun samaan aikaan tulee 200, 500 tai 2 000 kävijää? Hidastuuko sivu asteittain, palauttaako se virheitä vai pysähtyykö se kokonaan?
Joskus paras ratkaisu on lisätä kapasiteettia. Toisinaan tehokkaampaa on keventää sivua, poistaa tarpeettomia skriptejä, parantaa välimuistia tai siirtää raskas toiminto erilliseen palveluun. Lisää rautaa huonosti suunnitellun järjestelmän alle voi auttaa hetkeksi, mutta se muistuttaa vuotavan veneen tyhjentämistä isommalla ämpärillä.
Luotettavuus tarvitsee omistajan
Sivusto kaatuu todennäköisemmin, kun domain, hosting, sähköpostit, analytiikka, koodi ja integraatiot ovat eri toimijoilla ilman yhteistä kokonaisvastuuta. Häiriön hetkellä jokainen voi todeta, ettei ongelma ole omassa päässä. Asiakkaan näkökulmasta se ei auta yhtään.
Toimiva ylläpitomalli yhdistää infrastruktuurin, valvonnan, tietoturvapäivitykset, julkaisut ja tuen yhdeksi selkeäksi palveluksi. Netvoiman kaltaisessa jatkuvassa mallissa tarkoitus ei ole myydä teknisiä termejä, vaan pitää sivusto nopeana, saatavilla ja muutettavana ilman plugin-painajaisia.
Hyvä ensimmäinen askel on yllättävän käytännöllinen: kirjoita ylös, mitkä kolme sivuston toimintoa ovat myynnillesi kriittisiä, kuka saa hälytyksen niiden häiriöstä ja kuinka ne palautetaan. Kun nämä vastaukset ovat kunnossa ennen seuraavaa ruuhkaa, sivusto ei ole enää liiketoiminnan hiljainen riskitekijä vaan osa koneistoa, johon voi luottaa.