นักพัฒนามาจากดาวอังคาร ผู้ดูแลระบบมาจากดาวศุกร์

ความบังเอิญเป็นเรื่องบังเอิญ และแท้จริงแล้วมันอยู่บนดาวดวงอื่น...

ฉันอยากจะแบ่งปันเรื่องราวความสำเร็จและความล้มเหลวสามประการเกี่ยวกับวิธีการทำงานของนักพัฒนาแบ็กเอนด์ในทีมกับผู้ดูแลระบบ

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

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

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

ไม่สนใจก็เดินหน้าต่อไป

เรื่องที่สอง.
บริษัทใหญ่ โครงการใหญ่. มีฝ่ายธุรการที่มีพนักงาน 5-7 คน และกลุ่มพัฒนาหลายกลุ่ม เมื่อคุณมาทำงานในบริษัทดังกล่าว ผู้ดูแลระบบทุกคนคิดว่าคุณไม่ได้มาที่นี่เพื่อทำงานเกี่ยวกับผลิตภัณฑ์ แต่มาเพื่อทำลายบางสิ่งบางอย่าง NDA ที่ลงนามหรือการคัดเลือกในการสัมภาษณ์ไม่ได้บ่งชี้เป็นอย่างอื่น ไม่ ผู้ชายคนนี้มาที่นี่ด้วยมือเล็กๆ สกปรกของเขา เพื่อทำลายกระบวนการจูบของเรา ดังนั้นคุณต้องมีการสื่อสารขั้นต่ำกับบุคคลดังกล่าวอย่างน้อยที่สุดคุณก็สามารถส่งสติ๊กเกอร์ตอบกลับได้ อย่าตอบคำถามเกี่ยวกับสถาปัตยกรรมโครงการ ไม่แนะนำให้ให้สิทธิ์การเข้าถึงจนกว่าหัวหน้าทีมจะถาม และเมื่อเขาขอเขาก็จะคืนให้พร้อมสิทธิพิเศษน้อยกว่าที่พวกเขาขอด้วยซ้ำ การสื่อสารเกือบทั้งหมดกับผู้ดูแลระบบดังกล่าวถูกหลุมดำดูดกลืนระหว่างฝ่ายพัฒนาและฝ่ายธุรการ ไม่สามารถแก้ไขปัญหาได้ทันที แต่คุณไม่สามารถมาด้วยตนเองได้ เพราะผู้ดูแลระบบยุ่งมากตลอด 24 ชั่วโมงทุกวัน (คุณกำลังทำอะไรอยู่ตลอดเวลา?) ลักษณะการทำงานบางประการ:

• เวลาปรับใช้โดยเฉลี่ยในการผลิตคือ 4-5 ชั่วโมง
• เวลาใช้งานสูงสุดในการผลิต 9 ชั่วโมง
• สำหรับนักพัฒนา แอปพลิเคชันที่ใช้งานจริงจะเป็นกล่องดำ เช่นเดียวกับเซิร์ฟเวอร์ที่ใช้งานจริง มีทั้งหมดกี่ตัว?
• การเผยแพร่คุณภาพต่ำ มีข้อผิดพลาดบ่อยครั้ง
• นักพัฒนาซอฟต์แวร์ไม่ได้มีส่วนร่วมในกระบวนการเผยแพร่

ฉันคาดหวังอะไรไว้บ้าง แน่นอนว่าคนใหม่ไม่ได้รับอนุญาตให้ผลิต โอเค เมื่ออดทนมากขึ้น เราก็เริ่มได้รับความไว้วางใจจากผู้อื่น แต่ด้วยเหตุผลบางอย่าง ผู้ดูแลระบบจึงไม่ง่ายนัก

