โครงสร้างพื้นฐานเป็นรหัส: การรู้จักครั้งแรก

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

ความต่อเนื่องของชุดบทความที่เขียนขึ้นจากสุนทรพจน์ในงานภายในของเรา ฟอรั่มนักพัฒนา:

1. แมวของชโรดิงเงอร์ไม่มีกล่อง: ปัญหาฉันทามติในระบบแบบกระจาย
2. โครงสร้างพื้นฐานเป็นรหัส (คุณอยู่ที่นี่)
3. การสร้างสัญญา Typescript โดยใช้โมเดล C# (กำลังดำเนินการ...)
4. รู้เบื้องต้นเกี่ยวกับอัลกอริธึมฉันทามติ Raft (กำลังดำเนินการ...)
...

เราตัดสินใจสร้างทีม SRE เพื่อนำแนวคิดเหล่านั้นไปใช้ google sre. พวกเขาคัดเลือกโปรแกรมเมอร์จากนักพัฒนาของตนเองและส่งพวกเขาไปฝึกอบรมเป็นเวลาหลายเดือน

ทีมงานมีภารกิจการฝึกอบรมดังต่อไปนี้:

• อธิบายโครงสร้างพื้นฐานของเรา ซึ่งส่วนใหญ่อยู่ใน Microsoft Azure ในรูปแบบของโค้ด (Terraform และทุกสิ่งรอบตัว)
• สอนนักพัฒนาถึงวิธีการทำงานกับโครงสร้างพื้นฐาน
• เตรียมนักพัฒนาให้พร้อมปฏิบัติหน้าที่

เราแนะนำแนวคิดของโครงสร้างพื้นฐานเป็นโค้ด

ในรูปแบบปกติของโลก (การบริหารแบบคลาสสิก) ความรู้เกี่ยวกับโครงสร้างพื้นฐานมีอยู่สองแห่ง:

1. หรือในรูปแบบขององค์ความรู้ในหัวของผู้เชี่ยวชาญ
2. หรือข้อมูลนี้อยู่ในเครื่องพิมพ์ดีดบางรุ่นซึ่งบางรุ่นเป็นที่รู้จักของผู้เชี่ยวชาญ แต่ไม่ใช่ความจริงที่ว่าคนนอก (ในกรณีที่ทั้งทีมของเราเสียชีวิตกะทันหัน) จะสามารถเข้าใจได้ว่าอะไรทำงานอย่างไรและทำงานอย่างไร อาจมีข้อมูลมากมายเกี่ยวกับเครื่องจักร: อุปกรณ์เสริม, cronjobs, ข่มขู่ (ดู การติดตั้งดิสก์) ดิสก์และรายการสิ่งที่สามารถเกิดขึ้นได้ไม่รู้จบ เป็นการยากที่จะเข้าใจว่าเกิดอะไรขึ้นจริงๆ

ในทั้งสองกรณี เราพบว่าตัวเองติดอยู่กับการที่ต้องพึ่งพิง:

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

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

ดังนั้นโครงสร้างพื้นฐานในรูปแบบโค้ด (Incfastructure as Code - IaC) จึงเป็นคำอธิบายของโครงสร้างพื้นฐานที่มีอยู่ทั้งหมดในรูปแบบของโค้ด รวมถึงเครื่องมือที่เกี่ยวข้องสำหรับการทำงานกับโครงสร้างพื้นฐานและการนำโครงสร้างพื้นฐานจริงไปใช้

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

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

เราค้นหาพวกเขาเป็นเวลานานในตลาดบุคลากรภายนอกบริษัทของเรา แต่เราต้องยอมรับว่าเราไม่พบใครก็ตามที่ตรงกับคำขอของเรา ฉันต้องค้นหาในหมู่คนของฉันเอง

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

ตอนนี้เรามาดูตัวอย่างว่าโครงสร้างพื้นฐานสามารถฮาร์ดโค้ดเป็นโค้ดได้อย่างไร โค้ดเขียนได้ดี มีคุณภาพสูง พร้อมความคิดเห็นและการเยื้อง

ตัวอย่างโค้ดจาก Terraforma

ตัวอย่างโค้ดจาก Ansible

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

1. ปัญหาแรกคือ ในกรณีส่วนใหญ่ IaC จะเป็น dsl บางชนิด

และในทางกลับกัน DSL ก็คือคำอธิบายของโครงสร้าง สิ่งที่คุณควรมีอย่างแม่นยำยิ่งขึ้น: Json, Yaml, การดัดแปลงจาก บริษัท ขนาดใหญ่บางแห่งที่มาพร้อมกับ dsl ของตัวเอง (HCL ถูกใช้ใน Terraform)

ปัญหาคือมันอาจไม่มีสิ่งคุ้นเคยเช่น:

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

2. ปัญหาประการที่สองของโค้ดดังกล่าวคือ ส่วนใหญ่แล้วจะเป็นสภาพแวดล้อมที่ต่างกัน. โดยปกติแล้วคุณจะนั่งทำงานกับ C# เช่น ด้วยหนึ่งภาษา หนึ่งสแต็ก หนึ่งระบบนิเวศ และที่นี่คุณมีเทคโนโลยีที่หลากหลายมากมาย

