DevOps คืออะไร

คำจำกัดความของ DevOps นั้นซับซ้อนมาก ดังนั้นเราจึงต้องเริ่มการอภิปรายเกี่ยวกับเรื่องนี้ใหม่ทุกครั้ง มีสิ่งพิมพ์หลายพันรายการในหัวข้อนี้ในHabréเพียงอย่างเดียว แต่ถ้าคุณอ่านข้อความนี้อยู่ คุณคงจะรู้ว่า DevOps คืออะไร เพราะฉันไม่ได้ สวัสดีฉันชื่อ อเล็กซานเดอร์ ติตอฟ (@ออสมิโนก) และเราจะพูดถึง DevOps และฉันจะแบ่งปันประสบการณ์ของฉัน

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

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

เหนือสิ่งอื่นใด ฉันเป็นหนึ่งในผู้จัดงานชุมชน DevOps Moscow และผู้จัดงาน DevOps-Days 2017 แต่ฉันไม่ได้จัดงานปี 2018 Express 42 ทำงานร่วมกับหลายบริษัท เราขยาย DevOps ที่นั่น ดูว่ามันเกิดขึ้นอย่างไร สรุป วิเคราะห์ บอกข้อสรุปของเรากับทุกคน และฝึกอบรมผู้คนในแนวทางปฏิบัติ DevOps โดยทั่วไป เรากำลังพยายามอย่างดีที่สุดเพื่อเพิ่มประสบการณ์และความเชี่ยวชาญในเรื่องนี้

ทำไมต้อง DevOps

คำถามแรกที่หลอกหลอนทุกคนและตลอดเวลาคือ - ทำไม? หลายๆ คนคิดว่า DevOps เป็นเพียงระบบอัตโนมัติหรือสิ่งที่คล้ายกันที่ทุกบริษัทมีอยู่แล้ว

— เรามีการบูรณาการอย่างต่อเนื่อง - นั่นหมายความว่าเรามี DevOps อยู่แล้ว และเหตุใดสิ่งทั้งหมดนี้จึงจำเป็น? พวกเขากำลังสนุกสนานในต่างประเทศ แต่พวกเขาขัดขวางเราไม่ให้ทำงาน!

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

ทั้งหมดนี้เกิดจากการที่โลกกำลังเปลี่ยนแปลง เขาย้ายออกจากแนวทางระดับองค์กร เมื่อบริษัทต่างๆ มุ่งตรงไปสู่ความฝัน ดังที่เพลงคลาสสิกของเซนต์ปีเตอร์สเบิร์กของเราร้องเพลงจากจุด A ไปยังจุด B ตามกลยุทธ์บางอย่าง โดยมีโครงสร้างบางอย่างที่สร้างขึ้นเพื่อสิ่งนี้

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

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

เมื่อบริษัทผ่านตลาด ทำงานร่วมกับลูกค้า บริษัทจะสำรวจตลาดอย่างต่อเนื่องและเปลี่ยนจุดสิ้นสุด B นอกจากนี้ ยิ่งบริษัทเปลี่ยนทิศทางบ่อยเท่าใด ท้ายที่สุดก็จะประสบความสำเร็จมากขึ้นเท่านั้น เนื่องจากบริษัทเลือกตลาดมากขึ้น ซอก

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

ผลิตภัณฑ์นี้ถูกซื้อโดย Unilever ในราคา 1 พันล้านดอลลาร์ ขณะนี้สามารถแข่งขันกับยิลเลตต์และได้แย่งชิงส่วนแบ่งสำคัญของผู้บริโภคในตลาดอเมริกา One Box Shave พูดว่า:

— 4 ใบมีด? คุณจริงจังไหม? ทำไมคุณถึงต้องการสิ่งนี้ - มันไม่ได้ปรับปรุงคุณภาพการโกน ครีม น้ำหอม และมีดโกนคุณภาพสูงที่คัดสรรมาเป็นพิเศษพร้อมใบมีดสองใบช่วยแก้ปัญหาได้มากกว่าใบมีด Gillette 4 ใบที่โง่เขลา! เราจะถึง 10 เร็วๆ นี้ไหม?

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

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

