จากเสาหินไปจนถึงไมโครเซอร์วิส: ประสบการณ์ของ M.Video-Eldorado และ MegaFon

เมื่อวันที่ 25 เมษายน พวกเราที่ Mail.ru Group ได้จัดการประชุมเกี่ยวกับคลาวด์และบริเวณโดยรอบ - เมลไปที่:CLOUD. ไฮไลท์บางส่วน:

• หลัก ผู้ให้บริการชาวรัสเซีย — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center และ Yandex.Cloud พูดถึงข้อมูลเฉพาะของตลาดคลาวด์ของเราและบริการของพวกเขา
• เพื่อนร่วมงานจาก Bitrix24 เล่าให้พวกเขาฟังว่าพวกเขาเป็นอย่างไร มาถึงมัลติคลาวด์แล้ว;
• Leroy Merlin, Otkritie, Burger King และ Schneider Electric ให้ข้อมูลที่น่าสนใจ มุมมองจากผู้บริโภคระบบคลาวด์ — งานอะไรที่ธุรกิจของพวกเขากำหนดไว้สำหรับไอทีและเทคโนโลยีใดบ้าง รวมถึงงานคลาวด์ พวกเขามองว่ามีแนวโน้มมากที่สุด

คุณสามารถรับชมวิดีโอทั้งหมดได้จากการประชุม mailto:CLOUD ลิงค์และคุณสามารถอ่านการสนทนาเกี่ยวกับไมโครเซอร์วิสได้ที่นี่ Alexander Deulin หัวหน้าศูนย์วิจัยและพัฒนาระบบธุรกิจ MegaFon และ Sergey Sergeev ผู้อำนวยการด้านเทคโนโลยีสารสนเทศของกลุ่ม M.Video-Eldorado เล่าถึงกรณีที่ประสบความสำเร็จในการกำจัดเสาหิน นอกจากนี้เรายังหารือเกี่ยวกับประเด็นที่เกี่ยวข้องกับกลยุทธ์ด้านไอที กระบวนการ และแม้แต่ทรัพยากรบุคคล

ผู้ร่วมอภิปราย

• เซอร์โกเย เซอร์โกเก,กลุ่มซีไอโอ "เอ็ม.วิดีโอ-เอลโดราโด";
• อเล็กซานเดอร์ เดอลินหัวหน้าศูนย์วิจัยและพัฒนาระบบธุรกิจ เมก้าฟอน;
• ผู้ดำเนินรายการ — มิทรี ลาซาเรนโก,หัวหน้าฝ่ายทิศทาง PaaS Mail.ru โซลูชั่นคลาวด์.

หลังจากสุนทรพจน์ของ Alexander Deulin “MegaFon ขยายธุรกิจผ่านแพลตฟอร์มไมโครเซอร์วิสอย่างไร” เขาเข้าร่วมเพื่อหารือโดย Sergey Sergeev จาก M.Video-Eldorado และผู้ดำเนินรายการสนทนา Dmitry Lazarenko จาก Mail.ru Cloud Solutions

ด้านล่างนี้เราได้เตรียมสำเนาการสนทนาไว้ให้คุณแล้ว แต่คุณยังสามารถชมวิดีโอได้:

การเปลี่ยนไปใช้ไมโครเซอร์วิสเป็นการตอบสนองต่อความต้องการของตลาด

มิทรี:

คุณเคยมีประสบการณ์ที่ประสบความสำเร็จในการโยกย้ายไปยังไมโครเซอร์วิสหรือไม่? โดยทั่วไปแล้ว คุณเห็นว่าประโยชน์ทางธุรกิจสูงสุดจากการใช้ไมโครเซอร์วิสหรือการเปลี่ยนจากบริการขนาดใหญ่ไปสู่ไมโครเซอร์วิสมีที่ใดบ้าง

เซอร์เกย์:

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

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

