Ha Ön (vagy talán ezen a ponton voltál) GoDaddy ügyfélnek ezen a héten, az élet szopogatott neked, mert webhelye nem működik. Igen, biztos, hogy ingyenes havi jóváírást kapott a leállásokra, de lényeg az, hogy webhelyed nem számol be, és nem volt átkozott dolgod, amit tehetnél.
Vagy ott volt?
A legtöbb üzleti vállalkozást működtető kisvállalkozónak nincs DRP (katasztrófa utáni helyreállítási terv). Azt gondolná, hogy ha vállalkozást működtet, terméket értékesít, és attól függ , hogy webhelyén marad-e fel, akkor van valami készen arra, ha leesik. Nos, egy csomó embernek nem volt ilyen DRP-je, és amikor a webhelyük lement, csak annyit tehettek, hogy ülnek ki és várnak. És mint minden üzleti tulajdonos tudja, az idő pénz.
Néhány dolgot megtehetsz DRP célokra, ha most üzleti webhelyet futtat. Ezek közül néhány egyszerű, mások nem.
1. Ismeri az internetes házigazda Twitter-fiókját?
Ha a webes házigazda csökken, akkor a jobb web-szolgáltatók a Twitter-fiókjukon értesítik róla, mert a webhely leállásakor nincs mód arra, hogy egyébként figyelmeztessék az ügyfélkört.
Ha bármilyen probléma merül fel a webhelyén, és nem tudja feltölteni saját webhelyének webhelyét, lépjen a Twitter-fiókjába.
Példa: Személyes blogomban a Fluid Hosting szolgáltatást használom, és Twitter-fiókomat könyvjelzővel látom el. Mint minden internetes fogadó szolgáltatónál, néha előfordulnak áramkimaradások. Ha a webhelyem teljesítménye lassú, akkor még a támogatási jegy benyújtása előtt megyek erre a Twitter-fiókra, mert ha valami rendszerszintű a végén, akkor ott hirdetik meg, és egy óra múlva tudom, hogy megoldódik, így a jegy benyújtására nincs szükség.
2. Van Twitter-fiókod?
Szereted vagy gyűlöled a Twitter-et. Ez egy nagyszerű módja annak, hogy figyelmeztesse a tömeget, ha az Ön webhelyén problémák merülnek fel, mert a webhelyétől függetlenül működik. Ez azt jelenti, hogy még ha webhelye nem működik, a Twitter működik, és ott hirdetéseket tehet. Hé, jobb, mint semmi.
3. Általános szabály, hogy a webhely tárolása a regisztrált domainjének ugyanabban a helyén rossz ötlet.
Ha úgy mondjuk, hogy „összes tojását egy kosárba helyezi”, ez egy katasztrófa receptje az üzleti webhely tárhelyét illetően. A domain regisztrátornak és a webhelyének házigazdának külön kell lennie, különben sorban állsz egy kieső dominóhatással (az egyik rész lemegy, minden leesik).
Adok egy példát, hogy miért fontos ez a szétválasztás.
Ha a személyes blogom csökkent, és úgy értem, hogy olyan rosszra estem, hogy néhány napba telik, amíg az online visszatér, be tudok jelentkezni a domain regisztrátoromba, és a domaint átmeneti oldalra , például egy Twitter-fiókra mutathatom, míg az elsődleges a webhely feljavul. A javítás után visszaválthatom.
4. Mindig jó, ha DRP célokra biztonsági másolatú e-mail címet használunk egy ingyenes webmail szolgáltatónál.
A megfelelő üzleti tevékenységet olyan e-mail címekkel végzik, mint például a _business_site.com, de ha webhelye nem működik, akkor az e-mail szintén nem működik.
Sürgősségi célokra elegendő lehet egy Gmail vagy Hotmail, vagy bárhol másutt tárolt e-mail fiók, amíg az elsődleges e-mail biztonsági másolatot nem készít.
Ezt az e-mail címet a vállalkozás Twitter-fiókjában is továbbíthatja, ha erre szüksége van.
A Gmail itt a legjobb megoldás, mivel miután az elsődleges e-mail biztonsági másolatot készített, bejelentkezhet Gmail-fiókjába, és továbbíthatja az összes e-mailt az elsődleges címre, hogy ne maradjon ki egyetlen üzenet sem. Más szolgáltatók (mint például a Hotmail) hasonló funkciókat kínálnak, de a Gmail a legnagyobb mértékben tudja ellenőrizni, hogy hová megy az Ön levele, és hogyan jut el oda.
5. Tudnia kell, hogyan kell „átugorni a hajót”, ha feltétlenül szükséges.
Mint én (vagy Dave) megmondhatom, egy másik domain-regisztrátorra és / vagy internetes házigazdara váltás óriási fájdalmat jelent a seggbe. Nincs egyszerű módja annak, hogy bárki is mondja neked. De ez nem jelenti azt, hogy nem kellene megtanulnia, hogyan kell csinálni.
Váltás az egyik domainregisztrátorról a másikra (például a GoDaddyről a NameCheapre) nem ugyanazon a napon zajlik, és hozzávetőleg három-tíz munkanapot vesz igénybe a folyamat befejezése.
Váltás egyik internetes gazdagépről a másikra. Hoo fiú, igen, ez az igazán nehéz rész. Valószínűleg igaz, hogy a meglévő webhely olyan tartalommotort futtat, mint a WordPress vagy a Drupal, ahol az egész MySQL adatbázis-háttérrel működik, nagyon specifikus szervercímeket és portokat használva, és maga a motor nagyon specifikus szerverútvonalakat használ. Ha mindez megijeszti a pokolból, akkor kell.
Noha Dave és én tudjuk, hogyan mozgathatjuk azokat a webhelyeket, ahol minden helyesen migrálódik (csak azért, mert mindkettőnk 1990-es évek vége óta végez webhely-adminisztrációt, és nagyjából meg kellett tanulnunk az old-school módszert), valószínűleg nem t. Csak azt mondhatom, hogy nem zárjuk ki, hogy fizetni fogunk valakinek azért, hogy helyesen mozgassa az Ön webhelyét. Érdemes költeni a pénzt egy megfelelő migráció végrehajtására az egyik helyről a másikra.
Ha most üzleti helyet működtet, remélem, hogy soha nem kell ténylegesen mozgatnia a dolgot, mert az nem csinos. DRP célokból azonban, ha a hajókat a regisztrátorok és / vagy a házigazdák között kell átugornia, akkor is megtanulhatja, hogyan vándoroljon át, vagy tudja, hogyan kell valakit megtalálni az Ön számára. Ez a cucc egyáltalán nem olyan, mintha otthoni vagy laptopján lévő fájlokkal dolgozna, ahol egyszerűen másolja a dolgokat az egyik helyről a másikra, és minden más jól működik. A dinamikus szinten működő tartalommotorokat használó webhelyek teljesen különböző labdajátékok.
Ha komolyan veszi vállalkozását, akkor komolyan kell vennie a webhely DRP-jét
A legtöbb kisvállalkozás-tulajdonos nem tanul semmit a DRP fontosságáról, amíg nem történik valami rossz, például mi történt egy egész tonna GoDaddy ügyféllel.
Önnek, mint az üzleti webhely tulajdonosának, kell lennie valamire , amire visszatérhet, még akkor is, ha ez csak egy Twitter-fiók és egy Gmail e-mail cím. Az önmaga által üzemeltetett webhelyek mindig Murphy törvényének hatálya alá tartoznak, ezért fel kell készülnie erre.
