აღმოფხვრას, როდესაც Google Apps ვერ საწარმოთა

ეს ამბავი IT, ღრუბელი და ყველა დიდი და საშინელი რამ მოხდა, როდესაც ორი გავერთიანდეთ. In many ways cloud computing and Software as a Service (SaaS) არის კურთხევით ამისთვის understaffed, გადამუშავებული საინფორმაციო ტექნოლოგიების დეპარტამენტების, რომელიც, სავარაუდოდ, სიტყვით საუკეთესო ტექნოლოგია სთავაზობს ერთად 100% uptime და არ ბიუჯეტი. With the emergence of web enabled services from major vendors like Amazon, Microsoft, and Google the age old question posed to IT professionals — ეს არის თავისუფალი - საბოლოოდ გაეცეს პასუხი ერთად resounding დიახ! (ყოველ შემთხვევაში ძირითადი ვერსია).

მაგრამ როგორც ბევრი ჩვენი წინაპრების არ განაცხადა, გამოცდილებამ მასწავლა, რომ ძველი adage რჩება: თქვენ რა იხდით. რა თქმა უნდა, მომსახურების შესაძლოა უფასო, მაგრამ არ მომსახურების დონის შეთანხმება (SLA) არ არსებობს რესურსების როდესაც ელ outage როგორიცაა 6 ჩვენი უფრო outages რომ დაზარალებული Google Mail წელს 2009. But worry not end users! არსებობს გადახდილი განახლებანი შესაძლებელია, რომ მოიცავს SLA გარანტიას 99.9% uptime ასევე ტელეფონის და ელ მხარდაჭერა კრიტიკული საკითხები. At $50 ერთ წელიწადში ამ ხმები როგორც იპარავენ!

რა ზუსტად ისინი ნიშნავს მიერ uptime და კრიტიკული?

ყოველივე ეს გამოიყურება დიდი ქაღალდზე; არ არის საჭირო, რომ შევინარჩუნოთ ფიზიკური ტექნიკის აქტივები, არ IT თანამშრომლების გადახდა, და ღირებულება ნაკლები ლიცენზირების მარტო ყველაზე standalone გადაწყვეტილებები! სამწუხაროდ, ამ მარკეტინგული გარანტიები ჰგავს 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? ახლა გახდება მესამე მხარის ინსტრუმენტები. Okay, სამართლიანი საკმარისი. მესამე ინსტრუმენტები შესაძლებელია ეს, და ისინი მუშაობენ. არ ზიანის, არ foul. მაგრამ უფრო დოკუმენტაცია სათაური არ დააზარალებს.

შემდეგ ყველა ჯოჯოხეთი დაიწყო ფხვიერი. მუჭა წევრებს ვერ შეხვიდეთ მათი Google ანგარიშები. ასე, რომ ნადირობის მიზეზი დაიწყო.

მათ შეაჩერა? - არ არის!

მათ გამოყენებით არასწორი პაროლი - არ არის!

შემიძლია განახლება მათი დაგავიწყდათ - არ არის?

Strangely I could not update their user accounts using the web interface. Any change — password, მეტსახელებს, ელ მარშრუტიზაცია, სახელები - შედეგად უცნობი შეცდომა #1000.

Okay, მეგონა. იგი აცხადებს სცადეთ მოგვიანებით, მაგრამ მე უნდა შეეძლოს განახლება მათი დაგავიწყდათ გამოყენებით GADS.

წელი ვერ - 1301 პირი არ არსებობს!

GADS დავთრის მითითებულია, რომ არ არსებობს. ეს მოულოდნელი იყო, რადგან მე მხოლოდ შევხედე მომხმარებლის ინფორმაცია ვებ ინტერფეისი და ყველაზე მეტად რა თქმა უნდა, არ არსებობს.

ბილეთის დრო