เวลาสู่ตลาดเป็นเรื่องเกี่ยวกับการลดเวลาจากแนวคิดไปสู่การนำไปปฏิบัติขั้นสุดท้าย

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

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

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

ในปี 1968 เมลวิน คอนเวย์ ชายผู้มีวิสัยทัศน์กว้างไกลได้กำหนดแนวคิดดังต่อไปนี้

องค์กรที่สร้างระบบถูกจำกัดโดยการออกแบบที่จำลองโครงสร้างการสื่อสารขององค์กรนั้น

ในรายละเอียดเพิ่มเติม เพื่อสร้างระบบประเภทอื่น คุณต้องมีโครงสร้างการสื่อสารภายในบริษัทประเภทอื่นด้วย หากโครงสร้างการสื่อสารของคุณมีลำดับชั้นสูงสุด สิ่งนี้จะไม่อนุญาตให้คุณสร้างระบบที่สามารถให้ตัวบ่งชี้ Time-to-Market ที่สูงมากได้

อ่าน เกี่ยวกับกฎของคอนเวย์ หนึ่งสามารถ ผ่านลิงก์. มันเป็นสิ่งสำคัญสำหรับการทำความเข้าใจวัฒนธรรมหรือปรัชญา DevOps เพราะ สิ่งเดียวที่เปลี่ยนแปลงโดยพื้นฐานใน DevOps คือโครงสร้างการสื่อสารระหว่างทีม.

จากมุมมองของกระบวนการ ก่อน DevOps ทุกขั้นตอน: การวิเคราะห์ การพัฒนา การทดสอบ การดำเนินการ เป็นแบบเชิงเส้น
ในกรณีของ DevOps กระบวนการทั้งหมดเหล่านี้เกิดขึ้นพร้อมกัน

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

แล้วทำไมคุณถึงต้องการ DevOps?

สำหรับการพัฒนาผลิตภัณฑ์ดิจิทัล. หากบริษัทของคุณไม่มีผลิตภัณฑ์ดิจิทัล ก็ไม่จำเป็นต้องใช้ DevOps ซึ่งถือเป็นสิ่งสำคัญมาก

DevOps เอาชนะข้อจำกัดด้านความเร็วของการผลิตซอฟต์แวร์ตามลำดับ. ในนั้นกระบวนการทั้งหมดเกิดขึ้นพร้อมกัน

ความยากเพิ่มขึ้น เมื่อผู้เผยแพร่ DevOps บอกคุณว่าการเผยแพร่ซอฟต์แวร์จะง่ายขึ้นสำหรับคุณ นี่จึงเป็นเรื่องไร้สาระ

ด้วย DevOps สิ่งต่างๆ จะซับซ้อนมากขึ้นเท่านั้น

ในการประชุมที่บูธ Avito คุณจะเห็นว่าการนำคอนเทนเนอร์ Docker ไปใช้งานนั้นเป็นอย่างไร ซึ่งเป็นงานที่ไม่สมจริง ความซับซ้อนเป็นสิ่งต้องห้าม คุณต้องเล่นปาหี่ลูกบอลหลายลูกในเวลาเดียวกัน

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

คำถามสำหรับผู้เชี่ยวชาญ

คุณมีอะไร? คำถามที่คุณสามารถถามตัวเองขณะทำงานในบริษัทและพัฒนาในฐานะผู้เชี่ยวชาญ

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

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

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

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

องค์กร

ดังที่ผมได้กล่าวไว้ ตามกฎหมายของคอนเวย์ องค์กรของบริษัทมีการเปลี่ยนแปลง ฉันจะเริ่มต้นด้วยสิ่งที่ป้องกันไม่ให้ DevOps เจาะเข้าไปในบริษัทจากมุมมองขององค์กร

