แน่นอนว่าเรากำลังพูดถึงเกี่ยวกับ - หากคุณไม่ลงรายละเอียด ในวันที่ 30 กันยายนและ 1 ตุลาคม เราจะจัดการประชุมเกี่ยวกับการรวมกระบวนการพัฒนา การทดสอบ และการดำเนินการ และหากคุณลงรายละเอียด โปรดไปที่หัวข้อ cat
ภายในแนวทาง DevOps ทุกส่วนของการพัฒนาเทคโนโลยีของโครงการจะเชื่อมโยงกัน เกิดขึ้นแบบคู่ขนาน และมีอิทธิพลซึ่งกันและกัน สิ่งที่สำคัญที่สุดคือการสร้างกระบวนการพัฒนาแบบอัตโนมัติที่สามารถเปลี่ยนแปลง จำลอง และทดสอบได้แบบเรียลไทม์ สิ่งนี้ช่วยให้คุณตอบสนองต่อการเปลี่ยนแปลงในตลาดได้ทันที
ในการประชุม เราต้องการแสดงให้เห็นว่าแนวทางนี้มีอิทธิพลต่อการพัฒนาผลิตภัณฑ์อย่างไร วิธีการรับประกันความน่าเชื่อถือและความสามารถในการปรับตัวของระบบสำหรับลูกค้า DevOps เปลี่ยนโครงสร้างและแนวทางของบริษัทในการจัดกระบวนการทำงานอย่างไร
เบื้องหลัง
เป็นสิ่งสำคัญสำหรับเราที่จะไม่เพียงแต่รู้ว่าบริษัทต่างๆ กำลังทำอะไรภายใต้กรอบแนวทางของ DevOps แต่ยังต้องเข้าใจว่าเหตุใดจึงทำทั้งหมดนี้ ดังนั้นเราจึงเชิญไม่เพียงแต่ผู้เชี่ยวชาญให้เข้าร่วมคณะกรรมการโครงการ แต่ยังเชิญผู้เชี่ยวชาญที่เห็นวาทกรรม DevOps จากตำแหน่งต่างๆ:
- วิศวกรอาวุโส
- นักพัฒนา;
- หัวหน้าทีม;
- ซีทีโอ
ในด้านหนึ่ง สิ่งนี้จะสร้างปัญหาและข้อขัดแย้งเมื่อหารือเกี่ยวกับคำขอรายงาน หากวิศวกรสนใจที่จะวิเคราะห์อุบัติเหตุร้ายแรง นักพัฒนาจะต้องเข้าใจวิธีสร้างซอฟต์แวร์ที่ทำงานในระบบคลาวด์และโครงสร้างพื้นฐานเป็นสิ่งสำคัญมากกว่า แต่ด้วยการตกลง เราจะสร้างโปรแกรมที่จะมีคุณค่าและน่าสนใจสำหรับทุกคน ตั้งแต่วิศวกรไปจนถึง CTO
เป้าหมายของการประชุมของเราไม่ใช่แค่การเลือกรายงานที่กระแสฮือฮามากที่สุดเท่านั้น แต่ยังเพื่อนำเสนอภาพรวม: วิธีการทำงานของแนวทาง DevOps ในทางปฏิบัติ ประเภทของคราดที่คุณอาจพบเจอเมื่อย้ายไปยังกระบวนการใหม่ ในเวลาเดียวกัน เราสร้างส่วนเนื้อหา โดยเริ่มจากปัญหาทางธุรกิจไปจนถึงเทคโนโลยีเฉพาะ
ส่วนการประชุมจะยังคงเหมือนเดิมเช่นใน .
- แพลตฟอร์มโครงสร้างพื้นฐาน
- โครงสร้างพื้นฐานเป็นรหัส
- จัดส่งอย่างต่อเนื่อง.
- ข้อเสนอแนะ.
- สถาปัตยกรรมใน DevOps, DevOps สำหรับ CTO
- แนวทางปฏิบัติของ SRE
- การฝึกอบรมและการจัดการความรู้
- ความปลอดภัย DevSecOps
- การเปลี่ยนแปลง DevOps
Call for Papers: เรากำลังมองหารายงานประเภทใด
เราแบ่งเงื่อนไขผู้มีโอกาสเป็นผู้ชมการประชุมออกเป็นห้ากลุ่ม ได้แก่ วิศวกร นักพัฒนา ผู้เชี่ยวชาญด้านความปลอดภัย หัวหน้าทีม และ CTO แต่ละกลุ่มมีแรงจูงใจในการมาประชุมของตนเอง และหากคุณดู DevOps จากตำแหน่งเหล่านี้ คุณจะเข้าใจวิธีเน้นหัวข้อและจุดเน้นได้
สำหรับวิศวกร ที่กำลังสร้างแพลตฟอร์มโครงสร้างพื้นฐาน สิ่งสำคัญคือต้องเข้าใจแนวโน้มที่มีอยู่ เพื่อทำความเข้าใจว่าเทคโนโลยีใดที่ทันสมัยที่สุดในปัจจุบัน พวกเขาจะสนใจเรียนรู้ประสบการณ์จริงในการใช้เทคโนโลยีเหล่านี้และแลกเปลี่ยนความคิดเห็น วิศวกรยินดีรับฟังรายงานที่วิเคราะห์อุบัติเหตุร้ายแรง และในทางกลับกัน เราก็จะพยายามเลือกและขัดเกลารายงานดังกล่าว
สำหรับนักพัฒนา สิ่งสำคัญคือต้องเข้าใจแนวคิดดังกล่าว แอปพลิเคชันเนทิฟคลาวด์- นั่นคือวิธีการพัฒนาซอฟต์แวร์เพื่อให้ทำงานบนคลาวด์และโครงสร้างพื้นฐานต่างๆ นักพัฒนาซอฟต์แวร์จำเป็นต้องได้รับการตอบรับจากซอฟต์แวร์อย่างต่อเนื่อง ที่นี่ เราต้องการทราบกรณีต่างๆ เกี่ยวกับวิธีที่บริษัทต่างๆ สร้างกระบวนการนี้ วิธีตรวจสอบประสิทธิภาพของซอฟต์แวร์ และวิธีการทำงานของกระบวนการจัดส่งทั้งหมด
ผู้เชี่ยวชาญด้านความปลอดภัยทางไซเบอร์ สิ่งสำคัญคือต้องเข้าใจวิธีการตั้งค่ากระบวนการรักษาความปลอดภัย เพื่อไม่ให้กระบวนการพัฒนาและเปลี่ยนแปลงภายในบริษัทหยุดชะงัก หัวข้อเกี่ยวกับข้อกำหนดที่ DevOps กำหนดไว้สำหรับผู้เชี่ยวชาญดังกล่าวก็น่าสนใจเช่นกัน
หัวหน้าทีมต้องการทราบ, กระบวนการจัดส่งอย่างต่อเนื่องของบริษัทอื่นทำงานอย่างไร บริษัทต่างๆ ใช้เส้นทางใดเพื่อบรรลุเป้าหมายนี้ พวกเขาสร้างกระบวนการพัฒนาและประกันคุณภาพภายใน DevOps ได้อย่างไร หัวหน้าทีมก็สนใจ Cloud Native เช่นกัน และยังมีคำถามเกี่ยวกับการมีปฏิสัมพันธ์ภายในทีมและระหว่างทีมพัฒนาและทีมวิศวกรอีกด้วย
สำหรับ CTO สิ่งที่สำคัญที่สุดคือการหาวิธีเชื่อมโยงกระบวนการเหล่านี้ทั้งหมดและปรับให้เข้ากับความต้องการทางธุรกิจ เขาทำให้แน่ใจว่าแอปพลิเคชันมีความน่าเชื่อถือสำหรับทั้งธุรกิจและลูกค้า และที่นี่คุณต้องเข้าใจว่าเทคโนโลยีใดที่เหมาะกับงานทางธุรกิจใด วิธีสร้างกระบวนการทั้งหมด ฯลฯ CTO ยังรับผิดชอบด้านงบประมาณด้วย ตัวอย่างเช่น เขาต้องเข้าใจว่าต้องใช้เงินจำนวนเท่าใดในการฝึกอบรมผู้เชี่ยวชาญขึ้นใหม่เพื่อให้สามารถทำงานใน DevOps ได้
หากคุณมีเรื่องจะพูดเกี่ยวกับเรื่องเหล่านี้อย่าเงียบไป - กำหนดเวลาในการเรียกเอกสารคือวันที่ 20 สิงหาคม ยิ่งคุณลงทะเบียนเร็วเท่าไร คุณก็ยิ่งมีเวลามากขึ้นในการสรุปรายงานและเตรียมพร้อมสำหรับการนำเสนอของคุณ ดังนั้นอย่ารอช้า
ถ้าคุณไม่จำเป็นต้องพูดในที่สาธารณะก็แค่ และมาในวันที่ 30 กันยายน และ 1 ตุลาคม เพื่อพูดคุยกับเพื่อนร่วมงาน เราสัญญาว่ามันจะน่าสนใจและสร้างแรงบันดาลใจ
เราเห็น DevOps อย่างไร
เพื่อให้เข้าใจอย่างชัดเจนถึงความหมายของ DevOps ฉันแนะนำให้อ่าน (หรืออ่านซ้ำ) รายงานของฉัน “- เมื่อเดินผ่านกระแสคลื่นของตลาด ฉันสังเกตเห็นว่าแนวคิดของ DevOps เปลี่ยนแปลงไปอย่างไรในบริษัทขนาดต่างๆ ตั้งแต่สตาร์ทอัพขนาดเล็กไปจนถึงบริษัทข้ามชาติ รายงานนี้สร้างขึ้นจากชุดคำถาม การตอบคำถามเหล่านี้จะทำให้คุณเข้าใจได้ว่าบริษัทของคุณกำลังก้าวไปสู่ DevOps หรือมีปัญหาอยู่ที่ไหนสักแห่งหรือไม่
DevOps เป็นระบบที่ซับซ้อน โดยจะต้องประกอบด้วย:
- สินค้าดิจิตอล
- โมดูลธุรกิจที่พัฒนาผลิตภัณฑ์ดิจิทัลนี้
- ทีมผลิตภัณฑ์ที่เขียนโค้ด
- แนวทางปฏิบัติในการจัดส่งอย่างต่อเนื่อง
- แพลตฟอร์มเป็นบริการ
- โครงสร้างพื้นฐานเป็นบริการ
- โครงสร้างพื้นฐานเป็นรหัส
- แยกแนวทางปฏิบัติเพื่อรักษาความน่าเชื่อถือ ซึ่งมีอยู่ใน DevOps
- แนวปฏิบัติตอบรับที่อธิบายได้ทั้งหมด
ในตอนท้ายของรายงานจะมีแผนภาพที่ให้แนวคิดเกี่ยวกับระบบ DevOps ในบริษัท มันจะช่วยให้คุณเห็นว่ากระบวนการใดในบริษัทของคุณได้รับการปรับปรุงให้มีประสิทธิภาพแล้ว และกระบวนการใดที่ยังไม่ได้สร้างขึ้น
คุณสามารถชมวิดีโอรายงานได้ .
และตอนนี้จะมีโบนัส: วิดีโอหลายรายการจาก RIT++ 2019 ซึ่งกล่าวถึงปัญหาทั่วไปที่สุดของการเปลี่ยนแปลง DevOps
โครงสร้างพื้นฐานของบริษัทในฐานะผลิตภัณฑ์
Artyom Naumenko เป็นผู้นำทีม DevOps ที่ Skyeng และดูแลการพัฒนาโครงสร้างพื้นฐานของบริษัทของเขา เขาบอกว่าโครงสร้างพื้นฐานส่งผลต่อกระบวนการทางธุรกิจที่ SkyEng อย่างไร: วิธีคำนวณ ROI สำหรับโครงสร้างพื้นฐาน ควรเลือกตัวชี้วัดใดในการคำนวณ และวิธีทำงานเพื่อปรับปรุง
บนเส้นทางสู่ไมโครเซอร์วิส
บริษัท Nixys ให้การสนับสนุนโครงการเว็บและระบบแบบกระจายที่มีงานยุ่ง Boris Ershov ผู้อำนวยการฝ่ายเทคนิคบอกวิธีแปลผลิตภัณฑ์ซอฟต์แวร์ซึ่งการพัฒนาเริ่มขึ้นเมื่อ 5 ปีที่แล้ว (หรือมากกว่านั้น) สู่แพลตฟอร์มสมัยใหม่
ตามกฎแล้วโครงการดังกล่าวเป็นโลกพิเศษที่มีมุมมืดและโบราณของโครงสร้างพื้นฐานซึ่งวิศวกรปัจจุบันไม่รู้เกี่ยวกับพวกเขา และแนวทางด้านสถาปัตยกรรมและการพัฒนาที่เคยเลือกไว้นั้นล้าสมัยและไม่สามารถให้การพัฒนาและการเปิดตัวเวอร์ชันใหม่แก่ธุรกิจได้ เป็นผลให้การเปิดตัวผลิตภัณฑ์ทุกครั้งกลายเป็นการผจญภัยอันเหลือเชื่อ ซึ่งมีบางสิ่งหลุดลอยอยู่ตลอดเวลา และอยู่ในสถานที่ที่ไม่คาดคิดที่สุด
ผู้จัดการโครงการดังกล่าวต้องเผชิญกับความจำเป็นในการเปลี่ยนแปลงกระบวนการทางเทคโนโลยีทั้งหมดอย่างหลีกเลี่ยงไม่ได้ ในรายงานของเขา Boris กล่าวว่า:
- วิธีเลือกสถาปัตยกรรมที่เหมาะสมสำหรับโครงการและจัดโครงสร้างพื้นฐานให้เป็นระเบียบ
- เครื่องมือใดที่จะใช้และข้อผิดพลาดใดที่พบในเส้นทางสู่การเปลี่ยนแปลง
- จะทำอย่างไรต่อไป
ระบบอัตโนมัติของการปล่อยหรือวิธีการส่งมอบอย่างรวดเร็วและไม่ลำบาก
Alexander Korotkov เป็นผู้พัฒนาชั้นนำของระบบ CI/CD ของ CIAN เขาพูดถึงเครื่องมืออัตโนมัติที่ทำให้สามารถปรับปรุงคุณภาพและลดเวลาในการส่งโค้ดไปยังการผลิตได้ 5 เท่า แต่ผลลัพธ์ดังกล่าวไม่สามารถทำได้ด้วยระบบอัตโนมัติเพียงอย่างเดียว ดังนั้น Alexander จึงให้ความสำคัญกับการเปลี่ยนแปลงในกระบวนการพัฒนาด้วย
อุบัติเหตุช่วยให้คุณเรียนรู้ได้อย่างไร?
Alexey Kirpichnikov ใช้งาน DevOps และโครงสร้างพื้นฐานที่ SKB Kontur มาเป็นเวลา 5 ปีแล้ว ตลอดระยะเวลาสามปีที่ผ่านมา บริษัทของเขามีเรื่อง fakap ที่แตกต่างกันประมาณ 1000 เรื่อง ตัวอย่างเช่น 36% มีสาเหตุมาจากการเปิดตัวผลิตภัณฑ์คุณภาพต่ำสู่การใช้งานจริง และ 14% มีสาเหตุมาจากงานบำรุงรักษาฮาร์ดแวร์ในศูนย์ข้อมูล
การเก็บรายงาน (หลังชันสูตร) ที่วิศวกรของบริษัทเก็บรักษาไว้เป็นเวลาหลายปีติดต่อกัน ทำให้สามารถรับข้อมูลที่ถูกต้องเกี่ยวกับอุบัติเหตุได้ การชันสูตรพลิกศพเขียนโดยวิศวกรที่ปฏิบัติหน้าที่ ซึ่งเป็นคนแรกที่ตอบสนองต่อสัญญาณฉุกเฉินและเริ่มแก้ไขปัญหาทุกอย่าง เหตุใดวิศวกรที่ต้องดิ้นรนตอนกลางคืนกับ facaps ด้วยการเขียนรายงาน? ข้อมูลนี้ช่วยให้คุณเห็นภาพรวมและขับเคลื่อนการพัฒนาโครงสร้างพื้นฐานไปในทิศทางที่ถูกต้อง
ในสุนทรพจน์ของเขา Alexey แบ่งปันวิธีการเขียนการชันสูตรพลิกศพที่มีประโยชน์อย่างแท้จริง และวิธีการนำแนวปฏิบัติของรายงานดังกล่าวไปปฏิบัติในบริษัทขนาดใหญ่ หากคุณชอบเรื่องราวเกี่ยวกับการทำผิดของใครบางคน โปรดดูวิดีโอการแสดง
เราเข้าใจดีว่าวิสัยทัศน์เกี่ยวกับ DevOps ของคุณอาจไม่ตรงกับของเรา คงจะน่าสนใจที่จะทราบว่าคุณมองการเปลี่ยนแปลงของ DevOps อย่างไร แบ่งปันประสบการณ์และวิสัยทัศน์ของหัวข้อนี้ในความคิดเห็น
เรายอมรับรายงานใดบ้างในโปรแกรมแล้ว?
สัปดาห์นี้ คณะกรรมการโครงการได้นำรายงาน 4 ฉบับ: เกี่ยวกับการรักษาความปลอดภัย โครงสร้างพื้นฐาน และแนวปฏิบัติ SRE
บางทีหัวข้อที่เจ็บปวดที่สุดของการเปลี่ยนแปลง DevOps: จะแน่ใจได้อย่างไรว่าคนจากแผนกความปลอดภัยของข้อมูลจะไม่ทำลายการเชื่อมต่อที่สร้างไว้แล้วระหว่างการพัฒนา การปฏิบัติการ และการบริหาร บางบริษัทบริหารจัดการโดยไม่มีแผนกรักษาความปลอดภัยข้อมูล- จะมั่นใจความปลอดภัยของข้อมูลในกรณีนี้ได้อย่างไร? เกี่ยวกับมัน โมนา อาร์คิโปวา จาก sudo.su- จากรายงานของเธอ เราได้เรียนรู้:
- สิ่งที่ต้องได้รับการคุ้มครองและจากใคร
- กระบวนการรักษาความปลอดภัยตามปกติคืออะไร
- กระบวนการไอทีและความปลอดภัยของข้อมูลเชื่อมโยงกันอย่างไร
- CIS CSC คืออะไรและจะนำไปใช้อย่างไร
- อย่างไรและโดยตัวบ่งชี้ใดในการดำเนินการตรวจสอบความปลอดภัยของข้อมูลเป็นประจำ
รายงานฉบับถัดไปเกี่ยวข้องกับการพัฒนาโครงสร้างพื้นฐานในรูปแบบโค้ด ลดปริมาณของกิจวัตรแบบแมนนวลและไม่ทำให้ทั้งโปรเจ็กต์กลายเป็นความสับสนวุ่นวาย เป็นไปได้ไหม? สำหรับคำถามนี้ แม็กซิม โคสตริคิน จาก Ixtens- บริษัทของเขาใช้ terraform สำหรับการทำงานกับโครงสร้างพื้นฐาน AWS เครื่องมือนี้สะดวก แต่คำถามคือจะหลีกเลี่ยงการสร้างโค้ดจำนวนมากเมื่อใช้งานได้อย่างไร การบำรุงรักษามรดกดังกล่าวจะมีราคาแพงขึ้นทุกปี
Maxim จะแสดงให้เห็นว่ารูปแบบการวางโค้ดทำงานอย่างไร โดยมีเป้าหมายเพื่อลดความซับซ้อนของระบบอัตโนมัติและการพัฒนา
อื่น เราจะได้ยินเกี่ยวกับโครงสร้างพื้นฐานจาก วลาดิเมียร์ เรียบอฟ จาก Playkey- ที่นี่เราจะพูดถึงแพลตฟอร์มโครงสร้างพื้นฐาน และเราจะเรียนรู้:
- จะเข้าใจได้อย่างไรว่าพื้นที่เก็บข้อมูลถูกใช้อย่างมีประสิทธิภาพหรือไม่
- จำนวนผู้ใช้หลายร้อยรายที่สามารถรับเนื้อหา 10 TB หากใช้พื้นที่เก็บข้อมูลเพียง 20 TB
- วิธีการบีบอัดข้อมูล 5 ครั้งและมอบให้กับผู้ใช้แบบเรียลไทม์
- วิธีซิงโครไนซ์ข้อมูลระหว่างศูนย์ข้อมูลหลายแห่งได้ทันที
- วิธีกำจัดอิทธิพลของผู้ใช้ที่มีต่อกันเมื่อใช้เครื่องเสมือนเครื่องหนึ่งตามลำดับ
ความลับของความมหัศจรรย์นี้คือเทคโนโลยี ZFS สำหรับ FreeBSD และส้อมอันสดใหม่ ZFS บน Linux- Vladimir จะแบ่งปันเคสจาก Playkey
Matvey Kukuy จาก Amixr.IO พร้อมตัวอย่างจากชีวิต , เกิดอะไรขึ้น SRE และวิธีที่ช่วยสร้างระบบที่เชื่อถือได้ Amixr.IO ส่งผ่านเหตุการณ์ของลูกค้าผ่านแบ็กเอนด์ ทีมงานประจำหลายสิบคนทั่วโลกได้จัดการกับคดีไปแล้วกว่า 150 กรณี ในการประชุม Matvey จะแบ่งปันสถิติและข้อมูลเชิงลึกที่บริษัทของเขาสะสมมาจากการแก้ปัญหาของลูกค้าและการวิเคราะห์ความล้มเหลว
ฉันขอย้ำอีกครั้งว่าคุณอย่าโลภและแบ่งปันประสบการณ์ของคุณในฐานะซามูไร DevOps ให้บริการ สำหรับรายงาน คุณและฉันจะมีเวลา 2,5 เดือนในการเตรียมการนำเสนอที่ยอดเยี่ยม หากคุณอยากเป็นผู้ฟัง จดหมายข่าวพร้อมอัพเดตโปรแกรมและคิดอย่างจริงจังเกี่ยวกับการจองตั๋วล่วงหน้าเพราะจะมีราคาแพงกว่าเมื่อใกล้ถึงวันประชุม
ที่มา: will.com