ฉันเพิ่งเข้าร่วม DevOpsForum 2019 ซึ่งจัดโดย Logrocon ในการประชุมครั้งนี้ ผู้เข้าร่วมพยายามค้นหาโซลูชันและเครื่องมือใหม่เพื่อการโต้ตอบที่มีประสิทธิภาพระหว่างผู้เชี่ยวชาญด้านธุรกิจและการพัฒนาและผู้เชี่ยวชาญด้านบริการเทคโนโลยีสารสนเทศ
การประชุมประสบความสำเร็จ: มีรายงานที่เป็นประโยชน์มากมาย รูปแบบการนำเสนอที่น่าสนใจ และการสื่อสารกับวิทยากรมากมาย และสิ่งสำคัญอย่างยิ่งคือไม่มีใครพยายามขายอะไรให้ฉันเลย ซึ่งเป็นสิ่งที่วิทยากรในการประชุมใหญ่มักทำผิดในช่วงนี้
ข้อความที่ตัดตอนมาจากสุนทรพจน์ของ Raiffeisenbank, Alfastrakhovanie ประสบการณ์ของ Mango Telecom ในการใช้ระบบอัตโนมัติและรายละเอียดอื่นๆ ที่อยู่ระหว่างการปรับปรุง
ฉันชื่อ Yana ฉันทำงานเป็นผู้ทดสอบ ฉันทำงานอัตโนมัติ เช่นเดียวกับ DevOps และฉันชอบไปประชุมและพบปะสังสรรค์ ในช่วงสองปีที่ผ่านมา ฉันเคยเข้าร่วมการประชุมของ Oleg Bunin (HighLoad++, TeamLead Conf), กิจกรรม Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow
ก่อนอื่น ฉันดึงความสนใจไปที่โปรแกรมการประชุมใหญ่ ฉันไม่ค่อยสนใจว่ารายงานจะเกี่ยวกับอะไร และสนใจผู้บรรยายมากกว่า แม้ว่ารายงานจะดูเป็นเทคโนโลยีและน่าสนใจมาก แต่ก็ไม่ใช่ความจริงที่ว่าคุณจะสามารถนำแนวทางปฏิบัติที่ดีที่สุดบางส่วนจากรายงานในบริษัทของคุณไปประยุกต์ใช้ แล้วคุณจะต้องมีลำโพง
แสงสว่างที่ปลายท่อที่ Raiffeisenbank
โดยปกติแล้ว ฉันจะตามหาวิทยากรข้างสนามที่ฉันสนใจ ที่ DevOpsForum 2019 วิทยากรจาก Raiffeisenbank, Mikhail Bizhan ดึงดูดความสนใจของฉัน ในระหว่างสุนทรพจน์ เขาได้พูดคุยเกี่ยวกับวิธีที่พวกเขาค่อยๆ ดึงดูดทีมให้ติด DevOps ทำไมพวกเขาถึงต้องการมัน และจะขายแนวคิดเรื่องการเปลี่ยนแปลง DevOps ให้กับธุรกิจได้อย่างไร โดยทั่วไปฉันพูดถึงวิธีดูแสงที่ปลายท่อ
มิคาอิล บิซฮาน ผู้อำนวยการฝ่ายระบบอัตโนมัติของ Raiffeisenbank
ตอนนี้พวกเขาไม่มี “DevOps” ในบริษัทของพวกเขา นั่นคือเขาทำงาน แต่ไม่ใช่กับทุกทีม เมื่อนำ DevOps ไปใช้ พวกเขาจะต้องอาศัยความพร้อมของทีม ทั้งในแง่ของวิศวกรเฉพาะด้าน และในแง่ของความต้องการของผลิตภัณฑ์ และความพร้อมของแพลตฟอร์มที่ใช้สร้างผลิตภัณฑ์นี้ Misha บอกวิธีอธิบายให้ธุรกิจทราบว่าเหตุใดจึงจำเป็นต้องมี DevOps
ส่วนงานธนาคารมีปัจจัยขับเคลื่อนการเติบโตหลายประการ ได้แก่ ต้นทุนการให้บริการและการขยายฐานลูกค้า การเพิ่มต้นทุนการบริการไม่ใช่ตัวขับเคลื่อนที่ดีนัก แต่การขยายฐานลูกค้ากลับตรงกันข้าม หากคู่แข่งเปิดตัวผลิตภัณฑ์ที่ยอดเยี่ยม ลูกค้าทุกคนจะไปที่นั่น จากนั้นระดับตลาดก็จะหมดไปเมื่อเวลาผ่านไป ดังนั้นการแนะนำผลิตภัณฑ์ใหม่ออกสู่ตลาดและความรวดเร็วในการเปิดตัวจึงเป็นสิ่งสำคัญที่ธนาคารให้ความสำคัญ นี่คือสิ่งที่ DevOps มีไว้เพื่อ และธุรกิจต่างๆ ก็เข้าใจสิ่งนี้
หมายเหตุสำคัญถัดไป: DevOps ไม่ได้ลดเวลาในการออกสู่ตลาดเสมอไป DevOps ไม่สามารถทำงานตามลำพังได้ มันเป็นเพียงส่วนหนึ่งของกระบวนการสร้างและนำผลิตภัณฑ์ออกสู่ตลาดตั้งแต่การพัฒนาไปจนถึงการผลิต (จากโค้ดสู่ลูกค้า) แต่ทุกสิ่งที่อยู่ข้างหน้าโค้ดไม่ได้เกี่ยวข้องโดยตรงกับ DevOps นั่นคือนักการตลาดสามารถศึกษาตลาดได้เป็นเวลาหลายปีและใช้เวลาทั้งชีวิตเพื่อไล่ตามคู่แข่ง จำเป็นต้องเข้าใจอย่างรวดเร็วว่าลูกค้าต้องการอะไรและวางแผนการใช้งานฟีเจอร์นี้หรือฟีเจอร์นั้น - บ่อยครั้งนี่เป็นสิ่งที่ไม่เพียงพอสำหรับ DevOps ในการทำงานและบริษัทจะบรรลุเป้าหมาย ดังนั้น ก่อนอื่น Raiffeisenbank จึงตกลงกับธุรกิจว่าจำเป็นต้องเรียนรู้วิธีใช้ DevOps ระบบอัตโนมัติเพื่อประโยชน์ของระบบอัตโนมัติจะไม่ช่วยอะไรมากนักในการต่อสู้เพื่อลูกค้าใหม่
โดยทั่วไปแล้ว Misha เชื่อว่า DevOps จำเป็นต้องได้รับการนำไปใช้อย่างชาญฉลาด และเราต้องเตรียมพร้อมสำหรับความจริงที่ว่าในช่วงเริ่มต้นของการเปลี่ยนแปลง ประสิทธิภาพการทำงานของทีมจะลดลง จะได้รับเงินน้อยลง แต่จากนั้นก็สมเหตุสมผล
การทดสอบอัตโนมัติที่ Mango Telecom
รายงานที่น่าสนใจอีกฉบับสำหรับฉันในฐานะผู้ทดสอบได้รับจาก Egor Maslov จาก Mango Telecom การนำเสนอนี้มีชื่อว่า "การทำงานอัตโนมัติของรอบการทดสอบทั้งหมดในทีม SCRUM" Egor เชื่อว่า DevOps ถูกสร้างขึ้นสำหรับ SCRUM โดยเฉพาะ แต่ในขณะเดียวกัน การแนะนำ DevOps เข้าสู่ทีม SCRUM นั้นค่อนข้างเป็นปัญหา สิ่งนี้เกิดขึ้นเนื่องจากทีม SCRUM ทำงานที่ไหนสักแห่งอยู่เสมอ ไม่มีเวลาที่จะเสียสมาธิไปกับนวัตกรรมและสร้างกระบวนการขึ้นมาใหม่ ปัญหายังอยู่ที่ข้อเท็จจริงที่ว่า SCRUM ไม่ได้เกี่ยวข้องกับการแยกทีมย่อยในทีม (ทีมทดสอบ ทีมพัฒนา และอื่นๆ) นอกจากนี้ เพื่อให้กระบวนการที่มีอยู่เป็นแบบอัตโนมัติ จำเป็นต้องมีเอกสารประกอบ และใน SCRUM ส่วนใหญ่มักจะไม่มีเอกสารประกอบที่สมบูรณ์ - "ผลิตภัณฑ์มีความสำคัญมากกว่าการเขียนบางประเภท"
หลังจากเปลี่ยนมาใช้ SCRUM ผู้ทดสอบก็เริ่มปรึกษากับนักพัฒนาเกี่ยวกับวิธีการทดสอบฟีเจอร์ต่างๆ ปริมาณของฟังก์ชันการทำงานเพิ่มขึ้นทีละน้อย ไม่มีเอกสารประกอบ และพวกเขาเริ่มตรวจพบจุดบกพร่องจำนวนมากในฟังก์ชันการทำงานที่ไม่ครอบคลุมในการทดสอบ และโดยทั่วไปแล้ว ไม่ชัดเจนว่าใครเป็นผู้ทดสอบและเมื่อใด สรุป - ความสับสนและความสั่นคลอน เราตัดสินใจเปลี่ยนไปใช้การทดสอบอัตโนมัติ แต่ถึงอย่างนั้นก็เกิดความล้มเหลวโดยสิ้นเชิง พวกเขาจ้างผู้เชี่ยวชาญด้านระบบอัตโนมัติจากภายนอกซึ่งเขียนลงบนกลุ่มผู้ทดสอบภายในองค์กรไม่รู้จัก แน่นอนว่ากรอบการทำงานสำหรับการทดสอบอัตโนมัติใช้งานได้ แต่หลังจากที่ผู้เอาต์ซอร์สออกไปแล้ว กรอบการทำงานก็จะคงอยู่เป็นเวลาสองสัปดาห์ ถัดไปคือความพยายามที่จะแนะนำการทดสอบอัตโนมัติหมายเลขสอง เริ่มต้นด้วยความจริงที่ว่าทุกสิ่งจำเป็นต้องสร้างขึ้นภายในบริษัท ด้วยตัวคุณเอง (เวกเตอร์ที่เหมาะสม: สร้างความเชี่ยวชาญภายใน) ภายในกรอบการทำงานของ SCRUM และสร้างเอกสารในกระบวนการ สแต็กสำหรับการทำงานอัตโนมัติควรเท่ากับสแต็กของผลิตภัณฑ์ (ฉันกำลังเพิ่มเข้าไป อย่าทดสอบโปรเจ็กต์ JavaScript ของคุณด้วยสิ่งอื่นใด) ในตอนท้ายของการวิ่ง พวกเขาสาธิตวิธีการทำงานของการทดสอบอัตโนมัติกับทั้งทีม (มีประโยชน์) ดังนั้นการมีส่วนร่วมของสมาชิกในทีมทุกคนในกระบวนการอัตโนมัติจึงเพิ่มขึ้น เช่นเดียวกับความไว้วางใจในการทดสอบอัตโนมัติและโอกาสที่การทดสอบอัตโนมัตินี้จะถูกนำมาใช้อย่างแน่นอน (และจะไม่ถูกแสดงความคิดเห็นในหนึ่งเดือนเนื่องจากความล้มเหลวอย่างต่อเนื่อง)
อย่างไรก็ตาม ที่ DevOpsForum 2019 มีไมโครโฟนแบบเปิด ซึ่งเป็นรูปแบบการพูดที่มีประโยชน์ซึ่งเป็นที่รู้จักมายาวนานและในความคิดของฉัน คุณเดินไปรอบๆ แบบนี้ ฟังรายงาน แล้วตัดสินใจว่าในการประชุม สมควรที่จะหารือหัวข้อหรือปัญหาบางอย่าง แบ่งปันประสบการณ์ที่เกี่ยวข้องในการแก้ปัญหา
ฉันยังสังเกตเห็นว่าผู้จัดงานได้จัดทำรายงานสั้นๆ มากมาย รายงานแต่ละฉบับมีความยาวไม่เกิน 10 นาที ตามด้วยคำถาม วิธีนี้ทำให้คุณสามารถครอบคลุมหลายหัวข้อพร้อมกันและถามคำถามกับวิทยากรที่คุณสนใจ
ระหว่างการนำเสนอ ฉันเดินไปรอบๆ บูธของผู้ร่วมการประชุมและขโมย/ชนะรางวัลมากมาย โอ้ ฉันชอบเอกสารแจก!
ปัญหาโต๊ะกลมและ DevOps กับผู้อำนวยการฝ่ายพัฒนาที่ Alfastrakhovanie
สิ่งที่สำคัญที่สุดสำหรับเค้ก DevOpsForum 2019 สำหรับฉันคือเซสชั่นเต็มอิ่มกับผู้เชี่ยวชาญ DevOps ที่ใช้เวลานานหนึ่งชั่วโมง ผู้เข้าร่วมเซสชั่นสี่คนได้รับเชิญให้ชม DevOps จากมุมที่แตกต่างกัน: Anton Isanin (Alfastrakhovanie ผู้อำนวยการฝ่ายพัฒนา), Nailya Zamashkina (Fintech Lab ผู้อำนวยการฝ่ายปฏิบัติการ), Oleg Egorkin (Rostelecom, โค้ช Agile) และ Anton Martyanov (ผู้เชี่ยวชาญอิสระ มองไปที่ DevOps จากมุมมองทางธุรกิจ)
ผู้เชี่ยวชาญนั่งลงใกล้กับผู้คนมากขึ้น จากนั้นสิ่งต่างๆ ก็เริ่มเกิดขึ้น ผู้เข้าร่วมจากผู้ชมถามคำถามเป็นเวลาหนึ่งชั่วโมงเต็ม และผู้เชี่ยวชาญก็แร็พ บางครั้งก็มีการถกเถียงกันจริงๆ คำถามมีความแตกต่างกันมาก เช่น วิศวกร DevOps จำเป็นหรือไม่ เหตุใดพวกเขาจึงไม่สามารถฝึกอบรมให้เป็นผู้ดูแลระบบได้ ควรเสนอ DevOps ให้กับทุกคน คุณค่าของมันคืออะไร และอื่นๆ
จากนั้นผมได้คุยกับแอนทอน อิศนินเป็นการส่วนตัว เราได้พูดคุยถึงความจำเป็นในการนำวัฒนธรรม DevOps มาสู่ทุกบ้าน และเปิดเผยด้านมืดของการเปลี่ยนแปลง DevOps
ลองจินตนาการว่าทุกคนมารวมตัวกันและตัดสินใจว่า DevOps จำเป็นทั้งจากผลิตภัณฑ์และโดยธุรกิจและทีมงาน ไปปฏิบัติกันเลย ทุกอย่างได้ผล เราหายใจออก DevOps ทำให้เราใกล้ชิดกับลูกค้ามากขึ้น และตอนนี้เราสามารถเติมเต็มความปรารถนาทั้งหมดของเขาได้อย่างรวดเร็ว ด้วยเหตุนี้ เราจึงมีแผนกปฏิบัติการขนาดใหญ่ที่มีกฎระเบียบและข้อกำหนดที่เข้มงวด และแผนกจะค้นหาข้อบกพร่องในผลิตภัณฑ์อยู่ตลอดเวลาและสร้างคำขอจำนวนมาก ยิ่งไปกว่านั้น ข้อบกพร่องทั้งหมดจะถูกกำหนดสถานะเป็น "เร่งด่วน" แม้ว่าลูกค้าต้องการเปลี่ยนสีปุ่มเป็นสีเหลืองแทนสีเขียวโดยไม่คาดคิดก็ตาม โปรเจ็กต์กำลังเติบโต จำนวนการเผยแพร่เพิ่มขึ้น และจำนวนข้อบกพร่องและความเข้าใจผิดเกี่ยวกับฟังก์ชันการทำงานใหม่ของลูกค้าก็เพิ่มขึ้นตามไปด้วย Ops จ้างพนักงานเพิ่มอีก 10 คนเพื่อติดตามการรายงานข้อบกพร่อง และฝ่ายพัฒนาจ้างพนักงานเพิ่มอีก 15 คนเพื่อติดตามการปิดข้อบกพร่องเหล่านั้น และแทนที่จะแนะนำคุณสมบัติใหม่ ทีมงานทำงานร่วมกับ SD อย่างไม่มีที่สิ้นสุด โดยอธิบายฟังก์ชันการทำงานให้กับผู้ใช้และฝ่ายสนับสนุนไปพร้อมๆ กัน เป็นผลให้ทั้ง Ops และการพัฒนาทำงานได้ดี แต่ลูกค้าและธุรกิจไม่พอใจ: คุณสมบัติใหม่ติดขัด ปรากฎว่าดูเหมือนว่า DevOps มีอยู่จริง แต่ดูเหมือนว่าจะไม่มีอยู่จริง
ในส่วนของความจำเป็นในการใช้งาน DevOps นั้น Anton ระบุอย่างชัดเจนว่าสิ่งนี้ขึ้นอยู่กับขนาดของธุรกิจโดยตรง หากการให้บริการลูกค้ารายหนึ่งต่อปีทำให้บริษัทมีรายได้ถึงพันล้าน DevOps ก็ไม่จำเป็น (โดยมีเงื่อนไขว่าคุณไม่จำเป็นต้องเปิดตัวการเปลี่ยนแปลงใหม่กับไคลเอนต์รายนี้เป็นประจำ) ทุกอย่างถูกปกคลุมไปด้วยช็อคโกแลต แต่หากธุรกิจเติบโตขึ้นและมีลูกค้ามากขึ้น คุณก็จำเป็นต้องปฏิบัติตาม ตามกฎแล้ว ในตอนแรกบริษัทไม่มี Ops เจ๋งๆ เลย ขั้นแรกเราตัดผลิตภัณฑ์ออก และจากนั้นจึงเข้าใจว่าเพื่อให้ผลิตภัณฑ์ทำงานได้ เราต้องจับตาดูเซิร์ฟเวอร์และตรวจสอบวัสดุสิ้นเปลือง นั่นคือตอนที่ Ops เกิดขึ้น ยังคงเป็นที่เข้าใจกันว่า Ops ซึ่งเป็นแผนกที่แยกจากกัน จะเริ่มสร้างอุปสรรคมากมายในการพัฒนา และการส่งมอบทั้งหมดจะเริ่มหยุดชะงัก นั่นคือในกรณีนี้ วัฒนธรรม DevOps มีความเกี่ยวข้องอยู่แล้ว แต่เราต้องไม่ลืมด้านมืดของมัน
ที่มา: will.com