ปัญหาเรื่อง "บ่อน้ำ"

คำภาษาอังกฤษ "Silo" แปลเป็นภาษารัสเซียว่า "well" ประเด็นของปัญหานี้ก็คือ ไม่มีการแลกเปลี่ยนข้อมูลระหว่างทีม. แต่ละทีมเจาะลึกถึงความเชี่ยวชาญของตน โดยไม่ต้องสร้างแผนที่ร่วมกันเพื่อนำทาง

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

DevOps แนะนำให้ผ่านช่วงเวลาแห่งความงุนงงนี้ และทุกแผนกจะทำงานร่วมกันเพื่อสร้างแผนที่ปฏิสัมพันธ์ร่วมกัน

มีสองปัจจัยที่ขัดขวางสิ่งนี้

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

แต่สิ่งที่สำคัญที่สุดคือปัญหาของ "บ่อน้ำ" สำหรับวิศวกรที่ตื้นตันไปด้วยจิตวิญญาณของ DevOps ได้อ่าน Fowler และหนังสืออื่นๆ อีกจำนวนหนึ่ง แสดงให้เห็นความจริงที่ว่า "บ่อน้ำ" ไม่ยอมให้คุณทำสิ่งที่ "ชัดเจน". เรามักจะรวมตัวกันหลังจาก DevOps Moscow พูดคุยกัน และผู้คนก็บ่นว่า:

— เราแค่อยากเปิดตัว CI แต่กลับกลายเป็นว่าฝ่ายบริหารไม่ต้องการมัน

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

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

ผู้คนต่างต่อสู้เพื่อดวงดาวหรือธง ทุกคนต่างค้นหาความเชี่ยวชาญของตนเอง

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

มันเหมือนกันในบริษัทของคุณหรือไม่?

หากต้องการตรวจสอบสิ่งนี้ คุณสามารถถามตัวเองด้วยคำถามต่อไปนี้

ทีมใช้เครื่องมือทั่วไปและมีส่วนร่วมในการเปลี่ยนแปลงเครื่องมือทั่วไปเหล่านั้นหรือไม่

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

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

มันสำคัญแค่ไหนที่ผู้จัดการจะได้รับความสำเร็จส่วนบุคคลโดยไม่คำนึงถึงความสำเร็จของบริษัท?

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

โครงสร้างพื้นฐานเป็นรหัส

หลังจากที่ปัญหานี้ผ่านไปแล้ว แนวทางปฏิบัติที่สำคัญประการแรก ซึ่งหากไม่เป็นเช่นนั้นก็ยากที่จะพัฒนาต่อไปใน DevOps ก็คือ โครงสร้างพื้นฐานเป็นรหัส.

บ่อยครั้งที่โครงสร้างพื้นฐานเป็นโค้ดถูกรับรู้ดังนี้:

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

แต่นั่นไม่เป็นความจริง

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

คุณสามารถสร้างแผนที่ในรูปแบบของโค้ดร่วมกับทีมอื่นๆ ที่ทุกคนสามารถเข้าใจ และสามารถนำทางและนำทางได้ ไม่สำคัญว่าจะทำอะไรบน Chef, Ansible, Salt หรือการใช้ไฟล์ YAML ใน Kubernetes ก็ไม่มีความแตกต่าง

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

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

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

โค้ดได้รับการดูแลตามหลักปฏิบัติด้านโค้ดที่ดีที่สุด: การพัฒนาร่วมกัน, การตรวจสอบโค้ด, การเขียนโปรแกรม XP, การทดสอบ, คำขอดึงข้อมูล, CI สำหรับโครงสร้างพื้นฐานของโค้ด - ทั้งหมดนี้เหมาะสมและสามารถใช้ได้

โค้ดกลายเป็นภาษากลางสำหรับวิศวกรทุกคน

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

