วิศวกรรมด้านความเสถียรของไซต์คืออะไร
Site reliability engineering (SRE) เป็นแนวทางปฏิบัติในการใช้เครื่องมือซอฟต์แวร์เพื่อทำให้งานโครงสร้างพื้นฐานด้านไอทีเป็นไปโดยอัตโนมัติ เช่น การจัดการระบบ และการตรวจสอบแอปพลิเคชัน องค์กรใช้ SRE เพื่อให้แน่ใจว่าแอปพลิเคชันซอฟต์แวร์ของพวกเขายังคงเชื่อถือได้ท่ามกลางการปรับปรุงบ่อยๆจากทีมพัฒนา SRE ช่วยเพิ่มความน่าเชื่อถือของระบบซอฟต์แวร์ที่ปรับขนาดได้ เนื่องจากการจัดการระบบขนาดใหญ่โดยใช้ซอฟต์แวร์มีความยั่งยืนมากกว่าการจัดการเครื่องหลายร้อยเครื่องด้วยตนเอง
เหตุใดวิศวกรรมด้านความเสถียรของไซต์จึงมีความสำคัญ
ความเสถียรของไซต์บ่งบอกถึงความเสถียรและคุณภาพของบริการที่แอปพลิเคชันนำเสนอหลังจากให้บริการแก่ผู้ใช้ปลายทางแล้ว บางครั้งการบำรุงรักษาซอฟต์แวร์จะส่งผลต่อความเสถียรของซอฟต์แวร์หากไม่พบปัญหาทางเทคนิค ตัวอย่างเช่น เมื่อผู้พัฒนาทำการเปลี่ยนแปลงนั้นอาจสร้างผลกระทบไปยังแอปพลิเคชันที่มีอยู่โดยไม่ได้ตั้งใจ และทำให้เกิดข้อขัดข้องในการใช้งานในบางกรณี
ต่อไปนี้คือข้อดีบางประการของแนวทางปฏิบัติด้านวิศวกรรมด้านความเสถียรของไซต์ (SRE)
การทำงานร่วมกันที่ดีขึ้น
SRE ช่วยปรับปรุงการทำงานร่วมกันระหว่างทีมพัฒนา และฝ่ายปฏิบัติการ นักพัฒนามักจะต้องทำการเปลี่ยนแปลงอย่างรวดเร็วในแอปพลิเคชันเพื่อปล่อยฟีเจอร์ใหม่หรือแก้ไขข้อบกพร่องที่สำคัญ ในทางกลับกัน ทีมปฏิบัติการมีเพื่อให้แน่ใจว่ามีการส่งมอบบริการที่ราบรื่น ดังนั้น ทีมปฏิบัติการจึงใช้แนวทางปฏิบัติของ SRE เพื่อติดตามทุกการอัปเดตอย่างใกล้ชิด และตอบสนองต่อปัญหาที่เกิดขึ้นจากการเปลี่ยนแปลงในทันที
ประสบการณ์ของลูกค้าที่ดียิ่งขึ้น
องค์กรใช้โมเดล SRE เพื่อให้แน่ใจว่าข้อผิดพลาดของซอฟต์แวร์จะไม่ส่งผลกระทบต่อประสบการณ์ของลูกค้า ยกตัวอย่างเช่น ทีมซอฟต์แวร์ใช้เครื่องมือ SRE เพื่อทำให้วงจรการพัฒนาซอฟต์แวร์เป็นแบบอัตโนมัติ ซึ่งจะช่วยลดข้อผิดพลาด ซึ่งหมายความว่าทีมงานสามารถจัดลำดับความสำคัญของการพัฒนาฟีเจอร์ใหม่ๆ มากกว่าการแก้ไขข้อผิดพลาด
การวางแผนการดำเนินงานที่ดีขึ้น
ทีม SRE ยอมรับว่ามีโอกาสที่ซอฟต์แวร์จะล้มเหลว ดังนั้น ทีมงานจึงวางแผนการตอบสนองต่อเหตุการณ์ที่เหมาะสม เพื่อลดผลกระทบของการหยุดทำงานที่จะมีต่อธุรกิจและผู้ใช้ปลายทาง พวกเขายังสามารถประมาณต้นทุนของการหยุดทำงานได้ดีขึ้น และเข้าใจผลกระทบของเหตุการณ์ดังกล่าวต่อการดำเนินธุรกิจ
อะไรคือหลักการสำคัญของวิศวกรรมด้านความเสถียรของไซต์
ต่อไปนี้เป็นหลักการสำคัญของวิศวกรรมด้านความเสถียรของไซต์ (SRE)
การตรวจสอบแอปพลิเคชัน
ทีม SRE ยอมรับว่าข้อผิดพลาดเป็นส่วนหนึ่งของกระบวนการปรับใช้ซอฟต์แวร์ แทนที่จะพยายามหาโซลูชันที่สมบูรณ์แบบ พวกเขาตรวจสอบประสิทธิภาพของซอฟต์แวร์ในแง่ของสัญญาในระดับการให้บริการ (SLA) ตัวชี้วัดระดับการให้บริการ (SLIs) และวัตถุประสงค์ระดับการให้บริการ (SLOs) พวกเขาสังเกตและตรวจสอบตัวชี้วัดประสิทธิภาพการทำงานหลังจากปรับใช้แอปพลิเคชันในสภาพแวดล้อมการผลิต
การดำเนินการเปลี่ยนแปลงอย่างค่อยเป็นค่อยไป
แนวทางปฏิบัติของ SRE สนับสนุนให้มีการเปิดตัวการเปลี่ยนแปลงเล็กน้อยแต่บ่อยครั้ง เพื่อรักษาความเสถียรของระบบ เครื่องมือการทำงานอัตโนมัติ SRE ใช้กระบวนการที่สอดคล้องกัน แต่ทำซ้ำได้เพื่อดำเนินการต่อไปนี้
- ลดความเสี่ยงอันเนื่องมาจากการเปลี่ยนแปลง
- ให้ลูปฟึดแบ็กเพื่อวัดประสิทธิภาพของระบบ
- เพิ่มความเร็วและประสิทธิภาพของการดำเนินการเปลี่ยนแปลง
ระบบอัตโนมัติเพื่อการปรับปรุงความเสถียร
SRE ใช้นโยบายและกระบวนการที่ฝังหลักการความเสถียรในทุกขั้นตอนของขั้นตอนการส่งมอบ กลยุทธ์บางอย่างที่แก้ไขปัญหาโดยอัตโนมัติ ได้แก่
- การพัฒนาเส้นทางสู่คุณภาพตามวัตถุประสงค์ระดับบริการเพื่อตรวจจับปัญหาก่อนหน้านี้
- การทดสอบการสร้างแบบอัตโนมัติโดยใช้ตัวชี้วัดระดับการให้บริการ
- การตัดสินใจทางสถาปัตยกรรมเพื่อให้แน่ใจว่าระบบมีความยืดหยุ่นในช่วงเริ่มต้นของการพัฒนาซอฟต์แวร์
การสังเกตการณ์ในวิศวกรรมด้านความเสถียรของไซต์คืออะไร
การสังเกตการณ์เป็นกระบวนการที่เตรียมความพร้อมทีมงานซอฟต์แวร์สำหรับความไม่แน่นอนเมื่อซอฟต์แวร์เผยแพร่ไปสู่ผู้ใช้ปลายทาง ทีมวิศวกรด้านความเสถียรของไซต์ (SRE) ใช้เครื่องมือในการตรวจหาพฤติกรรมที่ผิดปกติในซอฟต์แวร์ และที่สำคัญไปกว่านั้นคือ การรวบรวมข้อมูลที่ช่วยให้นักพัฒนาเข้าใจถึงสาเหตุของปัญหา การสังเกตการณ์เกี่ยวข้องกับการเก็บรวบรวมข้อมูลต่อไปนี้ด้วยเครื่องมือ SRE
ตัววัด
ตัววัดเป็นค่าเชิงปริมาณที่สะท้อนให้เห็นถึงประสิทธิภาพการทำงานของแอปพลิเคชันหรือความสมบูรณ์ของระบบ ทีม SRE ใช้ตัววัดเพื่อตรวจสอบว่าซอฟต์แวร์สิ้นเปลืองทรัพยากรมากเกินไปหรือทำงานผิดปกติหรือไม่
ข้อมูลบันทึก
ซอฟต์แวร์ SRE จะสร้างข้อมูลที่มีเวลากำกับโดยละเอียดซึ่งเรียกว่าข้อมูลบันทึกเพื่อตอบสนองต่อเหตุการณ์ที่เฉพาะเจาะจง วิศวกรซอฟต์แวร์ใช้ข้อมูลบันทึกเพื่อทำความเข้าใจห่วงโซ่ของเหตุการณ์ที่นำไปสู่ปัญหาเฉพาะ
การตามรอย
การตามรอยเป็นการสังเกตเส้นทางโค้ดของฟังก์ชันเฉพาะในระบบแบบกระจาย ตัวอย่างเช่น การตรวจสอบตะกร้าสินค้าอาจเกี่ยวข้องกับสิ่งต่อไปนี้
- การเทียบราคากับฐานข้อมูล
- การตรวจสอบสิทธิ์ด้วยเกตเวย์การชำระเงิน
- การส่งคำสั่งซื้อไปยังผู้ขาย
การตามรอยของ ID ชื่อ และเวลา ช่วยให้นักพัฒนาซอฟต์แวร์ตรวจพบปัญหาเกี่ยวกับเวลาแฝง และปรับปรุงประสิทธิภาพของซอฟต์แวร์
การตรวจสอบในวิศวกรรมด้านความเสถียรของไซต์คืออะไร
การตรวจสอบเป็นกระบวนการของการสังเกตตัวชี้วัดที่กำหนดไว้ล่วงหน้าในแอปพลิเคชัน นักพัฒนาตัดสินใจว่าพารามิเตอร์ใดมีความสำคัญในการพิจารณาความสมบูรณ์ของแอปพลิเคชันและทำการตั้งค่าในเครื่องมือตรวจสอบ ทีมวิศวกรด้านความเสถียรของไซต์ (SRE) รวบรวมข้อมูลสำคัญที่สะท้อนถึงประสิทธิภาพของระบบและแสดงเป็นภาพในแผนภูมิ
ใน SRE ทีมซอฟต์แวร์จะตรวจสอบตัววัดเหล่านี้เพื่อรับข้อมูลเชิงลึกเกี่ยวกับความเสถียรของระบบ
เวลาแฝง
เวลาแฝงเป็นตัวบอกถึงความล่าช้าของแอปพลิเคชันในการตอบสนองต่อคำขอ ตัวอย่างเช่น การส่งแบบฟอร์มบนเว็บไซต์จะใช้เวลา 3 วินาที ก่อนที่จะนำผู้ใช้ไปยังหน้าเว็บตอบรับ
การรับส่งข้อมูล
การรับส่งข้อมูลจะวัดจำนวนผู้ใช้ที่เข้าถึงบริการของคุณพร้อมๆ กัน เป็นตัวช่วยทีมซอฟต์แวร์ในการคำนวณงบประมาณทรัพยากร เพื่อรักษาระดับการบริการที่น่าพอใจสำหรับผู้ใช้ทั้งหมด
ข้อผิดพลาด
ข้อผิดพลาดเป็นเงื่อนไขที่แอปพลิเคชันไม่สามารถดำเนินการหรือส่งมอบได้ตามความคาดหวัง ตัวอย่างเช่น เมื่อเว็บเพจไม่สามารถโหลด หรือทำธุรกรรมไม่ผ่าน ทีม SRE จะใช้เครื่องมือซอฟต์แวร์เพื่อติดตาม และตอบสนองต่อข้อผิดพลาดในแอปพลิเคชันโดยอัตโนมัติ
ความอิ่มตัว
ความอิ่มตัวบ่งบอกถึงความจุแบบเรียลไทม์ของแอปพลิเคชัน ความอิ่มตัวในระดับสูงมักจะส่งผลให้ประสิทธิภาพลดลง วิศวกรด้านความเสถียรของไซต์จะตรวจสอบระดับความอิ่มตัวและตรวจสอบให้แน่ใจว่าต่ำกว่าเกณฑ์ที่กำหนด
ตัววัดสำคัญสำหรับวิศวกรรมด้านความเสถียรของไซต์คืออะไร
ทีมวิศวกรด้านความเสถียรของไซต์ (SRE) วัดคุณภาพของการส่งมอบบริการและความเสถียรโดยใช้ตัวชี้วัดต่อไปนี้
วัตถุประสงค์ของระดับการให้บริการ
วัตถุประสงค์ของระดับการบริการ (SLO) เป็นเป้าหมายเฉพาะเจาะจงและวัดผลได้ ซึ่งทำให้คุณมั่นใจว่าซอฟต์แวร์สามารถบรรลุผลได้ในราคาที่สมเหตุสมผลเมื่อเทียบกับตัวชี้วัดอื่นๆ เช่น:
- เวลาพร้อมให้บริการ หรือเวลาที่ระบบกำลังทำงาน
- อัตราการโอนถ่ายข้อมูลของระบบ
- เอาต์พุตระบบ
- อัตราการดาวน์โหลดหรือความเร็วที่แอปพลิเคชันโหลด
SLO ยืนยันการจัดส่งผ่านทางซอฟต์แวร์ให้กับลูกค้า ตัวอย่างเช่น คุณตั้งค่าเวลา SLO พร้อมให้บริการไว้ที่ 99.95% สำหรับแอปจัดส่งอาหารของบริษัทของคุณ
ตัวชี้วัดระดับการให้บริการ
ตัวชี้วัดระดับการให้บริการ (SLI) คือการวัดที่แท้จริงของตัวชี้วัดที่ SLO กำหนด ในสถานการณ์จริงคุณอาจได้รับค่าที่ตรงหรือแตกต่างจาก SLO ตัวอย่างเช่น แอปพลิเคชันของคุณขึ้นว่าใช้งาน 99.92% ของเวลาทั้งหมด ซึ่งต่ำกว่าค่า SLO
สัญญาในระดับการให้บริการ
สัญญาในระดับการให้บริการ (SLA) เป็นเอกสารทางกฎหมายที่ระบุว่าจะเกิดอะไรขึ้นเมื่อไม่ตรงตาม SLO ตั้งแต่หนึ่งรายการขึ้นไป ตัวอย่างเช่น SLA ระบุว่าทีมเทคนิคจะแก้ไขปัญหาของลูกค้าของคุณภายใน 24 ชั่วโมงหลังจากได้รับรายงาน หากทีมของคุณไม่สามารถแก้ไขปัญหาได้ภายในระยะเวลาที่กำหนด คุณอาจต้องคืนเงินให้กับลูกค้า
งบประมาณผิดพลาด
งบประมาณผิดพลาด คือ ความคลาดเคลื่อนที่ยินยอมให้ไม่ปฏิบัติตาม SLO ได้ ตัวอย่างเช่น เวลาทำงาน 99.95% ใน SLO หมายความว่า การหยุดทำงานที่ได้รับอนุญาตคือ 0.05% หากการหยุดทำงานของซอฟต์แวร์เกินงบประมาณข้อผิดพลาด ทีมซอฟต์แวร์จะทุ่มเททรัพยากรและความเอาใจใส่ทั้งหมด ในการทำให้แอปพลิเคชันมีเสถียรภาพ
วิศวกรรมด้านความเสถียรของไซต์ทำงานอย่างไร
วิศวกรรมด้านความเสถียรของไซต์ (SRE) เกี่ยวข้องกับการมีส่วนร่วมของวิศวกรความเสถียรของไซต์ในทีมซอฟต์แวร์ ทีม SRE กำหนดตัวชี้วัดที่สำคัญสำหรับ SRE และตั้งงบประมาณผิดพลาดโดยพิจารณาจากระดับการยอมรับความเสี่ยงของระบบ หากจำนวนข้อผิดพลาดน้อย ทีมพัฒนาสามารถเผยแพร่ฟีเจอร์ใหม่ได้ อย่างไรก็ตาม หากข้อผิดพลาดเกินงบประมาณผิดพลาดที่ได้รับอนุญาต ทีมงานจะระงับการเปลี่ยนแปลงและแก้ไขปัญหาที่มีอยู่ก่อน
ตัวอย่างเช่น วิศวกรด้านความเสถียรของไซต์ใช้บริการเพื่อตรวจสอบตัวชี้วัดประสิทธิภาพและตรวจจับพฤติกรรมของแอปพลิเคชันที่ผิดปกติ หากมีปัญหากับแอปพลิเคชัน ทีม SRE จะส่งรายงานไปยังทีมวิศวกรซอฟต์แวร์ นักพัฒนาแก้ไขกรณีที่มีการรายงานเข้ามา และเผยแพร่แอปพลิเคชันที่ปรับปรุงแล้ว
DevOps
DevOps เป็นวัฒนธรรมซอฟต์แวร์ที่ทำลายเงื่อนไขเดิมๆ ของทีมพัฒนาและทีมปฏิบัติการ ด้วย DevOps นักพัฒนาและวิศวกรปฏิบัติการจะไม่ทำงานในไซโลอีกต่อไป แต่พวกเขาใช้เครื่องมือซอฟต์แวร์เพื่อปรับปรุงการทำงานร่วมกันและติดตามความก้าวหน้าอย่างรวดเร็วของการเผยแพร่การอัปเดตซอฟต์แวร์
SRE เมื่อเทียบกับ DevOps
SRE คือการนำ DevOps ไปปฏิบัติจริง DevOps เป็นรากฐานแนวคิดของสิ่งที่ต้องทำเพื่อรักษาคุณภาพของซอฟต์แวร์ ท่ามกลางระยะเวลาการพัฒนาที่สั้นลงเรื่อยๆ วิศวกรรมด้านความเสถียรของไซต์ให้คำตอบในการบรรลุความสำเร็จของ DevOps SRE ช่วยให้มั่นใจได้ว่าทีม DevOps จะสร้างความสมดุลระหว่างความเร็วและความเสถียร
อะไรคือความรับผิดชอบของวิศวกรด้านความเสถียรของไซต์
วิศวกรด้านความเสถียรของไซต์เป็นผู้เชี่ยวชาญด้านไอทีที่ใช้เครื่องมืออัตโนมัติในการตรวจสอบและสังเกตความเสถียรของซอฟต์แวร์ในสภาพแวดล้อมการผลิต พวกเขายังมีประสบการณ์ในการค้นหาปัญหาในซอฟต์แวร์ และการเขียนโค้ดเพื่อแก้ปัญหา พวกเขามักจะเป็นอดีตผู้ดูแลระบบ หรือวิศวกรปฏิบัติการที่มีทักษะการเขียนโค้ดที่ดี ต่อไปนี้คือความรับผิดชอบด้านความเสถียรของไซต์
การปฏิบัติการ
วิศวกรความเสถียรของไซต์ใช้เวลาถึงครึ่งหนึ่งของเวลาในการดำเนินงาน ซึ่งรวมถึงงานต่างๆ ดังต่อไปนี้
- การตอบสนองต่อเหตุการณ์ฉุกเฉิน
- การจัดการการเปลี่ยนแปลง
- การจัดการโครงสร้างพื้นฐานด้านไอที
วิศวกรใช้เครื่องมือ SRE เพื่อทำงานการทำงานหลายอย่างเป็นไปโดยอัตโนมัติและเพิ่มประสิทธิภาพของทีม
การรองรับระบบ
วิศวกรด้านความเสถียรของไซต์ทำงานอย่างใกล้ชิดกับทีมพัฒนาเพื่อสร้างฟีเจอร์ใหม่และทำให้ระบบการผลิตมีความเสถียร พวกเขาสร้างกระบวนการ SRE สำหรับทีมงานซอฟต์แวร์ทั้งหมด และพร้อมที่จะให้การช่วยเหลือเกี่ยวกับปัญหาที่จะเกิดขึ้น ที่สำคัญกว่านั้น ทีมงานด้านความเสถียรของไซต์จัดทำเอกสารขั้นตอนการปฏิบัติงานให้กับฝ่ายสนับสนุนลูกค้า เพื่อช่วยให้พวกเขาจัดการกับข้อร้องเรียนได้อย่างมีประสิทธิภาพ
การปรับปรุงกระบวนการ
วิศวกรด้านความเสถียรของไซต์ปรับปรุงวงจรชีวิตการพัฒนาซอฟต์แวร์โดยจัดให้มีการตรวจสอบหลังเกิดเหตุการณ์ ทีม SRE จัดทำเอกสารเกี่ยวกับปัญหาซอฟต์แวร์ทั้งหมดและวิธีการแก้ปัญหาที่เกี่ยวข้อง เพื่อเป็นฐานความรู้ที่ใช้ร่วมกัน ซึ่งจะช่วยให้ทีมงานซอฟต์แวร์สามารถตอบสนองต่อปัญหาที่คล้ายคลึงกันได้อย่างมีประสิทธิภาพในอนาคต
อะไรคือเครื่องมือทั่วไปของวิศวกรรมด้านความเสถียรของไซต์
ทีมวิศวกรด้านความเสถียรของไซต์ (SRE) ใช้เครื่องมือประเภทต่างๆ เพื่ออำนวยความสะดวกในการตรวจสอบ การสังเกตการณ์ และการตอบสนองต่อเหตุการณ์ที่เกิดขึ้น
เครื่องมือควบคุมระบบคอนเทนเนอร์
นักพัฒนาซอฟต์แวร์ใช้เครื่องมือควบคุมระบบคอนเทนเนอร์เพื่อเรียกใช้แอปพลิเคชันที่มีคอนเทนเนอร์บนแพลตฟอร์มต่างๆ แอปพลิเคชันที่มีคอนเทนเนอร์จัดเก็บไฟล์โค้ดและทรัพยากรที่เกี่ยวข้องไว้ในแพ็กเกจเดียวที่เรียกว่าคอนเทนเนอร์ ตัวอย่างเช่น วิศวกรซอฟต์แวร์ใช้ Amazon Elastic Kubernetes Service (Amazon EKS) เพื่อเรียกใช้และปรับขนาดแอปพลิเคชันคลาวด์
เครื่องมือการจัดการแบบ On-call
เครื่องมือการจัดการแบบ On-call เป็นซอฟต์แวร์ที่ช่วยให้ทีม SRE สามารถวางแผน จัดเรียง และจัดการบุคลากรฝ่ายสนับสนุนที่จัดการกับปัญหาซอฟต์แวร์ที่ได้รับรายงาน ทีม SRE ใช้ซอฟต์แวร์เพื่อให้แน่ใจว่ามีทีมสนับสนุนอยู่ในสถานะสแตนด์บายเพื่อรับการแจ้งเตือนเกี่ยวกับปัญหาซอฟต์แวร์อย่างทันท่วงที
เครื่องมือการตอบสนองต่อเหตุการณ์
เครื่องมือตอบสนองต่อเหตุการณ์ช่วยให้มั่นใจถึงเส้นทางการส่งต่อที่ชัดเจนสำหรับปัญหาซอฟต์แวร์ที่ตรวจพบ ทีม SRE ใช้เครื่องมือการตอบสนองต่อเหตุการณ์ในการจัดหมวดหมู่ความรุนแรงของแต่ละกรณีที่มีการรายงานและจัดการโดยทันที เครื่องมือนี้ยังสามารถจัดทำรายงานการวิเคราะห์หลังเหตุการณ์เพื่อป้องกันไม่ให้ปัญหาที่คล้ายกันเกิดขึ้นอีก
เครื่องมือจัดการการกำหนดค่า
เครื่องมือจัดการการกำหนดค่าเป็นซอฟต์แวร์ที่ทำให้เวิร์กโฟลว์ของซอฟต์แวร์เป็นไปโดยอัตโนมัติ ทีม SRE ใช้เครื่องมือเหล่านี้เพื่อลบงานที่ต้องทำซ้ำๆ เพื่อให้งานมีประสิทธิภาพมากขึ้น ตัวอย่างเช่น วิศวกรด้านความเสถียรของไซต์ใช้ AWS OpsWorks เพื่อตั้งค่าและจัดการเซิร์ฟเวอร์บนสภาพแวดล้อมของ AWS โดยอัตโนมัติ
AWS ช่วยงานวิศวกรรมด้านความเสถียรของไซต์ได้อย่างไร
บริการ AWS Management and Governance มีเครื่องมือที่จำเป็นสำหรับทีมซอฟต์แวร์ในการสร้าง ปรับขนาด และปรับใช้แอปพลิเคชันแบบกระจายโดยไม่กระทบต่อความเสถียรของระบบ ทีมกระบวนการสร้างความเสถียรของไซต์ (SRE) ใช้บริการ AWS Management and Governance ที่หลากหลายเพื่อตรวจสอบและควบคุม AWS และทรัพยากรการประมวลผลในองค์กร
- แค็ตตาล็อกบริการของ AWS ช่วยให้ทีม SRE จัดทำรายการ จัดการ และปรับใช้บริการด้านไอทีได้อย่างรวดเร็ว
- AWS Systems Manager ให้ศูนย์กลางการจัดการแบบรวมศูนย์สำหรับวิศวกรด้านความเสถียรของไซต์ เพื่อรับข้อมูลเชิงลึกด้านการปฏิบัติงานเกี่ยวกับทรัพยากรการประมวลผลซอฟต์แวร์
- AWS Proton เป็นเครื่องมือการจัดการอัตโนมัติสำหรับการปรับใช้แอปพลิเคชันแบบคอนเทนเนอร์และแบบไม่ต้องใช้เซิร์ฟเวอร์
เริ่มต้นใช้งานวิศวกรรมด้านความเสถียรของไซต์บน AWS ด้วยการสร้างบัญชี AWS วันนี้
ขั้นตอนต่อไปบน AWS
เริ่มต้นสร้างด้วยวิศวกรรมความเสถียรของเว็บไซต์บนคอนโซลการจัดการของ AWS