ახლა იმ მხარდაჭერისთვის გამოაგდონ წელს! მას შემდეგ ეს არაკომერციული გამოცემა, მხარდაჭერა შედის. ასე რომ აირჩიეთ მხარდაჭერა და შემდეგ მარშრუტიზაციის კითხვები. 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 დღის. მივიღე მოთხოვნების საწყისი პერსონალის შესახებ, როდესაც ისინი შეამოწმოთ ელ. როდესაც უნდა იყოს დაფიქსირებული? მათ ვადები და მნიშვნელოვანი საკითხები, რომ საჭირო იქნას განხილული მათ inboxes.

ვთხოვე მხარდაჭერა, რაც უპასუხა, რომ ისინი “არ ვიცი არც workarounds მომენტში.” ერთადერთი საშუალება, რომ ჩვენ შეგვეძლო ამუშავება იყო წაშლა ანგარიში და ხელახლა ეს – არ არის ძალიან კარგი გამოსავალი, რადგან ყველა გვერდის იქნება დაკარგა შორის გარდამავალი და დრო ანგარიშზე შეიძლება recreated.

ჩვენ დაელოდა კიდევ რამდენიმე. ელ ვერ გადაეცემა ამისთვის დაზარალებული წევრებს - ნებისმიერი ცვლილებების ელ მარშრუტიზაციის შედეგად უცნობი შეცდომა.

კვირა გავიდა, მე გამოქვეყნდა Google-ის მხარდაჭერა ფორუმის იმედი ვინმე - ვინმე - რომ აქვს წინადადება, თუ როგორ დაფიქსირება ან Workaround საკითხი. მომხმარებელი შემდეგ მომხმარებლის იტყობინება მსგავსი პრობლემები, რადგან Google-ის გადასვლის პროგრამები მომხმარებლებს Google ანგარიშები, მაგრამ არ იყო რეზოლუციებს გარდა დაველოდოთ სახელმძღვანელო ინტერვენციის Google თანამშრომელი.

ახლა აგრძელებს ticking

შემდეგ რვა დღის ლოდინის ჩამოვედი გადაწყვეტა ჩემს.

მას შემდეგ, რაც აღმოჩნდა, რომ ანგარიშებზე იყო ნაწილობრივ შექმნა (ისინი გაჩნდა ვებ ინტერფეისი და შეიძლება მიიღოს ელ მაგრამ არ შეიძლება შეიცვალოს ან მომსახურების ხელმისაწვდომობის) აღმოჩნდა, მათი იყო შეცდომა, თუ როგორ ანგარიშები დამუშავებულია დროს შექმნა. 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, მაგრამ მიუხედავად ავტომატური შევსების აღიარების სახელები, როცა აირჩიეთ შემდეგ მე გადაეცა შეცდომა, რომ ანგარიშები არ არსებობს.

ჩემი შემდეგი მიდგომა ახალი წევრებს იგივე სახელები გამოყენებით dashboard. ამჯერად მითხრეს იყო შეცდომა, რადგან ანგარიშები არ არსებობს. ცხადია, ორი ცალკე სისტემები მიმდინარეობს queried.

ეს მოხდა ჩემთან, რომ შესაძლოა უფრო სასარგებლო შეცდომა გზავნილების აპირებს ბრძანების ხაზი. მე დამონტაჟდა Google Apps მენეჯერი, რომელიც ასევე ცნობილია როგორც GAM. GAM იყენებს Google Apps provisioning API ურთიერთობის Google Apps ანგარიშის.

მე გაიქცა რიგ შეკითხვებს ანგარიშებზე ვიცოდი შეეხო გამოყენებით GAM დაინახოს, თუ რა მოხდა. While queries would return data about the username, მეტსახელებს, და თუ არა ისინი შეთანხმდნენ სამსახურის პირობებს, წევრებს ვერ განახლდა, დაბრუნების შეცდომა “1301 პირი არ არსებობს”. ასე რომ მე შევეცადე შექმნა მომხმარებლის კვლავ, რომელიც მოულოდნელი შედეგი.

