การกู้คืนเมื่อ 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, ไมโครซอฟท์, and Google the age old question posed to IT professionals — มันคือค่าธรรมเนียมของ -- สามารถจนได้รับการตอบรับกับดังก้อง ใช่! (อย่างน้อยสำหรับรุ่นพื้นฐาน).

แต่ชอบมากของปู่ย่าตายายของเราได้เคยพูดไว้ว่า, ประสบการณ์ได้สอนว่าสุภาษิตโบราณยังคงอยู่: คุณได้รับสิ่งที่คุณจ่ายสำหรับ. แน่นอน, อาจจะมีการบริการฟรี, แต่ไม่มีข้อตกลงระดับการให้บริการ (SLA) มีไม่มีการขอความช่วยเหลือเมื่อมีการหยุดทำงานเช่นอีเมล 6 หยุดทำงานมากขึ้นของเรา ที่ได้รับผลกระทบใน Google Mail 2009. But worry not end users! มี อัพเกรดจ่าย พร้อมใช้งานที่รวมการ SLA guaranteeing 99.9% การเปลี่ยนแปลงที่สำคัญรวมทั้งโทรศัพท์และการสนับสนุนทางอีเมลสำหรับปัญหาที่สำคัญ. At $50 ต่อผู้ใช้ต่อปีนี้เสียงเหมือนขโมย!

อะไร เผง พวกเขาจะหมายถึง สถานะการออนไลน์ และการ วิกฤต?

ทุกอย่างดูดีบนกระดาษ; ต้องมีการดำรงสินทรัพย์ทางกายภาพของฮาร์ดแวร์ไม่, ไม่มีพนักงานไอทีการชำระเงิน, และค่าใช้จ่ายน้อยกว่าการออกใบอนุญาตเพียงอย่างเดียวสำหรับการแก้ปัญหาแบบสแตนด์อโลนมากที่สุด! อับ, การค้ำประกันการตลาดเหล่านี้มีลักษณะเช่น vaporware เมื่อข้อมูลความนิยมเราเตอร์.

เพื่อแสดงให้เห็นข้อบกพร่องในเมฆ, ให้ตัวอย่างของการใช้ชีวิตจริง. ไม่สำหรับลูกค้ากำไรเราจะเรียก “X การกุศล” ต้องการที่จะลดค่าใช้จ่ายและปรับปรุงบริการสำหรับพนักงานของตน. หลังจากกว่าทศวรรษของการจัดการอีเมลและบริการภายใน, พวกเขาตัดสินใจเป็นเวลาที่จะย้ายไปยังเมฆ. Fortunately for them, เป็นไม่สำหรับสถาบันกำไรที่พวกเขามีคุณสมบัติสำหรับรุ่นที่ไม่แสวงหาผลกำไรของ Google Apps. ยิ่งใหญ่!

ต่อไปนี้เป็นผลประโยชน์ที่พวกเขาแสวงหา:

  1. เราสามารถลดการใช้แบนด์วิดท์ของเราโดยไม่ได้จัดการอีเมลด้วยตนเอง
  2. ทรัพยากรของเซิร์ฟเวอร์ของเราจะได้รับการปลดปล่อยขึ้นและสามารถนำมาใช้เพื่อวัตถุประสงค์อื่น ๆ
  3. เราสามารถให้บริการอีเมลทางเว็บที่ดีกว่าสำหรับพนักงานของเรา.
  4. เราได้รับการเข้าถึงทรัพยากรที่ใช้ร่วมกันเช่นการจัดการรายชื่อและเอกสารที่อยู่ ‘ในเมฆ

แต่เป็นความจริงว่าการเปลี่ยนแปลงนี้ไม่ได้ง่ายอย่างที่พวกเขาคาดหวัง. มัน wasn'ta เรื่องของการ คลิกโยกย้ายผู้.

นั่นคือเมื่อการกุศล 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.

ถูก, ฉันคิดว่า. มันกล่าวว่าเพื่อลองอีกครั้งในภายหลัง, แต่ฉัน Shoulda สามารถอัปเดตปี theire การใช้รหัสผ่าน.

ปี FAIL -- 1301 Entity ไม่มีอยู่!

