Възстановяване, когато Google Apps не отговаря на Enterprise

Това е една история за ИТ, облака и всички големи и страшни дела, които се случват, когато двете се събират. In many ways cloud computing and Software as a Service (SaaS) е благословия за персонал, претоварени информационни технологии отдели, които се очаква да доведат до най-добрата технология може да предложи с 100% непрекъсната работа и без бюджет. With the emergence of web enabled services from major vendors like Amazon, Microsoft, and Google the age old question posed to IT professionals — е то безплатно - Най-сетне може да се отговори с ярък Да! (Най-малко за основната версия).

Но както много от нашите баби и дядовци казвал и преди, Опитът учи, че старата поговорка остава: Вие какво сте платили за. Разбира се, на услуга може да бъде свободен, но без споразумение за нивото на обслужване (SLA) не е прибягва, когато е налице имейл прекъсване, като например 6 ни повече прекъсвания че засегнатите в Google Mail 2009. But worry not end users! Има платени ъпгрейди налични които включват гарантиращи SLA 99.9% непрекъсната работа, както и телефон и имейл поддръжка за спешни случаи. At $50 на потребител на година това звучи като опит за кражба!

Какво точно означават те от ъптайм и критичен?

Всичко изглежда чудесно на хартия; не е необходимо за поддържане на материални активи, хардуер, Не, работниците и служителите да заплати, и цената е по-малко от лицензирането само за най-самостоятелни решения! За съжаление, тези пазарни гаранции изглеждат vaporware когато данните хитове на рутера.

За да илюстрираме недостатъците в облака, нека използваме истински пример живот. А не за печалба клиент ние ще се обадя “Благотворителен X” Исках да намали загубите по линията и подобряване на услугите за своите служители. След повече от десетилетие на работа електронна поща и услуги, вътрешно, те решиха, че е време да се премести в облака. Fortunately for them, като не за печалба институция те се класира за нестопанска издание на Google Apps. Голяма!

Ето и ползите, които те искат:

  1. Ние можем да намалим използването честотна лента, като не е работа електронна поща се
  2. Нашите ресурсите на сървъра ще бъде освободена и може да се използва за други цели
  3. Ние можем да осигурим по-добро уеб-базирана поща за нашите служители.
  4. Ние получите достъп до споделени ресурси, като например за управление на контакти и документи, които са ‘в облака

Реалността обаче е, че тази промяна не е толкова просто, колкото те са очаквали. Не беше въпрос на кликнете мигрират потребители.

Това е, когато ми се обади Благотворителен X.

Започнах с конфигурирането им Google Apps сметка и преминават през процес на модернизация на с нестопанска цел издание. Аз мигрирали пощата си потребители с помощта на вградения в инструменти за миграция, and I synchronized the user accounts with Google Apps Directory Sync Tool (ГОДИНА). And that is where the utilities fell short. It appears that Google мисъл about the idea of users synchronizing their active directory passwords with Google Apps. I emphasize thought, тъй като очевидно това е, доколкото имам Google. Want Single Sign On? Want Synchronized passwords using LDAP or AD? Време е да се обърнат към трети партия оръдие. Добре, достатъчно честно. Трета страна инструменти са на разположение да направите това, и те работят. Не вреди, не фал. Но малко по-документация по този въпрос няма да боли.

След това всички ада разби насипно състояние. Шепа на потребителите, не може да влезете в техните профили в Google. Така че на лов за каузата започна.

Дали те спира? - Не!

Дали те използват грешна парола - Не!

Може ли да актуализират своите пароли - Не?

Strangely I could not update their user accounts using the web interface. Any change — password, прякори, имейл маршрутизация, имена "- завърши с неизвестна грешка #1000.

Добре, Мислех, че. Той казва, да се опита отново по-късно, но Трябваше да може да се актуализира следните стандарти: Използване ГОДИНА парола.

ГОДИНА НЕ - 1301 Субект не съществува!

Годината, в която е посочено прозорец на потребителя не съществува. Това беше неочаквано, тъй като аз току-що разглеждали информация на потребителя в уеб интерфейс и най-вероятно е съществувал.

Продажба на билети време

Време за тази подкрепа да плащам! Тъй като това е с нестопанска цел издание, подкрепа е включен. Така се кликне подкрепа и след определяне на маршрута въпроси. Google установи, че това не е "критична’ въпрос, тъй като услугата не е намалял напълно, и не мога да кажа, че не е съгласен. Google заяви, че единственият вариант налична подкрепа, е esupport.

Аз попълнени форми, и бързо бе посрещнат с приятелски имейл от един от техните представители за обслужване на клиенти. The representative worked with me to quickly determine that this issue was beyond his level of expertise and escalated the ticket to a specialist.

Дотук добре.

