Gjenopprette når Google Apps mislykkes i Enterprise

Dette er en historie om IT, skyen og alle de store og forferdelige ting som skjer når de to kommer sammen. In many ways cloud computing and Software as a Service (SaaS) er en velsignelse for underbemannet, overarbeidet Informasjonsteknologi avdelinger som forventes å levere den beste teknologien har å tilby med 100% oppetid og ingen budsjett. With the emergence of web enabled services from major vendors like Amazon, Microsoft, and Google the age old question posed to IT professionals — er det gratis - Kan endelig bli besvart med et rungende ja! (Minst for den grunnleggende versjonen).

Men som mange av våre besteforeldre har sagt før, erfaring har lært at det gamle ordtaket fortsatt: du får hva du betaler for. Sikker, tjenesten kan være gratis, men uten serviceavtale (SLA) det er ingen regress når det er en e-post strømbrudd som 6 våre mer strømbrudd som påvirket Google Mail i 2009. But worry not end users! Det er betalt oppgraderinger tilgjengelig som inkluderer en SLA garanterer 99.9% oppetid samt telefon-og e-poststøtte for alvorlige problemer. At $50 per bruker per år dette høres ut som et røverkjøp!

Hva nøyaktig gjør de mener med oppetid og kritisk?

Det ser alt flott ut på papiret; det er ikke nødvendig å opprettholde fysisk maskinvare eiendeler, ingen IT-ansatte å betale, og kostnadene er mindre enn lisensiering alene for de fleste frittstående løsninger! Dessverre, disse markedsføring garanterer se ut vaporware når dataene treffer ruteren.

For å illustrere svakhetene i skyen, la oss bruke en ekte liv eksempel. En ikke for profitt kundene vi ringer “Charity X” ønsket å redusere overhead og bedre tilbudet for de ansatte. Etter over et tiår med håndtering epost og tjenester internt, de bestemte seg for det var på tide å flytte til skyen. Fortunately for them, som en ikke for profitt institusjonen de kvalifiserte seg til non-profit utgaven av Google Apps. Great!

Her er fordelene de søkte:

  1. Vi kan redusere vår bruk av båndbredde ved å ikke håndtere e-post oss
  2. Vår server ressurser vil bli frigjort og kan brukes til andre formål
  3. Vi kan tilby bedre e for våre ansatte.
  4. Vi får tilgang til delte ressurser, for eksempel kundeoppfølging og dokumenter som er ‘i nettskyen

Realiteten om var at denne endringen ikke var så enkelt som de hadde forventet. Det var ikke spørsmål om Klikk migrere brukere.

Det er da Charity X ringte meg.

Jeg begynte med å konfigurere sin Google Apps-konto og gå gjennom prosessen med å oppgradere den til non-profit utgaven. Jeg migrerte brukernes post ved hjelp av innebygde migrasjon verktøy, and I synchronized the user accounts with Google Apps Directory Sync Tool (ÅR). And that is where the utilities fell short. It appears that Google trodde about the idea of users synchronizing their active directory passwords with Google Apps. I emphasize thought, fordi tilsynelatende som er like langt som Google fikk. Want Single Sign On? Want Synchronized passwords using LDAP or AD? Tid for å slå til tredjeparts verktøy. Okay, greit nok. Tredjeparts verktøy er tilgjengelige for å gjøre dette, og de fungerer. Ingen skade, ingen feil. Men litt mer dokumentasjon om emnet ikke ville skade.

Da helvete brøt løs. En håndfull brukere kan ikke logge inn til sine Google-kontoer. Så jakten på årsaken begynte.

Var de suspendert? - Ingen!

Var de bruker feil passord - Nei!

Kan jeg oppdatere sine passord - Nei?

Strangely I could not update their user accounts using the web interface. Any change — password, kallenavn, e-postruting, navn - resulterte i en ukjent feil #1000.

Okay, Jeg trodde. Det står å prøve igjen senere, men jeg skulle ha kunne oppdatere de verdenskjente Bruke passord ÅR.

ÅR FAIL - 1301 Entity eksisterer ikke!

Året at vinduet indikerte at brukeren finnes ikke. Det var uventet siden jeg nettopp hadde sett på brukerens informasjonen i web-grensesnittet og den absolutt fantes.

Ticket Time

Tid for at støtte til kick i! Siden dette var et non-profit utgaven, støtte er inkludert. Så jeg klikket støtte og fulgte routing spørsmål. Google fastslått at dette ikke var en "kritisk’ problem siden tjenesten ikke var helt ned, og jeg kan ikke si jeg var uenig. Google sa at den eneste støtten alternativet tilgjengelig er eSupport.

Jeg fylte ut skjemaet, og ble raskt møtt med en hyggelig e-post fra en av deres kundeservice representanter. The representative worked with me to quickly determine that this issue was beyond his level of expertise and escalated the ticket to a specialist.

Så langt så bra.

Jeg ventet på 3 dager. Jeg mottok henvendelser fra ansatte om når de kunne sjekke e-post. Når ville det være faste? De hadde tidsfrister og viktige saker som måtte behandles i innboksene.

