Herstellende toen Google Apps niet de Enterprise

Dit is een verhaal over IT, de wolk en alle grote en verschrikkelijke dingen die gebeuren wanneer de twee samen te komen. In many ways cloud computing and Software as a Service (SaaS) is een zegen voor onderbezet, overwerkte IT-afdelingen, die naar verwachting leveren de beste technologie te bieden heeft met 100% uptime en geen budget. With the emergence of web enabled services from major vendors like Amazon, Microsoft, and Google the age old question posed to IT professionals — is het gratis - Definitief kan worden beantwoord met een volmondig ja! (Althans voor de basisversie).

Maar zoals met veel van onze grootouders hebben al eerder gezegd, ervaring heeft geleerd dat het oude adagium blijft: je krijgt wat je betaalt voor. Zeker, de dienst zal wellicht vrij, maar zonder service level agreement (SLA) er is geen verhaal als er een e-mailstoring zoals de 6 onze meer uitval dat getroffen Google Mail in 2009. But worry not end users! Er zijn betaalde upgrades beschikbaar die bevatten een SLA garanderen 99.9% uptime als telefoon en e-mail ondersteuning voor kritieke problemen. At $50 per gebruiker per jaar dit klinkt als een koopje!

Wat precies betekenen ze door uptime en kritische?

Het ziet er allemaal geweldig op papier; er is geen noodzaak om fysieke hardware assets te behouden, geen IT-medewerkers te betalen, en de kosten minder dan licenties alleen al voor de meeste standalone oplossingen! Helaas, deze marketing garanties eruit vaporware wanneer de gegevens hits van de router.

Ter illustratie van de tekortkomingen in de cloud, Laten we gebruik maken van een real life voorbeeld. Een not for profit klant noemen we “Charity X” wilde overhead te verminderen en dienstverlening te verbeteren voor hun personeel. Na meer dan een decennium van het afhandelen van email en diensten intern, ze besloten dat het tijd was om te verhuizen naar de cloud. Fortunately for them, als een not for profit instelling ze zich hebben gekwalificeerd voor de non-profit editie van Google Apps. Grote!

Hier is de voordelen die ze zochten:

  1. We kunnen onze bandbreedte gebruik door niet het afhandelen van email ons
  2. Onze server resources wordt vrijgemaakt en kan gebruikt worden voor andere doeleinden
  3. We kunnen zorgen voor een betere webmail voor onze medewerkers.
  4. We krijgen toegang tot gedeelde bronnen, zoals contact opnemen met het beheer en de documenten die zijn ‘in de cloud

De realiteit was echter dat deze verandering niet zo eenvoudig als ze had verwacht. Het was geen kwestie van Klik migreren gebruikers.

Dat is wanneer Charity X me belde.

Ik begon met het configureren van hun Google Apps-account en gaan door het proces van upgraden naar de non-profit editie. Ik gemigreerd van hun gebruikers e-mail met behulp van de ingebouwde migratie tools, 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 dacht about the idea of users synchronizing their active directory passwords with Google Apps. I emphasize thought, want blijkbaar dat is zo ver als Google kreeg. Want Single Sign On? Want Synchronized passwords using LDAP or AD? De tijd zich te wenden tot third-party tools. Okay, eerlijk genoeg. Third-party tools beschikbaar zijn om dit te doen, en ze werken. Geen kwaad, geen fout. Maar een beetje meer documentatie over dit onderwerp zou geen kwaad.

Vervolgens brak de hel los. Een handvol van de gebruikers konden niet inloggen op hun Google-account. Dus de jacht naar de oorzaak begonnen.

Waren ze geschorst? - Geen!

Waren ze met behulp van het verkeerde wachtwoord - Geen!

Kan ik een update van hun wachtwoord - Geen?

Strangely I could not update their user accounts using the web interface. Any change — password, bijnamen, e-mail routing, namen - resulteerde in een onbekende fout #1000.

Okay, Ik dacht. Het zegt probeer het later nog eens, maar ik shoulda KUNNEN theire gebruiken wachtwoord jaar update.

JAAR FAIL - 1301 Entiteit bestaat niet!

Het jaar dat venster aangegeven de gebruiker bestaat niet. Dat was onverwacht, want ik had net gekeken naar informatie van de gebruiker in het web interface en het zeer zeker niet bestond.

Ticket Time

Tijd voor die steun te schoppen! Aangezien dit een non-profit editie, ondersteuning is inbegrepen. Dus klikte ik steun en volgde de routing vragen. Google bepaald dat dit niet een 'kritische’ kwestie, aangezien de service was niet volledig naar beneden, en ik kan niet zeggen dat ik het niet eens. Google zei dat de enige support optie beschikbaar is eSupport.

Ik vulde het formulier in, en werd al snel begroet met een vriendelijke e-mail van een van hun vertegenwoordigers van de klantendienst. 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 far so good.

Vervolgens heb ik gewacht 3 dagen. Ik vragen van het personeel ontvangen over wanneer ze konden hun e-mail te controleren. Wanneer zou dit worden opgelost? Ze hadden deadlines en belangrijke zaken die moesten worden behandeld in hun postvak.

