นี่เป็นเรื่องราวส่วนตัวของฉันในการเริ่มต้นองค์กร SRE ที่ Uber หากคุณต้องการคำแนะนำมากกว่าความทรงจำ ให้ดูที่ Trunk and Branches Model and Productivity ในยุคของการเติบโตอย่าง รวดเร็ว
หลังจากที่ฉันออกจาก SocialCode ในปี 2014 ฉันใช้เวลาหนึ่งเดือนในการสัมภาษณ์บริษัทไม่กี่แห่งที่พยายามคิดว่าจะทำอะไรต่อไป ฉันถูกแยกไม่ออกระหว่างการพิจารณาสองเส้นทางที่แตกต่างกัน: (1) วิศวกรรมชั้นนำในการเริ่มต้นขนาดเล็กมาก หรือ (2) บทบาทที่เล็กกว่ามากในบริษัทที่เติบโตอย่างรวดเร็ว โดยคาดหวังว่าการเติบโตจะสร้างโอกาส หลังจากไตร่ตรองอยู่พักหนึ่ง ฉันก็ลงเอยด้วยการใช้เส้นทางหลังเพื่อเข้าร่วม Uber
ฉันลืมไทม์ไลน์การสัมภาษณ์ที่แน่นอนที่ Uber แต่มันเป็นแนวเดียวกับ “การสัมภาษณ์ในวันอังคาร ข้อเสนอในวันพุธ และเริ่มในวันจันทร์ถัดไป (นี่ไม่ใช่การพลิกกลับที่เร็วที่สุดที่ฉันเคยเห็นที่ Uber ซึ่งค่อนข้างห่างไกลจากนี้มาก! ฉันเคยยื่นข้อเสนอให้ใครสักคนในวันศุกร์เวลาประมาณ 5:00 น. ซึ่งแจ้งให้ทราบและเริ่มดำเนินการในอีกสองวันต่อมาในวันจันทร์) บทบาทที่ฉันเป็น จ้างเป็น “DevOps Manager” ซึ่งในตอนแรกฉันค่อนข้างประหม่าเพราะฉันไม่ค่อยแน่ใจว่า DevOps หมายถึงอะไร ระหว่างรอวันหยุดสุดสัปดาห์เพื่อเริ่มต้น ฉันอ่านThe Phoenix Project อย่างใจจดใจจ่อเพื่อพยายามทำวิศวกรรมย้อนกลับในสิ่งที่ฉันเพิ่งได้รับการว่าจ้างให้ทำ
เท่าที่ฉันจำได้ มีสี่ทีมที่ทำสิ่งที่อาจเรียกกันว่า “โครงสร้างพื้นฐาน” แบบคลาสสิกเมื่อฉันเริ่มต้น ทีมวิศวกรรมข้อมูลและแผนที่ยังถูกจัดกลุ่มไว้ภายใต้องค์กรโครงสร้างพื้นฐานด้วย แต่พวกเขาค่อนข้างจะเน้นไปที่งานอื่น ดังนั้นฉันจะพูดถึงพวกเขาตามความสะดวกในการเล่าเรื่อง
ทีมโครงสร้างพื้นฐาน ได้แก่ (1) ทีมเครื่องมือสำหรับนักพัฒนา (2) ทีมวิศวกรโครงสร้างพื้นฐานด้านวิศวกรรมซึ่งมุ่งเน้นที่การเอาชนะความต้องการพื้นที่ดิสก์ของดัชนี PostgreSQL (3) ทีมในเดนมาร์กเน้นที่เครื่องมือการปรับใช้เป็นหลัก และ (4) ทีม InfraOps ที่ทำอย่างอื่น เรามีคนประมาณยี่สิบคนภายในองค์กรด้านวิศวกรรมที่มีประมาณสองร้อยคน อย่างรวดเร็วไปสู่สองพันคน
ฉันเข้าร่วมทีมสุดท้าย InfraOps เราห้าคนและรับผิดชอบในการบำรุงรักษาเซิร์ฟเวอร์ส่วนใหญ่ของบริษัท (Uber ไม่ได้ใช้ผู้ให้บริการระบบคลาวด์ ณ จุดนั้น) โครงสร้างพื้นฐานการกำหนดเส้นทาง (ส่วนใหญ่เป็น HAProxy) Kafka ฐานข้อมูลส่วนใหญ่ การจัดเตรียมบริการ (ใน “บริการที่มุ่งเน้น- สถาปัตยกรรม” ความรู้สึกของคำ) สิ่งด้านความปลอดภัยบางอย่าง (ในเวลานั้นมีวิศวกรความปลอดภัยเพียง คนเดียว ) หุ่นเชิด Clusto และนอตต่าง ๆ ของซอฟต์แวร์ที่อยู่ระหว่างเบาะรองขององค์กร
เมื่อฉันเริ่มต้น ฉันตรวจสอบความท้าทายของทีมและจำกัดให้เหลือพื้นที่ไม่กี่แห่งที่ต้องมุ่งเน้นอย่างเร่งด่วน: รักษาไซต์ให้ทำงานต่อไป (สิ่งต่างๆ มักผิดพลาดในช่วงบ่ายวันศุกร์เนื่องจากการเร่งโหลด และโทรศัพท์ของผู้อื่นหมดเป็นประจำ พลังอันเนื่องมาจากการส่งสัญญาณ Pagerduty ระหว่างการเปลี่ยนแปลงการโทร 12 ชั่วโมง), การปรับขนาด Kafka, การเตรียมพร้อมที่จะย้ายออกจากศูนย์ข้อมูลแห่งแรกของเราก่อนที่ปริมาณการใช้ข้อมูลในวันฮาโลวีนของ Uber จะพุ่งสูงขึ้น (เราตัดสินใจที่จะไม่ซื้อความจุเพิ่มเติมในศูนย์ข้อมูลปัจจุบันของเรา ดังนั้นสิ่งนี้ เป็นเส้นตายที่เข้มงวด) และสนับสนุนคำขอที่เข้ามาเพื่อให้บริการ ในสัปดาห์ที่สองและสามของฉัน ฉันได้เขียนกลยุทธ์สำหรับแต่ละรายการ และรู้สึกสั้นๆ ว่าเรามีเส้นทางข้างหน้าที่ชัดเจน
แผนเหล่านั้น – เป็นไปตามวัตถุประสงค์สูงสุดของฉันและไม่มีทางจดจำตัวเองได้ – แผนที่ยอดเยี่ยมที่สุด แผนการที่ดีดังกล่าว ซึ่งผู้จัดการของฉันจะเล่าในภายหลังว่าในตอนแรกเขากังวลว่าฉันจะเข้าไปข้างในและแก้ปัญหาที่เขากำลังเผชิญอยู่ทันที แน่นอน ในไม่ช้าก็จะเป็นที่ชัดเจนว่าแผนที่ยอดเยี่ยมเหล่านั้นทำงานได้ดีที่สุดบนกระดาษ
ขั้นตอนแรกของเราคือการตั้งค่า ตำราบริการ : ไฟล์ YAML ที่อธิบายงานที่เราทำสำหรับทีมอื่น และแอปพลิเคชัน Python Flask ที่รวบรวมไฟล์นั้นเป็น UI ที่ทำให้คำขอเหล่านั้นเป็นไปโดยอัตโนมัติหากเป็นไปได้ และสร้างตั๋วที่มีโครงสร้างดีซึ่งรวมถึงสิ่งที่จำเป็น ข้อมูลเพื่อให้งานเสร็จสมบูรณ์ ระบบตั๋วของเราในขณะนั้น ฟาบริเคเตอร์ ไม่รองรับการเพิ่มฟิลด์ที่จำเป็นสำหรับคำขอประเภทต่างๆ ดังนั้นตำราบริการจึงให้คุณค่ามากมายเพียงแค่ทำให้แน่ใจว่าข้อมูลที่ถูกต้องถูกรวมไว้กับคำขอแต่ละรายการ ที่สำคัญยิ่งกว่านั้น หนังสือบริการให้ข้อมูลบางอย่างที่เราพลาดไป นั่นคือข้อมูลเกี่ยวกับคำขอที่เข้ามา
เมื่อมีการรวบรวมข้อมูลการใช้งาน ในไม่ช้ามันก็ชัดเจนว่าเราใช้เวลาส่วนใหญ่ของเราในการตอบสนองต่อไฟไหม้การผลิตที่สำคัญ ซึ่งไม่ใช่สิ่งที่เรามองข้ามไป หรือจัดเตรียมบริการใหม่
การให้บริการ
การทำงานในเสาหินขนาดใหญ่ของ Uber กลายเป็นเรื่องยาก: การโยกย้ายมีความเสี่ยง การปรับใช้ช้า การดีบักเหตุการณ์เป็นสิ่งที่ท้าทายเพราะการปรับใช้แต่ละครั้งรวมถึงภาระผูกพันของหลายทีม เป็นต้น มีการตัดสินใจเลิกใช้เสาหินก้อนนี้ และทีมต่างๆ ก็หนีออกจากบริการใหม่โดยเร็วที่สุด
การจัดหาบริการเป็นกระบวนการที่ไม่แน่นอน หลังจากรันบุ๊กที่ยาวนานและต้องมีการปรับใช้การอัพเดตหุ่นตามลำดับบนโฮสต์ที่แตกต่างกันอย่างน้อยสามระดับ นอกเหนือจากการรวมบิตที่มีแนวโน้มผิดพลาดจำนวนมากใน Clusto (คล้ายกับ กงสุลของ Hashicorp แต่ก่อนนั้นด้วย บางปี กองเทคโนโลยีโครงสร้างพื้นฐานเริ่มต้นของ Uber ส่วนใหญ่ถูกย้ายจาก Digg โดย Jeremy วิศวกรรุ่นแรกๆ หลังจากขั้นตอนเหล่านั้น คุณจะเริ่มแก้ไขข้อบกพร่องในสิ่งที่คุณหรือทีมที่ขอใช้บริการใหม่ ทำผิดอย่างหลีกเลี่ยงไม่ได้ โดยรวมแล้ว คุณสามารถใช้เวลาครึ่งวันในการเตรียมใช้งานบริการใหม่อย่างง่ายดาย และอีกสัปดาห์กลับไปกลับมากับทีมเจ้าของบริการเพื่อให้งานสุดท้ายทำงานได้อย่างถูกต้อง
เราล้าหลังมากขึ้นอีกเล็กน้อยในแต่ละสัปดาห์เกี่ยวกับงานในมือในการจัดหาบริการ และเราไม่สามารถเพิ่มคนอื่นๆ ให้กับความพยายามในการเตรียมใช้งานโดยไม่นำพวกเขาออกจากความคิดริเริ่มเร่งด่วนอื่นๆ ของเรา ดังนั้นเราจึงมุ่งเน้นไปที่เครื่องมืออัตโนมัติที่ดีที่สุดของเรา
เรามีบุคลากรไม่มากนักที่จะทุ่มเทให้กับการจัดหาบริการ ดังนั้นในตอนแรก มีเพียงฉันที่ทำงานนอกเวลาและวิศวกรที่เข้าร่วมในวันเดียวกับที่ฉันทำ Xiaojian เท่านั้นยังไม่พอ เราจึงจ้างวิศวกรคนที่สองมาทำงานเต็มเวลาในไม่ช้านี้ วู้ดดี้ วู้ดดี้ใช้เวลามากในการจัดหาบริการจนเมื่อมีคนสับสนเมื่อรู้ว่าวู้ดดี้เป็นคนและไม่ใช่บอทของ Hipchat
ตำราบริการของเราได้ให้อินเทอร์เฟซแก่เราในการสกัดกั้นคำขอการจัดหาบริการที่เข้ามา และเรายังคงขยายการใช้เครื่องมือจนกว่าผู้คนจะจัดเตรียมได้อย่างเต็มที่โดยไม่ได้รับการสนับสนุนจากทีม ขั้นตอนระหว่างกาลบางอย่างค่อนข้างน่าอึดอัดใจ! โดยเฉพาะอย่างยิ่ง ฉันจำขั้นตอนหนึ่งที่เราสร้างการกำหนดค่า Puppet โดยอัตโนมัติสำหรับบริการใหม่แต่ละรายการ แต่ยังต้องการวิศวกรที่ร้องขอเพื่อรวมการเปลี่ยนแปลงในตัวเองจริงๆ ผู้คนค่อนข้างสับสนที่จะขอยุติบริการใหม่โดยวางการเปลี่ยนแปลงในที่เก็บหุ่นของเราและหวังว่ามันจะไม่เสียหายอะไร
ความท้าทายย่อยที่น่าสนใจอีกอย่างหนึ่งคือการค้นหาบริการและการกำหนดเส้นทาง เราค้นพบบริการผ่าน HAProxy ซึ่งคุณจะกำหนดเส้นทางไปยังบริการภายในสภาพแวดล้อมปัจจุบันของคุณโดยเชื่อมต่อบน localhost กับพอร์ตที่จัดสรรแบบคงที่ของบริการ ซึ่ง HAProxy จะกำหนดเส้นทางไปยังอินสแตนซ์ที่ทำงานอยู่ที่ไหนสักแห่งในสภาพแวดล้อมนั้น HAProxy ได้รับการกำหนดค่าในแต่ละเซิร์ฟเวอร์ทีละตัวเมื่อ Puppet ทำงาน โดยทั่วไปทุกๆ ชั่วโมงในแต่ละเซิร์ฟเวอร์ (การวิ่งหุ่นกระบอกรายชั่วโมงใช้เวลามากกว่ายี่สิบนาที ดังนั้นคุณจึงมีเวลาประมาณห้านาทีระหว่างการเปลี่ยนแปลงหุ่นที่ไม่ถูกต้องที่เริ่มเผยแพร่และกองเรือทั้งหมดล่ม เราเก่งในการหยุดการเปิดตัวชั่วคราวภายใต้การข่มขู่ แต่เราก็ทำผิดพลาดหลายอย่างเช่นกัน) ในการจัดหาบริการใหม่ คุณต้องจองพอร์ตที่ไม่ซ้ำกันทั่วโลก หากคุณนำพอร์ตกลับมาใช้ใหม่ คุณย่อมทำให้เกิดการหยุดทำงานอย่างหลีกเลี่ยงไม่ได้ ตอนแรกพอร์ตถูกบันทึกในหน้าวิกิที่ใดที่หนึ่ง ถึงแม้ว่าหลายๆ พอร์ตจะไม่ได้บันทึกไว้ที่ใดก็ตาม เพื่อให้ขั้นตอนการเตรียมบริการนี้เป็นแบบอัตโนมัติ เราเปลี่ยนจากการมอบหมายด้วยตนเองเป็นการมอบหมายอัตโนมัติ เป็นตัวอย่างที่ดีของตัวเลือกแรกๆ มากมายที่เราต้องผ่อนคลายอย่างเร่งด่วนเพื่อทำให้กระบวนการทั้งหมดเป็นไปโดยอัตโนมัติ
ปัญหาเหล่านี้ไม่ได้เกิดจาก “ทางเลือกที่ไม่ดี” ในการตั้งค่าโครงสร้างพื้นฐานเดิมแต่อย่างใด เช่นเดียวกับการตัดสินใจทางเทคนิคส่วนใหญ่ วิธีการต่างๆ ก็ไม่สามารถคงอยู่ได้เหมือนเดิมผ่านลำดับความสำคัญของการเติบโตหลายระดับ ความท้าทายมากมายที่เราพบนั้นแทบไม่เคยได้ยินมาก่อนในทุกวันนี้ แต่เครื่องมือส่วนใหญ่ที่จัดการกับปัญหาเหล่านี้ในปัจจุบันนั้นไม่มีอยู่จริงในฐานะตัวเลือกที่ได้รับการพิสูจน์แล้วเมื่อโครงสร้างพื้นฐานของ Uber ได้รับการตั้งค่าครั้งแรก (ในตัวอย่างภายหลัง Uber จะลงเอยด้วยการใช้ Mesos มากกว่า Kubernetes เนื่องจาก Kubernetes ในขณะนั้นเป็นโครงการแรกๆ ที่ไม่มีการใช้งานมากในขณะโหลด)
เมื่อเราแก้ไขปัญหาแต่ละข้อแล้ว การให้บริการก็เร็วขึ้นและมีโอกาสเกิดข้อผิดพลาดน้อยลง ภายใน 18 เดือน เราปรับขนาดจากบริการ 15 รายการเป็นมากกว่า 2,000 รายการ โดยทุกบริการเหล่านั้นจัดเตรียมโดยทีมนี้หรือแพลตฟอร์มที่พวกเขาสร้างขึ้น เมื่อทีมงานไปถึงจุดสูงสุดที่คนประมาณสี่คนที่ทำงานเกี่ยวกับปัญหานี้ คนส่วนใหญ่ก็ทำผ่านแพลตฟอร์ม ห่างไกลจากการทำงานข้ามทีมในช่วงเริ่มต้น ซึ่งใช้เวลา 1 สัปดาห์ การจัดหาบริการกลายเป็นเรื่องง่ายพอที่ถึงจุดหนึ่งวิศวกรที่เริ่มต้นใช้งานทุกคนจะจัดเตรียมบริการใหม่ในวันแรกของพวกเขา
จำนวนพนักงาน
นอกจากงานด้านระบบอัตโนมัติแล้ว เรายังเพิ่มการจ้างงานอีกด้วย ความท้าทายแรกที่ฉันพบ คือทีมปฏิเสธผู้สมัครทุกคน ในการสัมภาษณ์ผู้จัดการของฉัน ฉันลงเอยด้วยการทำ ปัญหาพนักงานขายเดินทาง ใน Python บนกระดานไวท์บอร์ด และนั่นก็เป็นเรื่องปกติสำหรับกระบวนการสัมภาษณ์ ไม่มีคำถามที่เป็นมาตรฐาน ไม่มีรูบริกสำหรับการประเมินผู้สมัคร และโครงสร้างโดยรวมก็แตกต่างกันไปสำหรับผู้จัดการการจ้างงานทุกคน
วันนี้ ฉันจะเริ่มต้นด้วยการออกแนวปฏิบัติทั่วไปเหล่านั้น แต่ ณ จุดนั้นในอาชีพของฉัน ฉันไม่เคยเห็นหรือได้ยินเกี่ยวกับแนวปฏิบัติที่ดีที่สุดเหล่านั้นมาก่อน ดังนั้นฉันจึงนั่งกับพันธมิตรสรรหาและแก้ปัญหาว่าทำไมแต่ละลูปไม่สามารถสร้างข้อเสนอได้ สำหรับผู้สมัครที่ฉันคิดว่าสามารถช่วยเราให้รอดพ้นจากการโจมตีของงานที่เข้ามา ฉันจะไปโต้เถียงกับทีมว่าทำไมเราถึงต้องจ้างพวกเขา ในที่สุดพวกเขาก็รู้สึกรำคาญที่มีข้อโต้แย้งแบบเดียวกันกับฉันและเริ่มเห็นด้วยกับการจ้างผู้สมัครบางคน
ในฐานะคนที่เคยจ้างวิศวกรสักหกคนก่อนมาร่วมงานกับ Uber นี่คือการรับบัพติศมาด้วยไฟอย่างแท้จริง ปีแรกของฉันที่ Uber ในแต่ละสัปดาห์ฉันมักจะทำหน้าจอโทรศัพท์สิบหน้าจอพร้อมกับการสัมภาษณ์สี่หรือห้าครั้ง ฉันจำได้แม่นว่าอยู่ในห้องกระจกเหล่านี้หลังจากทำหน้าจอโทรศัพท์แบบแบ็คทูแบ็คสามหน้าจอในวันหนึ่งและพยายามแยกความแตกต่างระหว่างตัวเลือกในบันทึกย่อของฉัน เราทำการสัมภาษณ์มากจนพัฒนากระบวนการในการหมุนเวียนผู้สัมภาษณ์ที่ดีในเชิงรุกออกจากการสัมภาษณ์เมื่อพวกเขาเริ่มหมดไฟ
นอกจากนี้เรายังมีประสบการณ์การจ้างงานทั้งที่สนุกสนานและน่าสยดสยองอันเป็นผลมาจากการกำกับดูแลหรือมาตรฐานเพียงเล็กน้อย เราปฏิเสธผู้สมัครคนหนึ่ง ซึ่งผู้อ้างอิงโน้มน้าวให้เราสัมภาษณ์พวกเขาอีกครั้งในอีกหกเดือนต่อมา ซึ่งเราปฏิเสธพวกเขาอีกครั้งในทันที ไม่ติดใจ อีกทีมยืนยันสัมภาษณ์ผู้สมัครเป็นครั้งที่สาม ฉันติดต่อผู้จัดการทีมเพื่อห้ามปรามพวกเขา แต่พวกเขาก็ยืนกรานและยื่นข้อเสนอ ผู้สมัครยอมรับ โดยเริ่มต้นที่ Uber จากนั้นสองสามชั่วโมงในวันแรกของพวกเขา พวกเขายอมรับข้อเสนอที่สองที่ Twitter แทน (ตามสะดวก ห่างออกไปหนึ่งช่วงตึก) ในท้ายที่สุด พวกเขาสัมภาษณ์ครั้งที่ Uber มากกว่าชั่วโมงทำงานที่นั่น
การจ้างงานในอัตรานี้ ควบคู่ไปกับการยิงจากการผลิตบ่อยครั้ง และทีมพันธมิตรที่ท้อแท้หลั่งไหลเข้ามาบ่อยครั้ง ไม่ต้องสงสัยเลยว่าเป็นการทำงานหนักที่สุดเท่าที่ฉันเคยทำงานมา มันสิ้นเปลืองทั้งหมด ด้านบวกก็ใช้งานได้ เราจ้างคนค่อนข้างน้อย และภายในหนึ่งปี เราก็เติบโตขึ้นจากห้าคนเป็นประมาณสี่สิบคนที่ขับเคลื่อนด้วยการจ้างงานภายนอกทั้งหมด
ก่อตั้ง SRE
เมื่อทีมของเราเติบโตขึ้นและการทำงานอัตโนมัติของเราดีขึ้น แผนของเราบ่งชี้ว่าสถานการณ์ต่างๆ จะดีขึ้น แต่พวกเขาไม่ได้ เรายังคงอยู่ใต้น้ำลึก แนวทางของเรา ได้ ผล แต่ทำงานได้ไม่เร็วพอ องค์กรด้านวิศวกรรมเพิ่มขึ้นเป็นสองเท่ารอบตัวเราทุก ๆ หกเดือน และทุก ๆ สองสามเดือนได้นำเสนอโครงการใหม่เร่งด่วนในระดับเช่น การจัดเตรียมศูนย์ข้อมูลใหม่สองแห่งในประเทศจีน
เราจะทำอะไรได้อีกบ้างเพื่อขุดออกมาจากใต้ภาระงานนี้ หากการเพิ่มขีดความสามารถของมนุษย์และซอฟต์แวร์ไม่เพียงพอ ทางเลือกเดียวที่เราคิดได้คือทำงานให้น้อยลง ชัดเจนมาก! วิธีการใด ๆ ในการทำน้อยต้องเป็นไปตามข้อกำหนดเฉพาะสองประการ ประการแรก เราต้องรักษาความสามารถของเราในการจัดหาพนักงานเกี่ยวกับปัญหาการผลิตที่คาดเดาไม่ได้แต่หลีกเลี่ยงไม่ได้ ซึ่งมาพร้อมกับภาระงานที่เพิ่มขึ้นเป็นสองเท่าทุก ๆ หกเดือน ประการที่สอง เราต้องให้การสนับสนุนอย่างเพียงพอแก่ทีมวิศวกรอื่นๆ เพื่อให้พวกเขาสามารถก้าวไปข้างหน้าตามเป้าหมายที่สำคัญและเป็นอิสระ
มีความเชื่อแบบมีมว่าวิธีแก้ปัญหาในการทำน้อยลงคือการบังคับให้ผู้จัดการของคุณจัดลำดับความสำคัญของภาระงานของคุณ แต่ฉันเห็นว่ากลยุทธ์นี้ใช้ได้เฉพาะในองค์กรที่ค่อนข้างบนลงล่าง นอกจากนี้ยังเป็นวิธีที่แน่นอนในการลดระดับตนเองจากผู้นำเป็นผู้จัดการ เป็นที่ยอมรับว่าหมกมุ่นอยู่กับทีมของเรามากเกินไปที่จะเอาชนะความท้าทายนี้ด้วยตัวเราเองโดยคิดว่าจะขอความช่วยเหลือ ในที่สุด เราก็ได้แนวทางอื่น: เราสามารถแก้ไขข้อจำกัดเหล่านี้โดยการเปลี่ยนรูปร่างขององค์กรของเราได้หรือไม่?
เป็นคำถามดังกล่าวที่จุดประกายให้เกิดการก่อตั้งองค์กร SRE ของ Uber
เรามีพนักงานคอยปรับขนาดโครงสร้างพื้นฐานของเราหากเราสามารถปกป้องพวกเขาจากคำของานที่เข้ามาได้ ดังนั้นเราจึงมุ่งเน้นไปที่วิธีปกป้องทีมเหล่านั้นจากการขัดจังหวะในขณะเดียวกันก็ให้การสนับสนุนทีมที่ร้องขออย่างเพียงพอเพื่อความก้าวหน้า โครงสร้างมีประสิทธิภาพ:
- พันธมิตรองค์กรชั้นนำสามหรือสี่รายของเราจะได้รับการสนับสนุน SRE โดยเฉพาะ ทีมพันธมิตรจะจัดลำดับความสำคัญของภาระงานของ SRE ที่สนับสนุนพวกเขาอย่างชัดเจน เรากำหนด “อันดับสูงสุด” ตามจำนวนคำขอ ไม่ใช่โดยผลกระทบ
- คนอื่นๆ จะได้รับการสนับสนุนจากทีมที่สร้างแพลตฟอร์มการบริการตนเอง พวกเขาจะจัดลำดับความสำคัญการทำงานบนหลักการเร่งอัตโนมัติ
- โครงสร้างพื้นฐานที่เหลือจะสนับสนุนด้านความสามารถในการปรับขนาดและการทำงานเฉพาะ เช่น เครือข่าย Kafka โดยส่วนใหญ่จะให้ความสำคัญกับความสามารถในการปรับขนาด การใช้งาน และประสิทธิภาพเป็นหลัก
เมื่อเราเริ่มดำเนินการนี้ เราพบปัญหา Uber ทั่วไป: เราไม่มีใครคอยดูแลทีม SRE อย่างไรก็ตาม ไม่นานนักที่เราจะจ้าง SRE แห่งแรกของ Uber คือ Rick Eamon ผู้จัดการ SRE คนแรกของ Uber และจ้างงานเพิ่มขึ้นจากที่นั่น
คำพูดที่สร้างแรงบันดาลใจของฉันกับริคตอนที่เขาเข้าร่วมนั้นไม่ค่อยดีเท่าไหร่ บางอย่างก็เหมือนกับว่า “คุณฉลาดและมีประสบการณ์จริงๆ คุณต้องช่วยทีมหุ้นส่วนนี้ให้ทำงานของพวกเขาให้ลุล่วงโดยไม่ต้องร้องขอใดๆ จากทีมโครงสร้างพื้นฐานในวงกว้าง ไม่ต้องรออนุญาต ไปทำธุระ ขอให้โชคดี!” ทั้งหมดนี้เป็นเครดิตของ Rick วิธีนี้ได้ผล
หลังจากนั้นไม่นาน วิศวกรอีกคนหนึ่งก็ได้รับการว่าจ้างให้เข้าร่วมกับริคโดยทำงานร่วมกับทีมพันธมิตรเดียวกัน จากนั้นจึงจ้างวิศวกรเพิ่มอีก 2 คนเพื่อสนับสนุนทีมพาร์ทเนอร์รายต่อไปในรายการ หลังจากนั้นทั้งสองก็สนับสนุนทีมที่สามและแผนก็เริ่มมารวมกัน เรายังคงใช้โมเดลนี้ต่อไป โดยเพิ่ม SRE เพื่อฝังลงในทีมพันธมิตรชั้นนำโดยตรง จนกว่าทีมพันธมิตรที่มีขนาดใหญ่พอที่จะสนับสนุนจะหมด
ในที่สุดทีมพันธมิตรก็สามารถจัดคำขอโครงสร้างพื้นฐานให้สอดคล้องกับงานของพวกเขาได้ ส่วนใหญ่หยุดการยกระดับ แม้ว่าเราจะไม่ได้ให้การสนับสนุนในระดับที่ต้องการแก่พวกเขา แต่เราได้ให้การควบคุมที่ชัดเจนและเปิดเผยแก่พวกเขาถึงการประนีประนอมที่ทีมของพวกเขาสร้างขึ้น ซึ่งหลายๆ อย่างพวกเขาไม่เคยทราบมาก่อนในรูปแบบก่อนหน้านี้
เมื่อการเปิดตัว SRE ของเรามีความเสถียร ดูเหมือนว่าเราจะแก้ปัญหานี้ได้ในที่สุด
โมเดล SRE นี้ไม่สมบูรณ์แบบ มันเติบโตได้ด้วยทีมพันธมิตรที่ทำงานร่วมกันและต่อสู้กับผู้อื่น แต่สามารถแก้ปัญหาที่ออกแบบมาเพื่อ: ทีมพันธมิตรของเรามีความก้าวหน้าที่คาดเดาได้ และเราสามารถจัดลำดับความสำคัญของงานด้านการปรับขยายได้พร้อมกัน สิ่งสำคัญที่สุดคือ มันแก้ปัญหานี้โดยไม่มีทิศทางล่างสุดในระดับโลกเกี่ยวกับลำดับความสำคัญ แทนที่จะพึ่งพาทีมพันธมิตรเพื่อแก้ไขลำดับความสำคัญของพวกเขาในท้องถิ่น
SRE v2
องค์กรโครงสร้างพื้นฐานที่กว้างขึ้นของ Uber มีแนวทางแก้ไขปัญหาแบบออร์แกนิก โดยพื้นฐานแล้วมันเป็นองค์กรจากล่างขึ้นบนที่มีกลยุทธ์ในท้องถิ่นโดยไม่มีกลยุทธ์ที่ครอบคลุมซึ่งสร้างความขัดแย้งค่อนข้างน้อย ในที่สุด การค้นหาบทบาทของผู้จัดการโดยตรงของฉันก็เริ่มต้นขึ้น และในที่สุด เราก็ได้ว่าจ้างหัวหน้าฝ่ายโครงสร้างพื้นฐานคนต่อไปของ Uber
หัวหน้าโครงสร้างพื้นฐานคนใหม่มีวิธีการเฉพาะในการจัดโครงสร้างองค์กรด้านสถาปัตยกรรมและโครงสร้างพื้นฐานตามประสบการณ์ก่อนหน้านี้ ภายในไม่กี่สัปดาห์ พวกเขาเริ่มโครงการเพื่อปรับโครงสร้างเทคโนโลยีและโครงสร้างพื้นฐานของ Uber ใหม่ เขายังมีมุมมองเฉพาะเจาะจงว่า SRE ควรทำงานอย่างไร และภายในเวลาไม่กี่เดือนได้ว่าจ้างเพื่อนร่วมงานคนก่อนให้เข้ามาเป็นผู้นำทีม SRE
ตามปกติแล้วหลังจากที่ผู้นำคนใหม่ เข้าร่วมเพื่อปรับใช้การตั้งค่าก่อนหน้านี้ อีกครั้ง บริบทที่สำคัญเกี่ยวกับวิธีการทำงานต่างๆ ก็ถูกมองข้ามไป ฉันยังอธิบายปัญหาเฉพาะที่เราแก้ไขกับองค์กร SRE ของ Uber ได้ไม่ดี จนถึงวันนี้ ฉันเชื่อว่าผู้นำใหม่เหล่านี้มีความเข้าใจผิดพื้นฐานเกี่ยวกับปัญหาที่องค์กร SRE ของ Uber กำลังแก้ไขอยู่ (ช่วยให้องค์กรระดับล่างสุดมีลำดับความสำคัญที่ลื่นไหลสูงซึ่งไม่ได้แก้ไขเป็นรายการลำดับความสำคัญเพียงรายการเดียวในทุกที่เพื่อให้ทำงานได้สำเร็จ) ดูแทน จากประสบการณ์ที่ผ่านมา ด้วยเหตุนี้ SRE จึงเปลี่ยนจากโมเดลแบบฝังไปเป็นแบบอื่นอย่างรวดเร็ว
ชื่อไม่เปลี่ยนแปลง แต่ในไม่ช้ามันก็เป็นทีมที่ต่างไปจากเดิมมาก ชื่อที่ไม่เปลี่ยนแปลงนั้นปิดบังจุดเริ่มต้นของความเป็นผู้นำและการเปลี่ยนแปลงทางวัฒนธรรมที่สำคัญ ซึ่งจะนำไปสู่บทสรุปของ Susan Rigetti หนึ่งปีที่แปลกมากที่ Uber ไม่กี่เดือนต่อมา เจ้านายคนที่ห้าของฉันในสองปีออกจากประตูบ้าน และหลังจากนั้นไม่นานฉันก็ตามไป
องค์กร SRE ยังคงอยู่ องค์กร SRE ที่เราสร้างขึ้นได้หายไปแล้ว
การสะท้อนกลับ
เมื่อเล่าเรื่องราวเช่นนี้หรือ การเปิดตัว Digg V4 มักเป็นการชักจูงในการนำเสนอตัวเองในวิธีที่ดีที่สุดเท่าที่จะเป็นไปได้ แต่ฉันพยายามเล่าถึงสิ่งเหล่านี้อย่างตรงไปตรงมา: ถ้าฉันสามารถทำเวลาใหม่ได้ ฉันจะทำหลายๆ อย่างแตกต่างออกไป Uber เป็นบทบาทแหกคุกสำหรับฉัน และฉันจะไม่ประสบความสำเร็จในงานต่อไปของฉันหากไม่มีทุกสิ่งที่ฉันได้เรียนรู้จาก Uber เป็นครั้งแรก ยังมีบางสิ่งที่ฉันภูมิใจมากกว่าสิ่งที่เราทำสำเร็จร่วมกัน ถึงคนที่ฉันทำงานด้วยและเรียนรู้จาก Uber: ขอบคุณ คุณเปลี่ยนชีวิตฉันให้ดีขึ้น
ไม่ได้หมายความว่าประสบการณ์นั้นดีทีเดียว การทำงานในยุคนั้นของ Uber สกัดค่าผ่านทาง คนอื่น ๆ หลายคนจ่ายราคาที่แย่กว่านั้นมาก ฉันจ่ายไปหนึ่งด้วย ฉันอยู่ในหัวของฉันในฐานะผู้นำและฉันก็ดิ้นรนกับมัน ในการเดินทางไปทำงานที่สำนักงาน Uber ลิทัวเนีย เพื่อนของฉันที่คบกันมาเจ็ดปีโทรมาบอกฉันว่าพวกเขาย้ายออกแล้ว การเขียนเป็นงานอดิเรกที่ฉันชอบ แต่ฉันเลิกเขียนในช่วงเวลาที่อยู่ที่นั่น บางบททำให้ชีวิตของเราสมบูรณ์ขึ้นโดยไม่ต้องเป็นสิ่งที่เราทำซ้ำ และแน่นอนว่า Uber ก็เป็นหนึ่งในบทเหล่านั้นสำหรับฉัน