Webhotellin vaihto ilman katkoa: testaa uusi palvelin ennen kuin kukaan asiakas näkee mitään

Webhotellin vaihto ilman katkoa ei ole ajoituskysymys vaan menetelmä. Näytämme miten testaat uuden palvelimen omalla koneellasi oikealla verkkotunnuksella, mitä kaikkea siirretään ja miksi sähköposti on oma projektinsa.

Lyhyt vastaus: Webhotellin vaihto ilman katkoa perustuu yhteen asiaan: sivusto rakennetaan uudelle palvelimelle valmiiksi ja testataan siellä ennen kuin yksikään kävijä ohjataan sinne. Testaus tehdään oman koneen hosts-tiedostolla, joka näyttää uuden palvelimen sinulle oikealla verkkotunnuksella, mutta ei kenellekään muulle. Vasta kun kaikki toimii, DNS-osoitus vaihdetaan — ja silloin vaihto kestää sekunteja, ei tunteja. Sähköposti siirretään erikseen ja eri aikaan.

Suurin osa webhotellin vaihdon ongelmista ei johdu siirrosta itsestään. Ne johtuvat siitä, että vika huomataan vasta kun sivusto on jo julkisesti uudella palvelimella. Lomake ei lähetä, kuvat puuttuvat, ostoskori kaatuu maksuvaiheeseen. Silloin olet korjaamassa tuotantoa kello kaksi yöllä, ja vanha palvelin on jo pois päältä.

Tämä on vältettävissä kokonaan. Siirron voi harjoitella etukäteen niin, että sivusto pyörii uudella palvelimella oikealla verkkotunnuksella, sinun selaimessasi, samaan aikaan kun kaikki muut näkevät edelleen vanhan. Menetelmä on vanha, ilmainen ja täysin peruttavissa. Sitä ei vain kirjoiteta juuri koskaan auki suomeksi pienyrittäjälle.

Jos etsit aikataulua — mitä teet kaksi viikkoa ennen, mitä siirtopäivänä ja missä järjestyksessä — se on kirjoitettu erikseen: aikataulutettu siirto-ohje käy läpi päivämäärät, TTL-arvot ja vaiheet. Tämä sivu ei toista sitä. Tämä sivu opettaa menetelmän: miten siirto tehdään käsillä niin, ettei katkoa synny.

Miksi katko syntyy, ja miksi se ei ole DNS:n vika?

Kun vaihdat DNS-osoituksen, muutos ei leviä maailmaan hetkessä: osa kävijöistä menee vielä tunteja vanhalle palvelimelle ja osa jo uudelle. Tätä kutsutaan usein katkoksi, mutta se ei ole katko — molemmat palvelimet vastaavat ja sivusto näkyy kummastakin. Ongelma syntyy vasta, jos uudella palvelimella on jotain rikki tai jos vanha sammutetaan liian aikaisin. Katko ei siis johdu DNS:n leviämisviiveestä vaan siitä, että vaihto tehdään ennen kuin uusi ympäristö on testattu. Oikea järjestys kääntää asetelman ympäri: ensin kopio, sitten testaus, sitten korjaukset ja vasta lopuksi DNS. Silloin leviämisviive on merkityksetön, koska kumpi tahansa palvelin kävijälle osuukin, sivusto toimii.

Oikea järjestys kääntää asetelman ympäri. Ensin kopio, sitten testaus, sitten korjaukset, ja vasta lopuksi DNS. Kun DNS-muutos tehdään viimeisenä, sen leviämisviive ei haittaa: kumpi tahansa palvelin kävijälle osuukin, sivusto toimii. Sinä pidät molemmat pystyssä muutaman päivän ja sammutat vanhan vasta kun liikenne on loppunut.

Mitä siirretään ja mistä se löytyy?