มันเป็นสิ่งสำคัญ: หากคุณยังไม่ได้ลองสิ่งนี้จำไว้ Ansible ไม่ใช่ทุบตี! อ่านเอกสารอย่างละเอียด ศึกษาสิ่งที่พวกเขาเขียนเกี่ยวกับเรื่องนี้

โครงสร้างพื้นฐานเป็นรหัสคือการแยกรหัสโครงสร้างพื้นฐานออกเป็นเลเยอร์ที่แยกจากกัน

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


ชั้นฐาน - นี่คือวิธีการกำหนดค่าระบบปฏิบัติการ การสำรองข้อมูล และสิ่งอื่นๆ ระดับต่ำ เช่น วิธีการใช้งาน Kubernetes ในระดับพื้นฐาน

ระดับการบริการ - นี่คือบริการที่คุณให้กับผู้พัฒนา: Log as a Service, Monitoring as a Service, Database as a Service, Balancer as a Service, Queue as a Service, Continuous Delivery as a Service - กลุ่มบริการที่แต่ละทีม สามารถนำมาพัฒนาได้ ทั้งหมดนี้จำเป็นต้องอธิบายไว้ในโมดูลแยกต่างหากในระบบการจัดการการกำหนดค่าของคุณ

เลเยอร์ที่ทำแอปพลิเคชัน และอธิบายว่าพวกมันจะเผยออกมาอย่างไรบนสองชั้นก่อนหน้า

คำถามควบคุม

บริษัทของคุณมีพื้นที่เก็บข้อมูลโครงสร้างพื้นฐานร่วมกันหรือไม่? คุณกำลังจัดการหนี้ทางเทคนิคในโครงสร้างพื้นฐานของคุณหรือไม่? คุณใช้แนวปฏิบัติในการพัฒนาในพื้นที่เก็บข้อมูลโครงสร้างพื้นฐานหรือไม่? โครงสร้างพื้นฐานของคุณถูกแบ่งออกเป็นหลายชั้นหรือไม่? คุณสามารถตรวจสอบแผนภาพ Base-service-APP ได้ การเปลี่ยนแปลงนั้นยากแค่ไหน?

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

จัดส่งอย่างต่อเนื่อง

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

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

เมื่อเราอยู่กับ วานยา เอฟตูโควิช เห็นหนังสือเล่มแรก เจซ ฮัมเบิล และกลุ่มผู้เขียน “จัดส่งอย่างต่อเนื่อง”ซึ่งเปิดตัวในปี 2009 เราคิดมานานแล้วว่าจะแปลชื่อเป็นภาษารัสเซียได้อย่างไร พวกเขาต้องการแปลว่า "ส่งมอบอย่างต่อเนื่อง" แต่น่าเสียดายที่แปลว่า "ส่งมอบอย่างต่อเนื่อง" สำหรับฉันดูเหมือนว่ามีบางสิ่งที่เป็นภาษารัสเซียในนามของเราด้วยความกดดัน

ส่งมอบสื่ออย่างต่อเนื่อง

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

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

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

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

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

“ส่งมอบอย่างต่อเนื่อง” มีลักษณะเช่นนี้

กระบวนการจัดส่ง Dev, CI, Test, PreProd, Prod ไม่ใช่สภาพแวดล้อมที่แยกจากกัน สิ่งเหล่านี้คือขั้นตอนหรือสถานีที่มีผลรวมในการกันไฟซึ่ง Artifact ของคุณจะผ่านไปได้

หากคุณมีรหัสโครงสร้างพื้นฐานที่อธิบายว่าเป็น Base Service APP ก็ช่วยได้ อย่าลืมสคริปต์ทั้งหมดและจดไว้เป็นโค้ดสำหรับสิ่งประดิษฐ์นี้ ส่งเสริมสิ่งประดิษฐ์ และเปลี่ยนมันตามที่คุณไป

คำถามทดสอบตัวเอง

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

