DBAs, A Priesthood No More

หมายเหตุ: โพสต์ทางวิศวกรรมนี้เขียนโดย DBA ของเรา Silvia Botros และปรากฏบนบล็อก Sysadvent ในเดือนธันวาคม 2559

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

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

เนื่องจากตามปกติแล้ว DBAs มีบทบาทเฉพาะตัวเช่นนี้ เวลาของพวกเขาอยู่ในระดับสูง มันจึงยากที่จะคิดภาพรวมเมื่องานประจำวันล้นหลาม เป็นเรื่องปกติที่จะใช้เครื่องมือที่เปราะบางเช่น bash สำหรับงานปฏิบัติการทุกประเภทใน DBA Land ต้องการการตั้งค่าฐานข้อมูลใหม่จากการติดตั้งระบบปฏิบัติการใหม่ทั้งหมดหรือไม่ รับ ตรวจสอบ หรือกู้คืนข้อมูลสำรองหรือไม่ หมุนพาร์ติชั่นหรือข้อมูลเก่า? เมื่อเครื่องมือที่ใช้บ่อยที่สุดของคุณคือการเขียนสคริปต์ทุบตี ทุกอย่างก็ดูเหมือนเป็นเล็บขบ ฉันแน่ใจว่าผู้อ่านหลายคนกำลังเตรียมทวีตเพื่อบอกฉันว่าทุบตีนั้นทรงพลังแค่ไหน แต่โปรดเก็บความคิดเห็นของคุณไว้จนกว่าจะประเมินเหตุผลของฉันแล้ว

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

นั่นเป็นวิธีที่สามารถปรับขนาดได้สำหรับสิ่งที่มักจะเป็นทีมเดียวกันในองค์กรที่เติบโตอย่างรวดเร็วหรือไม่?

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

ทำไม

คุณอาจจะถามว่าทำไมฉันถึงทำอย่างนี้? มีข้อโต้แย้งสำหรับการดำเนินการตามบทบาท DBA ตามธรรมเนียม: ความปลอดภัยของงานใช่ไหม องค์กรเทคโนโลยีหลายแห่งในปัจจุบันทำอย่างใดอย่างหนึ่งต่อไปนี้:

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

แล้วจะทำอะไรได้บ้างเพื่อทำลายไซโลนั้นและทำให้คนอื่นๆ แก้ปัญหาได้ง่ายขึ้น ช่วยปรับขนาดชั้นฐานข้อมูล และให้อำนาจวิศวกรในการออกแบบบริการที่สามารถปรับขนาดได้ ร้านค้าที่กำลังมาแรงส่วนใหญ่มี DBA ภายในองค์กรไม่เกินหนึ่งแห่ง DBA เดียวสามารถ 'นำเสนอ' ในการประชุมการออกแบบทั้งหมด อนุมัติการเปลี่ยนแปลงสคีมาทุกรายการ และพร้อมสำหรับฐานข้อมูลที่ขยายใหญ่ขึ้นเรื่อยๆ หรือไม่

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

การจัดการการตั้งค่า

นี้เป็นสิ่งที่สำคัญมาก DBA มักจะชอบเครื่องมือโรงเรียนเก่า เช่น bash สำหรับการตั้งค่าฐานข้อมูล ฉันพาดพิงถึงสิ่งนี้ก่อนหน้านี้และฉันไม่มีอะไรต่อต้านการใช้ bash เอง ฉันใช้มันมากจริงๆ แต่ไม่ใช่เครื่องมือที่เหมาะสมสำหรับการตั้งค่าคลัสเตอร์ โดยเฉพาะอย่างยิ่งถ้า ops ที่เหลือไม่ได้ใช้ Bash เพื่อจัดการส่วนที่เหลือของสถาปัตยกรรม เป็นความจริงที่วิศวกรฝ่ายปฏิบัติการรู้จัก Bash เช่นกัน แต่ถ้าพวกเขากำลังจัดการโครงสร้างพื้นฐานที่เหลือด้วยเครื่องมือเช่น Chef หรือ Puppet และฐานข้อมูลได้รับการจัดการโดยส่วนใหญ่โดยสคริปต์ที่สร้างขึ้นด้วยมือที่เขียนโดย DBA คุณกำลังกำหนดสิ่งกีดขวางเพื่อให้พวกเขาจัดหา ช่วยเหลือเมื่อจำเป็นต้องเปลี่ยนแปลงอย่างเร่งด่วน

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