หนึ่งในบริการแรกๆ ที่มีภาระงานมากที่สุดคือบริการคำนวณราคา ทุกครั้งที่คุณมาที่ช่องทางใด ๆ ในกลุ่มบริษัท M.Video-Eldorado ไม่ว่าจะเป็นเว็บไซต์หรือร้านค้าปลีก เลือกผลิตภัณฑ์ที่นั่น ดูราคาบนเว็บไซต์ หรือใน "ตะกร้า" ต้นทุนจะถูกโดยอัตโนมัติ คำนวณโดยบริการเดียว เหตุใดจึงจำเป็น: ก่อนหน้านี้ แต่ละระบบมีหลักการของตัวเองในการทำงานกับโปรโมชัน - พร้อมส่วนลดและอื่นๆ Back office ของเราจัดการเรื่องราคา มีการนำฟังก์ชันส่วนลดไปใช้ในระบบอื่น สิ่งนี้จำเป็นต้องรวมศูนย์และบริการที่เป็นเอกลักษณ์และแยกออกจากกันซึ่งสร้างขึ้นในรูปแบบของกระบวนการทางธุรกิจที่จะช่วยให้เราดำเนินการนี้ได้ นั่นเป็นวิธีที่เราเริ่มต้นมาก

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

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

วิธีวัดความสำเร็จของการโยกย้ายไปยังไมโครเซอร์วิส

มิทรี:

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

เซอร์เกย์:

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

อเล็กซานเดอร์:

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

เซอร์เกย์:

ใช่ฉันเห็นด้วย. ในสามปี เรามีบริการและงานที่ค้างอยู่มากกว่าสองร้อยรายการแล้ว ความต้องการทรัพยากรภายในทีมเพิ่มขึ้นเพียง 30% ต่อปี สิ่งนี้เกิดขึ้นเพราะผู้คนรู้สึกว่า มันเร็วขึ้น แตกต่าง มีเทคโนโลยีที่แตกต่างกัน ทั้งหมดนี้กำลังพัฒนา

ไมโครเซอร์วิสจะมา แต่แกนกลางจะยังคงอยู่

มิทรี:

มันเหมือนกับกระบวนการที่ไม่มีที่สิ้นสุดที่คุณลงทุนในการพัฒนา การเปลี่ยนผ่านสู่ไมโครเซอร์วิสสำหรับธุรกิจสิ้นสุดลงแล้วหรือไม่?

เซอร์เกย์:

มันง่ายมากที่จะตอบ คุณคิดอย่างไร: การเปลี่ยนโทรศัพท์เป็นกระบวนการที่ไม่มีที่สิ้นสุด เราเองก็ซื้อโทรศัพท์ทุกปี และนี่คือ: ตราบใดที่ยังมีความต้องการความเร็ว เพื่อปรับตัวให้เข้ากับตลาด การเปลี่ยนแปลงบางอย่างก็จำเป็นต้องมี นี่ไม่ได้หมายความว่าเราละทิ้งสิ่งมาตรฐาน

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

มิทรี:

ชีวิตอยู่ในสภาพที่ดี (หัวเราะ)

อเล็กซานเดอร์:

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

แต่เราวางแผนที่จะรักษาส่วนหลักไว้ เนื่องจากในแนวนอนของผู้ดำเนินการจะมีแพลตฟอร์มบางอย่างที่เราซื้ออยู่เสมอ ขอย้ำอีกครั้งว่าเราต้องการความสมดุลที่ดี: เราไม่ควรรีบเร่งที่จะตัดแกนกลางออก เราวางระบบไว้เคียงข้างกัน และตอนนี้ปรากฎว่าเราอยู่เหนือส่วนหลักหลายส่วนแล้ว นอกจากนี้ ในการพัฒนาฟังก์ชันการทำงาน เรายังสร้างการนำเสนอที่จำเป็นสำหรับทุกช่องทางที่ทำงานร่วมกับบริการสื่อสารของเรา

วิธีขายไมโครเซอร์วิสให้กับธุรกิจ

มิทรี:

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

เซอร์เกย์:

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

มิทรี:

คุณได้บันทึกเวลาของด่านแรกหรือไม่?

เซอร์เกย์:

แน่นอน. เราจัดสรรเวลา 6 เดือนเพื่อสร้างแกนหลักเป็นแพลตฟอร์มและทดสอบโปรแกรมนำร่อง ในระหว่างนี้ เราได้พยายามสร้างแพลตฟอร์มสำหรับเล่นสเก็ตนักบิน จากนั้นสมมติฐานก็ได้รับการยืนยัน และเมื่อได้ผล ก็หมายความว่าเราสามารถดำเนินการต่อไปได้ พวกเขาเริ่มทำซ้ำและเสริมความแข็งแกร่งให้กับทีม - พวกเขาย้ายมันไปยังดิวิชั่นแยกต่างหากที่ทำแบบนั้น