Jeg spurte støtter, som svarte at de “vet ikke noen midlertidig løsning for øyeblikket.” Den eneste muligheten for at vi klarte å komme opp med var å slette kontoen og opprette den på nytt – ikke en veldig god løsning siden all post ville være tapt mellom overgangen og tiden kontoen kunne gjenskapes.

Så vi ventet litt mer. E-posten kunne ikke engang bli videresendt for berørte brukere - eventuelle endringer i e-postruting resulterte i en ukjent feil.

En uke passerte, så jeg postet til Googles support forum håper noen - noen - ville ha et forslag på hvordan å fikse eller løsning på problemet. Bruker etter at brukeren har rapportert lignende problemer siden Googles overgangen Apps-brukere til Google-kontoer, men det var ingen vedtak annet enn å vente på manuell intervensjon fra en Google-ansatt.

Time holder på tikkende

Etter åtte dager med venting kom jeg til en løsning på egen hånd.

Siden det viste seg at kontoer ble delvis opprettet (De dukket opp i web-grensesnittet og kan motta e-post, men kunne ikke endres eller tilgang til tjenester) det viste seg hadde vært en feil i hvordan regnskapet ble behandlet under oppretting. It seemed clear to me that the problem was an inconsistency in Google’s infrastructure. Fjerne regnskapet ville tillate systemene å bli enige om kontoens status, men kunne de begge bli enige om at regnskapet eksisterte? 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, men til tross for auto-fill anerkjenner deres brukernavn, når jeg klikket neste jeg fikk en feil at regnskapet ikke fantes.

Min neste tilnærming var å opprette nye brukere med samme navn ved hjelp av dashbordet. Denne gangen var jeg fortalt at det var en feil fordi kontoene eksisterte. Klart det var to separate systemer som spørres.

Det slo meg at jeg kanskje kunne få mer nyttig feilmeldinger ved å gå til kommandolinjen. Så jeg installerte Google Apps Manager, som også er kjent som GAM. GAM bruker Google Apps API til å samhandle med Google Apps-konto.

Jeg løp et antall søk på kontoer jeg visste var påvirket bruker GAM å se hva som skjedde. While queries would return data about the username, kallenavn, og om de hadde godtatt vilkårene for tjenesten, brukerne kunne ikke endres, returnere feilen “1301 foretak eksisterer ikke”. Så jeg prøvde å opprette brukernavn igjen, som hadde et uventet resultat.

ServerBusy(1001)

Merkelig, Jeg ble fortalt at systemet var opptatt. Så jeg ventet og prøvde igjen.

EntityExists(1300)

Som jeg mistenkte, den fortalte meg at kontoen allerede eksisterte. Men ut av nysgjerrighet, Jeg prøvde å logge inn.

Det fungerte

For uansett årsak, Jeg var nå i stand til å logge inn på den aktuelle kontoen. Jeg prøvde en annen konto.

ServerBusy(1001)

Tenkte kanskje denne feilen betydde mer enn det var å la på, Jeg forsøkte å logge inn på denne andre kontoen før du prøver igjen. Denne kontoen nå også jobbet som forventet.

Jeg sjekket på dashbordet og på web grensesnittet nå jobbet som forventet på disse kontoene i tillegg.

Mens responsen var rart, hva skjedde på serveren enden så ut til å løse dette problemet, så jeg kjørte et script som inneholdt alle berørte brukere og løste problemer på gjenværende regnskapet.

Skyen trenger støtdempere

Charity X is now working merrily away using Google Apps, Dokumenter, og andre verktøy i nettskyen, men overgangen har gjort det klart overfor ledelsen at det er ikke magi ovnen som du bare kan “sett og glemme” når det gjelder IT. Mens det fortsatt er en stor verdi og besparelser å hente i skyen, denne nedetiden er urovekkende som IT-administrator. When I run my own systems, Jeg vet hva som skjer bak kulissene, og hvis ting går galt jeg vet hvor du skal lete etter svarene. With hosted services I am at the mercy of third parties to provide adequate documentation and timely support. Selv om arbeidet mitt er ikke årsaken til problemet, Jeg er fortsatt ventet å levere løsninger til kundene mine raskt. Når jeg ikke kan se under panseret, Jeg trenger samarbeidspartnere som kan løse problemer i timer - ikke uker. Kunden støtte betyr å gi faktiske løsninger. Bare erkjennelsen et problem er ikke nok.

Når skyen tilbydere kjemper for tilgang til lukrative kontrakter med statlige og føderale byråer og store selskaper det er viktig at de husker at hver kunde teller. Når en bruker ikke kan få tilgang til sin e-post er det kanskje ikke vurderes kritisk til Microsoft eller Google, men det er et kritisk problem for den brukeren. A week of downtime is simply unacceptable to users, spesielt hvis den aktuelle brukeren skjer for å være en beslutningstaker.

Jeg ser frem til å sky tjenester som fungerer som en magisk ovn, but for the foreseeable future I see only job security in skyen.