หากคำตอบทั้งหมดคือใช่ แสดงว่าคุณเจ๋งมาก! เขียนคำตอบของคุณในความคิดเห็น - ฉันจะดีใจ)

ข้อเสนอแนะ

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

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

- พวกคุณทำไมคุณถึงข่มขืนเซิร์ฟเวอร์ด้วยสิ่งที่ไม่ชัดเจน?

แต่แล้วก็มีเหตุการณ์เกิดขึ้นซึ่งแสดงให้เห็นว่านี่เป็นกลยุทธ์ที่เจ๋งมากจริงๆ

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

เราตกใจมากเมื่อเปิดกราฟของเราใน Zabbix และปรากฎว่าเมื่อหนึ่งสัปดาห์ครึ่งที่แล้ว พฤติกรรมของคำขอในบริการ API ที่โบรกเกอร์รายนี้ใช้เปลี่ยนไปอย่างมาก ต่อไปเราพบว่าความถี่ในการส่งข้อความบางประเภทเปลี่ยนไป ต่อมาเราพบว่าสิ่งเหล่านี้คือไคลเอนต์ Android เราถาม:

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

เพื่อเป็นการตอบสนอง เราได้ยินเรื่องราวที่น่าสนใจเกี่ยวกับวิธีที่พวกเขาออกแบบ UI ใหม่ ไม่น่าเป็นไปได้ที่ใครจะพูดทันทีว่าพวกเขาเปลี่ยนไลบรารี HTTP สำหรับลูกค้า Android ก็เหมือนกับการเปลี่ยนสบู่ในห้องน้ำ แต่จำไม่ได้ ด้วยเหตุนี้ หลังจากสนทนาไป 40 นาที เราพบว่าพวกเขาเปลี่ยนไลบรารี HTTP และการกำหนดเวลาเริ่มต้นก็เปลี่ยนไป สิ่งนี้นำไปสู่พฤติกรรมการรับส่งข้อมูลบนเซิร์ฟเวอร์ API ที่เปลี่ยนแปลง ซึ่งนำไปสู่สถานการณ์ที่ทำให้เกิดการแข่งขันภายในนายหน้า และเริ่มขัดข้อง

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

รวบรวมข้อมูลทั้งหมดเกี่ยวกับสิ่งที่เกิดขึ้นกับอาร์ติแฟกต์ในแต่ละขั้นตอนของกระบวนการจัดส่ง ไม่ใช่ในการใช้งานจริง

อัปโหลดการตรวจสอบไปยัง CI และสิ่งพื้นฐานบางอย่างจะปรากฏที่นั่นแล้ว หลังจากนั้นคุณจะเห็นสิ่งเหล่านี้ใน Test, PredProd และการทดสอบโหลด รวบรวมข้อมูลในทุกขั้นตอน ไม่เพียงแต่ตัวชี้วัด สถิติ แต่ยังรวมถึงบันทึก: แอปพลิเคชันเปิดตัวอย่างไร ความผิดปกติ - รวบรวมทุกอย่าง

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

คำถามสำหรับการควบคุมตนเอง

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

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

เมื่อคุณมีองค์ประกอบทั้งสามนี้แล้ว คุณจะนึกถึงแพลตฟอร์มโครงสร้างพื้นฐานประเภทใดในบริษัทของคุณได้

แพลตฟอร์มโครงสร้างพื้นฐาน

ประเด็นไม่ใช่ว่ามันเป็นชุดเครื่องมือที่แตกต่างกันออกไปที่ทุกบริษัทมี

จุดสำคัญของแพลตฟอร์มโครงสร้างพื้นฐานคือทุกทีมใช้เครื่องมือเหล่านี้และพัฒนาร่วมกัน

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