ถัดมาคือการทำงานอย่างเป็นระบบโดยคำนึงถึงความต้องการทางธุรกิจ โอกาส ความพร้อมของทรัพยากรและทุกสิ่งที่อยู่ในงานในปัจจุบัน

มิทรี:

ตกลง. อเล็กซานเดอร์ คุณพูดอะไร?

อเล็กซานเดอร์:

ไมโครเซอร์วิสของเราเกิดจาก "โฟมแห่งท้องทะเล" - เนื่องจากการประหยัดทรัพยากร เนื่องจากการเหลือบางส่วนในรูปแบบของความจุของเซิร์ฟเวอร์และการกระจายกำลังภายในทีม ในตอนแรกเราไม่ได้ขายโครงการนี้ให้กับธุรกิจ นี่เป็นโครงการที่เราทั้งวิจัยและพัฒนาตามนั้น เราเริ่มต้นเมื่อต้นปี 2018 และพัฒนาทิศทางนี้ด้วยความกระตือรือร้น การขายเพิ่งเริ่มต้นและเรากำลังดำเนินการอยู่

มิทรี:

เป็นไปได้ไหมที่ธุรกิจอนุญาตให้คุณทำสิ่งต่างๆ เช่น Google ได้ฟรีหนึ่งวันต่อสัปดาห์ คุณมีแนวทางดังกล่าวหรือไม่?

อเล็กซานเดอร์:

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

และผลกระทบที่สำคัญนั้นชัดเจนอยู่แล้ว - เราสามารถนับได้แล้ว ความเร็วของการเปิดตัวผลิตภัณฑ์และการสูญเสียรายได้สามารถประมาณได้หากเราเดินตามเส้นทางเก่า นี่คือสิ่งที่เรากำลังสร้างเคสนี้

ไมโครเซอร์วิส: กระแสเกินจริงหรือความจำเป็น?

มิทรี:

ตัวเลขก็คือตัวเลข และรายได้หรือเงินที่ประหยัดเป็นสิ่งสำคัญมาก แล้วถ้ามองอีกด้านล่ะ? ดูเหมือนว่าไมโครเซอร์วิสกำลังเป็นเทรนด์ กระแสเกินจริง และหลายบริษัทกำลังใช้มันในทางที่ผิด? คุณแยกแยะความแตกต่างระหว่างสิ่งที่คุณทำกับไม่ได้แปลเป็นไมโครเซอร์วิสได้ชัดเจนเพียงใด ถ้ามรดกตอนนี้อีก 5 ปี คุณจะยังมีมรดกไหม? ระบบสารสนเทศที่ทำงานที่ M.Video-Eldorado และ MegaFon มีอายุเท่าใดใน 5 ปี? จะมีระบบสารสนเทศสิบปี,สิบห้าปีหรือจะเป็นยุคใหม่? คุณเห็นสิ่งนี้ได้อย่างไร?

เซอร์เกย์:

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

บริษัทของเรามีอายุรวมกัน 25 ปี โดยมี ERP แบบคลาสสิกที่ลึกซึ้งมากในด้านระบบ เห็นได้ชัดว่าเรากำลังนำบางส่วนออกจากที่นั่นและพยายามรวมเข้ากับไมโครเซอร์วิส แต่แกนกลางจะยังคงอยู่ ตอนนี้มันยากสำหรับฉันที่จะจินตนาการว่าเราจะแทนที่ระบบหลักทั้งหมดที่นั่น และย้ายไปยังอีกด้านที่สดใสของระบบใหม่อย่างรวดเร็ว

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

เราเห็นการพัฒนานี้:

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

แต่ในขณะเดียวกันฉันก็เป็นผู้สนับสนุนให้ใช้หลักการเก่าต่อไปหากใช้อย่างเหมาะสม

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