พระราชบัญญัติ 1. ผู้ดูแลระบบไม่สามารถมองเห็นได้
วันที่วางจำหน่าย ผู้พัฒนาและผู้ดูแลระบบไม่สื่อสารกัน ผู้ดูแลระบบไม่มีคำถาม แต่คุณจะเข้าใจว่าทำไมในภายหลัง ผู้ดูแลระบบเป็นบุคคลที่มีหลักการ ไม่มีผู้ส่งสาร ไม่ให้หมายเลขโทรศัพท์ของตนแก่ใคร และไม่มีโปรไฟล์บนโซเชียลเน็ตเวิร์ก ไม่มีแม้แต่รูปถ่ายของเขาเลยคุณหน้าตาเป็นยังไงเพื่อน? เรานั่งคุยกับผู้จัดการที่รับผิดชอบด้วยความงุนงงประมาณ 15 นาที พยายามติดต่อกับยานโวเอเจอร์ 1 จากนั้นข้อความจะปรากฏในอีเมลของบริษัทว่าเขาได้ดำเนินการเสร็จสิ้นแล้ว เราจะติดต่อกันทางไปรษณีย์ไหม? ทำไมจะไม่ล่ะ? สะดวกไม่ใช่เหรอ? เอาล่ะ เรามาคลายร้อนกันดีกว่า กระบวนการนี้กำลังดำเนินการอยู่และจะไม่มีการย้อนกลับ อ่านข้อความอีกครั้ง "ฉันเสร็จแล้ว". คุณทำอะไรเสร็จ? ที่ไหน? ฉันควรมองหาคุณที่ไหน? คุณจะเข้าใจว่าทำไมการปล่อย 4 ชั่วโมงจึงเป็นเรื่องปกติ เราได้รับความตกใจจากการพัฒนา แต่เราเผยแพร่ให้เสร็จสิ้น ไม่มีความปรารถนาที่จะปลดปล่อยอีกต่อไป

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

องก์ที่ 3 สั้นๆ
ตั๋วด่วน ฟังก์ชั่นหลักใช้งานไม่ได้สำหรับผู้ใช้รายใดรายหนึ่งในการผลิต เราใช้เวลาสองสามชั่วโมงในการเจาะและตรวจสอบ ในสภาพแวดล้อมการพัฒนา ทุกอย่างทำงานได้ มีความเข้าใจที่ชัดเจนว่าเป็นความคิดที่ดีที่จะดูบันทึก php-fpm ในเวลานั้นไม่มีระบบบันทึกเช่น ELK หรือ Prometheus เราเปิดตั๋วให้กับแผนกธุรการเพื่อให้สามารถเข้าถึงบันทึก php-fpm บนเซิร์ฟเวอร์ ที่นี่คุณต้องเข้าใจว่าเราขอเข้าถึงด้วยเหตุผลบางอย่าง คุณจำไม่ได้เกี่ยวกับหลุมดำและผู้ดูแลระบบมีงานยุ่งตลอด 24 ชั่วโมงทุกวันหรือไม่? หากคุณขอให้พวกเขาดูบันทึกด้วยตนเอง แสดงว่างานนี้เป็นงานที่ "ไม่ได้อยู่ในชีวิตนี้" มาก่อน ตั๋วถูกสร้างขึ้น เราได้รับคำตอบทันทีจากหัวหน้าแผนกธุรการ: “คุณไม่จำเป็นต้องเข้าถึงบันทึกการใช้งานจริง เขียนได้โดยไม่มีจุดบกพร่อง” ผ้าม่าน.

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

การแปลงร่าง
หลังจากอดทนกับเรื่องทั้งหมดนี้มาเป็นเวลานานร่วมกับทีมเราจึงเริ่มนำทางไปในทิศทางที่ประสบความสำเร็จมากขึ้นสำหรับเรา สรุปเราประสบปัญหาอะไรบ้าง?

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

