Mailbag: ฉันเป็นผู้จัดการเร็วเกินไปหรือเปล่า?

ผู้เขียน.png

ฉันเพิ่งได้รับอีเมลเกี่ยวกับการย้ายเข้าสู่บทบาทการจัดการด้านวิศวกรรมเร็วเกินไปในอาชีพนักเขียนอีเมล:

ฉันได้เป็นผู้จัดการฝ่ายวิศวกรรมเมื่อสองปีก่อน ซึ่งเป็นเวลาสองปีในอาชีพการงานของฉัน เหตุผลหลักคือเราเป็นทีมเล็กๆ และเมื่อถึงเวลาต้องแอดไลน์ ผู้บริหาร ฉันก็รู้สึกเฉยๆ ฉันชอบตำแหน่งนี้มาก และพบว่าการสามารถรักษาตำแหน่งงานด้านเทคนิคไว้ได้ และยังคงมีงานที่เป็นมนุษย์อย่างลึกซึ้ง และสร้างความสัมพันธ์ที่แน่นแฟ้นกับทีมของฉันและทั่วทั้งบริษัท ฉันค่อนข้างประสบความสำเร็จในงานนี้และเป็นที่ยอมรับในบริษัท ตอนนี้ฉันกำลังพิจารณาที่จะลาออกจากบริษัท ฉันรู้สึกว่าเส้นทาง “ปกติ” สำหรับ EM คือการมีความอาวุโสด้านเทคนิคและความเชี่ยวชาญเป็นอย่างแรก (มากกว่าสองปีของงาน IC) ลึกๆ ฉันต้องการเป็นผู้จัดการ แต่ฉันสงสัยว่าถ้าคุณคิดว่าสิ่งที่สมเหตุสมผลที่ต้องทำหากฉันต้องการเข้าร่วมองค์กรขนาดใหญ่ในฐานะ EM คือการกลับไปใช้บทบาท IC และสร้างความเชี่ยวชาญแทนหรือไม่

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

ทำไมฉันถึงให้คำแนะนำนี้?

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

เกี่ยวกับ specalization ฉันพบว่าคนจำนวนมากเผชิญกับบทบาทแหกคุกในอาชีพการงานที่ทำให้พวกเขาก้าวหน้าอย่างมากในเส้นทางที่พวกเขาเป็นอยู่ในปัจจุบัน บทบาทฝ่าวงล้อมครั้งแรกของฉันคือการทำงานในองค์กรโครงสร้างพื้นฐานของ Uber และก่อตั้ง ทีม Uber SRE ฉันสามารถย้ายกลับเข้ามามีบทบาทเป็น Contributor แต่ละคนได้หลังจากจุดนั้น แต่มีแรงดึงดูดที่รุนแรงดึงฉันให้ดำเนินการต่อในเส้นทางการจัดการ: ในช่วง 2 ปีที่ผ่านมา ฉันกลายเป็นผู้สมัครระดับผู้จัดการที่แข็งแกร่งกว่าผู้สมัครวิศวกร และมันก็ยาก เพื่อเดินออกจากโอกาสทางอาชีพและค่าตอบแทนที่แข็งแกร่งขึ้น นี่เป็นหัวข้อที่ฉันเห็นในอาชีพของหลาย ๆ คน: หลังจากมีบทบาทแหกคุก ต้องใช้ความกล้าหาญอย่างมากในการเดินออกจากเส้นทางที่เร่งรีบนั้น และน้อยคนนักที่จะทำ

ไม่ใช่แค่ความกล้าหาญเท่านั้น แต่ยังเป็นปัญหาในทางปฏิบัติด้วย งานประจำวันของผู้จัดการสายงานในบริษัทขนาดเล็กมีหลายอย่างที่เหมือนกันกับงานที่วิศวกรอาวุโสอาจทำ นี่เป็นความจริงน้อยลงเรื่อยๆ ยิ่งคุณก้าวขึ้นไปอีกขั้นในสายงานด้านเทคนิคและการจัดการ ในฐานะรองประธานฝ่ายวิศวกรรม คุณอาจใช้เวลาส่วนใหญ่ไปกับนโยบายค่าตอบแทนและการแก้ปัญหาความสอดคล้องระหว่างกลยุทธ์ผลิตภัณฑ์และแผนทางการเงิน ในฐานะที่เป็น Staff Engineer คุณจะทำงานที่แตกต่างออกไปมาก สิ่งนี้ทำให้การเปลี่ยนเส้นทางยากขึ้นเมื่อคุณเลื่อนขั้นในอาชีพ เว้นแต่ว่าคุณจะสามารถทนต่อการรีเซ็ตโมเมนตัมในอาชีพของคุณ และบางทีคุณควรจะเป็น การมุ่งมั่นสู่บทบาทระดับสูงขึ้นเรื่อยๆ ไม่ใช่แผนที่จงใจในการทำงานตลอด สี่สิบปี