แต่เมื่อมี 5 โมดูลในแบ็คออฟฟิศ ซึ่งชิ้นส่วนของข้อมูลจะถูกรวบรวมเข้าสู่กระบวนการทางธุรกิจ ซึ่งจากนั้นจะถูกนำไปใช้โดยระบบแนวหน้า 8-10 แห่ง ผลประโยชน์จะเห็นได้ทันที คุณนำระบบ back-office ห้าระบบมาสร้างบริการแบบแยกเดี่ยวที่เน้นไปที่กระบวนการทางธุรกิจ ทำให้บริการมีความก้าวหน้าทางเทคโนโลยี - เพื่อที่จะแคชข้อมูลและทนทานต่อข้อผิดพลาด และยังทำงานร่วมกับเอกสารหรือองค์กรธุรกิจอีกด้วย และคุณบูรณาการตามหลักการเดียวกับผลิตภัณฑ์แนวหน้าทั้งหมด พวกเขายกเลิกผลิตภัณฑ์ส่วนหน้า - พวกเขาเพียงแค่ปิดการผสานรวม พรุ่งนี้คุณต้องเขียนแอปพลิเคชันบนมือถือหรือสร้างเว็บไซต์ขนาดเล็กและใส่เพียงส่วนเดียวในการทำงาน - ทุกอย่างเรียบง่าย: คุณประกอบมันขึ้นมาเหมือนตัวสร้าง ฉันเห็นการพัฒนามากขึ้นในทิศทางนี้ - อย่างน้อยก็ในประเทศของเรา

อเล็กซานเดอร์:

Sergey อธิบายแนวทางของเราไว้อย่างสมบูรณ์ ขอขอบคุณ ฉันจะบอกว่าเราจะไม่ไปที่ไหนอย่างแน่นอน - ไปยังส่วนหลักในหัวข้อการเรียกเก็บเงินออนไลน์ นั่นคือการให้คะแนนและการชาร์จจะยังคงเป็นเครื่องนวด "ใหญ่" ที่จะตัดเงินได้อย่างน่าเชื่อถือ และระบบนี้จะยังคงได้รับการรับรองจากหน่วยงานกำกับดูแลของเราต่อไป แน่นอนว่าทุกสิ่งทุกอย่างที่มุ่งเป้าไปที่ลูกค้าคือไมโครเซอร์วิส

มิทรี:

การรับรองที่นี่เป็นเรื่องหนึ่ง น่าจะสนับสนุนมากกว่า.. หากคุณใช้จ่ายเพียงเล็กน้อยในการสนับสนุนหรือระบบไม่ต้องการการสนับสนุนและการปรับเปลี่ยนจะเป็นการดีกว่าที่จะไม่แตะต้องมัน การประนีประนอมที่สมเหตุสมผล

วิธีการพัฒนาไมโครเซอร์วิสที่เชื่อถือได้

มิทรี:

ดี. แต่ฉันยังคงสนใจ ตอนนี้คุณกำลังบอกเล่าเรื่องราวความสำเร็จ: ทุกอย่างเรียบร้อยดี เราเปลี่ยนมาใช้ไมโครเซอร์วิส ปกป้องแนวคิดนี้ต่อธุรกิจ และทุกอย่างก็ดำเนินไปด้วยดี แต่ฉันเคยได้ยินเรื่องอื่นมาบ้าง

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

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

อเล็กซานเดอร์:

ตัวอย่างที่ไม่ประสบความสำเร็จ ได้แก่ ธุรกิจที่เปลี่ยนลำดับความสำคัญและการยกเลิกโครงการ เมื่ออยู่ในขั้นตอนความพร้อมที่ดี (อันที่จริง MVP พร้อมแล้ว) ธุรกิจกล่าวว่า: "เรามีลำดับความสำคัญใหม่ เรากำลังย้ายไปยังโครงการอื่น และเรากำลังปิดโครงการนี้"

เราไม่มีความล้มเหลวระดับโลกกับไมโครเซอร์วิส เรานอนหลับอย่างสงบ เรามีกะทำงานตลอด 24 ชั่วโมงทุกวันที่ให้บริการ BSS [ระบบสนับสนุนธุรกิจ]

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

