Ylläpidon laajuus kannattaa suhteuttaa kaupan riippuvuuksiin ja siihen, mitä häiriö käytännössä aiheuttaa. Yksinkertainen tuotemyynti ja useaan järjestelmään integroitu kauppa tarvitsevat erilaisen tarkistuksen. Tässä oppaassa kerromme, mitä ylläpidosta pitää sopia ja miten päivitys, varmistus sekä palautuminen muodostavat hallitun kokonaisuuden.
Tunnista kaupan kriittiset toiminnot
Aloita kuvaamalla tilauksen kulku tuotteen valinnasta toimitukseen. Mitkä osat ovat WooCommercessa ja mitkä maksu-, varasto-, kuljetus- tai taloushallintopalvelussa? Jokainen rajapinta on myös paikka, jossa tieto voi viivästyä tai jäädä siirtymättä. Vastuun pitää ulottua siihen asti, että tilaus löytyy käsittelystä oikeilla tiedoilla.
Kauppakohtaisia erityistapauksia voivat olla asiakaskohtaiset hinnat, alennuskoodit, nouto, osatoimitukset, tilausmaksut tai useat kieliversiot. Ylläpitäjän on tunnettava nämä ennen muutoksia. Muuten testaus kohdistuu helposti vain tavalliseen ostoskoriin ja tärkeä poikkeus jää huomaamatta.
Kirjaa myös se, mistä yrittäjä huomaa häiriön. Kassavirhe voi näkyä heti, mutta epäonnistunut taustasiirto vasta pakkaamossa seuraavana aamuna. Siksi teknisten virheiden lisäksi tarvitaan käytännön tarkistus siitä, syntyykö tilauksesta oikea jatkotoimenpide.
Päivitys alkaa valmistelusta
Selvitä päivitettävät osat ja niiden riippuvuudet. WooCommerce, teema, lisäosat ja palvelinympäristö muodostavat yhdessä toimivan kokonaisuuden. Erityisesti maksamiseen, kassaan ja tuotetietoon vaikuttava muutos tarvitsee tarkemman arvioinnin kuin näkyvän tekstivirheen korjaus.
WooCommercen oma päivitysohje käsittelee varmuuskopiointia ja muutosten kokeilemista testiympäristössä ennen tuotantopäivitystä. Kaupan ylläpidossa näiden periaatteiden rinnalle tarvitaan omaan tilausprosessiin sovitettu hyväksyntä. WooCommercen päivitysohje.
Valitse muutokselle sopiva ajankohta ja vastuuhenkilö. Tärkeä tietoturvakorjaus ei voi aina odottaa seuraavaa rauhallista kautta, mutta kiireessäkin pitää tietää, mitä muutetaan ja miten tulos varmistetaan. Kaikkia ongelmia ei ratkaista lykkäämällä päivityksiä, eikä kaikkea kannata päivittää sokkona yhdellä kertaa.
Testiympäristö ei saa toimia oikeana kauppana
Testikopiossa pitää estää oikeiden maksujen veloittaminen, asiakkaiden sähköpostit ja tilausten siirtyminen oikeaan varastoon. Myös ajastetut toiminnot ja ulkoiset yhteydet tarvitsevat rajauksen. Pelkkä eri verkko-osoite ei tee kopiosta turvallista testipaikkaa.
Käytä maksupalvelun tähän tarkoitukseen tarjoamaa testitapaa ja sovittua testiaineistoa. Oikean asiakkaan tilauksen kopioiminen testiin tuo mukaan henkilötietoja, joten aineiston käsittely ja käyttöoikeudet pitää miettiä. Kaikkea tuotantotietoa ei tarvita käyttöliittymän tai kassapolun varmistamiseen.
Kun muutos on testattu, tuotantoon siirretään sovittu muutos. Tuotannon koko tietokantaa ei korvata vanhalla testikopiolla vain siksi, että ulkoasu näyttää siinä oikealta. Väliin tulleet tilaukset ja asiakkaiden muutokset pitää säilyttää.
Varmuuskopio ja palautussuunnitelma ovat eri asioita
Varmuuskopio kertoo, että tietystä hetkestä on kopio. Palautussuunnitelma kertoo, miten kauppa saadaan takaisin toimintaan ja mitä kopion jälkeen syntyneille tapahtumille tehdään. Verkkokaupassa ero on ratkaiseva, koska uusia tilauksia voi tulla jatkuvasti.
Jos eilen otettu tietokanta palautetaan tänään, kaupan näkymä voi unohtaa aamulla tehdyn tilauksen, vaikka maksu olisi jo tapahtunut maksupalvelussa. Siksi palautuksessa pitää huomioida tilaukset, maksut, varastosiirrot ja asiakasviestit yhdessä. Tarvittaessa rajataan ensin myynti ja selvitetään tapahtumien tila ennen palauttamista.
Määrittele hyväksyttävä tietokatko ja tavoiteltu palautumisaika oman liiketoiminnan mukaan. Älä oleta, että hostingin varmistus sisältää automaattisesti kaiken tarvittavan tai että sitä on kokeiltu palauttaa. Säilytysaika, palautuksen tilaaminen ja tarkistuksen vastuu kuuluvat ylläpitosopimuksen käytännön sisältöön.
Mitä päivityksen jälkeen tarkistetaan?
Avaa kauppa tavallisella asiakkaan laitteella ja käy sovittu polku läpi. Tarkista tuotteen vaihtoehdot, hinta, ostoskori, toimitus, maksun käsittely ja tilauksen löytyminen hallinnasta. Jos kaupassa on yritysasiakashintoja tai kieliversioita, varmista myös ne. Pelkkä etusivun avautuminen ei todista myynnin toimivuutta.
Tarkista tapahtuman molemmat puolet. Asiakkaalle näkyvä onnistumisilmoitus ja järjestelmään kirjautunut onnistunut tilaus eivät aina ole sama asia. Samoin integraation lähettämä viesti pitää nähdä vastaanottavassa järjestelmässä ennen kuin sen toimivuus voidaan todeta.
Sovittu testaus ei tarkoita turhien oikeiden tilausten tekemistä. Tuotannossa käytettävä varmistustapa sovitaan etukäteen, jotta siitä ei synny tahattomia maksuja, toimituksia tai asiakkaiden viestejä. Ylläpitoraportti kertoo, mitä oikeasti tarkistettiin ja jäikö jokin ulkoisen palvelun vuoksi varmistamatta.
Esimerkki: maksamiseen liittyvä päivitys
Kuvitteellisessa kaupassa maksulisäosasta tulee uusi versio. Muutos kokeillaan ensin rajatussa testiympäristössä. Onnistuneen maksun lisäksi testataan asiakkaan keskeyttämä maksu ja tapaus, jossa maksun vahvistus saapuu viiveellä. Tavoitteena on, ettei sama tilaus lähde kahdesti käsittelyyn eikä keskeneräinen maksu näytä valmiilta ostokselta.
Tuotantopäivityksen jälkeen tarkistetaan sovittu turvallinen polku ja seurataan ensimmäisten oikeiden tilausten teknistä kulkua ilman niiden sisältöön tarpeettomasti puuttumista. Jos häiriö havaitaan, vastuuhenkilö tietää, rajataanko maksutapa, palautetaanko ohjelmistomuutos vai selvitetäänkö ulkoisen palvelun tilanne. Esimerkki havainnollistaa toimintamallia, ei tietyn lisäosan ominaisuuksia.
Ylläpito, korjaus ja kehitys kannattaa erottaa
Ylläpito pitää sovitun kokonaisuuden toimintakunnossa. Uusi integraatio, kassauudistus tai valikoiman rakennemuutos on kehitystyötä. Häiriön selvitys voi puolestaan paljastaa vanhan räätälöinnin, joka tarvitsee erillisen korjauksen. Näiden rajojen pitää olla ymmärrettäviä ilman teknistä sanastoa.
Sopikaa, kuka ottaa häiriöilmoituksen vastaan, milloin sitä käsitellään ja kuka päättää myyntiin vaikuttavista toimista. Ilmaus "ylläpito kuuluu hintaan" ei vielä kerro palveluaikaa, korjausten laajuutta tai ulkoisten palvelujen vastuuta. WooCommerce-toteutuksen yhteydessä nämä asiat on helpointa määritellä ennen julkaisua.
Jos ongelmat toistuvat samassa vanhassa kassassa tai lisäosaketjussa, pelkkä ylläpito ei välttämättä riitä. Silloin verkkokaupan uudistus voi olla perusteltu, kunhan ongelma ja uuden ratkaisun hyöty voidaan osoittaa. Kehitys kannattaa kohdistaa havaittuun pullonkaulaan.