'Valmis' veebisait on müüt: veena oma ülemust hoolduse vajalikkuses

Kokkuvõte

Enamik väikeseid turundusmeeskondi peab käivitamist finišijooneks, kuid elav veebisait on korduv vastutus: domeenid vajavad uuendamist, veebimajutus vajab tasumist, tarkvara vajab paikamist ja sisu vajab uuendamist. Mitte-tehnilisele ülemusele esitatud ettepanek ebaõnnestub, kui see on raamistatud kui 'rohkem veebitööd', ja õnnestub, kui see on raamistatud kui tulu ja maine kaitsmine. See artikkel selgitab tegelikku rikkerežiimi — saiti, mis laguneb vaikselt pärast käivitamist — ja loob praktilise põhjenduse hoolduse eelarvele, kasutades konkreetseid näiteid domeeni registreerimise, turvalisuse ja otsingunähtavuse kohta. See hõlmab vaimset nihet projektilt süsteemile, konkreetseid ülesandeid, mis peavad toimuma pärast käivitamist, ja vestlust, mis tegelikult ülemust veenab. Samuti saate teada, miks turvaargument ei peaks alustama häkkeritest ja kuidas siduda hooldus äritulemustega, mitte tehniliste tööülesannetega.

Sinu ülemus kuulutas just veebisaidi 'valmis' — miks see sõna kõhtu keerab?

Sa oled seda varem kogenud. Käivitasite neli nädalat tagasi ja kõrged viied on vaevu vaibunud. Siis saabub esimene muudatusettepanek (hinnalehel on trükiviga). Siis küsib müügimees, kas keegi kontrollis, miks sait Google'ist kadus. Siis annab su paroolihaldur teada tundmatust sisselogimisest. Miski pole katastroofiliselt katki, ja just see ongi probleem: sait laguneb sajal väikesel viisil ning su ülemus usub endiselt, et projekt on läbi, sest keegi pole talle öelnud, et elav sait nõuab pidevat tööd.

See on tegelik lünk. Veebisaidi loomise juhendid hõlmavad tavaliselt planeerimist, infoarhitektuuri, traatmudelite koostamist, disaini, sisu, arendust, testimist ja käivitamist. See on sama lünk, mis paneb inimesi vahele jätma planeerimisetapi, mille enamik uusi veebisaidi omanikke vahele jätab, välja arvatud seekord on see samm pärast käivitamist. Hooldus on üheksas, nähtamatu etapp, ja see on see, mis määrab, kas teie sait jääb varaks või muutub aeglaselt kohustuseks.

Selle lünga hind on nähtamatu, kuni see pole: domeen, mis aegub toote käivitamise ajal, varukoopia, mis vaikselt ebaõnnestub nädal enne ümberkujundust, vorm, mis pole kuu aega midagi kogunud. Ükski neist pole dramaatiline. Kõik need on kallid.

Ehitusrežiim ja elav režiim on erinevad tööd

Mõelge oma veebisaidile nagu varale, mida haldate. Hoone ehitamine on projekt; selle haldamine on protsess. Te ei ehitaks ladu ja siis kunagi ei kontrolliks katust, ei telliks uuesti laovarusid ega vahetaks lukke, kui töötaja lahkub. Veebisait käitub samamoodi, kuid projekti/protsessi eristus kaob, sest ehitusmaterjalid on digitaalsed ja kulud on väikesed.

See eristus on oluline ühel põhjusel: see muudab seda, mida teie ülemus heaks kiidab. Ehitusrežiimis on eesmärk 'tee see reaalseks'. Elavas režiimis on eesmärk 'hoia see usaldusväärsena'. Allolev tabel on versioon, mida kasutan mitte-tehniliste sidusrühmadega, sest see kaardistab iga asja, mis tundub 'valmis', sellega, mida see tegelikult tähendab, kui sait on elus.