"Siirrä sivusto" kuulostaa yhdeltä tiedostonipulta, mutta käytännössä siirrettäviä osia on kahdeksan ja ne asuvat eri paikoissa hallintapaneelissa. Ne ovat tiedostot, tietokanta, ohjelmistoversiot, kirjastot ja lisäosat lisensseineen, ajastetut tehtävät, SSL-varmenteet, uudelleenohjaukset ja sähköpostilaatikot. Käy alla oleva lista läpi ennen kuin aloitat, niin tiedät mitä olet unohtamassa — siirroissa harvoin unohtuu itse sivusto, mutta lähes aina unohtuu jokin näistä muista, ja puute huomataan vasta viikkojen päästä. Taulukko kertoo jokaisesta osasta sekä sen, mistä se otetaan, että sen, mikä siinä useimmiten jää tekemättä. Kun kaikki nämä ovat uudella palvelimella, sinulla on kopio — muttet vielä tiedä toimiiko se, ja siihen tarvitaan hosts-tiedosto.

Kun kaikki nämä ovat uudella palvelimella, sinulla on kopio — muttet vielä tiedä toimiiko se. Siihen tarvitaan hosts-tiedosto.

Mikä hosts-tiedosto on?

Hosts-tiedosto on koneesi paikallinen ohitus nimipalvelulle. Kun kirjoitat selaimeen yritys.fi, kone kysyy normaalisti nimipalvelulta, mihin IP-osoitteeseen se menee. Hosts-tiedosto kertoo vain sinun koneellesi, että yritys.fi löytyy tietystä IP-osoitteesta, eikä konetta kiinnosta sen jälkeen, mitä nimipalvelu sanoo. Tämä on koko siirtotempun ydin: voit osoittaa oman koneesi uuteen webhotelliin oikealla verkkotunnuksella ilman että kukaan muu maailmassa näkee mitään muutosta. Asiakkaasi, hakukoneet ja kilpailijasi näkevät edelleen vanhan sivuston, ja koska mikään DNS-tietue ei ole muuttunut, mitään ei tarvitse myöskään perua. Alla kerrotaan, miksi väliaikainen testiosoite ei kelpaa samaan tarkoitukseen. Ohitus koskee vain sitä konetta, jolle rivi on lisätty, joten se on turvallisin mahdollinen tapa testata.

Tämä on koko tempun ydin. Voit osoittaa oman koneesi uuteen webhotelliin oikealla verkkotunnuksella, ilman että kukaan muu maailmassa näkee mitään muutosta. Asiakkaasi, Google ja kilpailijasi näkevät edelleen vanhan sivuston. Sinä katselet uutta. Mikään DNS-tietue ei ole muuttunut, joten mitään ei tarvitse peruakaan.

Miksi tämä on tärkeää: se on ainoa tapa testata sivustoa oikealla verkkotunnuksella ennen julkaisua. Väliaikaiset testiosoitteet, joita webhotellit tarjoavat, näyttävät sivuston mutta rikkovat samalla puolet siitä. Kirjautumiset, ostoskorit, maksut ja kaikki sisäiset linkit on rakennettu oikean verkkotunnuksen varaan, joten testiosoite antaa väärän vastauksen molempiin suuntiin: se näyttää vikoja joita ei ole, ja piilottaa vikoja jotka ovat.

Näin lisäät rivin hosts-tiedostoon

Hosts-rivin lisäämiseen tarvitset yhden tiedon: uuden palvelimen IP-osoitteen. Se lukee uuden webhotellin hallintapaneelissa, yleensä palvelimen tai paketin tiedoissa nimellä IP-osoite tai "A-tietue", ja jos et löydä sitä, kysy tuesta — se on julkinen tieto eikä salaisuus. Itse työ on viisi vaihetta: tiedosto avataan järjestelmänvalvojana, rivit lisätään tiedoston loppuun, nimivälimuisti tyhjennetään, varmistetaan että katsot oikeaa palvelinta ja lopuksi rivit poistetaan heti testin jälkeen. Koko operaatio vie muutaman minuutin, ja se on peruutettavissa poistamalla lisätyt rivit. Alla jokainen vaihe on kuvattu erikseen molemmille käyttöjärjestelmille. Viimeinen vaihe on tärkein, koska tiedostoon jäänyt rivi näyttää sinulle eri sivuston kuin asiakkaillesi.