สมมติว่าเราปรับใช้บริการไร้สัญชาติของเรา - เรามีบริการเหล่านั้นใน Kubernetes ช่วยให้ทุกคนนอนหลับได้อย่างสงบสุขเนื่องจากการปรับขนาดอัตโนมัติและการเพิ่มบริการอัตโนมัติ และการเปลี่ยนหน้าที่จะหยิบยกเหตุการณ์ต่างๆ ขึ้นมา

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

ไมโครเซอร์วิสและทรัพยากรบุคคล

เซอร์เกย์:

ฉันเห็นด้วยกับเพื่อนร่วมงานเกี่ยวกับการโอนไปสนับสนุน - ว่างานจะต้องมีการจัดระเบียบอย่างถูกต้อง แต่ฉันจะบอกคุณเกี่ยวกับปัญหาที่มีอยู่แน่นอน

ประการแรกเทคโนโลยีเป็นสิ่งใหม่ นี่เป็นการฮือฮาในทางที่ดีและการค้นหาผู้เชี่ยวชาญที่จะเข้าใจและสามารถสร้างสิ่งนี้ได้ถือเป็นความท้าทายที่ยิ่งใหญ่ การแข่งขันแย่งชิงทรัพยากรเป็นไปอย่างดุเดือด ดังนั้นผู้เชี่ยวชาญจึงมีค่าดั่งทองคำ

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

ปัญหาอีกประการหนึ่ง - แม้ว่าจะดีในแบบของตัวเอง - ก็คือการแข่งขันภายใน “โอ้ หนุ่มทันสมัยคนใหม่ปรากฏตัวที่นี่ พวกเขาพูดภาษาใหม่” แน่นอนว่าผู้คนมีความแตกต่างกัน มีผู้ที่เคยชินกับการเขียนด้วย Java และผู้ที่เขียนและใช้ Docker และ Kubernetes คนเหล่านี้ต่างกันโดยสิ้นเชิง พูดต่างกัน ใช้คำต่างกัน และบางครั้งก็ไม่เข้าใจกัน ความสามารถหรือไม่สามารถแบ่งปันการปฏิบัติแบ่งปันความรู้ในแง่นี้ก็เป็นปัญหาเช่นกัน

ปรับขนาดทรัพยากร “เยี่ยมมาก ไปกันเลย! และตอนนี้เราต้องการเร็วขึ้นและมากขึ้น อะไรคุณไม่สามารถ? เป็นไปได้ไหมที่จะส่งมอบได้มากเป็นสองเท่าในหนึ่งปี? และทำไม?" ความเจ็บปวดที่เพิ่มขึ้นเช่นนี้อาจเป็นมาตรฐานสำหรับหลายสิ่ง หลายแนวทาง และคุณสามารถสัมผัสได้

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

มิทรี:

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

เซอร์เกย์:

ใช่อย่างแน่นอน

อเล็กซานเดอร์:

HR ถามคำถาม: “ยูนิคอร์นสีชมพูของคุณอยู่ที่ไหนระหว่าง backend และ frontend?” ฝ่ายทรัพยากรบุคคลไม่เข้าใจว่าไมโครเซอร์วิสคืออะไร เราบอกความลับแก่พวกเขาและบอกพวกเขาว่าแบ็กเอนด์ทำทุกอย่าง และไม่มียูนิคอร์น แต่ฝ่ายทรัพยากรบุคคลกำลังเปลี่ยนแปลง เรียนรู้อย่างรวดเร็ว และรับสมัครผู้ที่มีความรู้ด้านไอทีขั้นพื้นฐาน

วิวัฒนาการของไมโครเซอร์วิส

มิทรี:

หากคุณดูที่สถาปัตยกรรมเป้าหมาย ไมโครเซอร์วิสจะดูเหมือนสัตว์ประหลาด การเดินทางของคุณใช้เวลาหลายปี บางคนมีหนึ่งปี บางคนสามปี คุณมองเห็นปัญหาทั้งหมด, สถาปัตยกรรมเป้าหมาย, มีอะไรเปลี่ยนแปลงบ้างไหม? ตัวอย่างเช่น ในกรณีของไมโครเซอร์วิส เกตเวย์และโครงข่ายบริการจะปรากฏขึ้นอีกครั้ง คุณใช้มันในตอนแรกหรือคุณเปลี่ยนสถาปัตยกรรมเอง? คุณมีความท้าทายเช่นนี้หรือไม่?

