สุขสันต์วันศุกร์ทุกคน! เพื่อนๆ วันนี้เราจะสานต่อชุดสิ่งพิมพ์สำหรับหลักสูตรนี้โดยเฉพาะ เพราะชั้นเรียนในกลุ่มใหม่สำหรับหลักสูตรจะเริ่มปลายสัปดาห์หน้า เอาล่ะ มาเริ่มกันเลย!
การตรวจสอบคือ เพียงแค่. นี่คือข้อเท็จจริงที่ทราบแล้ว เรียกใช้ Nagios เรียกใช้ NRPE บนระบบระยะไกล กำหนดค่า Nagios บนพอร์ต NRPE TCP 5666 และคุณมีการตรวจสอบ
มันง่ายจนไม่น่าสนใจ ตอนนี้คุณมีตัววัดพื้นฐานสำหรับเวลา CPU, ระบบย่อยของดิสก์, RAM ซึ่งจัดหาให้กับ Nagios และ NRPE เป็นค่าเริ่มต้น แต่นี่ไม่ใช่ "การติดตาม" จริงๆ เช่นนี้ นี่เป็นเพียงการเริ่มต้น.
(โดยปกติแล้วพวกเขาจะติดตั้ง PNP4Nagios, RRDtool และ Thruk ตั้งค่าการแจ้งเตือนใน Slack และตรงไปที่ nagiosexchange แต่ขอปล่อยไว้ตอนนี้ก่อน)
การติดตามผลที่ดี จริงๆ แล้วค่อนข้างซับซ้อน คุณจำเป็นต้องรู้ภายในของแอปพลิเคชันที่คุณกำลังติดตามจริงๆ
การตรวจสอบยากไหม?
เซิร์ฟเวอร์ใดๆ ไม่ว่าจะเป็น Linux หรือ Windows ตามคำจำกัดความจะให้บริการตามวัตถุประสงค์บางประการ Apache, Samba, Tomcat, พื้นที่จัดเก็บไฟล์, LDAP - บริการทั้งหมดนี้มีเอกลักษณ์ไม่มากก็น้อยในแง่หนึ่งหรือหลายด้าน แต่ละคนมีหน้าที่ของตัวเองมีลักษณะเฉพาะของตัวเอง มีหลายวิธีในการรับตัวชี้วัด KPI (ตัวบ่งชี้ประสิทธิภาพหลัก) ที่น่าสนใจสำหรับคุณเมื่อเซิร์ฟเวอร์อยู่ระหว่างการโหลด
ผู้เขียนภาพถ่าย บน
(ฉันหวังว่าแดชบอร์ดของฉันจะเป็นสีฟ้านีออน - ถอนหายใจเหมือนฝัน -... อืม...)
ซอฟต์แวร์ใดๆ ที่ให้บริการจะต้องมีกลไกในการรวบรวมตัวชี้วัด Apache มีโมดูล mod-statusโดยแสดงหน้าสถานะเซิร์ฟเวอร์ Nginx มี - stub_status. Tomcat มี JMX หรือเว็บแอปพลิเคชันแบบกำหนดเองที่แสดงตัวชี้วัดหลัก MySQL มีคำสั่ง "show global status" เป็นต้น
เหตุใดนักพัฒนาจึงไม่สร้างกลไกที่คล้ายกันในแอปพลิเคชันที่พวกเขาสร้างขึ้น
มีเพียงนักพัฒนาเท่านั้นที่ทำสิ่งนี้หรือไม่?
การไม่แยแสในระดับหนึ่งต่อการฝังตัววัดไม่ได้จำกัดอยู่เพียงนักพัฒนาเท่านั้น ฉันทำงานในบริษัทที่พวกเขาพัฒนาแอปพลิเคชันโดยใช้ Tomcat และไม่ได้จัดเตรียมตัววัดใดๆ ของตนเอง ไม่มีบันทึกกิจกรรมการบริการ ยกเว้นบันทึกข้อผิดพลาดทั่วไปของ Tomcat นักพัฒนาซอฟต์แวร์บางรายสร้างบันทึกจำนวนมากซึ่งไม่มีความหมายอะไรกับผู้ดูแลระบบที่โชคไม่ดีพอที่จะอ่านบันทึกเหล่านี้ในเวลา 3:15 น. ในตอนเช้า
ผู้เขียนภาพถ่าย บน
วิศวกรระบบที่ทำให้ผลิตภัณฑ์ดังกล่าวออกจำหน่ายต้องรับผิดชอบต่อสถานการณ์ดังกล่าวด้วย วิศวกรระบบเพียงไม่กี่คนที่มีเวลาหรือใส่ใจในการพยายามแยกตัววัดที่มีความหมายจากบันทึก โดยไม่มีบริบทของตัววัดเหล่านั้น และความสามารถในการตีความตามกิจกรรมของแอปพลิเคชัน บางคนไม่เข้าใจว่าพวกเขาจะได้รับประโยชน์จากมันได้อย่างไร นอกเหนือจากตัวบ่งชี้ "มีบางอย่างผิดปกติในปัจจุบัน (หรือเร็วๆ นี้)"
การเปลี่ยนแปลงความคิดเกี่ยวกับความจำเป็นในการวัดจะต้องเกิดขึ้นไม่เพียงแต่ในหมู่นักพัฒนาเท่านั้น แต่ยังรวมถึงวิศวกรระบบด้วย
สำหรับวิศวกรระบบที่ไม่เพียงแต่ต้องตอบสนองต่อเหตุการณ์สำคัญเท่านั้น แต่ยังต้องแน่ใจว่าเหตุการณ์เหล่านั้นจะไม่เกิดขึ้น การขาดตัวชี้วัดมักจะเป็นอุปสรรคในการดำเนินการดังกล่าว
อย่างไรก็ตาม วิศวกรระบบมักจะไม่ยุ่งเกี่ยวกับโค้ดเพื่อสร้างรายได้ให้กับบริษัทของตน พวกเขาต้องการผู้นำนักพัฒนาที่เข้าใจถึงความสำคัญของความรับผิดชอบของวิศวกรระบบในการระบุปัญหา สร้างความตระหนักรู้เกี่ยวกับปัญหาด้านประสิทธิภาพ และอื่นๆ
สิ่งนี้ทำให้เสื่อมเสีย
ความคิดแบบ Devops อธิบายถึงการทำงานร่วมกันระหว่างการพัฒนา (dev) และการคิดแบบปฏิบัติการ (ops) บริษัทใดๆ ที่อ้างว่า "ทำ devops" จะต้อง:
- พูดสิ่งที่พวกเขาอาจจะไม่ (หมายถึงมีม The Princess Bride - "ฉันไม่คิดว่ามันหมายถึงสิ่งที่คุณคิดว่ามันหมายถึง!")
- ส่งเสริมทัศนคติในการปรับปรุงผลิตภัณฑ์อย่างต่อเนื่อง
คุณไม่สามารถปรับปรุงผลิตภัณฑ์ได้และรู้ว่าผลิตภัณฑ์ได้รับการปรับปรุงแล้วหากคุณไม่รู้ว่าผลิตภัณฑ์ทำงานอย่างไรในปัจจุบัน คุณไม่สามารถทราบได้ว่าผลิตภัณฑ์ทำงานอย่างไร หากคุณไม่เข้าใจว่าส่วนประกอบต่างๆ ทำงานอย่างไร บริการต่างๆ ที่ผลิตภัณฑ์ต้องพึ่งพา ปัญหาหลัก และปัญหาคอขวด
หากคุณไม่ระวังปัญหาคอขวดที่อาจเกิดขึ้น คุณจะไม่สามารถปฏิบัติตามเทคนิค Five Whys เมื่อเขียน Postmortem คุณจะไม่สามารถวางทุกอย่างไว้บนหน้าจอเดียวเพื่อดูว่าผลิตภัณฑ์ทำงานอย่างไรหรือรู้ว่ามันดูเหมือน "ปกติและมีความสุข" อย่างไร
เลื่อนไปทางซ้าย ซ้าย ฉันพูดว่า LEEEE—
สำหรับฉัน หลักการสำคัญประการหนึ่งของ Devops คือ "shift left" การเลื่อนไปทางซ้ายในบริบทนี้หมายถึงการเปลี่ยนความเป็นไปได้ (ไม่มีความรับผิดชอบแต่ความสามารถเท่านั้น) เพื่อทำสิ่งต่าง ๆ ที่วิศวกรระบบโดยทั่วไปสนใจ เช่น การสร้างการวัดประสิทธิภาพ การใช้บันทึกอย่างมีประสิทธิภาพมากขึ้น ฯลฯ ไปทางซ้ายในวงจรชีวิตการจัดส่งซอฟต์แวร์
ผู้เขียนภาพถ่าย บน
นักพัฒนาซอฟต์แวร์จะต้องสามารถใช้และรู้จักเครื่องมือตรวจสอบที่บริษัทใช้เพื่อทำการตรวจสอบในทุกรูปแบบ ตัวชี้วัด การบันทึก อินเทอร์เฟซการตรวจสอบ และที่สำคัญที่สุดคือ ดูวิธีการทำงานของผลิตภัณฑ์ในการผลิต. คุณไม่สามารถให้นักพัฒนาลงทุนความพยายามและเวลาในการตรวจสอบได้จนกว่าพวกเขาจะสามารถดูตัวชี้วัดและมีอิทธิพลต่อรูปลักษณ์ของพวกเขา วิธีที่เจ้าของผลิตภัณฑ์นำเสนอต่อ CTO ในการบรรยายสรุปครั้งถัดไป เป็นต้น
พูดสั้น ๆ
- นำม้าของคุณไปที่น้ำ แสดงให้นักพัฒนาเห็นว่าพวกเขาสามารถหลีกเลี่ยงปัญหาได้มากเพียงใด ช่วยพวกเขาระบุ KPI และหน่วยวัดที่เหมาะสมสำหรับแอปพลิเคชันของตน เพื่อที่เจ้าของผลิตภัณฑ์จะถูกตะโกนใส่โดย CTO น้อยลง พาพวกเขาไปสู่แสงสว่างอย่างอ่อนโยนและสงบ หากไม่ได้ผล ให้ติดสินบน ข่มขู่ และโน้มน้าวพวกเขาหรือเจ้าของผลิตภัณฑ์ให้ดำเนินการรับตัวชี้วัดเหล่านี้จากแอปพลิเคชันโดยเร็วที่สุด จากนั้นจึงวาดไดอะแกรม นี่จะเป็นเรื่องยากเนื่องจากจะไม่ถูกมองว่าเป็นลำดับความสำคัญ และแผนงานผลิตภัณฑ์จะมีโครงการสร้างรายได้มากมายที่รอดำเนินการ ดังนั้น คุณจะต้องมีกรณีทางธุรกิจเพื่อพิสูจน์เวลาและค่าใช้จ่ายที่ใช้ในการดำเนินการตรวจสอบในผลิตภัณฑ์
- ช่วยให้วิศวกรระบบนอนหลับสบายตลอดทั้งคืน แสดงให้พวกเขาเห็นว่าการใช้รายการตรวจสอบ "เปิดตัวเลย" สำหรับผลิตภัณฑ์ที่วางจำหน่ายเป็นสิ่งที่ดี และการตรวจสอบให้แน่ใจว่าแอปพลิเคชันทั้งหมดในการผลิตครอบคลุมด้วยการวัดจะช่วยให้คุณนอนหลับได้ดีขึ้นในเวลากลางคืนโดยช่วยให้นักพัฒนาเห็นว่าเกิดอะไรขึ้นและตรงไหน อย่างไรก็ตาม วิธีที่ถูกต้องในการสร้างความรำคาญและทำให้นักพัฒนา เจ้าของผลิตภัณฑ์ หรือ CTO หงุดหงิดก็คือการยืนหยัดและต่อต้าน ลักษณะการทำงานนี้จะส่งผลต่อวันที่วางจำหน่ายของผลิตภัณฑ์ใดๆ หากคุณรอจนถึงนาทีสุดท้ายอีกครั้ง ดังนั้นให้เลื่อนไปทางซ้ายอีกครั้งและนำปัญหาเหล่านี้เข้าสู่แผนโครงการของคุณโดยเร็วที่สุด หากจำเป็น ให้ไปที่การประชุมผลิตภัณฑ์ ใส่หนวดปลอมแล้วรู้สึกหรืออะไรสักอย่าง มันจะไม่มีวันล้มเหลว สื่อสารข้อกังวลของคุณ แสดงให้เห็นประโยชน์ที่ชัดเจน และประกาศข่าวประเสริฐ
- ตรวจสอบให้แน่ใจว่าทั้งการพัฒนา (dev) และการดำเนินงาน (ops) เข้าใจความหมายและผลที่ตามมาของตัวชี้วัดผลิตภัณฑ์ที่ย้ายเข้าสู่โซนสีแดง อย่าปล่อยให้ Ops เป็นผู้พิทักษ์สุขภาพผลิตภัณฑ์แต่เพียงผู้เดียว ตรวจสอบให้แน่ใจว่านักพัฒนาก็มีส่วนร่วมเช่นกัน (#productsquads)
- บันทึกเป็นสิ่งที่ดี แต่ตัวชี้วัดก็เช่นกัน รวมเข้าด้วยกันและอย่าปล่อยให้ท่อนไม้ของคุณกลายเป็นขยะในลูกบอลเพลิงอันไร้ประโยชน์ขนาดมหึมา อธิบายและแสดงให้นักพัฒนาเห็นว่าเหตุใดจึงไม่มีใครเข้าใจบันทึกของพวกเขา แสดงให้พวกเขาเห็นว่าการดูบันทึกที่ไม่มีประโยชน์ในเวลา 3:15 น. ในตอนเช้าเป็นอย่างไร
ผู้เขียนภาพถ่าย บน
นั่นคือทั้งหมดที่ วัสดุใหม่จะเปิดตัวในสัปดาห์หน้า หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับหลักสูตรนี้ เราขอเชิญคุณเข้าร่วม ซึ่งจะจัดขึ้นในวันจันทร์ และตอนนี้เรากำลังรอความคิดเห็นของคุณตามปกติ
ที่มา: will.com