ปีหน้าต่างที่แสดงให้เห็นผู้ใช้ไม่ได้อยู่. นั่นเป็นเพราะผมไม่คาดคิดได้มองเพียงแค่ที่ข้อมูลของผู้ใช้ในอินเตอร์เฟซเว็บและมันก็มีอยู่มากที่สุดอย่างแน่นอน.

เวลาจองตั๋ว

เวลาในการสนับสนุนที่จะเตะใน! ตั้งแต่นี้เป็นรุ่นที่ไม่แสวงหากำไร, สนับสนุนรวม. ดังนั้นผมจึงคลิกการสนับสนุนและปฏิบัติตามคำถามที่กำหนดเส้นทาง. 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 ของผู้ใช้บัญชีผู้ใช้ Google Apps, แต่มีมติไม่อื่น ๆ กว่าที่จะรอคู่มือการแทรกแซงโดยพนักงานของ 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, แต่แม้จะมีการรับรู้โดยอัตโนมัติกรอกชื่อผู้ใช้ของพวกเขา, เมื่อฉันคลิกถัดไปผมได้รับข้อผิดพลาดที่บัญชีไม่ได้อยู่.

วิธีการถัดไปของฉันคือการสร้างผู้ใช้ใหม่ที่มีชื่อเดียวกันโดยใช้แผงควบคุม. เวลาที่ผมบอกนี้มีข้อผิดพลาดเพราะบัญชีไม่อยู่. เห็นได้ชัดมีสองระบบแยกได้ถูกสอบถาม.

มันเกิดขึ้นกับผมว่าผมอาจจะได้รับข้อความแสดงข้อผิดพลาดที่มีประโยชน์มากขึ้นโดยไปที่บรรทัดคำสั่ง. ดังนั้นผมจึงติดตั้ง 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, Docs, และเครื่องมืออื่น ๆ ในเมฆ, แต่การเปลี่ยนแปลงมีจุดยืนที่ชัดเจนในการจัดการที่มีเตาอบไม่ใช่มายากลที่คุณสามารถเพียงแค่ “ตั้งค่าและลืม” เมื่อมันมาถึงไอที. ในขณะที่ยังคงมีค่าที่ดีและเงินฝากออมทรัพย์ที่จะได้ในเมฆ, การหยุดทำงานนี้เป็นอึกอักเป็นผู้ดูแลระบบไอที. When I run my own systems, ฉันรู้ว่าสิ่งที่เกิดขึ้นอยู่เบื้องหลัง, และถ้าสิ่งผิดไปฉันรู้ว่าจะสามารถหาคำตอบ. With hosted services I am at the mercy of third parties to provide adequate documentation and timely support. แม้ว่าการทำงานของผมไม่ได้สาเหตุของปัญหา, ผมคาดว่าจะยังคงนำเสนอโซลูชั่นให้กับลูกค้าของฉันได้อย่างรวดเร็ว. เมื่อฉันไม่สามารถดูใต้กระโปรงหน้ารถ, ฉันต้องการคู่ค้าที่สามารถแก้ไขปัญหาในชั่วโมง -- ไม่สัปดาห์. ฝ่ายบริการลูกค้าหมายถึงการให้บริการโซลูชั่นที่เกิดขึ้นจริง. เพียงแค่รับทราบปัญหาไม่เพียงพอ.

เมื่อผู้ให้บริการเมฆเป็น vying สำหรับการเข้าทำสัญญาให้ผลตอบแทนกับภาครัฐและรัฐบาลกลางและองค์กรขนาดใหญ่เป็นสิ่งสำคัญที่พวกเขาจำได้ว่าลูกค้าแต่ละรายจำนวน. เมื่อผู้ใช้ไม่สามารถเข้าถึงอีเมลของพวกเขามันอาจจะไม่ได้รับการพิจารณาที่สำคัญไปยัง Microsoft หรือ Google, แต่เป็นปัญหาที่สำคัญให้กับผู้ใช้ว่า. A week of downtime is simply unacceptable to users, โดยเฉพาะอย่างยิ่งหากผู้ได้รับผลกระทบเกิดขึ้นเป็นผู้ตัดสินใจ.

ฉันหวังว่าจะมีเมฆบริการที่ทำงานเช่นเตาอบมายากล, but for the foreseeable future I see only job security in เมฆ.