1. Avaa tiedosto järjestelmänvalvojana Windows: käynnistä Muistio tai muu tekstieditori hiiren oikealla → Suorita järjestelmänvalvojana, ja avaa sillä tiedosto C:\Windows\System32\drivers\etc\hosts (valitse avausikkunassa tiedostotyypiksi "kaikki tiedostot", muuten sitä ei näy). macOS ja Linux: avaa pääte ja anna komento sudo nano /etc/hosts. Molemmissa tarvitaan koneen ylläpito-oikeudet, koska tiedosto ohjaa koko koneen verkkoliikennettä.
2. Lisää rivit tiedoston loppuun Muoto on: IP-osoite, välilyönti, verkkotunnus. Esimerkiksi 203.0.113.10 yritys.fi — ja sen alle oma rivi www-versiolle: 203.0.113.10 www.yritys.fi. Www-versio on eri nimi ja vaatii oman rivinsä, muuten puolet linkeistä hyppää takaisin vanhalle palvelimelle kesken testin. Jos sivustolla on muita alaosoitteita, kuten kauppa.yritys.fi, lisää nekin.
3. Tallenna ja tyhjennä nimivälimuisti Kone muistaa vanhan vastauksen hetken. Windowsissa aja komentokehotteessa ipconfig /flushdns, macOS:ssä sudo dscacheutil -flushcache. Sulje sen jälkeen selain kokonaan ja avaa uusi yksityinen ikkuna — selaimella on oma välimuistinsa, joka ei välitä käyttöjärjestelmän komennoista.
4. Varmista että katsot oikeaa palvelinta Helpoin tarkistus: laita uudelle palvelimelle etusivulle hetkeksi jokin pieni näkyvä ero, vaikka yksi ylimääräinen merkki alatunnisteessa. Jos näet sen ja kollegasi ei näe, ohitus toimii. Poista merkki ennen julkaisua.
5. Poista rivit heti testin jälkeen Tämä on se kohta, joka unohtuu ja aiheuttaa eniten sekaannusta. Jos rivi jää tiedostoon, olet ainoa ihminen maailmassa, joka näkee sivuston oikein — ja siis ainoa, joka ei näe ongelmaa jos DNS-vaihto epäonnistuu. Poista rivit, tyhjennä nimivälimuisti uudestaan ja tarkista, että näet taas saman kuin muut.

Mitä testaat esikatselutilassa?

Kun hosts-rivi on paikallaan, selaimesi näyttää uuden palvelimen oikealla verkkotunnuksella. Käytä tämä tilaisuus kunnolla, koska se on ainoa hetki, jolloin voit rikkoa asioita ilman että kukaan huomaa. Testattavia kohtia on kuusi: etusivu ja kolme alasivua kuvineen, yhteydenottolomake oikealla viestillä, ostoskori ja maksuvaihe, kirjautuminen sekä asiakkaana että ylläpitäjänä, sivuston oma haku ja lopuksi https-varmenne. Ne kannattaa käydä läpi juuri tässä järjestyksessä, koska alkupään viat estävät loppupään testaamisen. Kirjaa jokainen löytynyt vika ylös, korjaa se uudella palvelimella ja toista kierros — kun kierros menee puhtaana läpi, siirto on käytännössä tehty. Kaikki kuusi kohtaa kannattaa testata myös puhelimella, koska osa vioista näkyy vain kapealla ruudulla.