มันเป็นสถานการณ์จริงมากเมื่อ bash ด้วย python เปิดตัวกระบวนการบางอย่างที่มีการแทรก Json ลงไป คุณวิเคราะห์มัน จากนั้นตัวสร้างอื่นจะสร้างไฟล์อีก 30 ไฟล์ สำหรับทั้งหมดนี้ ตัวแปรอินพุตจะได้รับจาก Azure Key Vault ซึ่งถูกดึงเข้าด้วยกันโดยปลั๊กอินสำหรับ drone.io ที่เขียนด้วยภาษา Go และตัวแปรเหล่านี้ส่งผ่าน yaml ซึ่งสร้างขึ้นโดยเป็นผลมาจากการสร้างจากกลไกเทมเพลต jsonnet มันค่อนข้างยากที่จะมีโค้ดที่อธิบายไว้อย่างดีอย่างเคร่งครัด เมื่อคุณมีสภาพแวดล้อมที่หลากหลายเช่นนี้

การพัฒนาแบบเดิมๆ ภายในกรอบงานเดียวมาพร้อมกับภาษาเดียว ที่นี่เราทำงานกับภาษาจำนวนมาก

3. ปัญหาที่สามคือการปรับแต่ง. เราคุ้นเคยกับบรรณาธิการสุดเจ๋ง (Ms Visual Studio, Jetbrains Rider) ที่ทำทุกอย่างเพื่อเรา และถึงแม้เราจะโง่เขาก็จะบอกว่าเราผิด ดูเหมือนเป็นเรื่องปกติและเป็นธรรมชาติ

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

ในขณะที่เขียนนี้ ปลั๊กอิน vscode-terraform ยังไม่ได้เปิดตัวเพื่อรองรับเวอร์ชัน 0.12 แม้ว่าจะเปิดตัวมา 3 เดือนแล้วก็ตาม

ถึงเวลาที่จะลืมเรื่อง...

1. การดีบัก
2. เครื่องมือการปรับโครงสร้างใหม่
3. เสร็จสิ้นอัตโนมัติ
4. การตรวจจับข้อผิดพลาดระหว่างการคอมไพล์

ตลกดีแต่ยังเพิ่มเวลาในการพัฒนาและเพิ่มจำนวนข้อผิดพลาดที่เกิดขึ้นอย่างหลีกเลี่ยงไม่ได้

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

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

แล้วการทดสอบล่ะ?

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

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

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

การแยกวิเคราะห์ Json ใน Go เป็นเรื่องยาก และคุณต้องเขียนในภาษา Go เนื่องจาก Terraform ใน Go เป็นวิธีปฏิบัติที่ดีในการทดสอบภาษาที่คุณเขียน การจัดระเบียบโค้ดนั้นอ่อนแอมาก ในขณะเดียวกัน นี่คือไลบรารี่ที่ดีที่สุดสำหรับการทดสอบ

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

แนวทางปฏิบัติที่ดีที่สุดโครงสร้างพื้นฐานเป็นโค้ด

เดินหน้าต่อไป หากไม่มีการทดสอบใน IaC IDE และการปรับแต่งไม่ดี อย่างน้อยก็ควรมีแนวทางปฏิบัติที่ดีที่สุด ฉันเพิ่งไปที่ Google Analytics และเปรียบเทียบคำค้นหาสองคำ: แนวทางปฏิบัติที่ดีที่สุดของ Terraform และแนวทางปฏิบัติที่ดีที่สุดของ c#

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

สำหรับคำขอ IaC: ที่นี่คุณกำลังพยายามรวบรวมข้อมูลทีละนิดจากรายงาน highload หรือ HashiConf จากเอกสารอย่างเป็นทางการและปัญหามากมายใน Github โดยทั่วไปจะแจกจ่ายโมดูลเหล่านี้อย่างไร จะทำอย่างไรกับโมดูลเหล่านี้? ดูเหมือนว่านี่เป็นปัญหาที่แท้จริง... มีชุมชนสุภาพบุรุษที่มีคำถามใด ๆ คุณจะได้รับ 10 ความคิดเห็นใน Github แต่มันก็ไม่แน่

น่าเสียดายที่ ณ เวลานี้ ผู้เชี่ยวชาญเพิ่งเริ่มปรากฏตัว จนถึงตอนนี้มีน้อยเกินไป และชุมชนเองก็กำลังอยู่กันในระดับพื้นฐาน

ทั้งหมดนี้จะไปที่ไหนและจะทำอย่างไร

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

โดยส่วนตัวแล้ว ฉันเดิมพันกับบางสิ่ง:

1. การพัฒนาในพื้นที่นี้เกิดขึ้นเร็วมาก นี่คือกำหนดการคำขอสำหรับ DevOps

   
   
   หัวข้อนี้อาจเป็นเรื่องเกินจริง แต่ความจริงที่ว่าทรงกลมกำลังเติบโตนั้นให้ความหวังอยู่บ้าง

   หากบางสิ่งบางอย่างเติบโตอย่างรวดเร็ว คนฉลาดก็จะปรากฏขึ้นอย่างแน่นอนซึ่งจะบอกคุณว่าต้องทำอะไรและไม่ควรทำอะไร ความนิยมที่เพิ่มขึ้นนำไปสู่ความจริงที่ว่าในที่สุดอาจมีบางคนมีเวลาเพิ่มปลั๊กอินลงใน jsonnet สำหรับ vscode ซึ่งจะช่วยให้คุณดำเนินการใช้งานฟังก์ชันต่อไปได้ แทนที่จะค้นหาโดยใช้ ctrl+shift+f เมื่อสิ่งต่าง ๆ พัฒนาขึ้น วัสดุก็ปรากฏขึ้นมากขึ้น การเผยแพร่หนังสือเกี่ยวกับ SRE จาก Google เป็นตัวอย่างที่ดีในเรื่องนี้

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

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

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

ข้อสรุป

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

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

ที่มา: will.com