เซอร์เกย์:

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

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

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

นี่คือวิวัฒนาการ - เช่นเดียวกับโทรศัพท์ เพียงแต่เร็วกว่ามาก ครั้งแรกมีโทรศัพท์แบบปุ่มกด จากนั้นสมาร์ทโฟนก็ปรากฏขึ้น พวกเขาเขียนและออกแบบผลิตภัณฑ์ใหม่เนื่องจากตลาดมีความต้องการที่แตกต่างกัน นี่คือวิธีที่เราพัฒนา: ชั้นประถมศึกษาปีที่ XNUMX, ชั้นประถมศึกษาปีที่ XNUMX, งาน

ในแต่ละปีมีการวางบางสิ่งบางอย่างซ้ำๆ จากมุมมองของเทคโนโลยี อย่างอื่นจากมุมมองของงานที่ค้างอยู่และความต้องการ เราเชื่อมโยงสิ่งหนึ่งกับอีกสิ่งหนึ่ง ทีมใช้จ่าย 20% สำหรับหนี้ทางเทคนิคและการสนับสนุนทางเทคนิคสำหรับทีม 80% สำหรับองค์กรธุรกิจ และเราดำเนินการด้วยความเข้าใจว่าเหตุใดเราจึงทำเช่นนี้ เหตุใดเราจึงปรับปรุงเทคโนโลยีเหล่านี้ และจะนำไปสู่อะไร เช่นนั้น.

มิทรี:

เย็น. มีอะไรอยู่ใน MegaFon?

อเล็กซานเดอร์:

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

คำถามต่อไปคือ “แล้วจะใช้ประโยชน์จากทั้งหมดนี้ได้อย่างไร?” และอีกอย่างหนึ่ง: “จะมั่นใจได้อย่างไรว่าการโต้ตอบที่โปร่งใสระหว่างไมโครเซอร์วิส” Service Mesh ช่วยให้เราตอบคำถามสุดท้ายได้ เราทดลองใช้ Istio และชอบผลลัพธ์ ตอนนี้เราอยู่ในขั้นตอนของการเปิดตัวเข้าสู่โซนการผลิต เรามีทัศนคติเชิงบวกต่อความท้าทายทั้งหมด ความจริงที่ว่าเราจำเป็นต้องเปลี่ยนแปลงอย่างต่อเนื่อง เรียนรู้สิ่งใหม่ ๆ เราสนใจที่จะพัฒนาโดยไม่ใช้ประโยชน์จากโซลูชันเก่า

มิทรี:

คำว่าทอง! ความท้าทายดังกล่าวทำให้ทีมและธุรกิจเตรียมพร้อมและสร้างอนาคต GDPR สร้างหัวหน้าเจ้าหน้าที่ปกป้องข้อมูล และความท้าทายในปัจจุบันทำให้เกิดหัวหน้าไมโครเซอร์วิสและเจ้าหน้าที่สถาปัตยกรรม และมันก็พอใจ

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

ขอบคุณผู้เข้าร่วมทุกคน ขอบคุณ Sergei และ Alexander!

คำถามจากผู้ฟัง

คำถามจากผู้ฟัง (1):

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

เซอร์เกย์:

ฉันเห็นด้วยกับเพื่อนร่วมงานว่าสถาปัตยกรรมมีความสำคัญมากในการขับเคลื่อนการเปลี่ยนแปลง เราเริ่มต้นด้วยการมีแผนกสถาปัตยกรรม สถาปนิกเป็นเจ้าของการกระจายฟังก์ชันการทำงานและข้อกำหนดว่าจะปรากฏในแนวนอนไปพร้อมๆ กัน ดังนั้นพวกเขาจึงทำหน้าที่เป็นผู้ประสานงานการเปลี่ยนแปลงเหล่านี้ด้วย เป็นผลให้มีการเปลี่ยนแปลงกระบวนการจัดส่งเฉพาะเมื่อเราสร้างแพลตฟอร์ม CI/CD

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

ในทางที่ดี การฉีดวัคซีนแสดงให้เห็นว่า คุณสามารถทำได้ด้วยวิธีนี้ แต่คุณสามารถทำได้ด้วยวิธีอื่น แน่นอนว่ามีปัญหาในด้านบุคลากร ความสามารถ ความรู้ และการต่อต้าน