Ik vroeg steun, die reageerde dat zij “weet niet geen oplossingen op het moment.” De enige mogelijkheid dat we in staat waren om te komen met was om de account te verwijderen en opnieuw maken – niet een erg goede oplossing, omdat alle e-mail verloren zou gaan tussen de overgang en het tijdstip waarop de rekening kon worden herschapen.

Dus wachtten we wat meer. De e-mail zelfs niet kon worden toegezonden voor de getroffen gebruikers - eventuele wijzigingen van e-mail routing resulteerde in een onbekende fout.

Een week voorbij, dus ik gepost ter ondersteuning van Google's forum hoop dat iemand - iedereen - zou een suggestie over hoe op te lossen of een tijdelijke oplossing van de kwestie hebben. Gebruiker nadat de gebruiker gemeld met soortgelijke problemen sinds de overgang van Google Apps-gebruikers naar Google Accounts, maar er waren geen resoluties anders dan te wachten tot handmatige interventie door een medewerker van Google.

Tijd blijft tikken

Na acht dagen wachten kwam ik tot een oplossing op mijn eigen.

Omdat bleek dat de rekeningen gedeeltelijk werden gecreëerd (zij verscheen in de webinterface en kan e-mail ontvangen, maar kon niet worden gewijzigd of toegang tot diensten) bleek hun was een fout in de manier waarop de rekeningen werden verwerkt tijdens het maken. It seemed clear to me that the problem was an inconsistency in Google’s infrastructure. Het verwijderen van de rekeningen zou de systemen te bereiken over de status van de account, maar kon ze beide worden gemaakt om in te stemmen dat de rekeningen 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 ondanks de auto-fill erkenning van hun gebruikersnamen, toen ik klikte op de volgende kreeg ik een foutmelding dat de rekeningen niet bestond.

Mijn volgende benadering was om nieuwe gebruikers met dezelfde naam maken met behulp van het dashboard. Deze keer kreeg ik te horen dat er was een fout omdat de rekeningen niet bestond. Kennelijk zijn er twee afzonderlijke systemen die worden opgevraagd.

Het viel me op dat ik misschien in staat om meer bruikbare foutmeldingen krijgt worden door te gaan naar de command-line. Dus ik geïnstalleerd Google Apps Manager, die ook bekend staat als de GAM. GAM maakt gebruik van het Google Apps-API te communiceren met de Google Apps-account.

Ik liep een aantal vragen over de rekeningen van ik wist werden beïnvloed met behulp van GAM om te zien wat er gebeurd is. While queries would return data about the username, bijnamen, en of ze hadden afgesproken om de voorwaarden van de dienst, de gebruikers kunnen niet worden gewijzigd, terug de fout “1301 entiteit bestaat niet”. Dus probeerde ik om de gebruiker opnieuw maken, die een onverwacht resultaat was.

ServerBusy(1001)

Vreemd, Ik kreeg te horen dat het systeem bezet was. Dus wachtte ik en probeerde het opnieuw.

EntityExists(1300)

Als ik vermoed, zij vertelde me de rekening al bestond. Maar uit nieuwsgierigheid, Ik heb geprobeerd om in te loggen.

Het werkte

Om wat voor reden, Ik was nu in staat in te loggen op de betreffende account. Ik heb geprobeerd een andere account.

ServerBusy(1001)

Denken misschien is dit fout betekende meer dan het was laat op, Ik heb geprobeerd om in te loggen om deze tweede account en probeer het opnieuw. Dit account nu ook gewerkt als verwacht.

Ik controleerde het dashboard en de webinterface nu werkte zoals verwacht op deze rekeningen alsmede.

Terwijl de respons was vreemd, wat is er gebeurd op de server einde leek dit probleem te verhelpen, dus ik liep een script dat alle betrokken gebruikers bevatte en het verdwijnen van de problemen op de resterende rekeningen.

De wolk moet schokdempers

Charity X is now working merrily away using Google Apps, Docs, en andere instrumenten in de cloud, maar de overgang heeft duidelijk gemaakt aan het management dat er magie is geen oven die je kunt gewoon “instellen en vergeten” als het gaat om IT-. Hoewel er nog steeds een grote waarde en besparingen te worden gehouden in de cloud, deze downtime is verontrustend als een IT-beheerder. When I run my own systems, Ik weet wat er gebeurt achter de schermen, en als het mis gaat weet ik waar te kijken voor de antwoorden. With hosted services I am at the mercy of third parties to provide adequate documentation and timely support. Zelfs als mijn werk is niet de oorzaak van het probleem, Ik ben nog steeds verwacht dat oplossingen snel kunnen leveren aan mijn klanten. Als ik niet kan kijken onder de motorkap, Ik heb partners die kunnen het oplossen van problemen in uren - niet weken. Klantenondersteuning betekent het verschaffen van concrete oplossingen. Gewoon erkennen een probleem is niet genoeg.

Als cloud providers strijden om toegang tot lucratieve contracten met staats-en federale agentschappen en grote bedrijven is het belangrijk dat ze beseffen dat elke klant telt. Wanneer een gebruiker geen toegang tot hun e-mail is het wellicht niet als kritisch beschouwd voor Microsoft of Google, maar het is een kritiek probleem aan die gebruiker. A week of downtime is simply unacceptable to users, vooral als de betrokken gebruiker toevallig een beslisser.

Ik kijk uit naar diensten die werken als een magisch oven wolk, but for the foreseeable future I see only job security in de wolk.