ServerBusy(1001)

უცნაურად, მითხრეს, რომ სისტემა იყო დაკავებული. მე დაელოდა და კიდევ ერთხელ სცადა.

EntityExists(1300)

როგორც ეჭვმიტანილი, ეს მითხრა ანგარიშზე უკვე არსებული. მაგრამ გარეთ ცნობისმოყვარეობა, ვცადე შესვლა.

იგი მუშაობდა

სხვა ნებისმიერი მიზეზი, მე დღეიდან შეხვიდეთ დაზარალებული ანგარიშის. ვცადე სხვა ანგარიშზე.

ServerBusy(1001)

ფიქრი იქნებ ეს შეცდომა ნიშნავდა მეტი იყო გაქირავების შესახებ, მე სცადა სისტემაში ამ მეორე ანგარიშის ადრე ცდილობს კვლავ. ეს ანგარიში ასევე არის მუშაობდა მოსალოდნელია.

მე შეამოწმა dashboard და ვებ ინტერფეისი ახლა მუშაობდა მოსალოდნელია ამ ანგარიშებზე ასევე.

მიუხედავად იმისა, რომ პასუხი იყო უცნაური, რაც მოხდა სერვერზე ბოლოს გამოჩნდა გამოასწოროს ეს პრობლემა, მე გაიქცა სკრიპტის, რომ შეიცავს ყველა დაზარალებული წევრებს და წყდება პრობლემების დარჩენილი ანგარიშები.

ღრუბელი სჭირდება შოკი absorbers

Charity X is now working merrily away using Google Apps, Docs, და სხვა ინსტრუმენტები ღრუბელი, მაგრამ გარდამავალი აქვს ნათლად მართვის რომ isn'ta ჯადოსნური ღუმელი, რომ შეგიძლიათ “მითითებული და დავივიწყოთ” როდესაც საქმე IT. მიუხედავად იმისა, რომ ჯერ კიდევ არსებობს დიდი მნიშვნელობა და დანაზოგების უნდა იყო ღრუბელი, ამ downtime არის disconcerting როგორც IT ადმინისტრატორი. When I run my own systems, მე ვიცი, რა ხდება კულისებში, და თუ რამ წავიდეთ არასწორი ვიცი სად უნდა ვეძებოთ პასუხი. With hosted services I am at the mercy of third parties to provide adequate documentation and timely support. მაშინაც კი, თუ ჩემი მუშაობა არ არის მიზეზი პრობლემა, მე ჯერ კიდევ მოსალოდნელია სიტყვით გადაწყვეტილებების ჩემი მომხმარებელს სწრაფად. როცა არ შეუძლია ქვეშ Hood, მჭირდება პარტნიორებს, რომ შეიძლება პრობლემები გადაჭრას საათი - არ კვირის. მომხმარებლის მხარდაჭერა გულისხმობს რეალური გადაწყვეტილებები. უბრალოდ აღიარებით, პრობლემა არ არის საკმარისი.

როდესაც ღრუბელი პროვაიდერები არიან vying ხელმისაწვდომობა მომგებიანი კონტრაქტები სახელმწიფო და ფედერალური სააგენტოების და მსხვილი კორპორაციები მნიშვნელოვანია, რომ გვახსოვდეს, რომ თითოეულ კლიენტთან ითვლის. როდესაც მომხმარებელი არ გავქთ მათი ელ შესაძლოა არ განიხილება კრიტიკული Microsoft ან Google, მაგრამ ეს არის კრიტიკული საკითხი, რომ მომხმარებლის. A week of downtime is simply unacceptable to users, განსაკუთრებით იმ შემთხვევაში, თუ დაზარალებული მომხმარებლის ხდება უნდა წყვეტს.

მე მჯერა, რომ ღრუბელი მომსახურების რომ მუშაობა როგორც ჯადოსნური ღუმელი, but for the foreseeable future I see only job security in ღრუბელი.