Anton Weiss ผู้ก่อตั้งและผู้อำนวยการ Otomato Software หนึ่งในผู้ริเริ่มและผู้สอนการรับรอง DevOps ครั้งแรกในอิสราเอลได้พูดในงานปีที่แล้ว เกี่ยวกับทฤษฎีเคออสและหลักการสำคัญของวิศวกรรมเคออส และยังอธิบายวิธีการทำงานขององค์กร DevOps ในอุดมคติแห่งอนาคตอีกด้วย
เราได้เตรียมรายงานในรูปแบบข้อความแล้ว
good morning!
DevOpsDays ในมอสโกเป็นปีที่สองติดต่อกัน นี่เป็นครั้งที่สองของฉันบนเวทีนี้ พวกคุณหลายคนอยู่ในห้องนี้เป็นครั้งที่สอง มันหมายความว่าอะไร? ซึ่งหมายความว่าขบวนการ DevOps ในรัสเซียกำลังเติบโต ทวีคูณ และที่สำคัญที่สุด หมายความว่าถึงเวลาแล้วที่จะพูดถึงว่า DevOps คืออะไรในปี 2018
ยกมือขึ้น ใครคิดว่า DevOps เป็นอาชีพแล้วในปี 2018? มีดังกล่าว. มีวิศวกร DevOps คนใดในห้องที่มีคำอธิบายงานว่า “DevOps Engineer” หรือไม่? มีผู้จัดการ DevOps อยู่ในห้องบ้างไหม? ไม่มีเช่นนั้น สถาปนิก DevOps? ไม่มีเช่นกัน ไม่พอ. เป็นเรื่องจริงหรือเปล่าที่ไม่มีใครบอกว่าตนเป็นวิศวกร DevOps?
พวกคุณส่วนใหญ่คิดว่านี่เป็นการต่อต้านรูปแบบใช่ไหม อาชีพแบบนี้ไม่น่ามีเลยเหรอ? เราสามารถคิดอะไรก็ได้ที่เราต้องการ แต่ในขณะที่เรากำลังคิด อุตสาหกรรมก็กำลังก้าวไปข้างหน้าอย่างเคร่งขรึมด้วยเสียงของทรัมเป็ต DevOps
ใครเคยได้ยินเกี่ยวกับหัวข้อใหม่ที่เรียกว่า DevDevOps บ้างไหม? นี่เป็นเทคนิคใหม่ที่ช่วยให้เกิดการทำงานร่วมกันอย่างมีประสิทธิภาพระหว่างนักพัฒนาและ Devops และไม่ใช่เรื่องใหม่ ดูจาก Twitter พวกเขาเริ่มพูดถึงเรื่องนี้เมื่อ 4 ปีที่แล้ว และจนถึงขณะนี้ความสนใจในเรื่องนี้มีเพิ่มขึ้นเรื่อย ๆ นั่นคือมีปัญหา ปัญหาจะต้องได้รับการแก้ไข
เราเป็นคนที่มีความคิดสร้างสรรค์ เราไม่เพียงแค่พักผ่อนง่ายๆ เราพูดว่า: DevOps ไม่ใช่คำที่ครอบคลุมเพียงพอ แต่ยังขาดองค์ประกอบที่แตกต่างและน่าสนใจทุกประเภท และเราไปที่ห้องปฏิบัติการลับของเรา และเริ่มสร้างการกลายพันธุ์ที่น่าสนใจ: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps
ตรรกะนั้นแข็งแกร่งใช่ไหม? ระบบการจัดส่งของเราไม่ทำงาน ระบบของเราไม่เสถียร และผู้ใช้ของเราไม่พอใจ เราไม่มีเวลาที่จะเผยแพร่ซอฟต์แวร์ตรงเวลา เราไม่เหมาะสมกับงบประมาณ เราจะแก้ปัญหาทั้งหมดนี้อย่างไร? เราจะมากับคำศัพท์ใหม่! มันจะลงท้ายด้วย "Ops" และปัญหาก็ได้รับการแก้ไข
ดังนั้นฉันจึงเรียกวิธีนี้ว่า - “ขออภัย และปัญหาได้รับการแก้ไขแล้ว”
ทั้งหมดนี้จะหายไปในเบื้องหลังถ้าเราเตือนตัวเองว่าทำไมเราถึงคิดเรื่องทั้งหมดนี้ขึ้นมา เราคิดค้น DevOps ทั้งหมดนี้ขึ้นเพื่อทำให้การส่งมอบซอฟต์แวร์และงานของเราเองในกระบวนการนี้ราบรื่น ไม่ยุ่งยาก มีประสิทธิภาพ และที่สำคัญที่สุดคือสนุกสนานที่สุดเท่าที่จะเป็นไปได้
DevOps เติบโตมาจากความเจ็บปวด และเราเหนื่อยกับความทุกข์ และเพื่อให้ทั้งหมดนี้เกิดขึ้น เราอาศัยหลักปฏิบัติที่ไม่สิ้นสุด: การทำงานร่วมกันอย่างมีประสิทธิผล แนวทางปฏิบัติที่ลื่นไหล และที่สำคัญที่สุดคือการคิดอย่างเป็นระบบ เพราะถ้าไม่มีวิธีนี้ DevOps ก็ทำงานไม่ได้
ระบบคืออะไร?
และหากเรากำลังพูดถึงการคิดเชิงระบบอยู่แล้ว เราก็ควรเตือนตัวเองว่าระบบคืออะไร
หากคุณเป็นแฮ็กเกอร์ผู้ปฏิวัติวงการ ระบบก็ชั่วร้ายอย่างเห็นได้ชัดสำหรับคุณ มันเป็นเมฆที่แขวนอยู่เหนือคุณและบังคับให้คุณทำสิ่งที่คุณไม่ต้องการทำ
จากมุมมองของการคิดเชิงระบบ ระบบคือภาพรวมที่ประกอบด้วยส่วนต่างๆ ในแง่นี้ เราแต่ละคนเป็นระบบ องค์กรที่เราทำงานเป็นระบบ และสิ่งที่คุณและฉันกำลังสร้างเรียกว่าระบบ
ทั้งหมดนี้เป็นส่วนหนึ่งของระบบสังคมเทคโนโลยีขนาดใหญ่ระบบเดียว และถ้าเราเข้าใจว่าระบบสังคมเทคโนโลยีนี้ทำงานร่วมกันอย่างไร เมื่อนั้นเท่านั้นที่เราจะสามารถเพิ่มประสิทธิภาพบางสิ่งในเรื่องนี้ได้อย่างแท้จริง
จากมุมมองของการคิดเชิงระบบ ระบบมีคุณสมบัติที่น่าสนใจหลายประการ ประการแรก ประกอบด้วยส่วนต่างๆ ซึ่งหมายความว่าพฤติกรรมของมันขึ้นอยู่กับพฤติกรรมของส่วนต่างๆ นอกจากนี้ทุกส่วนของมันยังพึ่งพาซึ่งกันและกันอีกด้วย ปรากฎว่ายิ่งระบบมีส่วนต่างๆ มากเท่าไร การทำความเข้าใจหรือคาดการณ์พฤติกรรมของระบบก็จะยิ่งยากขึ้นเท่านั้น
จากมุมมองของพฤติกรรม มีข้อเท็จจริงที่น่าสนใจอีกประการหนึ่ง ระบบสามารถทำบางสิ่งที่ไม่มีส่วนใดส่วนหนึ่งทำได้
ดังที่ ดร. รัสเซลล์ แอคคอฟ (หนึ่งในผู้ก่อตั้งระบบการคิด) กล่าวว่า สิ่งนี้ค่อนข้างง่ายที่จะพิสูจน์ด้วยการทดลองทางความคิด เช่น ใครในห้องรู้วิธีเขียนโค้ด? มีมือจำนวนมากและนี่เป็นเรื่องปกติ เพราะนี่เป็นหนึ่งในข้อกำหนดหลักสำหรับอาชีพของเรา คุณรู้วิธีการเขียน แต่มือของคุณสามารถเขียนโค้ดแยกจากคุณได้หรือไม่? มีคนพูดว่า: “ไม่ใช่มือของฉันที่เขียนโค้ด แต่สมองของฉันต่างหากที่เขียนโค้ด” สมองของคุณสามารถเขียนโค้ดแยกจากคุณได้หรือไม่? อาจจะไม่
สมองเป็นเครื่องจักรที่น่าทึ่ง เราไม่รู้ด้วยซ้ำถึง 10% ว่ามันทำงานอย่างไร แต่มันไม่สามารถทำงานแยกจากระบบที่เป็นร่างกายของเราได้ และนี่เป็นเรื่องง่ายที่จะพิสูจน์: เปิดกระโหลกของคุณ เอาสมองของคุณออกมา วางไว้หน้าคอมพิวเตอร์ ให้เขาลองเขียนอะไรง่ายๆ ตัวอย่างเช่น "สวัสดีชาวโลก" ใน Python
หากระบบสามารถทำบางสิ่งบางอย่างที่ไม่มีส่วนใดส่วนหนึ่งสามารถทำแยกกันได้ นั่นหมายความว่าพฤติกรรมของระบบไม่ได้ถูกกำหนดโดยพฤติกรรมของส่วนต่างๆ ของมัน แล้วมันถูกกำหนดด้วยอะไรล่ะ? มันถูกกำหนดโดยการโต้ตอบระหว่างส่วนเหล่านี้ ดังนั้นยิ่งส่วนต่างๆ มากเท่าไร การโต้ตอบก็จะยิ่งซับซ้อนมากขึ้นเท่านั้น การทำความเข้าใจและคาดการณ์พฤติกรรมของระบบก็จะยิ่งยากขึ้นเท่านั้น และสิ่งนี้ทำให้ระบบดังกล่าววุ่นวาย เนื่องจากการเปลี่ยนแปลงใดๆ ก็ตาม แม้แต่การเปลี่ยนแปลงที่มองไม่เห็นและไม่สำคัญที่สุดในส่วนใดๆ ของระบบก็อาจนำไปสู่ผลลัพธ์ที่ไม่อาจคาดเดาได้อย่างสมบูรณ์
ความอ่อนไหวต่อสภาวะเริ่มแรกนี้ถูกค้นพบและศึกษาครั้งแรกโดยนักอุตุนิยมวิทยาชาวอเมริกัน เอ็ด ลอเรนซ์ ต่อมาถูกเรียกว่า "เอฟเฟกต์ผีเสื้อ" และนำไปสู่การพัฒนาการเคลื่อนไหวของความคิดทางวิทยาศาสตร์ที่เรียกว่า "ทฤษฎีความสับสนวุ่นวาย" ทฤษฎีนี้ได้กลายเป็นหนึ่งในการเปลี่ยนแปลงกระบวนทัศน์ที่สำคัญในวิทยาศาสตร์แห่งศตวรรษที่ 20
ทฤษฎีความโกลาหล
คนที่ศึกษาเรื่องความโกลาหลเรียกตัวเองว่านัก chaosologist
จริงๆ แล้ว เหตุผลของรายงานฉบับนี้ก็คือ เมื่อทำงานกับระบบกระจายที่ซับซ้อนและองค์กรระหว่างประเทศขนาดใหญ่ เมื่อถึงจุดหนึ่งฉันก็ตระหนักว่านี่คือสิ่งที่ฉันรู้สึกเช่นนั้น ฉันเป็นนักความสับสนวุ่นวาย นี่เป็นวิธีที่ชาญฉลาดในการพูดว่า “ฉันไม่เข้าใจว่าเกิดอะไรขึ้นที่นี่ และฉันไม่รู้ว่าต้องทำอย่างไรกับเรื่องนี้”
ฉันคิดว่าพวกคุณหลายคนก็มักจะรู้สึกเช่นนี้ ดังนั้นคุณจึงเป็นนักวิทยาศาสตรวิทยาเช่นกัน ฉันขอเชิญคุณเข้าร่วมสมาคมนักความสับสนวุ่นวาย ระบบที่คุณและผมซึ่งเป็นเพื่อนนักวิทยาวิทยาวิทยาที่รักจะศึกษากันนั้นเรียกว่า "ระบบการปรับตัวที่ซับซ้อน"
การปรับตัวคืออะไร? ความสามารถในการปรับตัวหมายถึงพฤติกรรมส่วนบุคคลและส่วนรวมของส่วนต่างๆ ในระบบการปรับตัวดังกล่าวจะเปลี่ยนแปลงและจัดระเบียบตัวเอง ตอบสนองต่อเหตุการณ์หรือลูกโซ่ของเหตุการณ์ย่อยในระบบ นั่นคือระบบจะปรับตามการเปลี่ยนแปลงผ่านการจัดระเบียบตนเอง และความสามารถในการจัดระเบียบตนเองนี้ขึ้นอยู่กับความร่วมมือแบบกระจายอำนาจโดยสมัครใจของตัวแทนอิสระ
คุณสมบัติที่น่าสนใจอีกประการหนึ่งของระบบดังกล่าวก็คือสามารถปรับขนาดได้อย่างอิสระ สิ่งที่เราน่าจะสนใจอย่างไม่ต้องสงสัยในฐานะวิศวกรด้านความสับสนวุ่นวาย ดังนั้น ถ้าเราบอกว่าพฤติกรรมของระบบที่ซับซ้อนถูกกำหนดโดยปฏิสัมพันธ์ของส่วนต่างๆ ของมัน แล้วเราควรสนใจอะไร? ปฏิสัมพันธ์.
มีการค้นพบที่น่าสนใจอีกสองประการ
ประการแรก เราเข้าใจว่าระบบที่ซับซ้อนไม่สามารถทำให้ง่ายขึ้นได้โดยการทำให้ส่วนต่างๆ ของมันง่ายขึ้น ประการที่สอง วิธีเดียวที่จะทำให้ระบบที่ซับซ้อนง่ายขึ้นคือทำให้การโต้ตอบระหว่างส่วนต่างๆ ของระบบง่ายขึ้น
เราจะโต้ตอบกันอย่างไร? คุณและฉันล้วนเป็นส่วนหนึ่งของระบบข้อมูลขนาดใหญ่ที่เรียกว่าสังคมมนุษย์ เราโต้ตอบผ่านภาษากลาง หากเรามี หากเราพบ
แต่ภาษาเองก็เป็นระบบการปรับตัวที่ซับซ้อน ดังนั้นเพื่อที่จะโต้ตอบได้อย่างมีประสิทธิภาพและง่ายดายยิ่งขึ้น เราจำเป็นต้องสร้างโปรโตคอลบางประเภท นั่นคือลำดับของสัญลักษณ์และการกระทำที่จะทำให้การแลกเปลี่ยนข้อมูลระหว่างเราง่ายขึ้น คาดเดาได้มากขึ้น และเข้าใจได้มากขึ้น
ฉันอยากจะบอกว่าแนวโน้มไปสู่ความซับซ้อน สู่การปรับตัว สู่การกระจายอำนาจ ไปสู่ความสับสนวุ่นวาย สามารถติดตามได้ในทุกสิ่ง และในระบบที่คุณและฉันกำลังสร้าง และในระบบที่เราเป็นส่วนหนึ่ง
และเพื่อไม่ให้เป็นการไม่มีมูลความจริง เรามาดูกันว่าระบบที่เราสร้างขึ้นมีการเปลี่ยนแปลงอย่างไร
คุณกำลังรอคำนี้ฉันเข้าใจ เราอยู่ในการประชุม DevOps วันนี้คำนี้จะได้ยินเป็นแสนครั้ง แล้วเราจะฝันถึงมันในตอนกลางคืน
ไมโครเซอร์วิสเป็นสถาปัตยกรรมซอฟต์แวร์ตัวแรกที่เกิดจากการตอบสนองต่อแนวทางปฏิบัติของ DevOps ซึ่งได้รับการออกแบบมาเพื่อให้ระบบของเรามีความยืดหยุ่นมากขึ้น ปรับขนาดได้มากขึ้น และรับประกันการส่งมอบที่ต่อเนื่อง เธอทำเช่นนี้ได้อย่างไร? โดยการลดปริมาณการบริการ ลดขอบเขตของปัญหาที่บริการเหล่านี้ดำเนินการ ลดเวลาในการจัดส่ง นั่นคือเราลดและลดความซับซ้อนของส่วนต่าง ๆ ของระบบเพิ่มจำนวนและดังนั้นความซับซ้อนของการโต้ตอบระหว่างส่วนเหล่านี้จึงเพิ่มขึ้นอย่างสม่ำเสมอนั่นคือปัญหาใหม่เกิดขึ้นที่เราต้องแก้ไข
ไมโครเซอร์วิสไม่ใช่จุดสิ้นสุด โดยทั่วไปแล้ว ไมโครเซอร์วิสนั้นเกิดขึ้นเมื่อวานนี้แล้ว เนื่องจาก Serverless กำลังจะมา เซิร์ฟเวอร์ทั้งหมดถูกเบิร์นดาวน์ ไม่มีเซิร์ฟเวอร์ ไม่มีระบบปฏิบัติการ มีเพียงโค้ดปฏิบัติการล้วนๆ การกำหนดค่าแยกจากกัน สถานะแยกจากกัน ทุกอย่างถูกควบคุมโดยเหตุการณ์ ความสวยงาม ความสะอาด ความเงียบ ไม่มีเหตุการณ์ ไม่มีอะไรเกิดขึ้น ลำดับสมบูรณ์
ความซับซ้อนอยู่ที่ไหน? แน่นอนว่าความยากอยู่ที่การโต้ตอบ ฟังก์ชั่นหนึ่งสามารถทำอะไรได้ด้วยตัวเองมากแค่ไหน? มันโต้ตอบกับฟังก์ชั่นอื่น ๆ อย่างไร? คิวข้อความ ฐานข้อมูล บาลานเซอร์ จะสร้างเหตุการณ์บางอย่างขึ้นมาใหม่เมื่อเกิดความล้มเหลวได้อย่างไร? คำถามมากมายและคำตอบไม่กี่ข้อ
ไมโครเซอร์วิสและไร้เซิร์ฟเวอร์คือสิ่งที่เราเรียกว่า Cloud Native มันคือทั้งหมดที่เกี่ยวกับคลาวด์ แต่ระบบคลาวด์ก็มีข้อจำกัดในด้านความสามารถในการปรับขนาดด้วยเช่นกัน เราคุ้นเคยกับการคิดว่ามันเป็นระบบแบบกระจาย ที่จริงแล้ว เซิร์ฟเวอร์ของผู้ให้บริการคลาวด์อาศัยอยู่ที่ไหน? ในศูนย์ข้อมูล นั่นคือเรามีโมเดลแบบกระจายแบบรวมศูนย์ ที่จำกัดมากที่นี่
วันนี้เราเข้าใจดีว่า Internet of Things ไม่ใช่แค่คำสำคัญอีกต่อไป แม้จะเป็นเพียงการคาดการณ์เล็กๆ น้อยๆ ก็ตาม อุปกรณ์นับพันล้านเครื่องที่เชื่อมต่อกับอินเทอร์เน็ตรอเราอยู่ในห้าถึงสิบปีข้างหน้า ข้อมูลที่เป็นประโยชน์และไร้ประโยชน์จำนวนมหาศาลที่จะถูกรวมเข้ากับคลาวด์และอัพโหลดจากคลาวด์
คลาวด์นั้นอยู่ได้ไม่นาน ดังนั้นเราจึงพูดถึงสิ่งที่เรียกว่าการประมวลผลแบบเอดจ์มากขึ้นเรื่อยๆ หรือฉันชอบคำจำกัดความที่ยอดเยี่ยมของ "การประมวลผลด้วยหมอก" มันถูกปกคลุมไปด้วยเวทย์มนต์ของแนวโรแมนติกและความลึกลับ
คอมพิวเตอร์หมอก ประเด็นก็คือเมฆเป็นกลุ่มน้ำ ไอน้ำ น้ำแข็ง และหินที่รวมศูนย์ไว้ และหมอกก็คือหยดน้ำที่กระจัดกระจายอยู่รอบตัวเราในชั้นบรรยากาศ
ในกระบวนทัศน์หมอก งานส่วนใหญ่เสร็จสิ้นโดยหยดเหล่านี้โดยอัตโนมัติโดยสมบูรณ์หรือโดยร่วมมือกับหยดอื่นๆ และพวกเขาหันไปหาก้อนเมฆเฉพาะเมื่อพวกเขาถูกกดดันจริงๆ เท่านั้น
นั่นคือการกระจายอำนาจอีกครั้ง ความเป็นอิสระ และแน่นอนว่าพวกคุณหลายคนเข้าใจแล้วว่าทั้งหมดนี้กำลังดำเนินไปในทิศทางใด เพราะคุณไม่สามารถพูดถึงการกระจายอำนาจโดยไม่เอ่ยถึงบล็อคเชนได้
มีผู้ที่เชื่อเหล่านี้คือผู้ที่ลงทุนในสกุลเงินดิจิทัล มีคนที่เชื่อแต่กลัวเหมือนผม เป็นต้น และมีผู้ที่ไม่เชื่อ ที่นี่คุณสามารถรักษาได้แตกต่างออกไป มีเทคโนโลยี มีเรื่องใหม่ไม่รู้มีปัญหา เช่นเดียวกับเทคโนโลยีใหม่ ๆ มันทำให้เกิดคำถามมากกว่าคำตอบ
กระแสโฆษณารอบบล็อคเชนเป็นที่เข้าใจได้ นอกเหนือจากการตื่นทองแล้ว เทคโนโลยีเองก็ให้คำมั่นสัญญาที่น่าทึ่งสำหรับอนาคตที่สดใสยิ่งขึ้น: มีอิสระมากขึ้น มีอิสระมากขึ้น และกระจายความไว้วางใจไปทั่วโลก ไม่ต้องการอะไร?
ด้วยเหตุนี้ วิศวกรทั่วโลกจึงเริ่มพัฒนาแอปพลิเคชันแบบกระจายอำนาจมากขึ้นเรื่อยๆ และนี่คือพลังที่ไม่สามารถปฏิเสธได้โดยเพียงแค่พูดว่า: “อ่า บล็อกเชนเป็นเพียงฐานข้อมูลแบบกระจายที่มีการใช้งานไม่ดี” หรือผู้ขี้ระแวงชอบพูดว่า: “ไม่มีแอปพลิเคชันจริงสำหรับบล็อคเชน” ลองคิดดู 150 ปีที่แล้วพวกเขาพูดเรื่องไฟฟ้าเหมือนกัน และพวกเขาก็พูดถูกด้วยซ้ำในบางแง่ เพราะสิ่งที่ไฟฟ้าทำให้เกิดขึ้นได้ในปัจจุบันนั้นไม่มีทางเป็นไปได้เลยในศตวรรษที่ 19
ว่าแต่ใครจะรู้บ้างว่าโลโก้บนหน้าจอเป็นแบบไหน? นี่คือไฮเปอร์เลดเจอร์ นี่เป็นโครงการที่ได้รับการพัฒนาภายใต้การอุปถัมภ์ของ The Linux Foundation และรวมถึงชุดเทคโนโลยีบล็อกเชน นี่คือจุดแข็งของชุมชนโอเพ่นซอร์สของเราอย่างแท้จริง
วิศวกรรมความโกลาหล
ดังนั้น ระบบที่เรากำลังพัฒนาจึงมีความซับซ้อนมากขึ้นเรื่อยๆ วุ่นวายมากขึ้นเรื่อยๆ และมีการปรับตัวมากขึ้นเรื่อยๆ Netflix เป็นผู้บุกเบิกระบบไมโครเซอร์วิส พวกเขาเป็นหนึ่งในคนกลุ่มแรกๆ ที่เข้าใจสิ่งนี้ พวกเขาพัฒนาชุดเครื่องมือที่พวกเขาเรียกว่ากองทัพสิเมียน ซึ่งมีชื่อเสียงมากที่สุดก็คือ . พระองค์ทรงกำหนดสิ่งที่เรียกว่า .
อย่างไรก็ตาม ในกระบวนการจัดทำรายงาน เรายังแปลข้อความนี้เป็นภาษารัสเซียด้วย ดังนั้นไปที่ อ่านแสดงความคิดเห็นดุ
โดยสรุป หลักการของวิศวกรรมความโกลาหลกล่าวไว้ดังต่อไปนี้ ระบบแบบกระจายที่ซับซ้อนนั้นไม่อาจคาดเดาได้และมีปัญหาโดยธรรมชาติ ข้อผิดพลาดเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ซึ่งหมายความว่าเราต้องยอมรับข้อผิดพลาดเหล่านี้และทำงานกับระบบเหล่านี้ด้วยวิธีที่แตกต่างไปจากเดิมอย่างสิ้นเชิง
ตัวเราเองต้องพยายามนำข้อผิดพลาดเหล่านี้มาสู่ระบบการผลิตของเราเพื่อทดสอบระบบของเราสำหรับความสามารถในการปรับตัวแบบเดียวกันนี้ ความสามารถในการจัดระเบียบตนเอง เพื่อความอยู่รอด
และนั่นทำให้ทุกอย่างเปลี่ยนไป ไม่เพียงแต่วิธีที่เราเปิดตัวระบบสู่การใช้งานจริงเท่านั้น แต่ยังรวมไปถึงวิธีที่เราพัฒนาระบบและวิธีทดสอบอีกด้วย ไม่มีกระบวนการทำให้เสถียรหรือค้างโค้ด ในทางกลับกัน มีกระบวนการทำให้ไม่เสถียรอย่างต่อเนื่อง เรากำลังพยายามทำลายระบบและดูว่ามันจะอยู่รอดต่อไป
โปรโตคอลการรวมระบบแบบกระจาย
ด้วยเหตุนี้ จึงทำให้ระบบของเราต้องเปลี่ยนแปลงไปในทางใดทางหนึ่ง เพื่อให้มีเสถียรภาพมากขึ้น พวกเขาต้องการโปรโตคอลใหม่สำหรับการโต้ตอบระหว่างส่วนต่างๆ เพื่อให้ส่วนต่าง ๆ เหล่านี้สามารถตกลงและมาจัดระเบียบตนเองได้ และเครื่องมือใหม่ทุกประเภท โปรโตคอลใหม่ก็เกิดขึ้น ซึ่งฉันเรียกว่า "โปรโตคอลสำหรับการโต้ตอบของระบบแบบกระจาย"
ฉันกำลังพูดถึงอะไร? ประการแรกโครงการ . มีความพยายามที่จะสร้างโปรโตคอลการติดตามแบบกระจายทั่วไปซึ่งเป็นเครื่องมือที่ขาดไม่ได้อย่างแน่นอนสำหรับการดีบักระบบแบบกระจายที่ซับซ้อน
ไกลออกไป - . เราบอกว่าเราไม่สามารถคาดเดาได้ว่าจะเกิดอะไรขึ้นกับระบบ กล่าวคือ เราต้องเพิ่มความสามารถในการสังเกตและสังเกตได้ Opentracing อยู่ในกลุ่มเครื่องมือที่ช่วยให้ระบบของเราสามารถสังเกตได้ แต่เราต้องการความสามารถในการสังเกตเพื่อพิจารณาว่าระบบทำงานตามที่เราคาดหวังหรือไม่ เราจะนิยามพฤติกรรมที่คาดหวังได้อย่างไร? โดยการกำหนดนโยบายบางประเภท กฎเกณฑ์บางชุด โครงการ Open Policy Agent กำลังทำงานเพื่อกำหนดชุดกฎนี้ในขอบเขตต่างๆ ตั้งแต่การเข้าถึงไปจนถึงการจัดสรรทรัพยากร
ดังที่เราได้กล่าวไว้ ระบบของเราขับเคลื่อนด้วยเหตุการณ์มากขึ้น Serverless เป็นตัวอย่างที่ดีของระบบที่ขับเคลื่อนด้วยเหตุการณ์ เพื่อให้เราสามารถถ่ายโอนเหตุการณ์ระหว่างระบบและติดตามเหตุการณ์ได้ เราจำเป็นต้องมีภาษากลาง โปรโตคอลทั่วไปสำหรับวิธีที่เราพูดถึงเหตุการณ์ วิธีที่เราส่งข้อมูลถึงกัน นี่คือสิ่งที่เรียกว่าโครงการ .
การเปลี่ยนแปลงที่หลั่งไหลเข้ามาอย่างต่อเนื่องซึ่งล้างระบบของเรา และทำให้ระบบไม่เสถียรอย่างต่อเนื่อง คือการหลั่งไหลของสิ่งประดิษฐ์ซอฟต์แวร์อย่างต่อเนื่อง เพื่อให้เราสามารถรักษากระแสการเปลี่ยนแปลงอย่างต่อเนื่อง เราจำเป็นต้องมีโปรโตคอลทั่วไปบางประเภทซึ่งเราสามารถพูดถึงว่าสิ่งประดิษฐ์ของซอฟต์แวร์คืออะไร มีการทดสอบอย่างไร และผ่านการตรวจสอบอะไรบ้าง นี่คือสิ่งที่เรียกว่าโครงการ . นั่นคือโปรโตคอลเมตาดาต้าทั่วไปสำหรับสิ่งประดิษฐ์ของซอฟต์แวร์
และสุดท้าย ถ้าเราต้องการให้ระบบของเรามีความเป็นอิสระ ปรับตัวได้ และจัดระเบียบตัวเองได้อย่างสมบูรณ์ เราต้องให้สิทธิ์แก่ระบบในการระบุตัวตน โครงการที่เรียกว่า นี่คือสิ่งที่เขาทำ นี่เป็นโครงการภายใต้การอุปถัมภ์ของ Cloud Native Computing Foundation
โครงการทั้งหมดนี้ยังใหม่อยู่ พวกเขาทั้งหมดต้องการความรักและการตรวจสอบของเรา ทั้งหมดนี้เป็นโอเพ่นซอร์ส การทดสอบ และการนำไปใช้งานของเรา พวกเขาแสดงให้เราเห็นว่าเทคโนโลยีกำลังมุ่งหน้าไปทางไหน
แต่ DevOps ไม่เคยเกี่ยวข้องกับเทคโนโลยีเป็นหลัก แต่เป็นเรื่องเกี่ยวกับการทำงานร่วมกันระหว่างผู้คนมาโดยตลอด และด้วยเหตุนี้ ถ้าเราต้องการให้ระบบที่เราพัฒนาเปลี่ยนแปลง ตัวเราเองก็ต้องเปลี่ยนแปลง จริงๆ แล้ว เรากำลังเปลี่ยนแปลงอยู่ เราไม่มีทางเลือกมากนัก
มีอัศจรรย์ Rachel Botsman นักเขียนชาวอังกฤษ ซึ่งเธอเขียนเกี่ยวกับวิวัฒนาการของความไว้วางใจตลอดประวัติศาสตร์ของมนุษย์ เธอบอกว่าในตอนแรก ในสังคมดึกดำบรรพ์ ความไว้วางใจเกิดขึ้นในท้องถิ่น นั่นคือเราเชื่อใจเฉพาะคนที่เรารู้จักเป็นการส่วนตัวเท่านั้น
จากนั้นก็มีช่วงเวลาที่ยาวนานมาก - ช่วงเวลาที่มืดมนเมื่อความไว้วางใจถูกรวมศูนย์ เมื่อเราเริ่มเชื่อใจผู้คนที่เราไม่รู้จักบนพื้นฐานของข้อเท็จจริงที่ว่าเราอยู่ในสถาบันสาธารณะหรือของรัฐเดียวกัน
และนี่คือสิ่งที่เราเห็นในโลกสมัยใหม่ของเรา: ความไว้วางใจมีการกระจายและกระจายอำนาจมากขึ้นเรื่อยๆ และขึ้นอยู่กับเสรีภาพในการไหลเวียนของข้อมูล บนความพร้อมของข้อมูล
หากคุณลองคิดดู ความสามารถในการเข้าถึงนี้ซึ่งทำให้ความไว้วางใจเป็นไปได้ คือสิ่งที่คุณและฉันกำลังนำไปใช้ ซึ่งหมายความว่าทั้งวิธีที่เราทำงานร่วมกันและวิธีที่เราทำจะต้องเปลี่ยนแปลง เนื่องจากองค์กรไอทีแบบรวมศูนย์ที่มีลำดับชั้นในอดีตไม่ทำงานอีกต่อไป พวกเขาเริ่มที่จะตาย
พื้นฐานองค์กร DevOps
องค์กร DevOps ในอุดมคติแห่งอนาคตคือระบบกระจายอำนาจและปรับเปลี่ยนได้ซึ่งประกอบด้วยทีมที่เป็นอิสระ ซึ่งแต่ละทีมประกอบด้วยบุคคลที่เป็นอิสระ ทีมเหล่านี้กระจายอยู่ทั่วโลก โดยทำงานร่วมกันอย่างมีประสิทธิภาพโดยใช้การสื่อสารแบบอะซิงโครนัส โดยใช้โปรโตคอลการสื่อสารที่โปร่งใสสูง สวยมากใช่มั้ยล่ะ? อนาคตที่สวยงามมาก
แน่นอนว่าสิ่งนี้เป็นไปไม่ได้หากปราศจากการเปลี่ยนแปลงทางวัฒนธรรม เราต้องมีภาวะผู้นำการเปลี่ยนแปลง ความรับผิดชอบส่วนบุคคล มีแรงจูงใจภายใน
นี่คือพื้นฐานขององค์กร DevOps: ความโปร่งใสของข้อมูล การสื่อสารแบบอะซิงโครนัส ความเป็นผู้นำการเปลี่ยนแปลง การกระจายอำนาจ
เผาไหม้
ระบบที่เราเป็นส่วนหนึ่งและระบบที่เราสร้างขึ้นนั้นวุ่นวายมากขึ้น และเป็นเรื่องยากสำหรับมนุษย์ที่จะรับมือกับความคิดนี้ เป็นการยากที่จะละทิ้งภาพลวงตาของการควบคุม เราพยายามที่จะควบคุมพวกมันต่อไป และสิ่งนี้มักจะนำไปสู่ความเหนื่อยหน่าย ฉันพูดแบบนี้จากประสบการณ์ของตัวเอง ฉันก็ถูกไฟไหม้เช่นกัน ฉันก็พิการด้วยความล้มเหลวที่คาดไม่ถึงในการผลิต
ความเหนื่อยหน่ายเกิดขึ้นเมื่อเราพยายามควบคุมบางสิ่งที่ไม่สามารถควบคุมได้โดยธรรมชาติ เมื่อเราเหนื่อยหน่าย ทุกสิ่งทุกอย่างจะสูญเสียความหมายไป เพราะเราสูญเสียความปรารถนาที่จะทำสิ่งใหม่ๆ เราได้รับการตั้งรับ และเริ่มปกป้องสิ่งที่เรามี
วิชาชีพวิศวกรรมอย่างที่ฉันมักจะชอบเตือนตัวเองคืออาชีพที่มีความคิดสร้างสรรค์เป็นอันดับแรกและสำคัญที่สุด หากเราสูญเสียความปรารถนาที่จะสร้างบางสิ่ง เราก็จะกลายเป็นเถ้าถ่าน และกลายเป็นเถ้าถ่าน ผู้คนก็เหนื่อยหน่าย ทั้งองค์กรก็เหนื่อยหน่าย
ในความเห็นของผม ยอมรับแต่พลังสร้างสรรค์แห่งความโกลาหล การสร้างความร่วมมือตามหลักการเท่านั้นที่จะช่วยให้เราไม่สูญเสียสิ่งที่ดีในอาชีพของเรา
นี่คือสิ่งที่ฉันปรารถนาให้คุณ: รักงานของคุณ, รักในสิ่งที่เราทำ โลกนี้ฟีดข้อมูล เรามีเกียรติในการป้อนข้อมูลนั้น เรามาศึกษาความโกลาหล เป็นนัก chaosologist กันเถอะ สร้างคุณค่า สร้างสิ่งใหม่ ปัญหาอย่างที่เรารู้ไปแล้วเป็นสิ่งที่หลีกเลี่ยงไม่ได้ และเมื่อพวกมันปรากฏขึ้น เราก็จะพูดง่ายๆ ว่า "อ๊ะ!" แล้วปัญหาก็ได้รับการแก้ไข .
อะไรอีกนอกจาก Chaos Monkey?
จริงๆ แล้ว เครื่องดนตรีทั้งหมดนี้ยังเด็กมาก Netflix คนเดียวกันนี้สร้างเครื่องมือสำหรับตัวเอง สร้างเครื่องมือของคุณเอง อ่านหลักการของ Chaos Engineering และปฏิบัติตามหลักการเหล่านั้น แทนที่จะพยายามค้นหาเครื่องมืออื่นๆ ที่คนอื่นสร้างไว้แล้ว
พยายามทำความเข้าใจว่าระบบของคุณพังอย่างไร และเริ่มพังทลายลง และดูว่าระบบยังคงอยู่ได้อย่างไร เรื่องนี้มาก่อน และคุณสามารถค้นหาเครื่องมือได้ มีโครงการทุกประเภท
ฉันไม่ค่อยเข้าใจช่วงเวลาที่คุณบอกว่าระบบไม่สามารถทำให้ง่ายขึ้นได้ด้วยการลดความซับซ้อนของส่วนประกอบ และย้ายไปยังไมโครเซอร์วิสทันที ซึ่งทำให้ระบบง่ายขึ้นโดยทำให้ส่วนประกอบต่างๆ ง่ายขึ้นและทำให้การโต้ตอบซับซ้อนขึ้น สิ่งเหล่านี้โดยพื้นฐานแล้วเป็นสองส่วนที่ขัดแย้งกัน
ถูกต้องแล้ว ไมโครเซอร์วิสเป็นหัวข้อที่มีการถกเถียงกันมากโดยทั่วไป ที่จริงแล้ว การลดความซับซ้อนของชิ้นส่วนจะเพิ่มความยืดหยุ่น ไมโครเซอร์วิสให้อะไร? พวกเขาให้ความยืดหยุ่นและความรวดเร็วแก่เรา แต่พวกเขาไม่ได้ให้ความเรียบง่ายแก่เราอย่างแน่นอน พวกเขาเพิ่มความยาก
ดังนั้นตามปรัชญา DevOps ไมโครเซอร์วิสจึงไม่ใช่สิ่งที่ดีใช่ไหม
ความดีใด ๆ ก็มีด้านกลับกัน ข้อดีคือเพิ่มความยืดหยุ่น ช่วยให้เราทำการเปลี่ยนแปลงได้เร็วขึ้น แต่ก็เพิ่มความซับซ้อนและความเปราะบางของทั้งระบบด้วย
อย่างไรก็ตาม อะไรคือสิ่งที่สำคัญมากกว่า: ในการทำให้การโต้ตอบง่ายขึ้นหรือในการลดความซับซ้อนของส่วนต่างๆ
แน่นอนว่าการเน้นอยู่ที่การทำให้การโต้ตอบง่ายขึ้น เพราะหากเราดูสิ่งนี้จากมุมมองของวิธีที่เราทำงานร่วมกับคุณ ก่อนอื่นเลย เราต้องให้ความสำคัญกับการทำให้การโต้ตอบง่ายขึ้น และไม่ทำให้งานง่ายขึ้น ของเราแต่ละคนแยกกัน เพราะการทำให้งานง่ายขึ้นหมายถึงการเปลี่ยนเป็นหุ่นยนต์ ที่แมคโดนัลด์จะทำงานได้ตามปกติเมื่อคุณมีคำแนะนำ: ตรงนี้คุณใส่เบอร์เกอร์ ตรงนี้คุณราดซอส สิ่งนี้ใช้ไม่ได้กับงานสร้างสรรค์ของเราเลย
เป็นความจริงหรือไม่ที่ทุกสิ่งที่คุณพูดอยู่ในโลกที่ปราศจากการแข่งขัน และความโกลาหลที่นั่นช่างใจดี และไม่มีความขัดแย้งภายในความสับสนวุ่นวายนี้ ไม่มีใครอยากกินหรือฆ่าใครเลย? การแข่งขันและ DevOps ควรเป็นอย่างไร?
มันขึ้นอยู่กับว่าเรากำลังพูดถึงการแข่งขันประเภทไหน เป็นเรื่องเกี่ยวกับการแข่งขันในที่ทำงานหรือการแข่งขันระหว่างบริษัท?
เกี่ยวกับการแข่งขันด้านบริการที่มีอยู่เนื่องจากบริการมีหลายบริษัท เรากำลังสร้างสภาพแวดล้อมข้อมูลรูปแบบใหม่ และสภาพแวดล้อมใดๆ ก็ไม่สามารถอยู่ได้โดยปราศจากการแข่งขัน มีการแข่งขันทุกที่
Netflix เดียวกัน เราก็ถือเป็นแบบอย่าง ทำไมพวกเขาถึงคิดเรื่องนี้ขึ้นมา? เพราะพวกเขาจำเป็นต้องแข่งขัน ความยืดหยุ่นและความเร็วในการเคลื่อนที่นี้เป็นข้อกำหนดด้านการแข่งขันอย่างมากและทำให้เกิดความสับสนวุ่นวายในระบบของเรา นั่นคือความวุ่นวายไม่ใช่สิ่งที่เราตั้งใจทำเพราะเราต้องการมัน แต่เป็นสิ่งที่เกิดขึ้นเพราะโลกเรียกร้องมัน เราแค่ต้องปรับตัว และความโกลาหลเป็นผลจากการแข่งขันอย่างแน่นอน
นี่หมายความว่าความโกลาหลคือการไม่มีเป้าหมายอย่างที่เคยเป็นหรือไม่? หรือเป้าหมายเหล่านั้นที่เราไม่ต้องการเห็น? เราอยู่ในบ้านและไม่เข้าใจเป้าหมายของผู้อื่น ที่จริงแล้วการแข่งขันนั้นเกิดจากการที่เรามีเป้าหมายที่ชัดเจน และเรารู้ว่าเราจะไปจบลงที่จุดใดในแต่ละช่วงเวลาถัดไป จากมุมมองของฉัน นี่คือแก่นแท้ของ DevOps
ดูคำถามด้วย ฉันคิดว่าเราทุกคนมีเป้าหมายเดียวกัน: เพื่อความอยู่รอดและทำมันด้วย
ความสุขที่ยิ่งใหญ่ที่สุด และเป้าหมายการแข่งขันขององค์กรใดๆ ก็เหมือนกัน การเอาชีวิตรอดมักเกิดขึ้นจากการแข่งขัน คุณไม่สามารถทำอะไรกับมันได้
การประชุมในปีนี้ จะมีขึ้นในวันที่ 7 ธันวาคมที่ Technopolis เราเปิดรับใบสมัครสำหรับรายงานจนถึงวันที่ 11 พฤศจิกายน เราถ้าคุณต้องการที่จะพูด
เปิดลงทะเบียนสำหรับผู้เข้าร่วมแล้ว ตั๋วราคา 7000 รูเบิล เข้าร่วมกับเรา!
ที่มา: will.com