ผู้อำนวยการฝ่ายปฏิบัติการของพอร์ทัล Banki.ru Andrey Nikolsky พูดในการประชุมเมื่อปีที่แล้ว เกี่ยวกับบริการเด็กกำพร้า: วิธีระบุเด็กกำพร้าในโครงสร้างพื้นฐาน เหตุใดบริการเด็กกำพร้าถึงไม่ดี จะทำอย่างไรกับพวกเขา และจะทำอย่างไรหากไม่มีสิ่งใดช่วยได้
ด้านล่างของการตัดคือเวอร์ชันข้อความของรายงาน
สวัสดีเพื่อนร่วมงาน! ฉันชื่อ Andrey ฉันเป็นหัวหน้าฝ่ายปฏิบัติการที่ Banki.ru
เรามีบริการขนาดใหญ่ ซึ่งเป็นบริการแบบเสาหิน มีบริการในความหมายแบบคลาสสิก และยังมีบริการที่เล็กมาก ในศัพท์เฉพาะกรรมกร-ชาวนาของผม ผมบอกว่าถ้าบริการเรียบง่ายและเล็ก มันก็เป็นบริการระดับจุลภาค และถ้าไม่เรียบง่ายและเล็กมาก มันก็เป็นเพียงบริการเท่านั้น.
ข้อดีของการบริการ
ฉันจะอธิบายข้อดีของบริการนี้อย่างรวดเร็ว
ประการแรกคือการปรับขนาด คุณสามารถดำเนินการบางอย่างกับบริการและเริ่มการผลิตได้อย่างรวดเร็ว คุณได้รับปริมาณการใช้งาน คุณได้โคลนบริการแล้ว คุณมีปริมาณการเข้าชมมากขึ้น คุณได้โคลนมันและใช้ชีวิตอยู่กับมัน นี่เป็นโบนัสที่ดีและโดยหลักการแล้วเมื่อเราเริ่มต้นก็ถือเป็นสิ่งที่สำคัญที่สุดสำหรับเราว่าทำไมเราถึงทำทั้งหมดนี้
ประการที่สอง การพัฒนาแบบแยกเดี่ยว เมื่อคุณมีทีมพัฒนาหลายทีม มีนักพัฒนาที่แตกต่างกันหลายคนในแต่ละทีม และแต่ละทีมจะพัฒนาบริการของตนเอง
กับทีมมีความแตกต่างกันนิดหน่อย นักพัฒนามีความแตกต่างกัน และมีตัวอย่างเช่น . ฉันเห็นสิ่งนี้ครั้งแรกกับ Maxim Dorofeev บางครั้งคนเกล็ดหิมะก็อยู่ในทีมบางทีมและไม่ได้อยู่ในทีมอื่น สิ่งนี้ทำให้บริการต่างๆ ที่ใช้ทั่วทั้งบริษัทมีความไม่สม่ำเสมอเล็กน้อย
ดูจากภาพ นี่คือนักพัฒนาที่ดี มือใหญ่ ทำอะไรได้หลายอย่าง ปัญหาหลักคือว่ามือเหล่านี้มาจากไหน
บริการทำให้สามารถใช้ภาษาการเขียนโปรแกรมที่แตกต่างกันซึ่งเหมาะสมกับงานที่แตกต่างกันมากขึ้น บริการบางอย่างอยู่ใน Go บางอย่างอยู่ใน Erlang บางอย่างอยู่ใน Ruby บางอย่างอยู่ใน PHP บางอย่างอยู่ใน Python โดยทั่วไปแล้วคุณสามารถขยายวงกว้างได้มาก มีความแตกต่างที่นี่เช่นกัน
สถาปัตยกรรมเชิงบริการนั้นเกี่ยวกับ Devops เป็นหลัก นั่นคือ หากคุณไม่มีระบบอัตโนมัติ ไม่มีกระบวนการปรับใช้ หากคุณกำหนดค่าด้วยตนเอง การกำหนดค่าของคุณสามารถเปลี่ยนจากอินสแตนซ์บริการหนึ่งไปยังอีกอินสแตนซ์ได้ และคุณต้องไปที่นั่นเพื่อทำบางสิ่ง แสดงว่าคุณตกนรก
ตัวอย่างเช่น คุณมีบริการ 20 บริการและคุณต้องปรับใช้ด้วยตนเอง คุณมีคอนโซล 20 เครื่อง และคุณกด "Enter" พร้อมกันเหมือนนินจา มันไม่ค่อยดีนัก
หากคุณมีบริการหลังการทดสอบ (แน่นอนว่ามีการทดสอบ) และคุณยังต้องจัดทำไฟล์ให้เสร็จเพื่อให้สามารถใช้งานได้จริง ฉันก็แจ้งข่าวร้ายให้คุณทราบเช่นกัน
หากคุณพึ่งพาบริการเฉพาะของ Amazon และทำงานในรัสเซีย เมื่อสองเดือนที่แล้วคุณก็พบว่า “ทุกสิ่งรอบตัวลุกเป็นไฟ ฉันสบายดี ทุกอย่างเจ๋ง”
เราใช้ Ansible เพื่อปรับใช้อัตโนมัติ, Puppet เพื่อการบรรจบกัน, Bamboo เพื่อปรับใช้อัตโนมัติ และ Confluence เพื่ออธิบายทุกอย่าง
ฉันจะไม่กล่าวถึงรายละเอียดในเรื่องนี้ เนื่องจากรายงานมีเนื้อหาเกี่ยวกับแนวทางปฏิบัติในการโต้ตอบมากกว่า ไม่ใช่เกี่ยวกับการดำเนินการทางเทคนิค
ตัวอย่างเช่น เราประสบปัญหาในการที่ Puppet บนเซิร์ฟเวอร์ทำงานร่วมกับ Ruby 2 ได้ แต่แอปพลิเคชันบางตัวเขียนขึ้นสำหรับ Ruby 1.8 และแอปพลิเคชันเหล่านั้นไม่สามารถทำงานร่วมกันได้ มีบางอย่างผิดปกติเกิดขึ้นที่นั่น และเมื่อคุณต้องการรัน Ruby หลายเวอร์ชันในเครื่องเดียว คุณมักจะเริ่มประสบปัญหา
ตัวอย่างเช่น เราให้แพลตฟอร์มแก่นักพัฒนาแต่ละรายซึ่งมีทุกอย่างโดยประมาณที่เรามี บริการทั้งหมดที่สามารถพัฒนาได้ เพื่อให้เขามีสภาพแวดล้อมที่โดดเดี่ยว เขาสามารถทำลายมันและสร้างมันขึ้นมาได้ตามที่เขาต้องการ
มันเกิดขึ้นว่าคุณจำเป็นต้องมีแพ็คเกจที่คอมไพล์เป็นพิเศษพร้อมรองรับบางสิ่งที่นั่น มันค่อนข้างยาก ฉันฟังรายงานที่อิมเมจ Docker มีน้ำหนัก 45 GB แน่นอนว่าใน Linux มันง่ายกว่า ทุกอย่างเล็กลง แต่ก็ยังมีพื้นที่ไม่เพียงพอ
มีการขึ้นต่อกันที่ขัดแย้งกัน เมื่อชิ้นส่วนหนึ่งของโปรเจ็กต์ขึ้นอยู่กับไลบรารีของเวอร์ชันหนึ่ง ส่วนอีกชิ้นของโปรเจ็กต์ขึ้นอยู่กับเวอร์ชันอื่น และไลบรารีไม่ได้ถูกติดตั้งเข้าด้วยกันเลย
เรามีไซต์และบริการใน PHP 5.6 เรารู้สึกละอายใจกับมัน แต่เราจะทำอย่างไรได้? นี่คือเว็บไซต์เดียวของเรา มีเว็บไซต์และบริการบน PHP 7 มีมากกว่านั้นเราไม่ละอายใจเลย และนักพัฒนาแต่ละคนก็มีฐานของตัวเองที่เขาเห็นอย่างมีความสุข
หากคุณเขียนในบริษัทด้วยภาษาเดียว เครื่องเสมือนสามเครื่องต่อนักพัฒนาหนึ่งคนก็ฟังดูเป็นเรื่องปกติ หากคุณมีภาษาโปรแกรมที่แตกต่างกัน สถานการณ์จะแย่ลง
คุณมีไซต์และบริการเกี่ยวกับเรื่องนี้ บนนี้ และอีกไซต์หนึ่งสำหรับ Go ไซต์หนึ่งสำหรับ Ruby และ Redis อื่น ๆ อยู่ด้านข้าง เป็นผลให้ทั้งหมดนี้กลายเป็นช่องขนาดใหญ่สำหรับการสนับสนุนและบางส่วนก็สามารถพังได้ตลอดเวลา
ดังนั้นเราจึงแทนที่ประโยชน์ของภาษาการเขียนโปรแกรมด้วยการใช้เฟรมเวิร์กที่แตกต่างกัน เนื่องจากเฟรมเวิร์ก PHP ค่อนข้างแตกต่างกัน มีความสามารถต่างกัน มีชุมชนต่างกัน และรองรับต่างกัน และคุณสามารถเขียนบริการเพื่อให้คุณมีบางสิ่งที่พร้อมอยู่แล้ว
แต่ละบริการมีทีมงานของตัวเอง
ข้อได้เปรียบหลักของเราซึ่งตกผลึกตลอดหลายปีที่ผ่านมาก็คือแต่ละบริการมีทีมงานของตัวเอง สะดวกสำหรับโครงการขนาดใหญ่ คุณสามารถประหยัดเวลาในเอกสาร ผู้จัดการรู้จักโครงการของตนเป็นอย่างดี
คุณสามารถส่งงานจากฝ่ายสนับสนุนได้อย่างง่ายดาย เช่นบริการประกันภัยล่ม และทันทีที่ทีมงานที่เกี่ยวข้องกับประกันเข้าไปแก้ไข
คุณสมบัติใหม่กำลังถูกสร้างขึ้นอย่างรวดเร็ว เพราะเมื่อคุณมีบริการปรมาณูหนึ่งรายการ คุณสามารถสกรูบางอย่างลงไปได้อย่างรวดเร็ว
และเมื่อคุณทำลายบริการและสิ่งนี้เกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ คุณไม่ส่งผลกระทบต่อบริการของผู้อื่น และนักพัฒนาจากทีมอื่น ๆ จะไม่วิ่งเข้ามาหาคุณและพูดว่า: "เอ้า อย่าทำอย่างนั้น"
เช่นเคยมีความแตกต่าง เรามีทีมที่มั่นคง ผู้จัดการทีมก็ติดทีม มีเอกสารชัดเจน ผู้จัดการ ติดตามทุกอย่างอย่างใกล้ชิด แต่ละทีมที่มีผู้จัดการมีบริการหลายอย่าง และมีความสามารถเฉพาะจุด
หากทีมลอยตัว (บางครั้งเราก็ใช้วิธีนี้เช่นกัน) มีวิธีการที่ดีที่เรียกว่า "แผนที่ดาว"
คุณมีรายชื่อบริการและผู้คน เครื่องหมายดอกจันหมายความว่าบุคคลนั้นเป็นผู้เชี่ยวชาญในบริการนี้ หนังสือหมายความว่าบุคคลนั้นกำลังศึกษาบริการนี้ งานของบุคคลนั้นคือเปลี่ยนหนังสือเล่มเล็กเป็นเครื่องหมายดอกจัน และหากไม่มีการเขียนต่อหน้าบริการ ปัญหาก็เริ่มต้นขึ้น ซึ่งฉันจะพูดถึงต่อไป
บริการเด็กกำพร้าปรากฏอย่างไร?
ปัญหาแรก วิธีแรกในการรับบริการเด็กกำพร้าในโครงสร้างพื้นฐานของคุณคือการไล่คนออก มีใครเคยมีธุรกิจตรงตามกำหนดเวลาก่อนที่จะมีการประเมินงานหรือไม่? บางครั้งอาจมีกำหนดเวลาที่จำกัดและมีเวลาไม่เพียงพอในการจัดทำเอกสาร “เราจำเป็นต้องส่งมอบบริการให้กับฝ่ายผลิต จากนั้นเราจะเพิ่มเข้าไป”
ถ้าทีมเล็กก็เกิดว่ามี Developer คนหนึ่งที่เขียนทุกอย่างที่เหลือก็อยู่ในปีก “ฉันเขียนสถาปัตยกรรมพื้นฐาน มาเพิ่มอินเทอร์เฟซกันดีกว่า” จากนั้นเมื่อถึงจุดหนึ่งผู้จัดการก็ออกไป และในช่วงเวลานี้ เมื่อผู้จัดการออกไปและยังไม่ได้แต่งตั้งผู้จัดการคนใหม่ นักพัฒนาเองจะเป็นผู้ตัดสินใจว่าบริการจะไปที่ไหนและเกิดอะไรขึ้นที่นั่น และดังที่เราทราบ (ย้อนกลับไปดูสไลด์บางส่วน) ในบางทีมมีคนเกล็ดหิมะ บางครั้งก็มีหัวหน้าทีมเกล็ดหิมะ จากนั้นเขาก็ลาออก และเราได้รับบริการเด็กกำพร้า
ในเวลาเดียวกัน งานจากฝ่ายสนับสนุนและจากธุรกิจจะไม่หายไป แต่จะจบลงที่ Backlog หากมีข้อผิดพลาดทางสถาปัตยกรรมในระหว่างการพัฒนาบริการ ข้อผิดพลาดเหล่านั้นก็จะอยู่ใน Backlog เช่นกัน การบริการก็แย่ลงเรื่อยๆ
จะระบุเด็กกำพร้าได้อย่างไร?
รายการนี้อธิบายสถานการณ์ได้ดี ใครได้เรียนรู้อะไรเกี่ยวกับโครงสร้างพื้นฐานของพวกเขาบ้าง
เกี่ยวกับการแก้ไขเอกสาร: มีบริการและโดยทั่วไปใช้งานได้ มีคู่มือสองหน้าเกี่ยวกับวิธีการใช้งาน แต่ไม่มีใครรู้ว่าภายในทำงานอย่างไร
หรือตัวอย่างเช่น มีตัวย่อลิงค์บางประเภท ตัวอย่างเช่น ขณะนี้เรามีตัวย่อลิงค์สามตัวที่ใช้งานเพื่อวัตถุประสงค์ที่แตกต่างกันในบริการที่แตกต่างกัน นี่เป็นเพียงผลที่ตามมา
ตอนนี้ฉันจะเป็นกัปตันที่ชัดเจน ควรทำอย่างไร? ขั้นแรก เราต้องโอนบริการไปยังผู้จัดการคนอื่นหรือทีมอื่น หากหัวหน้าทีมของคุณยังไม่ลาออก ดังนั้นในทีมอื่น เมื่อคุณเข้าใจว่าบริการนี้เหมือนกับเด็กกำพร้า คุณจะต้องรวมคนที่เข้าใจอย่างน้อยบางอย่างเกี่ยวกับเรื่องนี้ด้วย
สิ่งสำคัญ: คุณต้องมีขั้นตอนการโอนที่เขียนด้วยเลือด ในกรณีของเรา ฉันมักจะติดตามสิ่งนี้ เพราะฉันต้องการให้ทุกอย่างทำงาน ผู้จัดการต้องการให้จัดส่งอย่างรวดเร็ว และสิ่งที่เกิดขึ้นในภายหลังก็ไม่สำคัญสำหรับพวกเขาอีกต่อไป
วิธีต่อไปในการสร้างเด็กกำพร้าคือ “เราจะจ้างคนภายนอก เร็วขึ้น แล้วจึงส่งมอบให้กับทีม” เห็นได้ชัดว่าทุกคนมีแผนบางอย่างในทีม บ่อยครั้งที่ลูกค้าธุรกิจคิดว่าผู้เอาต์ซอร์สจะทำแบบเดียวกับฝ่ายเทคนิคที่บริษัทมี แม้ว่าแรงจูงใจจะแตกต่างกันก็ตาม มีโซลูชันทางเทคโนโลยีที่แปลกประหลาดและโซลูชันอัลกอริธึมที่แปลกประหลาดในการเอาท์ซอร์ส
เช่น เรามีบริการที่มีสฟิงซ์อยู่ในสถานที่ต่างๆที่คาดไม่ถึง ฉันจะบอกคุณทีหลังว่าฉันต้องทำอะไรบ้าง
ผู้ว่าจ้างภายนอกมีกรอบการทำงานที่เขียนขึ้นเอง นี่เป็นเพียง PHP เปล่าที่มีการคัดลอกและวางจากโปรเจ็กต์ก่อนหน้า ซึ่งคุณสามารถค้นหาได้ทุกประเภท สคริปต์การปรับใช้ถือเป็นข้อเสียเปรียบอย่างมาก เมื่อคุณจำเป็นต้องใช้สคริปต์ Bash ที่ซับซ้อนเพื่อเปลี่ยนแปลงหลายบรรทัดในไฟล์บางไฟล์ และสคริปต์การปรับใช้เหล่านี้ถูกเรียกโดยสคริปต์ตัวที่สามบางตัว เป็นผลให้คุณเปลี่ยนระบบการปรับใช้ เลือกอย่างอื่น กระโดด แต่บริการของคุณไม่ทำงาน เนื่องจากจำเป็นต้องใส่ลิงก์อีก 8 ลิงก์ระหว่างโฟลเดอร์ต่างๆ หรือเกิดขึ้นว่าบันทึกนับพันใช้งานได้ แต่แสนบันทึกไม่ทำงานอีกต่อไป
ผมจะทำหน้าที่กัปตันต่อไป การยอมรับบริการจากภายนอกเป็นขั้นตอนบังคับ มีใครเคยได้รับบริการจากภายนอกและไม่ได้รับการยอมรับจากที่ไหน? แน่นอนว่าสิ่งนี้ไม่ได้รับความนิยมเท่ากับบริการเด็กกำพร้า แต่ถึงกระนั้น
จำเป็นต้องตรวจสอบบริการ จำเป็นต้องตรวจสอบบริการ จำเป็นต้องเปลี่ยนรหัสผ่าน เรามีกรณีที่พวกเขาให้บริการแก่เรา มีแผงผู้ดูแลระบบ “ถ้าเข้าสู่ระบบ == 'ผู้ดูแลระบบ' && รหัสผ่าน == 'ผู้ดูแลระบบ'...” มันถูกเขียนไว้ในโค้ดโดยตรง เรานั่งคิดแล้วคนเขียนเรื่องนี้ในปี 2018 เหรอ?
การทดสอบความจุก็เป็นสิ่งที่จำเป็นเช่นกัน คุณต้องดูว่าจะเกิดอะไรขึ้นกับบันทึกนับแสนรายการ ก่อนที่คุณจะนำบริการนี้ไปใช้งานจริงที่ใดที่หนึ่งด้วยซ้ำ
ไม่ควรละอายใจในการส่งบริการเพื่อการปรับปรุง เมื่อคุณพูดว่า: “เราจะไม่ยอมรับบริการนี้ เรามี 20 งาน ทำแล้วเราจะยอมรับ” นี่เป็นเรื่องปกติ มโนธรรมของคุณไม่ควรเสียหายจากข้อเท็จจริงที่ว่าคุณกำลังจัดตั้งผู้จัดการหรือธุรกิจกำลังสิ้นเปลืองเงิน ธุรกิจก็จะใช้จ่ายมากขึ้น
เรามีกรณีเมื่อเราตัดสินใจว่าจ้างโครงการนำร่องจากภายนอก
จัดส่งตรงเวลา และนี่คือเกณฑ์คุณภาพเพียงอย่างเดียว นั่นเป็นเหตุผลที่เราสร้างโครงการนำร่องขึ้นมาอีกโครงการหนึ่ง ซึ่งแม้จะไม่ใช่โครงการนำร่องอีกต่อไปแล้วก็ตาม บริการเหล่านี้ได้รับการยอมรับแล้ว และพวกเขากล่าวว่า "นี่คือรหัสของคุณ นี่คือทีม นี่คือผู้จัดการของคุณ" บริการได้เริ่มทำกำไรแล้วจริงๆ ในขณะเดียวกัน พวกเขายังคงเป็นเด็กกำพร้า ไม่มีใครเข้าใจวิธีการทำงานของพวกเขา และผู้จัดการก็พยายามอย่างเต็มที่ที่จะละทิ้งงานของตน
มีแนวคิดที่ยอดเยี่ยมอีกประการหนึ่งคือการพัฒนาแบบกองโจร เมื่อแผนกใดแผนกหนึ่งซึ่งมักจะเป็นแผนกการตลาด ต้องการทดสอบสมมติฐานและสั่งบริการทั้งหมดจากภายนอก รถเริ่มไหลเข้า ปิดเอกสาร เซ็นเอกสารกับผู้รับเหมา เริ่มดำเนินการ แล้วพูดว่า “เพื่อน เรามีบริการที่นี่ รถติดแล้ว มันนำเงินมาให้เรา ยอมรับเถอะ” พวกเราก็แบบว่า “โอปป้า เป็นไปได้ยังไงล่ะ”
และอีกวิธีหนึ่งในการรับบริการเด็กกำพร้า: เมื่อบางทีมพบว่าตัวเองมีภาระงานมากกะทันหัน ฝ่ายบริหารกล่าวว่า: “มาโอนบริการของทีมนี้ไปยังทีมอื่นกันเถอะ มันมีภาระน้อยกว่า” จากนั้นเราจะโอนไปยังทีมที่สามและเปลี่ยนผู้จัดการทีม และสุดท้ายเราก็มีเด็กกำพร้าอีกครั้ง
เด็กกำพร้ามีปัญหาอะไร?
ใครไม่รู้ นี่คือเรือประจัญบาน Wasa ที่ได้รับการเลี้ยงดูในสวีเดน มีชื่อเสียงจากการที่มันจมลงหลังจากเปิดตัวได้ 5 นาที และกษัตริย์แห่งสวีเดนก็ไม่ได้ประหารชีวิตใครในเรื่องนี้ มันถูกสร้างขึ้นโดยวิศวกรสองรุ่นที่ไม่รู้ว่าจะสร้างเรือแบบนี้ได้อย่างไร เอฟเฟกต์ธรรมชาติ
อย่างไรก็ตาม เรืออาจจมลงในวิธีที่แย่กว่านั้นมาก เช่น ตอนที่กษัตริย์กำลังประทับอยู่บนเรือที่ไหนสักแห่งท่ามกลางพายุ ดังนั้นเขาจึงจมน้ำตายทันที ตามข้อมูลของ Agile ถือเป็นการดีที่จะล้มเหลวตั้งแต่เนิ่นๆ
ถ้าเราล้มเหลวเร็วก็มักจะไม่มีปัญหา ตัวอย่างเช่นในระหว่างการยอมรับก็ถูกส่งไปแก้ไข แต่ถ้าเราล้มเหลวในการผลิตอยู่แล้ว ลงทุนไปก็อาจเกิดปัญหาได้ ผลที่ตามมาตามที่เรียกว่าในธุรกิจ
เหตุใดบริการเด็กกำพร้าจึงเป็นอันตราย:
- บริการอาจหยุดทำงานกะทันหัน
- การบริการใช้เวลานานในการซ่อมหรือไม่มีการซ่อมเลย
- ปัญหาด้านความปลอดภัย
- ปัญหาเกี่ยวกับการปรับปรุงและอัปเดต
- หากบริการสำคัญเสียหาย ชื่อเสียงของบริษัทก็จะลดลง
จะทำอย่างไรกับบริการเด็กกำพร้า?
ฉันจะทำซ้ำสิ่งที่ต้องทำอีกครั้ง ก่อนอื่นต้องมีเอกสารประกอบ 7 ปีที่ Banki.ru สอนฉันว่าผู้ทดสอบไม่ควรยึดถือคำพูดของนักพัฒนา และฝ่ายปฏิบัติการไม่ควรยึดถือคำพูดของทุกคน เราจำเป็นต้องตรวจสอบ
ประการที่สอง จำเป็นต้องเขียนไดอะแกรมปฏิสัมพันธ์ เนื่องจากบริการที่ไม่ได้รับการตอบรับอย่างดีนั้นมีการขึ้นต่อกันที่ไม่มีใครพูดถึง ตัวอย่างเช่น นักพัฒนาได้ติดตั้งบริการบนคีย์ของตนใน Yandex.Maps หรือ Dadata บางส่วน คุณใช้ขีดจำกัดฟรีหมดแล้ว ทุกอย่างพัง และคุณไม่รู้ว่าเกิดอะไรขึ้น ต้องอธิบายคราดทั้งหมด: บริการใช้ Dadata, SMS หรืออย่างอื่น
ประการที่สาม การทำงานกับหนี้ทางเทคนิค เมื่อคุณใช้ไม้ค้ำยันหรือรับบริการและบอกว่าจำเป็นต้องทำบางอย่าง คุณต้องแน่ใจว่าสิ่งนั้นเสร็จสิ้นแล้ว เพราะงั้นอาจกลายเป็นว่ารูเล็กๆไม่เล็กจนจะหลุดผ่านไปได้
ด้วยงานสถาปัตยกรรม เรามีเรื่องราวเกี่ยวกับสฟิงซ์ หนึ่งในบริการที่ใช้สฟิงซ์เพื่อป้อนรายการ เป็นเพียงรายการแบ่งหน้า แต่จะมีการจัดทำดัชนีใหม่ทุกคืน มันถูกประกอบขึ้นจากดัชนีสองอัน: ดัชนีขนาดใหญ่หนึ่งอันจะถูกจัดทำดัชนีทุกคืน และยังมีดัชนีขนาดเล็กที่ถูกขันเข้ากับมันด้วย ทุกๆ วัน มีโอกาส 50% ที่จะเกิดระเบิดหรือไม่ก็ตาม ดัชนีจะพังระหว่างการคำนวณ และข่าวของเราก็หยุดอัปเดตบนหน้าหลัก ในตอนแรกใช้เวลา 5 นาทีในการจัดทำดัชนีใหม่ จากนั้นดัชนีก็ขยายตัว และเมื่อถึงจุดหนึ่ง ดัชนีก็เริ่มใช้เวลา 40 นาทีในการจัดทำดัชนีใหม่ เมื่อเราตัดสิ่งนี้ออก เราก็ถอนหายใจด้วยความโล่งอก เพราะเห็นได้ชัดว่าต้องใช้เวลาอีกสักหน่อยและดัชนีของเราก็จะถูกจัดทำดัชนีใหม่เต็มเวลา นี่จะเป็นความล้มเหลวสำหรับพอร์ทัลของเรา ไม่มีข่าวเป็นเวลาแปดชั่วโมง แค่นั้นแหละ ธุรกิจก็หยุดลง
แผนการทำงานกับสถานบริการเด็กกำพร้า
อันที่จริงนี่เป็นเรื่องยากมากที่จะทำ เพราะ Devops เป็นเรื่องเกี่ยวกับการสื่อสาร คุณต้องการสร้างความสัมพันธ์ที่ดีกับเพื่อนร่วมงาน และเมื่อคุณตีเพื่อนร่วมงานและผู้จัดการด้วยกฎระเบียบ พวกเขาอาจมีความรู้สึกขัดแย้งกับคนที่ทำเช่นนี้
นอกเหนือจากประเด็นทั้งหมดเหล่านี้ ยังมีสิ่งสำคัญอีกประการหนึ่ง: บุคคลเฉพาะจะต้องรับผิดชอบสำหรับแต่ละบริการเฉพาะ สำหรับแต่ละส่วนเฉพาะของขั้นตอนการปรับใช้ เมื่อไม่มีใครและคุณต้องดึงดูดคนอื่นมาศึกษาเรื่องนี้ทั้งหมดมันจะกลายเป็นเรื่องยาก
หากทั้งหมดนี้ไม่ได้ผล และบริการเด็กกำพร้าของคุณยังคงเป็นเด็กกำพร้า ไม่มีใครอยากรับไป ไม่มีการเขียนเอกสาร ทีมที่ถูกเรียกเข้าสู่บริการนี้ปฏิเสธที่จะทำอะไร มีวิธีง่ายๆ - ทำซ้ำ ทุกอย่าง
นั่นคือคุณรับข้อกำหนดสำหรับบริการอีกครั้งและเขียนบริการใหม่ ดีกว่า บนแพลตฟอร์มที่ดีกว่า โดยไม่ต้องมีโซลูชันทางเทคโนโลยีที่แปลกประหลาด และคุณย้ายไปอยู่ในการต่อสู้
เรามีสถานการณ์เมื่อเราใช้บริการบน Yii 1 และตระหนักว่าเราไม่สามารถพัฒนาต่อไปได้ เนื่องจากเรามีนักพัฒนาที่สามารถเขียนได้ดีบน Yii 1 ไม่เพียงพอ นักพัฒนาทุกคนเขียนได้ดีบน Symfony XNUMX จะทำอย่างไร? เราจัดสรรเวลา จัดสรรทีม จัดสรรผู้จัดการ เขียนโครงการใหม่ และสลับการรับส่งข้อมูลไปยังโครงการได้อย่างราบรื่น
หลังจากนี้จะสามารถลบบริการเก่าได้ นี่เป็นขั้นตอนโปรดของฉัน เมื่อคุณจำเป็นต้องรับและล้างบริการบางอย่างจากระบบการจัดการการกำหนดค่า จากนั้นดำเนินการและดูว่ารถยนต์ทั้งหมดในการผลิตถูกปิดใช้งาน เพื่อให้นักพัฒนาไม่เหลือร่องรอยใดๆ พื้นที่เก็บข้อมูลยังคงอยู่ใน Git
นี่คือทั้งหมดที่ฉันต้องการพูด ฉันพร้อมที่จะพูดคุย หัวข้อคือ holivar หลายคนว่ายอยู่ในนั้น
สไลด์บอกว่าคุณรวมภาษาเข้าด้วยกัน ตัวอย่างคือการปรับขนาดรูปภาพ จำเป็นหรือไม่ที่จะต้องจำกัดให้เป็นภาษาเดียวอย่างเคร่งครัด? เนื่องจากการปรับขนาดรูปภาพใน PHP สามารถทำได้จริงใน Golang
ในความเป็นจริง มันเป็นทางเลือก เช่นเดียวกับการปฏิบัติทั้งหมด บางทีในบางกรณีก็เป็นสิ่งที่ไม่พึงปรารถนาด้วยซ้ำ แต่คุณต้องเข้าใจว่าหากคุณมีแผนกเทคนิคในบริษัทที่มีจำนวน 50 คน 45 คนในนั้นเป็นผู้เชี่ยวชาญด้าน PHP อีก 3 คนเป็นผู้พัฒนาที่รู้จัก Python, Ansible, Puppet และอะไรทำนองนั้น และมีเพียงคนเดียวเท่านั้นที่เขียนในบางเรื่อง ประเภทของภาษา บริการปรับขนาดรูปภาพ Go บางส่วน จากนั้นเมื่อออกไปความเชี่ยวชาญก็จะไปด้วย และในขณะเดียวกัน คุณจะต้องมองหานักพัฒนาเฉพาะตลาดที่รู้ภาษานี้ โดยเฉพาะอย่างยิ่งหากเป็นภาษานี้หาได้ยาก นั่นคือจากมุมมองขององค์กร นี่เป็นปัญหา จากมุมมองของ Devops คุณจะไม่เพียงแต่ต้องโคลน Playbooks ชุดสำเร็จรูปที่คุณใช้ในการใช้บริการ แต่คุณจะต้องเขียนมันใหม่ทั้งหมดอีกครั้ง
ขณะนี้เรากำลังสร้างบริการบน Node.js และนี่จะเป็นเพียงแพลตฟอร์มใกล้เคียงสำหรับนักพัฒนาแต่ละคนที่มีภาษาแยกกัน แต่เรานั่งคิดว่าเกมนี้คุ้มค่ากับเทียน คือเป็นคำถามให้นั่งคิด
คุณจะตรวจสอบบริการของคุณอย่างไร? คุณจะรวบรวมและติดตามบันทึกอย่างไร?
เรารวบรวมบันทึกใน Elasticsearch และใส่ไว้ใน Kibana และมีการใช้ตัวรวบรวมที่แตกต่างกันไป ขึ้นอยู่กับว่าเป็นสภาพแวดล้อมการใช้งานจริงหรือการทดสอบ ที่ไหนสักแห่ง คนตัดไม้ ที่ไหนสักแห่ง อย่างอื่น ฉันจำไม่ได้ และยังมีบางสถานที่ในบริการบางอย่างที่เราติดตั้ง Telegraf และถ่ายทำที่อื่นแยกกัน
จะอยู่กับ Puppet และ Ansible ในสภาพแวดล้อมเดียวกันได้อย่างไร
ที่จริงแล้ว ตอนนี้เรามีสภาพแวดล้อมสองแบบ สภาพแวดล้อมหนึ่งคือ Puppet และอีกสภาพแวดล้อมหนึ่งคือ Ansible เรากำลังดำเนินการเพื่อผสมผสานพวกมันเข้าด้วยกัน Ansible เป็นเฟรมเวิร์กที่ดีสำหรับการตั้งค่าเริ่มต้น Puppet เป็นเฟรมเวิร์กที่ไม่ดีสำหรับการตั้งค่าเริ่มแรกเนื่องจากต้องใช้การทำงานจริงบนแพลตฟอร์มโดยตรง และ Puppet ช่วยให้มั่นใจว่าคอนฟิกูเรชันบรรจบกัน ซึ่งหมายความว่าแพลตฟอร์มจะรักษาตัวเองให้อยู่ในสถานะที่ทันสมัย และเพื่อให้เครื่อง Ansibilized ได้รับการปรับปรุงให้ทันสมัยอยู่เสมอ คุณจะต้องเรียกใช้ Playbooks บนเครื่องตลอดเวลาด้วยความถี่ระดับหนึ่ง นั่นคือความแตกต่าง
คุณจะรักษาความเข้ากันได้ได้อย่างไร? คุณมีการกำหนดค่าทั้ง Ansible และ Puppet หรือไม่
นี่คือความเจ็บปวดครั้งใหญ่ของเรา เรารักษาความเข้ากันได้กับมือของเรา และคิดว่าจะก้าวต่อไปจากเรื่องทั้งหมดนี้ได้อย่างไรในตอนนี้ ปรากฎว่า Puppet เปิดตัวแพ็คเกจและดูแลลิงก์บางส่วนที่นั่น และตัวอย่างเช่น Ansible เปิดตัวโค้ดและปรับการกำหนดค่าแอปพลิเคชันล่าสุดที่นั่น
การนำเสนอเป็นเรื่องเกี่ยวกับ Ruby เวอร์ชันต่างๆ ทางออกอะไร?
เราเจอสิ่งนี้ในที่เดียวและเราต้องเก็บมันไว้ในหัวตลอดเวลา เราเพียงแต่ปิดส่วนที่รันบน Ruby ซึ่งเข้ากันไม่ได้กับแอปพลิเคชัน และแยกส่วนนั้นไว้
การประชุมในปีนี้ จะมีขึ้นในวันที่ 7 ธันวาคมที่ Technopolis เราเปิดรับใบสมัครสำหรับรายงานจนถึงวันที่ 11 พฤศจิกายน เราถ้าคุณต้องการที่จะพูด
เปิดลงทะเบียนสำหรับผู้เข้าร่วมแล้ว เข้าร่วมกับเรา!
ที่มา: will.com