ทั้งหมดนี้เป็นข้อกังวลในอนาคต และเมื่อพิจารณาจากการตัดสินใจของคุณในวันนี้ คุณจะตัดสินใจผิดพลาดไม่ได้จริงๆ ในทำนองเดียวกันกับคุณ ฉันได้ย้ายเข้ามามีบทบาทเป็นผู้จัดการโดยส่วนตัวหลังจากมีประสบการณ์การพัฒนาเต็มเวลาสองปี และเป็นเพราะความต้องการของบริษัททั้งหมด เนื่องจากผู้จัดการทั้งหมดได้ลาออกหรือถูกเลิกจ้าง กะแรกนี้ไม่ได้ทำร้ายฉัน แม้ว่าฉันหวังว่าฉันจะใช้เวลามากขึ้นในฐานะวิศวกรเพียงเพราะฉันสนุกกับงานนั้นจริงๆ ที่กล่าวว่าสี่สิบปีเป็นเวลานานและคุณสามารถทำอะไรได้มากมายข้ามขอบฟ้านั้น!

ย้ายเส้นชัย.

ผู้เขียน.png

เมื่อฉันยังเป็นเด็ก ลูกพี่ลูกน้องมอบสำเนาเพลงฮิตที่ยิ่งใหญ่ที่สุดของ Steely Dan ให้ฉัน ในยุคของซีดีและโมเด็มบอด 56k นั้น ฉันไม่มีเพลงใหม่ให้เล่นมากนัก และในช่วงฤดูร้อน ฉันฟังซีดีแผ่นนั้นมากเพียงพอที่ชิ้นส่วนต่างๆ จะกลับมาหาฉันทั้งๆ ที่ไม่ได้ฟังเพลงของ Steely Dan อย่างรู้เท่าทัน อย่างน้อย 25 ปี โดยเฉพาะอย่างยิ่งเพลงหนึ่ง Black Cow มีเนื้อเพลงที่เข้ามาในหัวเป็นครั้งคราวว่า “คุณควรรู้ / มืออาชีพทุกคนเล่นเกมอย่างไร / คุณเปลี่ยนชื่อของคุณ”

เนื้อเพลงคล้ายกับเรื่องตลกที่บางครั้งฉันบอกผู้จัดการที่ย้ายเข้ามามีบทบาทผู้จัดการของผู้จัดการ: “คุณรู้ไหมว่าทำไม VPs ไม่เคยพลาดเป้าหมายของพวกเขา? พวกเขาเข้าเส้นชัย!” เรื่องตลกไม่ใช่เรื่องตลกเลย แต่ฉันพูดเพราะเป็นเรื่องสำคัญที่ผู้จัดการใหม่หลายคนต้องดิ้นรนเพื่อชื่นชม: ผู้บริหารจะได้รับการประเมินตามผลลัพธ์ที่รับรู้มากกว่าผลลัพธ์ที่แท้จริง

เพื่อยกตัวอย่างที่เป็นรูปธรรม ฉันเคยทำงานในบริษัทที่ทีมวิศวกรมีปัญหาในการวางแผนงาน หัวหน้าฝ่ายวิศวกรรมได้รับคำสั่งให้เราย้ายไปต่อสู้ เพื่อเตรียมการ พวกเขาบอกให้ผู้จัดการจัดทำเอกสารการต่อสู้บนหน้าวิกิวิศวกรรม หลังจากอัปเดตวิกิแล้ว หัวหน้าฝ่ายวิศวกรรมได้ประกาศว่าเราเปลี่ยนมาใช้ scrums ได้สำเร็จ ไม่มีทีมใดเริ่มใช้การต่อสู้กันจริงๆ การวางแผนไม่ได้เปลี่ยนแปลง นับประสาปรับปรุง แต่หัวหน้าฝ่ายวิศวกรรมภูมิใจที่บรรลุเป้าหมาย หลังจากนั้น ไม่เคยกล่าวถึงการโยกย้ายไปสู่การต่อสู้ทั้งหมดอีกเลย หากคุณไม่ได้ทำงานในวงการนี้มาเป็นเวลานาน อาจดูเหมือนเป็นเรื่องโกหก แต่มันเกิดขึ้นแล้วจริงๆ และไม่ใช่เรื่องแปลกโดยเฉพาะ