Valdkond	Mida ülemus arvab, et 'valmis' tähendab	Mida 'valmis' tegelikult tähendab
Domeen	Ostsime aadressi, nii et see on meie oma	Aadress on registreeritud teatud perioodiks; ICANNi protsessi kirjelduse kohaselt valite nime, kontrollite saadavust registripidaja kaudu ja esitate kontaktandmed. Need andmed määravad, kes saab uuendusteateid, nii et need peavad olema õiged ja jälgitud
Veebimajutus	Failid on kuskil internetis	IBM määratleb veebimajutuse kui teie saidi failide salvestamise serveris interneti kättesaadavuse tagamiseks. See server on korduv suhe kuluga, ja keegi peab teadma, kuidas sinna sisse logida
Tarkvara	Käivitasime uusima versiooniga	Tarkvara saab paikad, pluginad uuendatakse ja integratsioonid vajavad ülevaatamist. Kõik see toimub pärast käivitamist, mitte enne
Sisu	Tekst kiideti heaks	Sisu on vestlus teie turuga. See muutub vananenuks, kui pakkumised, hinnad, tõenduspunktid ja tootenimed muutuvad
Otsing	Google teab, et me eksisteerime	Otsingumootoreid tuleb uuesti külastada; XML-kaartidele tuleb lisada uusi URL-e, robots.txt-failid peavad jääma täpseks ja tehniline alus peab püsima tervena

Seda tabelit saab lugeda kahel viisil. Tööülesannete loeteluna on see ülekaalukas. Kirjeldusena sellest, mis teie veebisait tegelikult on — süsteem, mille sisendeid te kontrollite — on see selgitav. Teie ülemus ei eksi, kui tahab lõpetatust. Nad eksivad selles, kuidas lõpetatus välja näeb.

Siin on ka no-code hoiatus. Kui teie sait ehitati lohistamise teel ehitajaga, haldab platvormi müüja serverikoodi, kuid teie sisu, juurdepääs ja integratsioonid vajavad siiski hooldust. No-code eemaldab palju ehitusetööd; see ei eemalda elava režiimi tööd.

Muutke hooldus kalendriks, mitte hirmulooks

Nii et kust alustada? Mitte dramaatilise turvaesitlusega. Alustage kõige konkreetsema, kõige vähem emotsionaalse korduva ülesandega ja looge selle ümber kalender.

Võtke domeen. Kujutage ette, et asutaja registreeris selle viis aastat tagasi isikliku e-posti aadressiga. Registripidaja juhtpaneel on sisselogimise taga, mida teab ainult üks inimene. ICANNi domeeni registreerimisprotsess algab nime valimisega, saadavuse kontrollimisega registripidaja kaudu ja kontaktteabe esitamisega — ja see kontaktteave on nöör, mis ühendab registripidajat päris inimesega. Kui kontakti e-posti ei jälgita, võib uuendusteatis sattuda postkasti, mida keegi ei loe. Lahendus pole tehniline ümberkorraldus; see on tabelirida, ühine postkast ja kalendrimeeldetuletus kolm nädalat enne uuendamist. See on igav. Just sellepärast on see täiuslik esimene punkt: see tõestab, et hooldus koosneb väikestest, juhitavatest ülesannetest.

Nüüd tehke veebimajutus. IBMi selgitus teeb selle lihtsaks — teie failid elavad serveris — kuid igal serveril on salvestusmahud, ribalaiuse kulud ja mandaadid. Kui veebimajutuse seadistanud inimene on sama, kes domeeni seadistas, ja see inimene lahkus kuus kuud tagasi, olete ühe sisselogimise kaugusel sellest, et olete oma saidist välja lukustatud. Hoolduslahendus on viia iga teenus ühte dokumenti, märkida, kellel on juurdepääs, ja planeerida iga-aastane audit. Te ei küsi suurt eelarvet. Te küsite tund aega kuus, et hoida uksi lukust lahti.

