Wanneer die Wolk Trips
Herstel wanneer Google Apps versuim om die Enterprise
Dit is 'n storie oor IT, die wolk en die hele groot en vreeslike dinge wat gebeur wanneer die twee bymekaar kom. In many ways cloud computing and Software as a Service (SaaS) is 'n seën vir onvoldoende, oorwerkte Inligtingstegnologie departemente wat verwag word om te red en die beste tegnologie te bied met 100% uptime en geen begroting. With the emergence of web enabled services from major vendors like Amazon, Microsoft, and Google the age old question posed to IT professionals — is dit gratis - Kan uiteindelik beantwoord word met 'n klinkende yes! (Ten minste vir die basiese weergawe).
Maar soos met baie van ons oupas en oumas het al voorheen gesê, ervaring het geleer dat die ou spreekwoord bly: jy kry wat jy betaal vir. Seker, die diens kan wees vry, maar met geen service level agreement (SLA) daar is geen beroep wanneer daar 'n e-pos onderbreking, soos die 6 ons meer kragonderbrekings wat geraak Google Mail in 2009. But worry not end users! Daar is betaal upgrades beskikbaar wat insluit 'n SLA waarborg 99.9% uptime sowel as telefoon-en e-pos ondersteuning vir kritieke probleme. At $50 per gebruiker per jaar dit klink soos 'n steel!
Wat presies doen wat hulle bedoel met uptime en kritiese?
Dit lyk al baie op papier; daar is geen behoefte fisiese hardeware bates in stand te hou, geen IT-werknemers te betaal, en die koste is minder as lisensiëring alleen vir die meeste selfstandige oplossings! Ongelukkig, hierdie bemarking waarborg lyk soos vaporware wanneer die data treffers die router.
Te illustreer die tekortkominge in die wolke, Kom ons gebruik 'n werklike voorbeeld. 'N nie-winsgewende klante ons sal bel "Charity X" wou oorhoofse verminder en dienste vir hul personeel. Na meer as 'n dekade van die hantering van e-pos en dienste intern, het hulle besluit dit is tyd om te skuif na die wolk. Fortunately for them, as 'n nie-winsgewende instansie wat hulle gekwalifiseer het vir die nie-winsgewende uitgawe van google apps. Groot!
Hier is die voordele wat hulle gesoek:
Ons kan ons bandwydte gebruik verminder deur nie die hantering van e-pos onsself
Ons bediener hulpbronne sal aan vrygestel gaan word en kan gebruik word vir ander doeleindes
Ons kan 'n beter webmail vir ons mense.
Ons kry toegang tot gedeelde hulpbronne soos kontak bestuur en dokumente wat 'in die wolke'
Die werklikheid egter is dat hierdie verandering is nie so eenvoudig soos hulle verwag het. Dit was nie 'n saak van Klik migreer gebruikers.
Dit is wanneer Charity X het my.
Ek het begin met die instel hul Google Apps-rekening en gaan deur die proses van opgradering dit aan die nie-winsgewende uitgawe. Ek migreer om die gebruiker se e-pos met behulp van die gebou in migrasie gereedskap, and I synchronized the user accounts with Google Apps Directory Sync Tool (JAAR). And that is where the utilities fell short. It appears that Google gedink about the idea of users synchronizing their active directory passwords with Google Apps. I emphasize thought, want blykbaar dit is so ver as Google het. Want Single Sign On? Want Synchronized passwords using LDAP or AD? Tyd om te draai na die derde party gereedskap. Okay, eerlik genoeg. Derde party gereedskap wat beskikbaar is om dit te doen, en hulle werk. Geen kwaad, geen vuil. Maar 'n bietjie meer dokumentasie oor die onderwerp sou nie seermaak.
Toe het al die hel los gebreek het. 'N handvol van gebruikers kan nie inteken om hul Google Rekeninge. So het die jag vir die saak begin.
Was hulle geskors? - Geen!
Was hulle met behulp van die verkeerde wagwoord - Geen!
Kon ek werk die wagwoord - Geen?
Strangely I could not update their user accounts using the web interface. Any change — password, byname, e-pos routing, name - het gelei tot 'n onbekende fout #1000.
Okay, Ek het gedink. Dit sê om te probeer om later weer, maar ek shoulda KAN theire gebruik wagwoord JAAR te werk.
JAAR DRUIP - 1301 Entiteit bestaan ​​nie!
Die jaar wat window aangedui op die gebruiker nie bestaan ​​nie. Dit was onverwags, want ek het net gekyk na die gebruiker se inligting in die web koppelvlak en dit die nodigste het beslis nie bestaan ​​nie.
Tyd vir die ondersteuning om in te skop! Want dit was 'n nie-winsgewende uitgawe, ondersteuning is ingesluit. So ek gebruik ondersteuning en agter die routing vrae. Google bepaal dat dit nie 'n kritiese' kwessie aangesien die diens was nie in die steek heeltemal, en ek kan nie sê ek stem nie saam. Google het gesê die enigste ondersteuning opsie beskikbaar is esupport.
Ek vervul die vorm, en is vinnig gegroet met 'n vriendelike e-pos van een van hul kliënte diens verteenwoordigers. The representative worked with me to quickly determine that this issue was beyond his level of expertise and escalated the ticket to a specialist.
So ver so goed.
Ek het toe gewag vir 3 dae. Ek het navrae van personeel oor wanneer hulle hul e-pos check. Wanneer sou dit vasgestel word? Hulle het deadlines en belangrike sake wat nodig is om te wees behandel in hulle e-pos.
Ek het gevra ondersteuning, wat geantwoord dat hulle "weet nie enige regstellings op die oomblik." Die enigste moontlikheid dat ons in staat was om te kom met was om die rekening te verwyder en herskep dit – nie 'n baie goeie oplossing aangesien alle pos sal verlore gaan tussen die oorgang en die tyd wat die rekening kan herskep word.
So ons wag nog meer. Die e-pos kon nie eens gestuur word aan geaffekteerde gebruikers - enige veranderinge aan e-pos routing gelei tot 'n onbekende fout.
'N week verby, so ek gepos word aan Google se support forum hoop dat iemand - enigiemand - sou 'n voorstel oor hoe om vas te stel of oplossing die probleem het. Gebruiker na gebruiker gerapporteer soortgelyke probleme sedert Google se oorgang van Apps gebruikers te Google Rekeninge, maar daar was geen besluite anders as om te wag vir die handleiding ingryping deur 'n Google-werknemer.
Tyd hou op te merk
Na agt dae van wag ek het gekom om 'n oplossing op my eie.
Aangesien dit blyk dat die rekeninge is gedeeltelik geskep (hulle verskyn in die web koppelvlak en kan e-pos ontvang, maar kon nie verander word of toegang tot dienste) Dit blyk hulle het 'n fout in hoe die rekeninge verwerk tydens die skepping. It seemed clear to me that the problem was an inconsistency in Google's infrastructure. Die verwydering van die rekeninge sou toelaat dat die stelsels in te stem op die rekening se status, maar kon hulle albei gemaak word om saam te stem dat die rekeninge bestaan? Perhaps I could force Google to recreate the already existing accounts without losing the current data.
I attempted to rerun the transition to Google Accounts on the affected users manually, maar ten spyte van die motor-vul die erkenning van hul gebruikers name, wanneer ek gebruik die volgende Ek het 'n fout dat die rekeninge nie bestaan ​​het nie.
My volgende benadering was om nuwe gebruikers met dieselfde name te skep met behulp van die dashboard. Hierdie keer het ek het gesê daar was 'n fout, want die rekeninge bestaan ​​het nie. Dit is duidelik dat daar twee afsonderlike stelsels bevraagteken.
Dit vir my voorgekom dat ek dalk in staat wees meer bruikbaar fout boodskappe te kry deur te gaan na die command-line. So het ek geïnstalleer Google Apps Bestuurder, Dit is ook bekend as GAM. GAM gebruik die Google Apps API vir interaksie met die Google Apps rekening.
Ek het 'n aantal navrae op rekeninge het ek geweet geraak met GAM om te sien wat gebeur. While queries would return data about the username, byname, en of hulle ooreengekom het om die terme van die diens, die gebruikers kan nie verander word nie, die terugkeer van die fout "1301 entiteit bestaan ​​nie". Dus het ek probeer om die gebruiker te weer skep, wat het 'n onverwagte resultaat.
Vreemd, Ek is meegedeel dat die stelsel was besig om. So het ek gewag en probeer weer.
Soos ek vermoed, dit het my vertel die rekening reeds bestaan. Maar uit nuuskierigheid, Ek het probeer om aan te meld.
Dit het gewerk
Vir watter rede ookal, Ek was nou in staat om aan te meld by die betrokke rekening. Ek het probeer om 'n ander rekening.
Dink dalk die fout beteken meer as wat dit was laat op, Ek het gepoog om aan te meld by die tweede rekening voordat ek weer. Hierdie rekening ook nou het gewerk soos verwag.
Ek sien die dashboard en die web koppelvlak nou het gewerk soos verwag op hierdie rekeninge asook.
Terwyl die reaksie was vreemd, alles wat gebeur het op die bediener einde verskyn hierdie probleem op te los, so ek het 'n script wat vervat alle geaffekteerde gebruikers en besluit om die probleme op die oorblywende rekeninge.
Die wolk behoeftes skokbrekers
Charity X is now working merrily away using Google Apps, Docs, en ander instrumente in die wolke, maar die oorgang het dit duidelik gemaak te bestuur dat daar geen magic oond wat jy kan net "stel en te vergeet" wanneer dit kom by IT. Terwyl daar nog 'n groot waarde en spaargeld te wees het in die wolke, hierdie downtime is kommerwekkend as 'n IT-bestuurder. When I run my own systems, Ek weet wat gebeur agter die skerms, en as dinge verkeerd gaan ek weet waar om te kyk na die antwoorde. With hosted services I am at the mercy of third parties to provide adequate documentation and timely support. Selfs as my werk is nie die oorsaak van die probleem, Ek is nog steeds verwag om oplossings te lewer aan my kliënte vinnig. Wanneer ek nie kan kyk onder die enjinkap, Ek moet vennote wat jou kan probleme op te los in ure - nie weke. Customer support beteken die verskaffing van die werklike oplossings. Eenvoudig erken 'n probleem is nie genoeg nie.
Wanneer wolk verskaffers veg om toegang tot winsgewende kontrakte met die staat en federale agentskappe en groot maatskappye is dit belangrik dat hulle onthou dat elke kliënt tel. Wanneer 'n gebruiker kan nie hul e-pos toegang is dit dalk nie oorweeg word nie van kritieke belang om Microsoft of Google, maar dit is 'n kritiese kwessie wat' n gebruiker. A week of downtime is simply unacceptable to users, veral as die betrokke gebruiker gebeur met 'n besluitnemer wees.
Ek sien uit daarna dienste wat werk soos 'n magic oond tot wolk, but for the foreseeable future I see only job security in die wolk.