บริษัทที่ดำเนินกิจการมาอย่างดีไม่ยอมให้การรับรู้ที่ผิดเพี้ยนไปจากความเป็นจริงมากเกินไป ดังนั้นโดยทั่วไปแล้วผู้บริหารจะต้องรับผิดชอบต่อผลลัพธ์ที่แท้จริงของพวกเขา บริษัทที่บริหารงานไม่ดีมักจะลงโทษผู้บริหารที่คุ้นเคยกับความเป็นจริงมากเกินไป และผลที่ตามมาก็คือดำเนินการในขอบเขตของการเข้าใจผิดร่วมกัน หากคุณเคยทำงานในบริษัทขนาดใหญ่ คุณจะคุ้นเคยกับเทคนิคมากมายในการแก้ไขความเป็นจริง: การจัดระเบียบใหม่บ่อยครั้งที่ทำให้ระบุความรับผิดชอบได้ยาก ผู้นำใหม่ที่ถูกไล่ออกอย่างรวดเร็วเนื่องจากไม่สามารถแก้ไขปัญหาที่มีอยู่ก่อนได้, การเปลี่ยนแปลงที่แท้จริง สู่เป้าหมายเป้าหมายรายไตรมาส การกำหนดนิยามใหม่ของการเปิดตัวทั่วไปเป็นการกำหนดเป้าหมาย การเปลี่ยนการเปิดตัวเป้าหมายเป็นการทดสอบอัลฟ่า และอื่นๆ

บทเรียนต่อจากเรื่องตลกของฉันคือมันค่อนข้างยากที่จะบังคับให้บริษัทที่ดำเนินกิจการแย่ๆ ดำเนินกิจการได้ดีขึ้น ง่ายต่อการทำการปรับปรุงในท้องถิ่นในทีมของคุณ ยากกว่าเล็กน้อยที่จะ อนุญาตให้การปรับปรุงในพื้นที่ของคุณแพร่กระจายแบบอินทรีย์ แต่ทำได้ เป็นเรื่องยากมากที่จะก้าวต่อไป: บริษัทขนาดเล็กบางครั้งทำสิ่งแปลก ๆ เนื่องจากขาดประสบการณ์กับปัญหาในปัจจุบันของพวกเขา แต่บริษัทขนาดใหญ่มีพฤติกรรมแปลก ๆ เนื่องจากพวกเขาได้เลือกอย่างรอบคอบ คุณต้องมีบทบาทเป็นผู้บริหารหรือมีผู้สนับสนุนระดับผู้บริหารที่มีส่วนร่วมจริงๆ

หากคุณพบผู้สนับสนุนระดับผู้บริหารที่มีส่วนร่วม (หากคุณไม่แน่ใจว่าพวกเขามีส่วนร่วมหรือไม่ ให้ขอให้พวกเขาทำบางสิ่งเพื่อช่วย และดูว่าพวกเขาทำหรือไม่) คุณก็จะสามารถก้าวไปสู่การดำเนินการที่ดีได้ โดยดำเนินการบางอย่างควบคู่ไปกับ การประชุมทบทวนธุรกิจ และ สร้างความมั่นใจว่าผู้บริหารจะแสดงขึ้นเพื่อผลักดันเนื้อหา คนติดกับดักของการ ตำหนิพลาดจำนวนพนักงานไม่เพียงพอ หรือไม่ เป้าหมายของพวกเขาสอดคล้องกับสิ่งที่สำคัญอย่างแท้จริงหรือไม่? ผู้นำเสนอออกจากการทบทวนแต่ละครั้งด้วยความเข้าใจที่ชัดเจนว่าผู้นำประเมินงานของตนอย่างไร

มันจะไม่เปลี่ยนแปลงอะไรในชั่วข้ามคืน แต่จะค่อยๆ ยากที่จะเคลื่อนเข้าเส้นชัย และความเป็นจริงจะค่อย ๆ ยืนยันตัวเองเกี่ยวกับวิธีการดำเนินงานของบริษัท

ก่อตั้ง Uber SRE

ผู้เขียน.png

นี่เป็นเรื่องราวส่วนตัวของฉันในการเริ่มต้นองค์กร 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