След това чакаше 3 дни. Получихме запитвания от страна на персонала за това, кога те могат да проверят електронната си поща. Кога тя ще бъде определена? Те са сроковете и важни въпроси, които трябва да се разглеждат в техните пощенски кутии.

Попитах подкрепа, които отговарят, че “Не зная кой заобикаляне в момента.” Единствената възможност, че сме били в състояние да излезе с е да изтриете профила и го пресъздаде – не е много добро решение, тъй като всички писма ще бъдат загубени между прехода и момента, в който сметката може да бъде пресъздаден.

Така че сме чакали още. Имейл дори не можеше да се изпращат за засегнатите потребители - всички промени на приятел маршрута доведе до неизвестна грешка.

А премина седмица, така че аз качен на Google за поддръжка форум надявайки се някой - някой - ще има предложения за това как да се определи или заобиколно решение на проблема. Потребителски след употреба съобщава подобни проблеми, тъй като преход на Google Apps на потребителите за Google Профили, но не е имало резолюции, които не се чака за ръчна намеса от Google служител.

Времето си тиктака

След осем дни на чакане да дойде до решение на собствените си.

Тъй като се оказа, че сметките са били частично е създаден (са се появили в уеб интерфейс и може да получава електронна поща, но не може да бъде променен или достъп до услуги) се оказа, си е грешка в начина, по сметки са били преработени по време на създаването. It seemed clear to me that the problem was an inconsistency in Google’s infrastructure. Премахването на сметки ще позволят на системите да се споразумеят за статута на сметката, но може и двамата да се да се споразумеят, че отчетите съществува? 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, но въпреки автоматично запълване признаване на техните потребителски имена, , когато се кликне следващия ми дадоха грешка, че сметките не са съществували.

Следващата ми подход е да се създадат нови потребители със същите имена, на таблото. Този път ми казаха, не е грешка, защото сметките са съществували. Очевидно става въпрос за две отделни системи, които са под въпрос.

Това ми хрумна, че мога да бъда в състояние да получи по-полезни съобщения за грешка, като отидете на командния ред. Така че аз инсталирани Google Apps Manager, който е известен също като GAM. GAM използва Google Apps провизии API да взаимодейства с Google Apps сметка.

Тичах няколко запитвания по сметки Знаех, са били засегнати използване GAM, за да видите какво се е случило. While queries would return data about the username, прякори, и дали те са се съгласили с условията за ползване, на потребителите не може да се промени, връщане на грешка “1301 предприятието не съществува”. Така че аз се опитах да се създаде ръководство отново, който е неочакван резултат.

ServerBusy(1001)

Странно, Казаха ми, че системата е зает. Така че аз чаках и се опита отново.

EntityExists(1300)

Като заподозрени, тя ми каза, че предвид вече са съществували. Но от любопитство, Опитах се да влезете.

Той е работил

За какъвто и причина, Бях вече в състояние да влезете в засегнатия профил. Опитах друга сметка.

ServerBusy(1001)

Мисля си може би тази грешка означава повече, отколкото е отдаване под наем на, Опитах се да влезете в този втори профил, преди да опитате отново. Този профил и сега работи както се очаква.

Проверих на таблото и на уеб интерфейс сега работи както се очаква по тях, както и.

Въпреки че този отговор е странно, Какво се случи на сървъра края появи за коригиране на този проблем, така че аз се завтече скрипт, който съдържа всички засегнати потребители и решения на проблемите по отношение на останалите сметки.

Облакът нужди амортисьори

Charity X is now working merrily away using Google Apps, Документи, и други инструменти в облака, но преходът даде да се разбере на ръководството, че там не е магическа пещ, която може просто да “определени и да забрави” когато става дума за ИТ. Докато все още има голяма стойност и спестявания за да се вземе в облака, този престой е объркващо като ИТ администратора. When I run my own systems, Знам какво се случва зад кулисите, и ако нещо се обърка знам къде да гледам за отговорите. With hosted services I am at the mercy of third parties to provide adequate documentation and timely support. Дори ако работата ми не е причина за проблема, Аз съм все още очаква да доведат до решения на клиентите си бързо. Когато не мога да гледам под капака, Имам нужда от партньори, които могат да решат проблемите в час - не седмици. Помощ за клиента означава предоставяне на действителни решения. Просто признава проблем не е достатъчно.

Когато облак доставчиците се борят за достъп до изгодни договори с държавните и федерални агенции и големи корпорации това е важно, че те не забравяйте, че всеки клиент брой. Когато даден потребител не може да влезе електронната си поща може да не се смята за особено важно за Microsoft и Google, но това е критичен въпрос, на този потребител. A week of downtime is simply unacceptable to users, особено, ако засегнатата потребител случва да бъде един производител на решение.

Очаквам с нетърпение да тежи на услуги, които работят като вълшебна фурна, but for the foreseeable future I see only job security in облака.