SLA หรือที่เรียกว่า "ข้อตกลงระดับบริการ" คือข้อตกลงการรับประกันระหว่างลูกค้าและผู้ให้บริการเกี่ยวกับสิ่งที่ลูกค้าจะได้รับในแง่ของการบริการ นอกจากนี้ยังกำหนดค่าตอบแทนในกรณีที่เครื่องหยุดทำงานเนื่องจากความผิดพลาดของซัพพลายเออร์เป็นต้น โดยพื้นฐานแล้ว SLA เป็นข้อมูลประจำตัวที่ได้รับความช่วยเหลือจากศูนย์ข้อมูลหรือผู้ให้บริการโฮสติ้งโน้มน้าวผู้มีโอกาสเป็นลูกค้าว่าเขาจะได้รับการปฏิบัติอย่างกรุณาในทุกวิถีทางที่เป็นไปได้ คำถามคือคุณสามารถเขียนสิ่งใดก็ได้ที่คุณต้องการใน SLA และเหตุการณ์ที่เขียนในเอกสารนี้ไม่ได้เกิดขึ้นบ่อยเกินไป SLA ยังห่างไกลจากแนวทางในการเลือกศูนย์ข้อมูล และคุณไม่ควรเชื่อถือศูนย์ข้อมูลดังกล่าวอย่างแน่นอน
เราทุกคนคุ้นเคยกับการลงนามข้อตกลงบางประเภทที่กำหนดภาระผูกพันบางประการ SLA ก็ไม่มีข้อยกเว้น โดยปกติแล้วจะเป็นเอกสารที่ไม่สมจริงที่สุดเท่าที่จะจินตนาการได้ สิ่งเดียวที่น่าจะไร้ประโยชน์มากกว่าคือ NDA ในเขตอำนาจศาลซึ่งแนวคิดเรื่อง "ความลับทางการค้า" ไม่มีอยู่จริง แต่ปัญหาทั้งหมดก็คือ SLA ไม่ได้ช่วยลูกค้าในการเลือกซัพพลายเออร์ที่เหมาะสม แต่เพียงแต่ทำให้ฝุ่นเข้าตาเท่านั้น
เจ้าของที่พักมักเขียนอะไรใน SLA เวอร์ชันสาธารณะที่พวกเขาแสดงต่อสาธารณะมากที่สุด? บรรทัดแรกคือคำว่า “ความน่าเชื่อถือ” ของผู้โฮสต์ ซึ่งโดยปกติจะเป็นตัวเลขตั้งแต่ 98 ถึง 99,999% ที่จริงแล้ว ตัวเลขเหล่านี้เป็นเพียงสิ่งประดิษฐ์ที่สวยงามของนักการตลาด กาลครั้งหนึ่ง เมื่อโฮสติ้งยังใหม่และมีราคาแพง และคลาวด์เป็นเพียงความฝันสำหรับผู้เชี่ยวชาญ (เช่นเดียวกับการเข้าถึงบรอดแบนด์สำหรับทุกคน) ตัวบ่งชี้เวลาทำงานของโฮสติ้งมีความสำคัญอย่างยิ่ง ในปัจจุบัน เมื่อซัพพลายเออร์ทุกรายใช้อุปกรณ์เดียวกัน บวกหรือลบ บนเครือข่ายแกนหลักเดียวกัน และเสนอแพ็คเกจบริการเดียวกัน ตัวบ่งชี้เวลาทำงานก็ไม่มีอะไรโดดเด่นอย่างแน่นอน
มี SLA ที่ "ถูกต้อง" หรือไม่
แน่นอนว่า SLA มีเวอร์ชันที่เหมาะสมที่สุด แต่ทั้งหมดนี้เป็นเอกสารที่ไม่ได้มาตรฐาน และมีการลงทะเบียนและสรุประหว่างลูกค้าและซัพพลายเออร์ด้วยตนเอง นอกจากนี้ SLA ประเภทนี้มักเกี่ยวข้องกับงานตามสัญญาบางประเภทมากกว่าการบริการ
SLA ที่ดีควรประกอบด้วยอะไรบ้าง เพื่อให้เป็น TLDR SLA ที่ดีคือเอกสารที่ควบคุมความสัมพันธ์ระหว่างสองหน่วยงาน ซึ่งทำให้ฝ่ายใดฝ่ายหนึ่ง (ลูกค้า) ควบคุมกระบวนการได้สูงสุด นั่นคือวิธีการทำงานในโลกแห่งความเป็นจริง: มีเอกสารที่อธิบายกระบวนการปฏิสัมพันธ์ระดับโลกและควบคุมความสัมพันธ์ระหว่างทั้งสองฝ่าย มันกำหนดขอบเขต กฎเกณฑ์ และในตัวมันเองกลายเป็นอิทธิพลที่ทั้งสองฝ่ายสามารถนำมาใช้ได้อย่างเต็มที่ ดังนั้น ด้วย SLA ที่ถูกต้อง ลูกค้าจึงสามารถบังคับผู้รับเหมาให้ทำงานตามที่ตกลงไว้ได้ และช่วยให้ผู้รับเหมาต่อสู้กับ "ความต้องการ" ของลูกค้าที่กระตือรือร้นมากเกินไปซึ่งไม่สมเหตุสมผลตามสัญญา ดูเหมือนว่า: “SLA ของเราบอกสิ่งนี้และนั่น ออกไปจากที่นี่ เราทำทุกอย่างตามที่ตกลงกัน”
นั่นคือ "SLA ที่ถูกต้อง" = "สัญญาที่เพียงพอสำหรับการให้บริการ" และให้การควบคุมสถานการณ์ แต่จะเป็นไปได้ก็ต่อเมื่อทำงาน "เท่าเทียม" เท่านั้น
สิ่งที่เขียนบนเว็บไซต์และสิ่งที่รออยู่ในความเป็นจริงเป็นสองสิ่งที่แตกต่างกัน
โดยทั่วไป ทุกสิ่งที่เราจะพูดคุยเพิ่มเติมนั้นเป็นเทคนิคทางการตลาดทั่วไปและการทดสอบความเอาใจใส่
หากเรารับผู้ให้บริการโฮสต์ในประเทศยอดนิยม ข้อเสนอหนึ่งก็ดีกว่าข้อเสนออื่น: รองรับ 25/8 เวลาทำงานของเซิร์ฟเวอร์ 99,9999999% ของเวลา มีศูนย์ข้อมูลของตัวเองอย่างน้อยก็ในรัสเซีย โปรดจำไว้ว่าประเด็นเกี่ยวกับศูนย์ข้อมูล เราจะกลับมาอีกครั้งในภายหลัง. ในระหว่างนี้ เรามาพูดถึงสถิติการทนทานต่อข้อผิดพลาดในอุดมคติ และสิ่งที่บุคคลเผชิญเมื่อเซิร์ฟเวอร์ของเขายังคงตกอยู่ใน “0,0000001% ของความล้มเหลว”
ด้วยตัวบ่งชี้ที่ 98% ขึ้นไป การลดลงใดๆ ถือเป็นเหตุการณ์ที่จวนจะเกิดข้อผิดพลาดทางสถิติ อุปกรณ์การทำงานและการเชื่อมต่อมีหรือไม่มี คุณสามารถใช้ผู้ให้บริการโฮสต์ที่มีคะแนน “ความน่าเชื่อถือ” 50% (ตาม SLA ของตัวเอง) เป็นเวลาหลายปีโดยไม่มีปัญหาใด ๆ หรือคุณสามารถ “ล้มเหลว” เดือนละครั้งเป็นเวลาสองสามวันกับผู้ที่อ้างสิทธิ์ 99,99%
เมื่อช่วงเวลาของการล้มมาถึง (และเราขอเตือนคุณว่า สักวันหนึ่งทุกคนก็ล้ม) ลูกค้าจะต้องเผชิญกับกลไกภายในองค์กรที่เรียกว่า "การสนับสนุน" และข้อตกลงการบริการและ SLA จะถูกเปิดเผย มันหมายความว่าอะไร:
- เป็นไปได้มากว่าในช่วงสี่ชั่วโมงแรกของการหยุดทำงาน คุณจะไม่สามารถนำเสนอสิ่งใดได้เลย แม้ว่าโฮสต์บางรายจะเริ่มคำนวณภาษีใหม่ (การชำระค่าชดเชย) นับตั้งแต่ช่วงเวลาที่เกิดการขัดข้อง
- หากเซิร์ฟเวอร์ไม่พร้อมใช้งานเป็นระยะเวลานาน คุณอาจสามารถส่งคำขอคำนวณภาษีใหม่ได้
- และนี่คือเงื่อนไขว่าปัญหาเกิดขึ้นเนื่องจากความผิดของซัพพลายเออร์
- หากปัญหาของคุณเกิดขึ้นเนื่องจากบุคคลที่สาม (บนทางหลวง) ดูเหมือนว่า “ไม่มีใครถูกตำหนิ” และเมื่อปัญหาได้รับการแก้ไขก็ขึ้นอยู่กับโชคของคุณ
อย่างไรก็ตาม สิ่งสำคัญคือต้องเข้าใจว่าคุณจะไม่สามารถเข้าถึงทีมวิศวกรได้ โดยส่วนใหญ่แล้วคุณมักจะถูกหยุดโดยฝ่ายสนับสนุนระดับแรกที่ติดต่อคุณในขณะที่วิศวกรตัวจริงพยายามแก้ไขสถานการณ์ เสียงที่คุ้นเคย?
ที่นี่ หลายๆ คนพึ่งพา SLA ซึ่งดูเหมือนว่าจะปกป้องคุณจากสถานการณ์ดังกล่าว แต่ในความเป็นจริงแล้ว บริษัทต่างๆ แทบจะไม่ก้าวข้ามขอบเขตของเอกสารของตนเองหรือสามารถพลิกสถานการณ์ในลักษณะที่จะลดต้นทุนของตนเองได้ ภารกิจหลักของ SLA คือการเฝ้าระวังและโน้มน้าวว่าแม้ในกรณีที่เกิดสถานการณ์ที่ไม่คาดฝัน “ทุกอย่างจะเรียบร้อยดี” วัตถุประสงค์ที่สองของ SLA คือการสื่อสารประเด็นสำคัญที่สำคัญ และให้พื้นที่แก่ผู้ให้บริการในการจัดทำ ซึ่งก็คือ ความสามารถในการระบุถึงความล้มเหลวของบางสิ่งที่ซัพพลายเออร์ "ไม่รับผิดชอบ"
ในเวลาเดียวกัน ลูกค้ารายใหญ่ไม่ได้สนใจเรื่องค่าตอบแทนภายใน SLA เลย “การชดเชย SLA” คือการคืนเงินภายในอัตราภาษีตามสัดส่วนการหยุดทำงานของอุปกรณ์ ซึ่งจะไม่ครอบคลุมแม้แต่ 1% ของการสูญเสียทางการเงินและชื่อเสียงที่อาจเกิดขึ้น ในกรณีนี้ ลูกค้าจะต้องแก้ไขปัญหาโดยเร็วที่สุดมากกว่า "การคำนวณภาษีใหม่" บางประเภท
“ศูนย์ข้อมูลหลายแห่งทั่วโลก” เป็นเรื่องที่น่ากังวล
เราได้วางสถานการณ์ที่มีศูนย์ข้อมูลจำนวนมากไว้ที่ผู้ให้บริการในหมวดหมู่แยกต่างหาก เนื่องจากนอกเหนือจากปัญหาการสื่อสารที่ชัดเจนที่อธิบายไว้ข้างต้นแล้ว ปัญหาที่ไม่ชัดเจนยังเกิดขึ้นอีกด้วย ตัวอย่างเช่น ผู้ให้บริการของคุณไม่สามารถเข้าถึงศูนย์ข้อมูล “ของพวกเขา” ได้
ในบทความล่าสุดของเรา สาระสำคัญคือการขายต่อความสามารถของผู้อื่นภายใต้หน้ากากของตัวเอง ผู้ให้บริการโฮสต์สมัยใหม่ส่วนใหญ่ที่อ้างว่ามี “ศูนย์ข้อมูลของตนเอง” ในหลายภูมิภาคเป็นผู้ค้าปลีกที่ใช้โมเดล White Label กล่าวคือ โดยทางกายภาพแล้วพวกเขาไม่ได้เกี่ยวข้องอะไรกับศูนย์ข้อมูลแบบมีเงื่อนไขในสวิตเซอร์แลนด์ เยอรมนี หรือเนเธอร์แลนด์
การชนที่น่าสนใจอย่างยิ่งเกิดขึ้นที่นี่ SLA ของคุณกับผู้ให้บริการยังคงใช้งานได้และใช้ได้ แต่ซัพพลายเออร์ไม่สามารถมีอิทธิพลต่อสถานการณ์อย่างรุนแรงในกรณีที่เกิดอุบัติเหตุได้ ตัวเขาเองอยู่ในตำแหน่งที่ต้องพึ่งพาซัพพลายเออร์ของเขาเอง - ศูนย์ข้อมูลที่ซื้อชั้นวางพลังงานเพื่อขายต่อ
ดังนั้น หากคุณไม่เพียงให้ความสำคัญกับถ้อยคำที่สวยงามในสัญญาและ SLA เกี่ยวกับความน่าเชื่อถือและการบริการ แต่ยังรวมถึงความสามารถของผู้ให้บริการในการแก้ปัญหาอย่างรวดเร็ว คุณควรทำงานโดยตรงกับเจ้าของสิ่งอำนวยความสะดวก สิ่งนี้เกี่ยวข้องกับการโต้ตอบโดยตรงกับศูนย์ข้อมูลโดยตรง
ทำไมเราไม่พิจารณาทางเลือกต่างๆ ในเมื่อ DC จำนวนมากสามารถอยู่ในบริษัทเดียวได้ มีบริษัทประเภทนี้น้อยมาก ศูนย์ข้อมูลขนาดเล็กหนึ่ง สอง สามแห่งหรือใหญ่หนึ่งแห่งก็เป็นไปได้ แต่ DC หลายสิบแห่งซึ่งครึ่งหนึ่งอยู่ในสหพันธรัฐรัสเซียและแห่งที่สองในยุโรปนั้นแทบจะเป็นไปไม่ได้เลย ซึ่งหมายความว่ามีบริษัทตัวแทนจำหน่ายมากมายเกินกว่าที่คุณจะจินตนาการได้ นี่เป็นตัวอย่างง่ายๆ:
ประมาณจำนวนศูนย์ข้อมูลบริการ Google Cloud มีเพียงหกคนในยุโรป ในลอนดอน อัมสเตอร์ดัม บรัสเซลส์ เฮลซิงกิ แฟรงก์เฟิร์ต และซูริก กล่าวคือ ณ จุดทางหลวงสายหลักทุกแห่ง เนื่องจากศูนย์ข้อมูลมีราคาแพง ซับซ้อน และเป็นโครงการขนาดใหญ่มาก ตอนนี้ จำบริษัทโฮสติ้งจากที่ไหนสักแห่งในมอสโกที่มี “ศูนย์ข้อมูลหลายสิบแห่งทั่วรัสเซียและยุโรป”
แน่นอนว่าไม่มีซัพพลายเออร์ที่ดีที่มีพันธมิตรในโครงการ White Label ก็มีเพียงพอและพวกเขาก็ให้บริการในระดับสูงสุด พวกเขาทำให้สามารถเช่าความจุในสหภาพยุโรปและสหพันธรัฐรัสเซียพร้อมกันผ่านหน้าต่างเบราว์เซอร์เดียวกัน รับการชำระเงินเป็นรูเบิล ไม่ใช่สกุลเงินต่างประเทศ และอื่นๆ แต่เมื่อกรณีที่อธิบายไว้ใน SLA เกิดขึ้น พวกเขาจะกลายเป็นตัวประกันคนเดียวกันกับคุณทุกประการ
สิ่งนี้เตือนเราอีกครั้งว่า SLA จะไม่มีประโยชน์หากคุณไม่มีความเข้าใจเกี่ยวกับโครงสร้างองค์กรและความสามารถของซัพพลายเออร์
ผลลัพธ์คืออะไร
เซิร์ฟเวอร์ล่มนั้นเป็นเหตุการณ์ที่ไม่พึงประสงค์เสมอและสามารถเกิดขึ้นได้กับทุกคนทุกที่ คำถามคือคุณต้องการควบคุมสถานการณ์มากน้อยเพียงใด ขณะนี้ในตลาดมีซัพพลายเออร์โดยตรงที่มีกำลังการผลิตไม่มากนัก และถ้าเราพูดถึงผู้เล่นรายใหญ่ พวกเขาก็เป็นเจ้าของ DC เพียงแห่งเดียวในมอสโกจากหลายสิบแห่งทั่วยุโรปที่คุณสามารถเข้าถึงได้
ลูกค้าแต่ละรายจะต้องตัดสินใจด้วยตัวเองว่า: ฉันจะเลือกความสะดวกสบายในตอนนี้หรือใช้เวลาและความพยายามในการค้นหาศูนย์ข้อมูลในตำแหน่งที่ยอมรับได้ในรัสเซียหรือยุโรป ซึ่งฉันสามารถวางอุปกรณ์หรือซื้อความจุได้ ในกรณีแรก โซลูชันมาตรฐานที่มีอยู่ในตลาดปัจจุบันมีความเหมาะสม ในวินาทีที่คุณจะต้องเหงื่อออก
ก่อนอื่น จำเป็นต้องพิจารณาว่าผู้ขายบริการเป็นเจ้าของสิ่งอำนวยความสะดวก/ศูนย์ข้อมูลโดยตรงหรือไม่ ผู้ค้าปลีกหลายรายที่ใช้โมเดล White Label พยายามอย่างเต็มที่เพื่อปกปิดสถานะของตนเอง และในกรณีนี้ คุณจำเป็นต้องมองหาสัญญาณทางอ้อม ตัวอย่างเช่น หาก “DCs ในยุโรปของพวกเขา” มีชื่อและโลโก้เฉพาะบางอย่างที่แตกต่างจากชื่อของบริษัทซัพพลายเออร์ หรือถ้ามีคำว่า “คู่หู” ปรากฏที่ไหนสักแห่ง พันธมิตร = White Label ใน 95% ของกรณี
ถัดไป คุณต้องทำความคุ้นเคยกับโครงสร้างของบริษัท หรือดูอุปกรณ์ด้วยตนเองดีกว่า ในบรรดาศูนย์ข้อมูล การฝึกทัศนศึกษาหรืออย่างน้อยบทความเกี่ยวกับการท่องเที่ยวบนเว็บไซต์หรือบล็อกของตนเองไม่ใช่เรื่องใหม่ (เราเขียนเช่นนั้น и ) โดยพูดคุยเกี่ยวกับศูนย์ข้อมูลพร้อมรูปถ่ายและคำอธิบายโดยละเอียด
ด้วยศูนย์ข้อมูลจำนวนมาก คุณสามารถนัดหมายการเยี่ยมชมสำนักงานเป็นการส่วนตัวและการเดินทางสั้นๆ ไปยัง DC ได้ คุณสามารถประเมินระดับของการสั่งซื้อได้ที่นั่นบางทีคุณอาจจะสามารถสื่อสารกับวิศวกรคนใดคนหนึ่งได้ เป็นที่แน่ชัดว่าจะไม่มีใครทัวร์ชมการผลิตหากคุณต้องการเซิร์ฟเวอร์หนึ่งตัวในราคา 300 RUB ต่อเดือน แต่ถ้าคุณต้องการความจุที่จริงจัง ฝ่ายขายก็อาจมาพบคุณได้ ตัวอย่างเช่น เราดำเนินการทัศนศึกษาดังกล่าว
ไม่ว่าในกรณีใด ควรใช้สามัญสำนึกและความต้องการทางธุรกิจ ตัวอย่างเช่น หากคุณต้องการโครงสร้างพื้นฐานแบบกระจาย (เซิร์ฟเวอร์บางตัวอยู่ในสหพันธรัฐรัสเซีย และอีกเซิร์ฟเวอร์หนึ่งในสหภาพยุโรป) การใช้บริการของผู้ให้บริการโฮสต์ที่เป็นพันธมิตรกับ DC ของยุโรปโดยใช้ White Label จะง่ายกว่าและให้ผลกำไรมากกว่า แบบอย่าง. หากโครงสร้างพื้นฐานทั้งหมดของคุณกระจุกตัวอยู่ที่จุดเดียว นั่นคือในศูนย์ข้อมูลแห่งเดียว ก็คุ้มค่าที่จะใช้เวลาค้นหาซัพพลายเออร์
เนื่องจาก SLA ทั่วไปไม่น่าจะช่วยคุณได้ แต่การทำงานร่วมกับเจ้าของสิ่งอำนวยความสะดวกและไม่ใช่ผู้ค้าปลีกจะช่วยเร่งการแก้ไขปัญหาที่อาจเกิดขึ้นได้อย่างมาก
ที่มา: will.com