• Etusivu ja kolme alasivua. Latautuvatko kuvat? Puuttuva kuva tarkoittaa yleensä, että tiedostoja jäi kopioimatta tai polku osoittaa vanhaan palvelimeen.
• Yhteydenottolomake. Lähetä oikea viesti ja tarkista, että se tulee perille. Lomakkeet lakkaavat toimimasta siirroissa useammin kuin mikään muu, koska ne lähettävät sähköpostia palvelimen kautta ja palvelin on nyt eri.
• Ostoskori ja maksuvaihe. Verkkokaupassa vie yksi tilaus maksusivulle asti. Maksunvälittäjän asetuksissa voi olla palvelinkohtainen rajaus.
• Kirjautuminen. Sekä asiakkaan että oma ylläpitokirjautumisesi. Jos kirjautuminen heittää takaisin sisäänkirjautumissivulle, syy on usein istuntoasetuksissa tai tiedosto-oikeuksissa.
• Haku ja sisäinen navigaatio. Sivuston oma haku käyttää tietokantaa. Jos se ei löydä mitään, tietokannan vienti jäi kesken.
• https-varmenne. Näkyykö lukko? Uudella palvelimella tarvitaan oma varmenne. Osa varmenteista voidaan myöntää vasta kun DNS osoittaa uuteen palvelimeen — silloin selain valittaa testin aikana, ja se on odotettua. Tarkista tässä tapauksessa vain, että sivu latautuu, ja tilaa varmenne heti DNS-vaihdon jälkeen.

Kirjaa jokainen löytynyt vika ylös ja korjaa se uudella palvelimella. Toista kierros. Kun kierros menee puhtaana läpi, siirto on käytännössä tehty — jäljellä on enää yksi asetusmuutos.

Miksi sähköposti on oma projektinsa?

Sivusto ja sähköposti näyttävät hallintapaneelissa saman palvelun osilta, mutta ne liikkuvat eri tietueilla ja eri tavalla: sivustoa ohjaa A-tietue ja sähköpostia MX-tietue. Sivustosta voi tehdä kopion ja jättää alkuperäisen paikalleen, jolloin molemmat toimivat rinnakkain. Sähköpostia ei voi kopioida samalla tavalla, koska uusia viestejä saapuu koko ajan ja jokainen niistä saapuu vain toiseen paikkaan — sinne, minne MX-tietue sillä hetkellä osoittaa. Juuri siitä katoavat viestit syntyvät, eikä katoamista huomaa mistään virheilmoituksesta. Siksi sähköposti siirretään omana operaationaan, mieluiten eri päivänä kuin sivusto, ja alla oleva viiden vaiheen järjestys on rakennettu niin, ettei yksikään viesti putoa väliin. Jos yrityksesi pyörii sähköpostin varassa, harkitse samalla, siirretäänkö posti ylipäätään webhotelliin vai erilliseen palveluun.

Siksi sähköposti siirretään omana operaationaan, mieluiten eri päivänä kuin sivusto:

1. Luo uudet laatikot ensin Tee uudelle palvelimelle täsmälleen samat osoitteet, alias-osoitteet ja edelleenohjaukset kuin vanhalla. Kirjoita salasanat talteen. Älä muuta vielä mitään tietuetta — laatikot vain seisovat tyhjinä ja odottavat.
2. Kopioi vanhat viestit IMAP-siirrolla Useimmissa hallintapaneeleissa on työkalu, joka kirjautuu vanhaan laatikkoon ja uuteen ja kopioi viestit kansiorakenteineen. Se kysyy vanhan palvelimen osoitteen ja tunnukset. Vaihtoehtoisesti lisää molemmat tilit samaan sähköpostiohjelmaan ja raahaa kansiot puolelta toiselle. Kopiointi ei poista mitään vanhasta laatikosta, joten sen voi ajaa monta kertaa.
3. Ota kaksoisvastaanotto käyttöön siirtoikkunaksi Ennen MX-muutosta laita vanhaan laatikkoon edelleenohjaus, joka kopioi saapuvat viestit myös uuteen osoitteeseen, ja säilyttää kopion vanhassa. Näin kumpaan tahansa palvelimeen viesti osuukin, se päätyy myös uuteen laatikkoon.
4. Vaihda MX-tietue viimeisenä Vasta kun laatikot ovat paikallaan, viestit kopioitu ja kaksoisvastaanotto päällä. MX-muutos leviää samalla viiveellä kuin muutkin tietueet, joten seuraavan vuorokauden ajan viestejä tulee molempiin paikkoihin. Se on odotettua, ei vika.
5. Aja IMAP-kopiointi vielä kerran Vuorokausi tai kaksi MX-muutoksen jälkeen aja sama kopiointi uudelleen. Se poimii siirtoikkunan aikana vanhaan laatikkoon jääneet viestit. Pidä vanha postilaatikko avoinna vielä pari viikkoa ja katso sitä silmämääräisesti läpi ennen kuin suljet tilin lopullisesti.