Sama loogika kehtib kõigi teenuste puhul, millest sõltute: meililistid, maksetöötlejad, vormitööriistad. Igal neist on sisselogimine, arveldustsükkel ja keegi, kes peaks suutma selle taastada, kui algne omanik lahkub. Pange need kõik ühte tabelisse. Kalendriga alustamise ilu on see, et see möödab vana 'see on tehniline probleem' vastuväite. Uuenduste ja juurdepääsu ülevaatuste kalender on projektijuhtimise probleem ja iga mitte-tehniline ülemus mõistab projektijuhtimist.

Oht, mis pole häkker

Turvavestlus ebaõnnestub tavaliselt, sest see algab vale kurjategijaga. 'Me oleme väike turundussait,' ütlete endale. 'Keegi meid ei sihi.' Ja teil on ilmselt õigus — kuid kõige tõenäolisem oht pole sihitud häkker. See on hooletus.

UpGuardi veebiturvalisuse juhend loetleb tavalised meetmed: hoidke tarkvara ajakohasena, rakendage tugevat autentimist nagu mitmeastmeline autentimine, piirake kasutajaõigusi, varundage andmeid ja kasutage SSL/TLS-krüptimist. Mida iganes sellest loendist märkate, on oluline osa tegusõna aeg. Need on pidevad tavad, mitte käivitamispäeva märkeruudud.

Teeme selle konkreetseks. Paljud sise meeskonnad päravad saidi, millel on üks jagatud administraatori sisselogimine, mida kasutavad kõik: müügimeeskond, turunduspraktikant, vabakutseline, kes kirjutas ühe ajaveebipostituse. Keegi ei tea, kes see vabakutseline oli. UpGuard nimetaks seda kasutajaõiguste probleemiks; võite seda nimetada riskiks, mida teie ülemus juba mõistab. Kui te ei tea, kes saab sisse logida, ei tea te, kes saab avalehte redigeerida, hindu muuta või installida midagi, mida seal ei peaks olema. Lahendus on lihtne: lähtestage paroolid, looge individuaalsed kontod ja eemaldage juurdepääs, kui inimesed lahkuvad. See pole turvaprojekt; see on turvatöö.

Teen vastupidise ettepaneku: ärge alustage turvalisusest, kui taotlete eelarvet. Väikese meeskonna jaoks käivitab sõna 'turvalisus' kas 'meil pole IT-eelarvet' või 'see ei juhtu meiega'. Mis käivitab tegutsemise, on konkreetne lähedane õnnetus: brauseri hoiatus, kuna SSL/TLS-sertifikaat aegus, varukoopia, mis kunagi ei käinud, endine töövõtja, kes saab endiselt sisse logida. Kasutage neid konkreetseid punkte, et luua põhjendus igakuisele 'saidi tervise' plokile. Te ei müü hirmu; te müüte pädevust.

Ja kui ehitate praegu uut saiti, oleme käsitlenud no-code saidi käivitamist SEO ja turvalisusega esimesest päevast mujal — kuid esimese päeva distsipliin tasub end ära ainult siis, kui sellest saab kaheteistkümnenda kuu distsipliin.

Otsing ei oota sind

Teine põhjus, miks sait laguneb, on vaiksem, sest see toimub saidist väljaspool. Otsingumootori optimeerimine pole ühekordne seadistamine. Digital Marketing Institute'i juhend kirjeldab SEO-d kui sisu, struktuuri ja tehniliste elementide optimeerimist, et parandada otsingureitinguid, kasutajakogemust ja brändi usaldusväärsust. Sõna 'optimeerimine' tähendab muutumist aja jooksul, mitte lõpetatud olekut.