คำถามจากผู้ฟัง (2):

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

อเล็กซานเดอร์:

การย้ายจากไมโครเซอร์วิสไปยังแพลตฟอร์มอาจเป็นเรื่องยาก แต่ก็สามารถแก้ไขได้

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

และปัญหาของเราอยู่ที่ทีมเล็กเท่านั้น วิศวกรควบคุมคุณภาพหนึ่งคนจำเป็นสำหรับผลิตภัณฑ์ที่มีเงื่อนไขหนึ่งรายการ ดังนั้นเราจึงจัดส่งผลิตภัณฑ์ไมโครเซอร์วิส 5-7 รายการ ซึ่งบุคคลที่สามสามารถพัฒนาได้ 2-3 รายการ ตัวอย่างเช่น เรามีผลิตภัณฑ์ที่อยู่ในการพัฒนาซึ่งผู้จำหน่ายระบบการเรียกเก็บเงินของเรา Mail.ru Group และ MegaFon R&D เข้าร่วม เราจำเป็นต้องครอบคลุมเรื่องนี้ด้วยการทดสอบก่อนที่จะส่งไปยังการผลิต วิศวกร QA ทำงานเกี่ยวกับผลิตภัณฑ์นี้มาเป็นเวลาหนึ่งเดือนครึ่งแล้ว และส่วนที่เหลือในทีมก็ไม่ได้รับการสนับสนุนจากเขา

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

เซอร์เกย์:

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

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

บางครั้งเราไม่ได้ทำการทดสอบแบบ end-to-end โดยตั้งใจ เพราะเราไม่ต้องการหยุดการพัฒนา แม้ว่าเราจะมีบางอย่างหลังจากนั้นก็ตาม ภูมิประเทศมีขนาดใหญ่มาก ซับซ้อน มีหลายระบบ บางครั้งมันก็แค่ Stubs ใช่แล้ว คุณลดขอบเขตความปลอดภัยลง ความเสี่ยงก็เพิ่มมากขึ้น แต่ในขณะเดียวกันคุณก็ปล่อยอุปทาน

อเล็กซานเดอร์:

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

คำถามจากผู้ฟัง (3):

เท่าที่ฉันเข้าใจ ไมโครเซอร์วิสเริ่มแรกเติบโตจากทีมที่แยกจากกัน และตอนนี้ก็มีอยู่ในโมเดลนี้แล้ว ข้อดีและข้อเสียของมันคืออะไร?

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

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

อเล็กซานเดอร์:

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

เซอร์เกย์:

ฉันจะบอกเส้นทางที่เราเดินไป เราเริ่มทำงานเป็นทีมเดียวจริงๆ แต่ตอนนี้เราไม่ได้อยู่คนเดียวแล้ว ฉันเป็นผู้เสนอสิ่งต่อไปนี้: จะต้องมีเจ้าของกระบวนการ มีคนจำเป็นต้องเข้าใจ จัดการ ควบคุม และสร้างกระบวนการพัฒนาไมโครเซอร์วิส เขาต้องเป็นเจ้าของทรัพยากรและมีส่วนร่วมในการจัดการทรัพยากร

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

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

อเล็กซานเดอร์:

Sergey คุณเป็นเจ้าของกระบวนการจริงๆ ใช่ไหม? มีการแบ่งปันงานที่ค้างอยู่หรือไม่ ใครเป็นผู้รับผิดชอบในการจัดจำหน่าย?

เซอร์เกย์:

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

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

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

จบการสนทนาแต่ไม่ทั้งหมด

ได้จัดการประชุม mailto:CLOUD Mail.ru โซลูชั่นคลาวด์.

เรายังจัดกิจกรรมอื่นๆ เช่น @Kubernetes มีตติ้งที่เรามองหาวิทยากรดีๆ อยู่เสมอ:

• ติดตาม @Kubernetes และข่าวสาร @Meetup อื่นๆ ในช่อง Telegram ของเรา t.me/k8s_mail
• สนใจที่จะพูดที่หนึ่งใน @Meetups หรือไม่? ฝากไว้เพื่อขอ mcs.mail.ru/speak

ที่มา: will.com