Jos yrityksesi pyörii sähköpostin varassa — tarjouspyynnöt, varaukset, laskut — kannattaa harkita, siirretäänkö posti ylipäätään toiseen webhotelliin vai erilliseen sähköpostipalveluun, jolloin se ei enää koskaan liiku sivuston mukana. Vertailu on kirjoitettu auki sivulla sähköposti yritykselle. Sama logiikka koskee muutakin toimittajavalintaa: mitä katsoa ennen kuin sitoudut, on käyty läpi artikkelissa webhotelli-vertailu.

Vasta sitten DNS — mitä sinä päivänä tapahtuu?

Kun sivusto on testattu ja hosts-rivi poistettu, itse vaihto on yksi muutos nimipalvelun hallinnassa: A-tietue osoittamaan uuteen IP-osoitteeseen. Se vie minuutin, ja se on koko projektin helpoin kohta juuri siksi, että kaikki työ on tehty etukäteen. Sinä päivänä tehdään kolme asiaa heti muutoksen jälkeen: tilataan uusi varmenne, jos se ei ollut aiemmin mahdollista, tarkistetaan sivuston latautuminen myös puhelimen mobiiliverkosta, joka käyttää eri nimipalvelua kuin toimistosi verkko, ja jätetään vanha palvelin päälle vähintään viikoksi. Vanhan sammuttaminen ei säästä mitään, mutta sen pitäminen pystyssä tarkoittaa, että viiveellä saapuvat kävijät näkevät toimivan sivuston. Varaa vaihtopäivälle pari tuntia omaa aikaa, vaikka itse muutos veisi minuutin.

Kolme asiaa hoidetaan heti sen jälkeen. Tilaa uusi varmenne, jos se ei ollut vielä mahdollista. Tarkista, että sivusto latautuu vielä normaalisti myös puhelimen mobiiliverkosta, joka käyttää eri nimipalvelua kuin toimistosi verkko — se on nopein tapa nähdä miltä muutos näyttää muualta. Ja jätä vanha palvelin päälle vähintään viikoksi. Sen sammuttaminen ei säästä mitään, mutta sen pitäminen pystyssä tarkoittaa, että viiveellä saapuvat kävijät näkevät toimivan sivuston vanhastakin osoitteesta.

Milloin webhotellia EI kannata vaihtaa?

Webhotellin vaihto on yllättävän usein hyvä työkalu väärään ongelmaan, ja neljässä tilanteessa se kannattaa jättää tekemättä. Ensimmäinen on käynnissä oleva kampanja tai sesonki, jolloin riskin ja hyödyn suhde on väärä. Toinen on tilanne, jossa vika onkin sivustossa eikä palvelimessa — liian isot kuvat, liikaa lisäosia tai raskas teema seuraavat mukana uuteen webhotelliin. Kolmas on se, ettet saa tunnuksia vanhaan hallintapaneeliin, jolloin siirto on arvonta eikä projekti. Neljäs on se, että ainoa syy on muutaman kympin vuosisäästö, joka ei kata puolen päivän työtä. Alla jokainen tilanne on avattu erikseen ja kerrottu, mitä kannattaa tehdä sen sijaan.