เรามีพนักงานคอยปรับขนาดโครงสร้างพื้นฐานของเราหากเราสามารถปกป้องพวกเขาจากคำของานที่เข้ามาได้ ดังนั้นเราจึงมุ่งเน้นไปที่วิธีปกป้องทีมเหล่านั้นจากการขัดจังหวะในขณะเดียวกันก็ให้การสนับสนุนทีมที่ร้องขออย่างเพียงพอเพื่อความก้าวหน้า โครงสร้างมีประสิทธิภาพ:

  1. พันธมิตรองค์กรชั้นนำสามหรือสี่รายของเราจะได้รับการสนับสนุน SRE โดยเฉพาะ ทีมพันธมิตรจะจัดลำดับความสำคัญของภาระงานของ SRE ที่สนับสนุนพวกเขาอย่างชัดเจน เรากำหนด “อันดับสูงสุด” ตามจำนวนคำขอ ไม่ใช่โดยผลกระทบ
  2. คนอื่นๆ จะได้รับการสนับสนุนจากทีมที่สร้างแพลตฟอร์มการบริการตนเอง พวกเขาจะจัดลำดับความสำคัญการทำงานบนหลักการเร่งอัตโนมัติ
  3. โครงสร้างพื้นฐานที่เหลือจะสนับสนุนด้านความสามารถในการปรับขนาดและการทำงานเฉพาะ เช่น เครือข่าย 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 ก็เป็นหนึ่งในบทเหล่านั้นสำหรับฉัน

แพลตฟอร์มเปลี่ยนไป แต่ URI ที่ยอดเยี่ยมไม่เปลี่ยน

ผู้เขียน.png

จากข่าวล่าสุดของ คณะกรรมการของ Twitter ที่ยอมรับข้อเสนอของ Elon Musk ในการซื้อ Twitter มีคนพูดถึงการออกจาก Twitter ในระยะยาว การก่อตั้งในปี 2549 ทำให้ Twitter เป็นบริษัทใหม่ แต่อินเทอร์เน็ตแตกต่างออกไป และในช่วง 16 ปีที่ผ่านมาได้กลายเป็นแพลตฟอร์มกลางสำหรับคนจำนวนมากที่ทำงานด้านเทคโนโลยี (รวมถึงบริษัทอื่นๆ อีกมากมาย) Twitter มีความสำคัญเป็นพิเศษสำหรับผู้ที่เขียนเนื้อหาออนไลน์ เท่าที่กลไกการแจกจ่ายที่มีประสิทธิภาพมากที่สุดสำหรับนักเขียนหลายคน นี่เป็นเรื่องจริงสำหรับผู้เขียนที่ตีพิมพ์เองที่ทำการตลาดของตัวเอง แต่ฉันเคยได้ยินเรื่องราวของผู้จัดพิมพ์ที่กำหนดไว้ในสัญญาว่าผู้เขียนต้องใช้งานบน Twitter รวมถึงการกรองผู้เขียนที่คาดหวังบางส่วนตามขนาดของการติดตาม Twitter ของพวกเขา

ฉันหวังว่า Twitter ยังคงเป็นฟอรัมที่มีชีวิตชีวาและมีประสิทธิภาพสำหรับการสนทนาตลอดจนช่องทางการจัดจำหน่ายที่มีประสิทธิภาพ แต่เป็นการเตือนความจำที่สำคัญว่าแม้แต่แพลตฟอร์มที่ดีที่สุดก็จะไม่คงอยู่ตลอดไป Tumblr และ Flickr เป็นบ้านของชุมชนที่มีชีวิตชีวามากมายก่อนที่ Yahoo จะเข้าซื้อกิจการทั้งคู่! MySpace จางหายไปในทำนองเดียวกันหลังจากที่ได้มา แพลตฟอร์มและข้อมูลเทคโนโลยีของ Digg ไม่รอดจากการได้ มา Facebook ยังคงอยู่ แต่ API รุ่นแรกๆ ที่ขับเคลื่อนระบบนิเวศของแอปพลิเคชันนั้นหมดไปนานแล้ว แม้แต่ Twitter เองก็เปลี่ยนจากการส่งเสริมระบบนิเวศของนักพัฒนาที่เน้น API และอุดมไปด้วย API ไปเป็นการปิดการใช้ API ส่วนใหญ่โดยปริยาย

คุณสามารถโต้แย้งได้อย่างแน่นอนว่าแพลตฟอร์มเหล่านั้นไม่ใช่เนื้อหาหรือแพลตฟอร์มการแจกจ่าย จริง ๆ แต่มันยากที่จะดูจดหมายข่าวการสมัครสมาชิกล่าสุดที่รัก Substack โดยไม่ต้องคิดถึง paywalls ที่คาดเดาไม่ได้มากขึ้นของบล็อกเกอร์ที่รัก Medium ของปีกลาย ตามทฤษฎีแล้ว คุณสามารถเปลี่ยนแพลตฟอร์มได้ทุก ๆ ห้าหรือหกปี แต่ URI ที่ยอดเยี่ยมจะไม่เปลี่ยนแปลง และจัดรูปแบบใหม่จะสร้างความเสียหายอย่างมากต่อการค้นพบและการเผยแพร่เนื้อหา