เราทำอะไรไปแล้วบ้าง?
สำหรับแต่ละรุ่น จะมีการสร้างรายการบันทึกประจำรุ่น ซึ่งรวมถึงรายการงานที่ต้องทำบนเซิร์ฟเวอร์เพื่อให้รุ่นถัดไปทำงานได้ รายการประกอบด้วยหลายส่วน งานที่ควรดำเนินการโดยผู้ดูแลระบบ บุคคลที่รับผิดชอบในการเผยแพร่ และนักพัฒนา นักพัฒนาได้รับการเข้าถึงเซิร์ฟเวอร์ที่ใช้งานจริงทั้งหมดโดยไม่ต้องรูท ซึ่งช่วยเร่งการพัฒนาโดยทั่วไปและโดยเฉพาะการแก้ปัญหา นักพัฒนายังมีความเข้าใจเกี่ยวกับวิธีการทำงานของการผลิต บริการที่แบ่งออกเป็น ที่ไหน และมีราคาเท่าใดในการจำลอง ปริมาณการรบบางส่วนมีความชัดเจนมากขึ้น ซึ่งส่งผลต่อคุณภาพของโค้ดอย่างไม่ต้องสงสัย การสื่อสารระหว่างกระบวนการเผยแพร่เกิดขึ้นในแชทของหนึ่งในผู้ส่งข้อความโต้ตอบแบบทันที ประการแรก เรามีบันทึกการกระทำทั้งหมด และประการที่สอง การสื่อสารเกิดขึ้นในสภาพแวดล้อมที่ใกล้ชิดยิ่งขึ้น การมีประวัติการดำเนินการมากกว่าหนึ่งครั้งทำให้พนักงานใหม่สามารถแก้ไขปัญหาได้เร็วขึ้น มันเป็นเรื่องที่ขัดแย้งกัน แต่สิ่งนี้มักจะช่วยผู้ดูแลระบบเอง ฉันจะไม่รับปากแน่นอน แต่สำหรับฉันแล้วดูเหมือนว่าผู้ดูแลระบบเริ่มเข้าใจมากขึ้นว่าโครงการทำงานอย่างไรและเขียนอย่างไร บางครั้งเราก็แบ่งปันรายละเอียดบางอย่างให้กันและกันด้วย เวลาปล่อยเฉลี่ยลดลงเหลือหนึ่งชั่วโมง บางครั้งเราก็เสร็จภายใน 30-40 นาที จำนวนข้อบกพร่องลดลงอย่างมาก หากไม่ถึงสิบเท่า แน่นอนว่า ปัจจัยอื่นๆ ยังส่งผลต่อเวลาในการเผยแพร่ที่ลดลง เช่น การทดสอบอัตโนมัติ หลังจากเผยแพร่แต่ละครั้ง เราก็เริ่มดำเนินการย้อนหลัง เพื่อให้ทั้งทีมได้รู้ว่ามีอะไรใหม่ อะไรเปลี่ยนแปลง และอะไรถูกลบออกไป น่าเสียดายที่ผู้ดูแลระบบไม่ได้มาหาพวกเขาเสมอไป ผู้ดูแลระบบมีงานยุ่ง... ความพึงพอใจในงานของฉันในฐานะนักพัฒนาเพิ่มขึ้นอย่างไม่ต้องสงสัย เมื่อคุณสามารถแก้ไขปัญหาเกือบทุกอย่างที่อยู่ในขอบเขตความสามารถของคุณได้อย่างรวดเร็ว คุณจะรู้สึกเหนือกว่า ต่อมา ฉันจะเข้าใจว่าเราได้แนะนำวัฒนธรรม Devops ในระดับหนึ่ง ซึ่งยังไม่ทั้งหมด แต่แม้กระทั่งจุดเริ่มต้นของการเปลี่ยนแปลงก็ยังน่าประทับใจ