DBA ที่ได้รับการปรับให้เข้ากับผลิตภัณฑ์และโครงสร้างพื้นฐานขององค์กรด้านวิศวกรรมโดยรวมนั้นมีค่ามาก

Runbooks

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

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

นอกจากนี้ ฉันยังเพิ่มลิงก์ไปยังส่วน runbook ที่เกี่ยวข้อง (ใช้จุดยึด!) ไปยังคำอธิบายหน้าที่ไปที่เพจเจอร์ สิ่งนี้มีประโยชน์อย่างเหลือเชื่อสำหรับผู้ที่ถูกเพจโดยโฮสต์ฐานข้อมูลเวลา 3:00 น. เพื่อค้นหาจุดเริ่มต้น สิ่งเหล่านี้อาจดูเล็กน้อย แต่จากประสบการณ์ของผม สิ่งเหล่านี้ได้ทำลายอุปสรรคทางจิตสำหรับทีมปฏิบัติการของผมที่ทำงานบนชั้นฐานข้อมูลเมื่อจำเป็น

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

ทัศนวิสัย

เราชอบหน้าจอเทอร์มินัลของเรา เรารักพวกเขา เครื่องมือที่ได้รับความนิยมมากที่สุดใน MySQL ยังคงเป็นเครื่องมือปลายทางที่อาศัยอยู่โดยตรงบนโฮสต์ db และต้องการความรู้เบื้องต้นเกี่ยวกับเครื่องมือเหล่านี้และวิธีใช้งาน ฉันกำลังพูดถึงสิ่งต่าง ๆ เช่น innotop และ MySQL shell สิ่งเหล่านี้ใช้ได้และยังมีประโยชน์อยู่ แต่ถูกสร้างขึ้นสำหรับ DBA หากคุณไม่ต้องการเป็นผู้รักษาประตูให้กับคำถามเช่น "ตอนนี้มีการจำลองแบบล่าช้าหรือไม่" คุณจำเป็นต้องมีเครื่องมือที่ดีกว่าในการสร้างความสมบูรณ์ของคลัสเตอร์ทั้งในอดีตและปัจจุบัน พร้อมใช้งานและเข้าใจง่ายสำหรับสมาชิกในทีมทุกคน ฉันมีตัวอย่างบางส่วนในเวทีนี้:

ออเคสตรา

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

กราฟาน่า/กราไฟท์

เมตริกสำหรับเลเยอร์ DB จำเป็นต้องอยู่ในที่เดียวกันสำหรับโครงสร้างพื้นฐานที่เหลือ เป็นสิ่งสำคัญสำหรับทีมที่จะต้องวางเมตริกเหล่านี้เคียงข้างกัน และสิ่งสำคัญคือต้องมีวิธีง่ายๆ ในการดูเมตริกที่ผ่านมาสำหรับคลัสเตอร์ DB แม้ว่าคุณอาจมีความชอบส่วนตัวสำหรับ cacti หรือ munin หรือแม่แบบงานฝีมือที่คุณเขียนในช่วงหลายปีที่ผ่านมา หากตัวชี้วัดที่คุณใช้เพื่อตรวจสอบปัญหาไม่ได้อยู่ในที่เดียวกับตัวชี้วัดโครงสร้างพื้นฐานที่เหลือจะเป็นอุปสรรคสำหรับ วิศวกรที่มีงานยุ่งคนอื่นๆ และพวกเขาจะไม่ค่อยใช้เครื่องมือของคุณกับงานที่ใช้ในที่อื่น กราไฟต์มีการใช้กันอย่างแพร่หลายในการนำเข้าเมตริกในทีมโครงสร้างพื้นฐานที่ทันสมัย ​​และ Grafana เป็นส่วนหน้าแดชบอร์ดที่ใช้กันอย่างแพร่หลายสำหรับเมตริกและการวิเคราะห์

ประสิทธิภาพของแบบสอบถาม

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

ต่อสู้กับความเหนื่อยล้าของเพจเจอร์

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

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

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

ขอขอบคุณเป็นพิเศษสำหรับทีมปฏิบัติการที่ยอดเยี่ยมของ Sendgrid ที่คอยสอนอะไรหลายๆ อย่างให้กับฉันอย่างต่อเนื่อง และสำหรับ Charity Majors ที่สร้างชื่อโพสต์นี้ และดูโพสต์เพิ่มเติมเกี่ยวกับ DBA ที่นี่