สำหรับผู้ที่ทุ่มเทเวลาอย่างมากในการสร้างเนื้อหาออนไลน์ ฉันคิดว่านี่หมายความว่าคุณจำเป็นต้องเป็นเจ้าของเนื้อหาของคุณ เป็นเจ้าของระเบียน DNS ที่เชื่อมต่อผู้อ่านกับเนื้อหาของคุณ และเป็นเจ้าของรายชื่อผู้รับจดหมายของคุณ ตราบใดที่คุณควบคุมอินเทอร์เฟซเหล่านั้น คุณ สามารถ ย้ายแพลตฟอร์มได้โดยไม่กระทบต่อการค้นพบได้ แน่นอนว่าเป็นงานเล็กน้อย แต่บล็อกนี้ได้ย้ายห้าครั้งจาก Dreamhost ไปยัง Linode ไปยัง AWS ไปยัง GCP ไปยัง Github Pages ในช่วง 15 ปีที่ผ่านมาและเท่าที่ฉันทราบ URI ทั้งหมดยังคงทำงานอยู่ ถ้าฉันกำหนดเส้นทางคน โดยตรง ไปยังสื่อหรือไปยังหน้า Github บนโดเมน Github ฉันจะไม่สามารถทำการโยกย้ายได้อย่างหมดจด (บังเอิญว่าแพลตฟอร์มเหล่านั้นไม่มีอยู่เมื่อฉันเริ่มเขียน แต่นั่นไม่ใช่ประเด็นจริงๆ ที่นี่).

URI ที่สำคัญที่สุดน่าจะเป็น URI ที่ฟีด RSS ของคุณอาศัยอยู่ RSS เป็นกลไกการแจกจ่ายที่มีความสำคัญน้อยกว่าเมื่อทศวรรษที่แล้ว แต่โปรแกรมอ่าน RSS เป็นผู้อ่านที่มีค่าที่สุดบางส่วน เพราะพวกเขารวมกลุ่มย่อยของผู้ที่ ค้นพบเนื้อหาเพื่อแชร์ต่อบนแพลตฟอร์มข่าวโซเชียลต่างๆ

เป็นเวลานานที่ฉันยึดมั่นในความฝันว่า RSS จะเพียงพอ แต่ในที่สุดฉันก็ เริ่มส่งรายชื่อผู้รับจดหมาย ขณะที่ฉันเริ่มมุ่งสู่การปล่อย An Elegant Puzzle แม้วันนี้รายชื่อนั้นจะไม่ใหญ่มากนัก แต่ก็ยังมีคนมากกว่า 6,000 คนที่ฉันสามารถติดต่อได้โดยตรงแม้ว่า Twitter จะหายไปในวันพรุ่งนี้ (รายชื่อผู้รับจดหมายของ Staff Engineer นั้นใหญ่กว่าเล็กน้อย รายชื่อ Infrastructure Engineer ยังใหม่และเล็กมาก) . นอกจากนี้ยังเป็นส่วนย่อยที่มีส่วนร่วมสูงซึ่งมีแนวโน้มที่จะตอบอีเมลด้วยความคิดของพวกเขามากขึ้น ฉันเชื่ออย่างไม่เต็มใจว่า URI และอีเมลเป็นส่วนต่อประสานและโปรโตคอลที่ทนทานซึ่งจะคงอยู่นานกว่าทุก ๆ การใช้งานสูงสุดของแพลตฟอร์มที่กำหนด (แม้ว่าลองนึกภาพความโกลาหลที่แท้จริงของ gmail ที่ต้องปิดตัวลงในวันหนึ่ง แต่ฉันก็เสียใจที่ไม่ได้ แต่ย้ายอีเมลไปยังโดเมนของตัวเอง อาจเป็นโครงการที่ดีสำหรับปีนี้)

หากคุณวางแผนที่จะเขียนข้ามทศวรรษ คุณเพียงแค่ต้องเป็นเจ้าของส่วนต่อประสานกับเนื้อหาของคุณ คุณควรเจาะลึกลงไปในแพลตฟอร์มอื่น ๆ อย่างเต็มที่ เนื่องจากพวกเขามักจะกลายเป็นชุมชนที่ไม่ธรรมดาที่มีการแจกจ่ายที่ยอดเยี่ยม แต่จะไม่มีวันเป็นบ้านที่ทนทาน