เรื่องที่สาม
การเริ่มต้น ผู้ดูแลระบบคนหนึ่ง แผนกพัฒนาขนาดเล็ก เมื่อมาถึงฉันก็เป็นศูนย์โดยสมบูรณ์เพราะ... ฉันไม่สามารถเข้าถึงได้ทุกที่ยกเว้นจากจดหมาย เราเขียนถึงผู้ดูแลระบบและขอสิทธิ์เข้าถึง นอกจากนี้ยังมีข้อมูลที่เขาทราบเกี่ยวกับพนักงานใหม่และความจำเป็นในการเข้าสู่ระบบ/รหัสผ่าน พวกเขาให้สิทธิ์การเข้าถึงจากพื้นที่เก็บข้อมูลและ VPN เหตุใดจึงให้สิทธิ์การเข้าถึง wiki, teamcity, rundesk? สิ่งที่ไร้ประโยชน์สำหรับคนที่ถูกเรียกให้เขียนส่วนแบ็กเอนด์ทั้งหมด เราสามารถเข้าถึงเครื่องมือบางอย่างได้เมื่อเวลาผ่านไปเท่านั้น แน่นอนว่าการมาถึงพบกับความไม่ไว้วางใจ ฉันกำลังพยายามค่อยๆ ทำความเข้าใจว่าโครงสร้างพื้นฐานของโครงการทำงานอย่างไรผ่านการแชทและคำถามนำ โดยพื้นฐานแล้วฉันไม่รู้จักอะไรเลย การผลิตเป็นกล่องดำเหมือนเดิม แต่ยิ่งกว่านั้น แม้แต่สเตจเซิร์ฟเวอร์ที่ใช้สำหรับการทดสอบก็ยังเป็นกล่องดำอีกด้วย เราไม่สามารถทำอะไรได้นอกจากปรับใช้สาขาจาก Git ที่นั่น นอกจากนี้เรายังไม่สามารถกำหนดค่าแอปพลิเคชันของเราเช่นไฟล์ .env ได้ ไม่อนุญาตให้เข้าถึงการดำเนินการดังกล่าว คุณต้องขอให้มีการเปลี่ยนแปลงบรรทัดในการกำหนดค่าแอปพลิเคชันของคุณบนเซิร์ฟเวอร์ทดสอบ (มีทฤษฎีที่ว่าผู้ดูแลระบบรู้สึกว่าตนมีความสำคัญต่อโปรเจ็กต์เป็นสิ่งสำคัญ หากไม่ได้รับการขอให้เปลี่ยนบรรทัดในการกำหนดค่า พวกเขาก็ไม่จำเป็น) ก็เช่นเคยไม่สะดวกใช่ไหม? สิ่งนี้เริ่มน่าเบื่ออย่างรวดเร็ว หลังจากการสนทนาโดยตรงกับผู้ดูแลระบบ เราพบว่านักพัฒนาเกิดมาเพื่อเขียนโค้ดที่ไม่ดี โดยธรรมชาติแล้วจะเป็นคนไร้ความสามารถ และควรแยกพวกเขาออกจากการผลิต แต่ที่นี่ก็มาจากเซิร์ฟเวอร์ทดสอบด้วยเช่นกัน ความขัดแย้งรุนแรงขึ้นอย่างรวดเร็ว ไม่มีการสื่อสารกับผู้ดูแลระบบ สถานการณ์เลวร้ายลงเมื่อเขาอยู่คนเดียว ต่อไปนี้เป็นภาพทั่วไป ปล่อย. ฟังก์ชั่นบางอย่างไม่ทำงาน เราใช้เวลานานในการพิจารณาว่าเกิดอะไรขึ้น แนวคิดต่างๆ จากนักพัฒนาถูกโยนเข้าไปในแชท แต่ผู้ดูแลระบบในสถานการณ์เช่นนี้มักจะถือว่านักพัฒนาต้องถูกตำหนิ แล้วเขาก็เขียนในแชทว่าเดี๋ยวผมแก้ไขให้ เมื่อถูกขอให้ทิ้งเรื่องราวพร้อมข้อมูลเกี่ยวกับปัญหา เราได้รับข้อแก้ตัวที่เป็นพิษ เช่น อย่าเอาจมูกไปจ่อตรงที่ไม่เป็นส่วนหนึ่งของมัน นักพัฒนาจะต้องเขียนโค้ด สถานการณ์ที่การเคลื่อนไหวร่างกายจำนวนมากในโปรเจ็กต์ต้องอาศัยคนเพียงคนเดียวและมีเพียงเขาเท่านั้นที่สามารถเข้าถึงการผ่าตัดที่ทุกคนต้องการได้ เป็นเรื่องที่น่าเศร้าอย่างยิ่ง บุคคลเช่นนี้เป็นคอขวดที่แย่มาก หากแนวคิด Devops มุ่งมั่นที่จะลดเวลาในการนำสินค้าออกสู่ตลาด คนดังกล่าวก็คือศัตรูตัวร้ายที่สุดของแนวคิด Devops น่าเสียดายที่ม่านปิดลงที่นี่

ป.ล. หลังจากที่พูดคุยกันเล็กน้อยเกี่ยวกับนักพัฒนาและผู้ดูแลระบบในการแชทกับผู้คน ฉันก็ได้พบกับผู้คนที่แบ่งปันความเจ็บปวดของฉัน แต่ก็มีคนที่บอกว่าไม่เคยเจออะไรแบบนี้มาก่อน ในการประชุม Devops ครั้งหนึ่ง ฉันถาม Anton Isanin (Alfa Bank) ว่าพวกเขาจัดการกับปัญหาคอขวดในรูปแบบของผู้ดูแลระบบอย่างไร ซึ่งเขาตอบว่า: "เราแทนที่พวกเขาด้วยปุ่ม" อนึ่ง ปัจเจก ด้วยการมีส่วนร่วมของเขา ฉันอยากจะเชื่อว่ามีผู้ดูแลระบบที่ดีมากกว่าศัตรูมากมาย ใช่แล้ว ภาพตอนต้นคือจดหมายโต้ตอบจริงๆ

ที่มา: www.habr.com