ทุกทีมพัฒนาแพลตฟอร์มโครงสร้างพื้นฐานและปฏิบัติต่อมันด้วยความเอาใจใส่เสมือนเป็น IDE ของพวกเขาเอง. ใน IDE ของคุณ คุณติดตั้งปลั๊กอินต่างๆ เพื่อทำให้ทุกอย่างดีและรวดเร็ว และกำหนดค่าปุ่มลัด เมื่อคุณเปิด Sublime, Atom หรือ Visual Studio Code มีข้อผิดพลาดของโค้ดหลั่งไหลเข้ามาและคุณรู้ว่ามันเป็นไปไม่ได้เลยที่จะทำงานเลย คุณจะรู้สึกเศร้าทันทีและคุณรีบวิ่งไปแก้ไข IDE ของคุณ

ปฏิบัติต่อแพลตฟอร์มโครงสร้างพื้นฐานของคุณในลักษณะเดียวกัน หากคุณเข้าใจว่ามีบางอย่างผิดปกติ ให้ส่งคำขอหากคุณไม่สามารถแก้ไขได้ด้วยตนเอง ถ้ามีอะไรง่ายๆ แก้ไขเอง ส่ง pull request หนุ่มๆจะพิจารณาบวกให้ครับ นี่เป็นแนวทางที่แตกต่างออกไปเล็กน้อยสำหรับเครื่องมือทางวิศวกรรมในหัวของนักพัฒนา

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

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

โครงการนี้

นี่คือแผนภาพพื้นฐานของแพลตฟอร์มโครงสร้างพื้นฐานที่จะช่วยคุณในการตั้งค่าแนวทางปฏิบัติและกระบวนการทั้งหมดในบริษัท DevOps

มาดูกันว่าประกอบด้วยอะไรบ้าง

ระบบการประสานทรัพยากรซึ่งจัดเตรียม CPU, หน่วยความจำ, ดิสก์ให้กับแอปพลิเคชันและบริการอื่นๆ ยิ่งไปกว่านั้น - บริการระดับต่ำ: การตรวจสอบ, การบันทึก, กลไก CI/CD, พื้นที่จัดเก็บสิ่งประดิษฐ์, โครงสร้างพื้นฐานเป็นรหัสระบบ

บริการระดับที่สูงขึ้น: ฐานข้อมูลในรูปแบบบริการ, คิวเป็นบริการ, Load Balance เป็นบริการ, การปรับขนาดรูปภาพเป็นบริการ, โรงงาน Big Data เป็นบริการ ยิ่งไปกว่านั้น - ไปป์ไลน์ที่ส่งโค้ดที่แก้ไขอย่างต่อเนื่องให้กับลูกค้าของคุณ.

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

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

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

การสร้างแพลตฟอร์ม

นี่เป็นกระบวนการสื่อสารที่ซับซ้อน เมื่อคุณมีแนวทางปฏิบัติขั้นพื้นฐาน คุณจะเริ่มต้นการสื่อสารระหว่างวิศวกรและผู้เชี่ยวชาญต่างๆ ที่พัฒนาข้อกำหนดและมาตรฐาน และเปลี่ยนเครื่องมือและแนวทางต่างๆ อย่างต่อเนื่อง วัฒนธรรมที่เรามีใน DevOps มีความสำคัญที่นี่

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

คุณมีอะไร?

คำถามที่คุณสามารถถามตัวเองอีกครั้ง

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

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

ดังนั้น DevOps...

... นี่เป็นระบบที่ซับซ้อน จะต้องมี:

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

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

มันจะจบลงในอีกสองสามสัปดาห์ DevOpsConf 2019. ซึ่งเป็นส่วนหนึ่งของ RIT++ เชิญมาที่การประชุมซึ่งคุณจะได้พบกับรายงานเจ๋งๆ มากมายเกี่ยวกับการส่งมอบอย่างต่อเนื่อง โครงสร้างพื้นฐานในรูปแบบโค้ด และการเปลี่ยนแปลง DevOps จองตั๋วของคุณ, หมดเขตราคาสุดท้ายคือวันที่ 20 พฤษภาคม

ที่มา: will.com