สวัสดีฮับ! ฉันสนับสนุนระบบ Highload IT มาเป็นเวลาสิบปีแล้ว ฉันจะไม่เขียนบทความนี้เกี่ยวกับปัญหาในการตั้งค่า nginx ให้ทำงานในโหมด 1000+ RPS หรือเรื่องทางเทคนิคอื่น ๆ ฉันจะแบ่งปันข้อสังเกตของฉันเกี่ยวกับปัญหาในกระบวนการที่เกิดขึ้นในการสนับสนุนและการทำงานของระบบดังกล่าว
การตรวจสอบ
ฝ่ายสนับสนุนด้านเทคนิคไม่รอจนกว่าคำขอจะมาถึงพร้อมกับเนื้อหา “ทำไม... ไซต์ไม่ทำงานอีกครั้ง?” ภายในหนึ่งนาทีหลังจากที่ไซต์ขัดข้อง ฝ่ายสนับสนุนควรทราบปัญหาแล้วและเริ่มแก้ไข แต่ไซต์นี้เป็นเพียงส่วนยอดของภูเขาน้ำแข็ง. ความพร้อมใช้งานเป็นหนึ่งในสิ่งแรกๆ ที่ได้รับการตรวจสอบ
จะทำอย่างไรกับสถานการณ์เมื่อสินค้าคงเหลือของร้านค้าออนไลน์ไม่มาจากระบบ ERP อีกต่อไป? หรือระบบ CRM ที่คำนวณส่วนลดสำหรับลูกค้าหยุดตอบสนอง? ดูเหมือนว่าไซต์จะทำงานได้ Zabbix แบบมีเงื่อนไขได้รับการตอบกลับ 200 ครั้ง หัวหน้ากะไม่ได้รับการแจ้งเตือนใดๆ จากผู้เฝ้าติดตาม และกำลังรับชมตอนแรกของ Game of Thrones ซีซั่นใหม่อย่างมีความสุข
การตรวจสอบมักจำกัดอยู่เพียงการวัดสถานะของหน่วยความจำ RAM และโหลดโปรเซสเซอร์ของเซิร์ฟเวอร์เท่านั้น แต่สำหรับธุรกิจ การมีผลิตภัณฑ์พร้อมจำหน่ายบนเว็บไซต์นั้นสำคัญกว่ามาก ความล้มเหลวตามเงื่อนไขของเครื่องเสมือนหนึ่งเครื่องในคลัสเตอร์จะนำไปสู่ความจริงที่ว่าการรับส่งข้อมูลจะหยุดไปที่เครื่องนั้นและภาระบนเซิร์ฟเวอร์อื่นจะเพิ่มขึ้น บริษัทจะไม่ขาดทุน
ดังนั้น นอกเหนือจากการตรวจสอบพารามิเตอร์ทางเทคนิคของระบบปฏิบัติการบนเซิร์ฟเวอร์แล้ว คุณยังต้องกำหนดค่าการวัดทางธุรกิจอีกด้วย ตัวชี้วัดที่ส่งผลโดยตรงต่อเงิน การโต้ตอบต่างๆ กับระบบภายนอก (CRM, ERP และอื่นๆ) จำนวนคำสั่งซื้อในช่วงระยะเวลาหนึ่ง การอนุญาตลูกค้าที่สำเร็จหรือไม่สำเร็จและตัวชี้วัดอื่น ๆ
การโต้ตอบกับระบบภายนอก
เว็บไซต์หรือแอปพลิเคชันมือถือใด ๆ ที่มีมูลค่าการซื้อขายมากกว่าพันล้านรูเบิลต่อปีจะโต้ตอบกับระบบภายนอก เริ่มต้นจาก CRM และ ERP ที่กล่าวมาข้างต้น และปิดท้ายด้วยการถ่ายโอนข้อมูลการขายไปยังระบบ Big Data ภายนอก เพื่อวิเคราะห์การซื้อและเสนอผลิตภัณฑ์ให้กับลูกค้าว่าเขาจะซื้อแน่นอน (อันที่จริงไม่ใช่) แต่ละระบบดังกล่าวมีการสนับสนุนของตัวเอง และบ่อยครั้งที่การสื่อสารกับระบบเหล่านี้ทำให้เกิดความเจ็บปวด โดยเฉพาะอย่างยิ่งเมื่อปัญหาเกิดขึ้นทั่วโลกและคุณต้องวิเคราะห์ในระบบต่างๆ
บางระบบจะให้หมายเลขโทรศัพท์หรือโทรเลขแก่ผู้ดูแลระบบ คุณต้องเขียนจดหมายถึงผู้จัดการที่ไหนสักแห่งหรือไปที่ตัวติดตามบั๊กของระบบภายนอกเหล่านี้ แม้จะอยู่ในบริบทของบริษัทขนาดใหญ่แห่งหนึ่ง ระบบที่แตกต่างกันก็มักจะทำงานในระบบบัญชีแอปพลิเคชันที่แตกต่างกัน บางครั้งการติดตามสถานะของแอปพลิเคชันก็เป็นไปไม่ได้ คุณได้รับคำขอใน Jira แบบมีเงื่อนไขเดียว จากนั้นในความคิดเห็นของ Jira แรกนี้ คุณใส่ลิงก์ไปยังปัญหาใน Jira อื่น ในจิราตัวที่สองในแอปพลิเคชันมีคนเขียนความคิดเห็นไว้แล้ว คุณต้องโทรหาผู้ดูแลระบบที่มีเงื่อนไข Andrey เพื่อแก้ไขปัญหา เป็นต้น
ทางออกที่ดีที่สุดสำหรับปัญหานี้คือการสร้างพื้นที่เดียวสำหรับการสื่อสาร เช่น ใน Slack ขอเชิญผู้เข้าร่วมกระบวนการปฏิบัติการระบบภายนอกทุกท่านเข้าร่วม และยังมีตัวติดตามเดียวเพื่อไม่ให้แอปพลิเคชันซ้ำกัน ควรติดตามแอปพลิเคชันในที่เดียว ตั้งแต่การตรวจสอบการแจ้งเตือนไปจนถึงผลลัพธ์ของการแก้ไขข้อบกพร่องในอนาคต คุณจะบอกว่าสิ่งนี้ไม่สมจริง และเคยเกิดขึ้นในอดีตที่เราทำงานในเครื่องติดตามเครื่องหนึ่ง และเครื่องมือเหล่านั้นทำงานในเครื่องติดตามเครื่องอื่นด้วย ระบบต่างๆ ปรากฏขึ้น พวกเขามีทีมไอทีที่เป็นอิสระของตัวเอง ฉันเห็นด้วย ดังนั้นปัญหาจึงต้องได้รับการแก้ไขจากด้านบนในระดับ CIO หรือเจ้าของผลิตภัณฑ์
ทุกระบบที่คุณโต้ตอบด้วยควรให้การสนับสนุนเป็นบริการโดยมี SLA ที่ชัดเจนเพื่อแก้ไขปัญหาตามลำดับความสำคัญ และไม่ใช่เมื่อผู้ดูแลระบบที่มีเงื่อนไข Andrey มีเวลาสักครู่สำหรับคุณ
ผู้ชายคอขวด
ทุกคนในโครงการ (หรือผลิตภัณฑ์) มีบุคคลที่ไปเที่ยวพักผ่อนจนเกิดอาการชักในหมู่ผู้บังคับบัญชาหรือไม่? นี่อาจเป็นวิศวกร นักวิเคราะห์ หรือนักพัฒนา Devops ท้ายที่สุดแล้ว มีเพียงวิศวกร Devops เท่านั้นที่รู้ว่าเซิร์ฟเวอร์ใดมีคอนเทนเนอร์ใดติดตั้งอยู่ วิธีรีบูตคอนเทนเนอร์ในกรณีที่เกิดปัญหา และโดยทั่วไปแล้ว ปัญหาที่ซับซ้อนใด ๆ ไม่สามารถแก้ไขได้หากไม่มีเขา นักวิเคราะห์เป็นเพียงคนเดียวที่รู้ว่ากลไกที่ซับซ้อนของคุณทำงานอย่างไร กระแสข้อมูลใดไปที่ไหน ภายใต้พารามิเตอร์ของการร้องขอบริการใดที่เราจะได้รับการตอบสนอง
ใครจะเข้าใจได้อย่างรวดเร็วว่าเหตุใดจึงมีข้อผิดพลาดในบันทึกและแก้ไขข้อบกพร่องร้ายแรงในผลิตภัณฑ์โดยทันที แน่นอนว่าเป็นผู้พัฒนาคนเดียวกัน ยังมีอย่างอื่นอีก แต่ด้วยเหตุผลบางอย่างมีเพียงเขาเท่านั้นที่เข้าใจว่าโมดูลต่างๆ ของระบบทำงานอย่างไร
สาเหตุของปัญหานี้คือการไม่มีเอกสารประกอบ. ท้ายที่สุดแล้ว หากมีการอธิบายบริการทั้งหมดในระบบของคุณ ก็สามารถจัดการกับปัญหาได้โดยไม่ต้องมีนักวิเคราะห์ หาก Devops ใช้เวลาสองสามวันจากตารางงานที่ยุ่งของเขา และอธิบายเซิร์ฟเวอร์ บริการ และคำแนะนำทั้งหมดสำหรับการแก้ปัญหาทั่วไป ปัญหาในกรณีที่เขาไม่อยู่ก็สามารถแก้ไขได้โดยไม่มีเขา คุณไม่จำเป็นต้องดื่มเบียร์บนชายหาดให้เสร็จอย่างรวดเร็วในช่วงวันหยุดและมองหา Wi-Fi เพื่อแก้ไขปัญหา
ความสามารถและความรับผิดชอบของเจ้าหน้าที่สนับสนุน
ในโครงการขนาดใหญ่ บริษัทต่างๆ จะไม่ละเลยเงินเดือนของนักพัฒนา พวกเขากำลังมองหาคนกลางหรือผู้อาวุโสที่มีราคาแพงจากโครงการที่คล้ายกัน ด้วยการสนับสนุนสถานการณ์จะแตกต่างออกไปเล็กน้อย พวกเขากำลังพยายามลดต้นทุนเหล่านี้ในทุกวิถีทางที่เป็นไปได้ บริษัทต่างๆ จ้างคนงาน Enikey ที่ราคาไม่แพงเมื่อวานนี้และเข้าสู่การต่อสู้อย่างกล้าหาญ กลยุทธ์นี้เป็นไปได้หากเรากำลังพูดถึงเว็บไซต์นามบัตรของโรงงานในเซเลโนกราด
หากเรากำลังพูดถึงร้านค้าออนไลน์ขนาดใหญ่ การหยุดทำงานทุก ๆ ชั่วโมงจะมีค่าใช้จ่ายมากกว่าเงินเดือนรายเดือนของผู้ดูแลระบบ Enikey ลองใช้มูลค่าการซื้อขายประจำปี 1 พันล้านรูเบิลเป็นจุดเริ่มต้น นี่คือมูลค่าการซื้อขายขั้นต่ำของร้านค้าออนไลน์จากการจัดอันดับ . หารจำนวนนี้ด้วยจำนวนชั่วโมงต่อปีและรับผลขาดทุนสุทธิมากกว่า 100 รูเบิล และถ้าคุณไม่นับชั่วโมงกลางคืน คุณสามารถเพิ่มจำนวนเป็นสองเท่าได้อย่างปลอดภัย
แต่เงินไม่ใช่สิ่งสำคัญใช่ไหม? (ไม่สิ สิ่งสำคัญคือ) นอกจากนี้ยังมีการสูญเสียชื่อเสียงอีกด้วย การล่มสลายของร้านค้าออนไลน์ที่มีชื่อเสียงอาจทำให้เกิดกระแสวิจารณ์บนโซเชียลเน็ตเวิร์กและสิ่งตีพิมพ์ในสื่อเฉพาะเรื่อง และบทสนทนาของเพื่อนๆ ในครัวสไตล์ “อย่าซื้ออะไรตรงนั้น เว็บเขาล่มตลอด” ก็วัดกันไม่ได้เลย
ตอนนี้มารับผิดชอบ ในทางปฏิบัติของฉันมีกรณีที่ผู้ดูแลระบบที่ปฏิบัติหน้าที่ไม่ตอบสนองต่อการแจ้งเตือนจากระบบการตรวจสอบเกี่ยวกับความไม่พร้อมใช้งานของไซต์ทันเวลา ในเย็นวันศุกร์ของฤดูร้อนอันน่ารื่นรมย์ เว็บไซต์ของร้านค้าออนไลน์ชื่อดังแห่งหนึ่งในมอสโกวเงียบงัน ในเช้าวันเสาร์ ผู้จัดการผลิตภัณฑ์ของไซต์นี้ไม่เข้าใจว่าทำไมไซต์จึงไม่เปิดขึ้น และฝ่ายสนับสนุนและการแจ้งเตือนด่วนใน Slack ก็เงียบไป ความผิดพลาดดังกล่าวทำให้เราเสียเงินเป็นจำนวนหกหลัก และเจ้าหน้าที่ผู้ปฏิบัติหน้าที่คนนี้ก็เป็นงานของเขา
ความรับผิดชอบเป็นทักษะที่ยากต่อการพัฒนา ไม่ว่าบุคคลจะมีหรือไม่ก็ตาม ดังนั้นในระหว่างการสัมภาษณ์ ฉันพยายามระบุการมีอยู่ด้วยคำถามต่างๆ ที่แสดงให้เห็นทางอ้อมว่าบุคคลนั้นคุ้นเคยกับการรับผิดชอบหรือไม่ ถ้ามีคนตอบว่าเลือกมหาวิทยาลัยเพราะพ่อแม่บอก หรือเปลี่ยนงานเพราะภรรยาบอกว่ารายได้ไม่พอ ก็อย่าไปยุ่งกับคนแบบนั้นดีกว่า
การโต้ตอบกับทีมพัฒนา
เมื่อผู้ใช้พบปัญหาง่ายๆ กับผลิตภัณฑ์ระหว่างการใช้งาน ฝ่ายสนับสนุนจะแก้ไขด้วยตนเอง พยายามจำลองปัญหา วิเคราะห์บันทึก และอื่นๆ แต่จะทำอย่างไรเมื่อมีข้อบกพร่องปรากฏในผลิตภัณฑ์? ในกรณีนี้ ฝ่ายสนับสนุนจะมอบหมายงานให้กับนักพัฒนา และนี่คือจุดเริ่มต้นของความสนุก
นักพัฒนามีภาระงานมากเกินไปอย่างต่อเนื่อง พวกเขากำลังสร้างคุณสมบัติใหม่ การแก้ไขข้อบกพร่องด้วยการขายไม่ใช่กิจกรรมที่น่าสนใจที่สุด ใกล้จะถึงกำหนดเวลาในการวิ่งครั้งต่อไปให้เสร็จสิ้น แล้วคนสนับสนุนที่ไม่พอใจก็มาบอกว่า “เลิกทุกอย่างทันที เรามีปัญหา” ลำดับความสำคัญของงานดังกล่าวมีน้อย โดยเฉพาะอย่างยิ่งเมื่อปัญหาไม่ได้สำคัญที่สุดและฟังก์ชันหลักของไซต์ใช้งานได้ และเมื่อผู้จัดการรุ่นไม่ได้วิ่งไปรอบ ๆ ด้วยสายตาโปนและเขียนว่า: "เพิ่มงานนี้อย่างเร่งด่วนในรุ่นถัดไปหรือโปรแกรมแก้ไขด่วน"
ปัญหาที่มีลำดับความสำคัญปกติหรือต่ำจะถูกย้ายจากรุ่นสู่รุ่น กับคำถามที่ว่า “งานจะเสร็จเมื่อไร?” คุณจะได้รับคำตอบในรูปแบบ: “ขออภัย ขณะนี้มีงานจำนวนมาก โปรดสอบถามหัวหน้าทีมหรือผู้จัดการฝ่ายปล่อย”
ปัญหาด้านประสิทธิภาพมีลำดับความสำคัญสูงกว่าการสร้างคุณลักษณะใหม่ บทวิจารณ์ที่ไม่ดีจะเกิดขึ้นได้ไม่นานหากผู้ใช้พบข้อบกพร่องอยู่ตลอดเวลา ชื่อเสียงที่เสียหายนั้นยากจะกู้คืน
ปัญหาของการมีปฏิสัมพันธ์ระหว่างการพัฒนาและการสนับสนุนได้รับการแก้ไขโดย DevOps ตัวย่อนี้มักใช้ในรูปแบบของบุคคลเฉพาะที่ช่วยสร้างสภาพแวดล้อมการทดสอบสำหรับการพัฒนา สร้างไปป์ไลน์ CICD และนำโค้ดที่ทดสอบมาสู่การใช้งานจริงอย่างรวดเร็ว DevOps เป็นแนวทางในการพัฒนาซอฟต์แวร์เมื่อผู้เข้าร่วมทุกคนในกระบวนการโต้ตอบกันอย่างใกล้ชิด และช่วยสร้างและอัปเดตผลิตภัณฑ์และบริการซอฟต์แวร์ได้อย่างรวดเร็ว ฉันหมายถึงนักวิเคราะห์ นักพัฒนา ผู้ทดสอบ และฝ่ายสนับสนุน
ในแนวทางนี้ การสนับสนุนและการพัฒนาไม่ใช่แผนกที่แตกต่างกันโดยมีเป้าหมายและวัตถุประสงค์ของตนเอง การพัฒนาเกี่ยวข้องกับการดำเนินงานและในทางกลับกัน วลีที่มีชื่อเสียงของทีมกระจาย: “ปัญหาไม่ได้อยู่ข้างฉัน” ไม่ปรากฏในแชทบ่อยนักอีกต่อไป และผู้ใช้ปลายทางก็มีความสุขมากขึ้นเล็กน้อย
ที่มา: will.com