Kun kampanja on käynnissä. Jos sinulla on mainoskampanja, sesonki tai kausimyynti menossa, siirto tehdään vasta sen jälkeen. Riskin ja hyödyn suhde on väärä: parhaassakin tapauksessa säästät muutaman kympin vuodessa, huonoimmassa menetät kampanjan tuoton.

Kun vika onkin sivustossa eikä palvelimessa. Hidas sivusto johtuu useimmiten liian isoista kuvista, liiasta määrästä lisäosia tai raskaasta teemasta. Kaikki nämä seuraavat mukana uuteen webhotelliin. Testaa sivuston nopeus ensin, korjaa kuvat, ja katso vasta sitten onko palvelin oikeasti pullonkaula. Jos hitaus on samanlainen vuorokaudenajasta riippumatta, vika on lähes varmasti sivustossa.

Kun et saa tunnuksia vanhaan hallintapaneeliin. Ilman pääsyä et saa ulos tietokantaa, .htaccess-tiedostoa etkä sähköposteja. Hanki tunnukset ensin — sivuston tehneeltä toimistolta, entiseltä työntekijältä, tai toimittajan tuen kautta yrityksen nimissä. Vasta kun ne ovat kädessä, siirto on projekti eikä arvonta.

Kun ainoa syy on muutama kymppi vuodessa. Siirtoon menee huolella tehtynä puoli päivää. Jos säästö on kolmekymmentä euroa vuodessa, laske oma tuntihintasi ja katso onko kauppa kannattava. Jos syy sen sijaan on toistuvat katkot, puuttuva tuki tai vanha PHP-versio, jota ei suostuta päivittämään, vaihto maksaa itsensä takaisin heti.

Kuka tämän tekee?

Kaikki edellä kuvattu on tehtävissä itse, jos osaat käyttää FTP-ohjelmaa ja uskallat avata tietokantatyökalun. Puoli päivää on realistinen arvio tavalliselle yrityssivustolle silloin, kun mitään ei mene pieleen, ja kokonainen päivä silloin, kun jokin menee — ja jokin menee tyypillisesti sähköpostissa tai ohjelmistoversioissa. Ennen kuin päätät tehdä siirron itse, katso kaksi asiaa: saatko tunnukset vanhaan hallintapaneeliin ja onko sinulla puolen päivän yhtäjaksoinen aika, jota ei tarvitse keskeyttää. Jos molempiin on kyllä, tämän sivun ohje riittää alusta loppuun. Jos ei, siirto kannattaa ostaa tai siirtää rauhallisempaan hetkeen. Kummassakin tapauksessa tunnukset uuteen palvelimeen kuuluvat sinulle, ei siirron tekijälle.

Jos et halua käyttää päivääsi tähän, teemme siirron avaimet käteen: kopio, testaus hosts-tiedostolla, sähköpostit, DNS ja varmenteet. Saat samalla listan siitä, mitä uudella palvelimella pitää jatkossa itse seurata, ja tunnukset jäävät sinulle. Työn hinta lukee hinnastossa, ja jos siirron yhteydessä on tarkoitus uudistaa itse sivusto, se kannattaa katsoa yhtenä pakettina — verkkosivut yritykselle kertoo mitä siihen kuuluu.

Usein kysyttyä

Lue seuraavaksi

• Verkkosivujen vaihto toimittajalta toiselle — mitä otat mukaan ja miten pyydät sen
• Webhotellin hinta nousee ensimmäisen vuoden jälkeen — dokumentoitu hintahistoria ja viiden vuoden laskelma
• Yrityssovelluksen kehittämisen hinta
• WordPress-ylläpidon hinta ja mitä siihen oikeasti kuuluu
• WordPressin hakukoneoptimointi: neljä asetusta, jotka ratkaisevat teknisen puolen

Lue myös: Sähköpostin perillemenon korjaus · Uutiskirjepalvelu pienyritykselle · kanta-asiakassovellus yritykselle · QR-koodi generaattori · yhteystiedot · blogi · hinnasto · kassajärjestelmä ravintolaan