Realistlik stsenaarium: teie müügijuht küsib, miks konkurent edestab teid teie enda tootenime otsingus. Uurite ja avastate, et XML-kaarti pole pärast käivitamist uuendatud ja robots.txt-fail blokeerib osa uutest lehtedest. Need on mõlemad tehnilised seadistusülesanded, mis tundusid esimesel päeval tehtud. Lahendus on kümne minuti pikkune igakuine ülevaade: lisage saidikaardile uued URL-id, esitage see uuesti ja kontrollige, et robots-fail ei peidaks teie parimat sisu. SEO juhiste uurimine osutab ka HTTPS-turvalisusele kui tehnilise aluse osale — mis viib otse tagasi turvatööde juurde, mille just planeerisite.

Kõige hullem otsingulagunemise juures on see, et see on progresseeruv. Te kaotate harva reitinguid ühe päevaga; kaotate positsiooni siin ja positsiooni seal, kuni konkurent on lehe koha täielikult üle võtnud. Otsing on ka parim äriargument hoolduseks, sest see on otseselt seotud tuluga. Sait, mis ei hoolda oma otsinguinfrastruktuuri, ei kao dramaatilise 'häki' tõttu; see annab vaikselt kliendid konkurentidele, kes hoiavad oma tehnilise maja korras.

Hoolduse müümine inimesele, kes allkirjastab tšekid

See toob meid vestluseni, mida olete vältinud. Peate küsima eelarvet või vähemalt ruumi meeskonna kalendris ja peate, et ülemus ütleks jah ilma pilke ümber pööramata.

Alustage tulu kaitsmisest. Ärge öelge 'meil on tehniline võlg' või 'peame oma CMS-i uuendama'. Öelge 'sait on kaupluse fassaad ja fassaadid vajavad regulaarset hooldust'. Kasutage varem loodud hoolduskalendrit tõendusmaterjalina: siin on uuendamiskuupäevad, siin on juurdepääsuülevaated, siin on varukoopia test, mida teeme iga kuu. Ülemuselt ei paluta teile usaldada; talle näidatakse süsteemi, mis juba töötab.

Seejärel andke talle valik. Esitage kaks või kolm taset: minimaalne hooldus (domeen, veebimajutus, varukoopiad, SSL), tervislik hooldus (lisage sisu uuendused ja otsingukontrollid) ja aktiivne kasv (lisage katsed, sihtlehed ja pühendatud tugi). Kui raamite otsuse kui 'millist usaldusväärsuse taset soovite?' mitte 'kas saame rohkem raha kulutada?', valib ülemus tulemuse, mitte ei kiida heaks tehnilist kulutust.

Üks hoiatus: ülemus võib ikkagi öelda ei. Kui see juhtub, võtke kaks peamist riski — tavaliselt juurdepääsukontroll ja varukoopia kinnitamine — ja parandage need ikkagi oma vabal ajal. Te ei eira seda 'ei'; ostate aega, et näidata, et hooldus teeb mõõdetava vahe. See on sama loogika, mis on kliendisaidi hoolduse küpsusmudeli taga, isegi kui teie 'klient' on teie enda sisemine sidusrühm. Mudel viib saidi tulekahjudest raamistikeni ja see töötab kaheliikmelises turundusmeeskonnas sama hästi kui agentuuris.

Valmis veebisaiti pole olemas

Veebisait, mille käivitasite, pole see, mida halddate. See muutub, sest teie äri muutub, tarkvara muutub ja veeb ise muutub. Ainus tõeline küsimus on, kas haldute seda muutust tahtlikult, väikese eelarve ja kalendriga, või juhuslikult, paanikaseeriana.

Alustage kõige väiksemast konkreetsest asjast: üks kalendrimeeldetuletus, üks ühine postkast, üks kontode audit. Need ebaglamuursed ülesanded pole lisakulud. Need hoiavad saiti, mille ehitamiseks nii palju vaeva nägite, vaikselt roostetamast kapoti all. Kui teie ülemus küsib, mis edasi saab, naeratage ja näidake talle kalendrit. See on saidi tegelik pidev töö.