%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

กรกฎาคม 17, 2020	6 ความท้าทายในการย้ายระบบคลาวด์ทั่วไป 6 ความท้าทายในการย้ายระบบคลาวด์ทั่วไป ในฐานะวิศวกรซอฟต์แวร์สำหรับประสบการณ์ของลูกค้ากับ SIOS ฉันมักจะช่วย บริษัท ที่กำลังโยกย้ายสภาพแวดล้อมการจัดกลุ่มที่มีความพร้อมใช้งานสูงในสถานที่ไปยังระบบคลาวด์ การโอนย้ายระบบคลาวด์เป็นกระบวนการไม่ใช่ปลายทาง เมื่อเราดึงดูดลูกค้าที่เปลี่ยนไปใช้ระบบคลาวด์นั้นมักจะมาช้าในกระบวนการวางแผนซึ่งไม่เหมาะ แต่ไม่ผิดปกติในการย้ายระบบคลาวด์ ด้านล่างนี้คือความท้าทายในการย้ายระบบคลาวด์หกประการที่เราเห็นบ่อยเกินไป เวลา – ทำความเข้าใจว่าต้องใช้เวลานานแค่ไหนในการถ่ายโอนข้อมูลไปยังคลาวด์ ใช้เวลานานแค่ไหนในการรับข้อมูลจากสถานที่ตั้งสู่ระบบคลาวด์ มันสามารถแตกต่างกันค่อนข้างมากขึ้นอยู่กับแอปพลิเคชันประเภทข้อมูลและผู้ให้บริการคลาวด์ของคุณ รายละเอียดที่มักถูกมองข้ามอย่างหนึ่งคือเวลาที่ใช้ในการซิงค์ข้อมูลจากโหนดหลักไปยังโหนดรองและในบางกรณีไปยังไซต์การกู้คืนความเสียหาย (DR) ลูกค้าที่ไม่บัญชีเวลาในการซิงค์ซ้ำจะถูกทำให้นิ้วหัวแม่มือของพวกเขาทวีคูณในขณะที่ข้อมูลทำซ้ำ ค่าใช้จ่าย – ทำความเข้าใจกับความหมายของการถ่ายโอนข้อมูลภายในคลาวด์ การถ่ายโอนข้อมูลภายในพื้นที่คลาวด์นั้นไม่มีค่าใช้จ่าย การถ่ายโอนข้อมูลระหว่างภูมิภาคจะมีค่าใช้จ่าย โดยทั่วไปแล้วเราจะเห็นสถาปัตยกรรมที่โหนดหลักและโหนดรองตั้งอยู่ในโซนความพร้อมใช้งานแบบคลาวด์ที่แยกต่างหากภายในภูมิภาค ค่าใช้จ่ายสามารถเพิ่มขึ้นอย่างมีนัยสำคัญเมื่อมีการแนะนำไซต์ DR เนื่องจากไซต์ DR จะอยู่ในภูมิภาคอื่นเสมอ การกู้คืนความเสียหายสำหรับแอปพลิเคชันที่มีข้อมูลจำนวนมากเช่น SAP NetWeaver อาจช่วยลดต้นทุนในการทำซ้ำในภูมิภาคต่างๆ การจำลองแบบระหว่างภูมิภาค การจำลองแบบระหว่างภูมิภาคนำเสนอความท้าทายอื่น: ประเภทการจำลองแบบ การจำลองแบบอะซิงโครนัสหรือซิงโครนัสภายใน AZ ถูกกำหนดโดยข้อกำหนด RTO และ RPO ของลูกค้า ไม่ว่าจะมีขนาดของอินสแตนซ์หรือไม่การจำลองข้อมูลจะเกิดความล่าช้าเมื่อข้ามระหว่างภูมิภาค SIOS แนะนำให้จำลองแบบอะซิงโครนัสระหว่างภูมิภาคเพื่อลดผลกระทบของเวลาแฝงนั้น Concurrency Labs ให้ข้อมูลที่ชาญฉลาดเกี่ยวกับเวลาแฝงระหว่างภูมิภาค EC2 องค์ประกอบของ Cloud Configuration สามารถปรับใช้อิมเมจระบบปฏิบัติการสำเร็จรูปจากคลาวด์ ความสะดวกสบายนี้มาพร้อมกับค่าใช้จ่ายซึ่งเป็นการแนะนำปัจจัยอีกประการหนึ่งให้กับการจัดการการกำหนดค่า บริการ cloud-init ที่รวมอยู่ในอิมเมจ SuSE Enterprise Linux ที่ปรับให้เหมาะกับคลาวด์สามารถลบที่อยู่ IP เสมือนที่ผู้ใช้กำหนด ไม่มีอะไรจะหยุด PoC เหมือนที่อยู่ IP เสมือนที่หายไปทุกสองนาที! ความปลอดภัยบนคลาวด์ ขนาดของคลาวด์คอมพิวติ้งมีความปลอดภัยมากกว่าธุรกิจที่สามารถจ่ายได้ในดาต้าเซ็นเตอร์ในสถานที่ ปริมาณงานบนคลาวด์ใช้ประโยชน์จากการรักษาความปลอดภัยที่ทันสมัยโดยที่ไม่รู้ตัว ตัวอย่างเช่นโดยค่าเริ่มต้น AWS EC2 อินสแตนซ์บล็อกการรับส่งข้อมูลใด ๆ ที่ไม่ได้ส่งหรือส่งไปยังอินสแตนซ์เอง นี่เป็นคุณสมบัติที่ยอดเยี่ยมสำหรับการรักษาความปลอดภัยเครือข่ายในคลาวด์ หากระบบต้องการ Network Address Translation (NAT) มาตรการรักษาความปลอดภัยเริ่มต้นของ EC2 จะทำให้ที่อยู่ IP ล้มเหลว การปิดใช้งานการตรวจสอบต้นทาง / ปลายทางจากคอนโซลจะช่วยแก้ปัญหา ขึ้นอยู่กับความคุ้นเคยของผู้ใช้กับ AWS ซึ่งอาจใช้เวลาระหว่างการคลิกไม่กี่ครั้งเพื่อรับการสนับสนุน การทำความเข้าใจกับรายละเอียดว่าระบบโต้ตอบในสภาพแวดล้อมเป็นกุญแจสำคัญในการย้ายระบบคลาวด์ที่ประสบความสำเร็จ การทดสอบการยอมรับของผู้ใช้บนคลาวด์ (UAT) ลูกค้าที่มาจากระบบในสถานที่จะต้องได้รับการเตือนว่าทรัพยากรไม่ได้เป็นปัจจัย จำกัด อีกต่อไป ในระบบคลาวด์ระบบสามารถคัดลอกและใช้งานได้อย่างง่ายดายโดยแยกส่วนการผลิตสิ่งที่ไม่สำคัญในสถานที่ การเข้าถึงทรัพยากรไอทีตามความต้องการช่วยให้ UAT ของ HA และ DR ขยายเกิน "ปิดโหนดหลัก" เครือข่ายสามารถก่อวินาศกรรมเมล็ดสามารถตื่นตระหนกแม้ฐานข้อมูลอาจเสียหายและไม่มีสิ่งใดที่จะส่งผลกระทบต่อการผลิต! การระบุและทดสอบภาพจำลองเหล่านี้ปรับปรุงท่า HA และ DR การดำเนินการโยกย้ายคลาวด์ที่ประสบความสำเร็จนั้นจำเป็นต้องมีการป้อนข้อมูลจากผู้มีส่วนได้ส่วนเสียทั้งหมด ความพร้อมใช้งานสูงและการกู้คืนความเสียหายเป็นประเด็นหลักของภาระงานระดับองค์กรใด ๆ ไม่ว่า SIOS จะเป็นส่วนหนึ่งของระบบปัจจุบันของคุณอยู่แล้วหรือจะเป็นส่วนหนึ่งของการย้ายระบบคลาวด์ในอนาคตของคุณขอให้เรามีส่วนร่วม! -Harrison Howell วิศวกรซอฟต์แวร์สำหรับประสบการณ์ลูกค้า ทำซ้ำโดยได้รับอนุญาตจาก SIOS
กรกฎาคม 15, 2020	SIOS Protection Suite สำหรับ Linux เวอร์ชัน 9.5 มาแล้ว! SIOS Protection Suite สำหรับ Linux เวอร์ชัน 9.5 มาแล้ว! เราภูมิใจที่จะประกาศความพร้อมใช้งานของ SIOS Protection Suite สำหรับ Linux เวอร์ชัน 9.5 ผลิตภัณฑ์นี้แนะนำระบบอัตโนมัติขั้นสูงและการเฝ้าระวังการใช้งานทำให้เป็นซอฟต์แวร์การจัดกลุ่ม SAP S / 4HANA ที่ครอบคลุมและทันสมัยที่สุดในอุตสาหกรรม เรารู้ว่าการสร้างคลัสเตอร์ S / 4HANA ด้วยตนเองเป็นเรื่องยุ่งยากเพียงใดตรวจสอบให้แน่ใจว่าบริการ HANA ทั้งหมดจะล้มเหลวไปยังตำแหน่งที่เหมาะสมและเริ่มต้นในลำดับที่ถูกต้อง ชั่วโมงของการเขียนสคริปต์การทดสอบและการทำให้รุนแรงขึ้น และเดิมพันสูง การทำให้ผิดพลาดอาจหมายถึงความล้มเหลวจะไม่เกิดขึ้นหรือแย่ลง – การหยุดทำงาน, การสูญเสียข้อมูล, การโทรซ้ำซ้อนของผู้ใช้จำนวนมาก นั่นคือเหตุผลที่เราเพิ่มความพร้อมใช้งานของแอปพลิเคชันอัจฉริยะสำหรับการกำหนดค่าฐานข้อมูล SAP S / 4HANA สองโหนดที่ใช้การจำลองแบบระบบ HANA (HSR) เราได้สร้างรุ่นนี้เพื่อลดความยุ่งยากและความเสี่ยงออกจากการสร้างและจัดการคลัสเตอร์ SIOS Protection Suite v9.5 เป็นระบบอัตโนมัติและมอนิเตอร์ เริ่มต้นจากการกำหนดค่าตัวช่วยสร้างที่ใช้งานง่ายซึ่งจะตรวจสอบอินพุตของคุณจริง ไม่มีการเขียนสคริปต์ด้วยตนเอง…หรือค้นหาการกดแป้นผิดพลาดเมื่อสิ่งต่างๆไม่ถูกต้อง มันตรวจสอบกระบวนการทั้งหมดใน HANA stack จากแอปพลิเคชันไปจนถึงฮาร์ดแวร์เซิร์ฟเวอร์และเครือข่าย – ไม่ใช่แค่ตรวจสอบว่าเซิร์ฟเวอร์ทำงานเหมือนซอฟต์แวร์การทำคลัสเตอร์อื่น ๆ และแตกต่างจากโซลูชันการจัดกลุ่มอื่น ๆ ที่ก่อให้เกิดความล้มเหลวสำหรับทุกสิ่งหาก SIOS Protection Suite ตรวจพบปัญหามันจะดำเนินการกู้คืนที่เหมาะสมโดยอัตโนมัติไม่ว่าจะเป็นการเริ่มบริการใหม่เพียงแค่การกู้คืนบนโหนดที่อยู่ในบริการ ปม การพูดถึงการจัดการล้มเหลวจะช่วยให้มั่นใจได้ว่าจะมีการปรับปรุงวิธีปฏิบัติที่ดีที่สุดสำหรับ SAP โดยเฉพาะ ตัวอย่างเช่นทำให้แน่ใจว่าใน failover หรือ switchover ASCS จะไม่อยู่บนเซิร์ฟเวอร์ที่มีแอปพลิเคชันหลักหรือบนเซิร์ฟเวอร์เดียวกันกับ ERS หากการกำหนดค่าที่ขับเคลื่อนด้วยตัวช่วยสร้างนั้นไม่ง่ายพอเรายังเพิ่มคุณสมบัติการโคลนอินเตอร์เฟสบรรทัดคำสั่ง (CLI) ใหม่ที่ช่วยให้คุณปรับใช้คลัสเตอร์ SIOS ได้ง่ายๆโดยการนำเข้าคำแนะนำ CLI สำหรับการกำหนดค่า คุณยังสามารถส่งออกคำสั่ง CLI ของคลัสเตอร์ที่มีอยู่เพื่อสร้างโคลนได้ ขณะนี้ SIOS Protection Suite สำหรับ Linux คุณสามารถสร้างคลัสเตอร์ความพร้อมใช้งานสูงได้อย่างรวดเร็วและง่ายดายเพื่อปกป้องแอปพลิเคชันใด ๆ ซึ่งรวมถึง SQL Server, Oracle, SAP และ S / 4HANA จากการหยุดทำงานและภัยพิบัติ ขอทดลองใช้ฟรี ทำซ้ำโดยได้รับอนุญาตจาก SIOS
กรกฎาคม 14, 2020	แนวทางปฏิบัติที่ดีที่สุดในการตรวจสอบ EC2: การใช้ SIOS AppKeeper เพื่อปกป้อง NGINX Webservers บน Amazon EC2 แนวทางปฏิบัติที่ดีที่สุดในการตรวจสอบ EC2: การใช้ SIOS AppKeeper เพื่อปกป้อง NGINX Webservers บน Amazon EC2 NGINX เป็นเว็บเซิร์ฟเวอร์ที่สามารถทำหน้าที่เป็น load balancer, reverse proxy, เป็นต้น เมื่อรวมเข้าด้วยกัน NGINX และ Apache ให้บริการมากกว่า 50% ของปริมาณข้อมูลบนเว็บ ทุกวันนี้หลาย บริษัท กำลังเรียกใช้ NGINX Open Source หรือ NGINX Plus webservers บนสภาพแวดล้อม Amazon EC2 โดยใช้ Amazon Linux, Red Hat Linux และ Ubuntu ทุกคนยอมรับว่าเป็นวิธีปฏิบัติที่ดีที่สุดในการตรวจสอบแอปพลิเคชันเช่น NGINX บน EC2 และตอบสนองต่อความผิดปกติของระบบอย่างรวดเร็ว ผู้ใช้คาดหวังว่าจะสามารถเข้าถึงแอพพลิเคชั่นได้อย่างรวดเร็วและต่อเนื่อง ตัวเลือกปัจจุบันสำหรับการตรวจสอบเว็บเซิร์ฟเวอร์ NGINX บน Amazon EC2 บริษัท หลายแห่งกำลังปรับใช้ Amazon CloudWatch เพื่อตรวจสอบแอปพลิเคชันของพวกเขาและแม้กระทั่งการสร้างระดับอัตโนมัติโดยการพัฒนาสคริปต์หรือโดยใช้ AWS Lambda แต่การกำหนดค่า Amazon CloudWatch อย่างถูกต้องด้วยตัวชี้วัดที่กำหนดเองและการตั้งค่า Amazon Lambda ต้องใช้ความเชี่ยวชาญด้านเทคนิคจำนวนหนึ่งซึ่งอาจเกินกว่า บริษัท หลายแห่ง และมีค่าใช้จ่ายและความพยายามในการบำรุงรักษาสคริปต์ใด ๆ อีกทางเลือกหนึ่งคือการปรับใช้โซลูชันการตรวจสอบประสิทธิภาพแอปพลิเคชัน (APM) เช่นหนึ่งจาก New Relic, Dynatrace, Datadog หรือ LogicMonitor โซลูชั่นของ APM นั้นยอดเยี่ยม พวกเขาทำงานได้ดีมากในการเฝ้าดูระบบทั้งหมดของคุณและระบุสิ่งที่เกิดขึ้นและทำไม พวกเขาสร้างบันทึกที่สามารถแบ่งปันและตีความโดยทีมพัฒนาของคุณเพื่อสร้างปัญหาขึ้นใหม่และตรวจสอบให้แน่ใจว่ามันจะไม่เกิดขึ้นอีก แต่นี่คือสิ่งที่: โซลูชั่น APM ให้ข้อมูลจำนวนมากที่คุณต้องจัดเรียง (แยก "สัญญาณจากเสียงรบกวน") และพวกเขาไม่ทำอะไรเลยที่จะกู้คืนจากความล้มเหลวเมื่อเกิดขึ้น เครื่องมือ APM เป็นเพียงส่วนหนึ่งของการแก้ปัญหาเมื่อมันมาถึงการลดการหยุดทำงานสำหรับเว็บเซิร์ฟเวอร์ NGINX ของคุณ แต่บาง บริษัท ไม่มีเจ้าหน้าที่ภายในหรือเครื่องมือในการตรวจสอบสภาพแวดล้อม EC2 ด้วยตนเอง นี่คือเหตุผลที่พวกเขาเลือกที่จะ outsource งานให้กับผู้ให้บริการที่มีการจัดการ มีประโยชน์อย่างมากในการทำงานกับ MSP เพื่อจัดการสภาพแวดล้อมของคุณเช่นไม่ต้องจ้างพนักงานเพิ่มเมื่อสภาพแวดล้อมของคุณขยายออกหรือไม่ต้องฝึกอบรมทีมของคุณเกี่ยวกับเทคโนโลยีใหม่ และ MSP มีความสุขกับประสิทธิภาพเนื่องจากสามารถกระจายการลงทุนไปยังลูกค้าหลายรายได้ แต่มีข้อเสีย ในบางกรณีคุณสามารถล็อคสัญญาที่มีค่าใช้จ่ายคงที่สูงและค่าใช้จ่ายอาจเพิ่มขึ้นหากมีปัญหาและพวกเขาต้องเลื่อนระดับเพื่อจัดการกับปัญหาเหล่านั้น และคุณจะสูญเสียความต่อเนื่องระหว่างทีมที่กำลังตรวจสอบสภาพแวดล้อมและผู้รับผิดชอบในการสร้างและปรับใช้แอปพลิเคชัน ไม่ว่าคุณจะเลือกลงทุนในโซลูชั่น APM หรือให้บริการ MSP ภายนอกคุณยังต้องพิจารณาว่าคุณสามารถกู้คืนเซิร์ฟเวอร์เว็บ NGINX ของคุณได้อย่างรวดเร็วเพียงใดจากการหยุดทำงานหากเกิดขึ้นและเมื่อใด เราต้องการเสนอทางเลือกอื่น: การแก้ไขอัตโนมัติด้วย SOIS AppKeeper SIOS AppKeeper: การแก้ไขอัตโนมัติสำหรับเว็บเซิร์ฟเวอร์ NGINX บน EC2 ลูกค้าของเราหลายคนเลือกใช้ SIOS AppKeeper เพื่อปกป้องเว็บเซิร์ฟเวอร์ของ NGINX ในขณะที่พวกเขาสามารถเลือกโซลูชันแอพพลิเคชั่นการตรวจสอบประสิทธิภาพมาตรฐาน (APM) หรือโซลูชันการตรวจสอบบุคคลที่สามพวกเขาเลือกที่จะพึ่งพา AppKeeper เพื่อกู้คืนบริการโดยอัตโนมัติหรืออินสแตนซ์ EC2 ทั้งหมดหากเกิดความล้มเหลว เราจะดูที่สาเหตุบางประการและแบ่งปันวิดีโอสั้น ๆ กับคุณซึ่งแสดงให้เห็นว่า AppKeeper ทำงานกับ NGINX อย่างไร SIOS AppKeeper เป็นบริการ SaaS ที่ง่ายต่อการติดตั้งและกำหนดค่าและตรวจสอบแอปพลิเคชันใด ๆ ที่ทำงานบน Amazon EC2 เช่นเว็บเซิร์ฟเวอร์ NGINX ของคุณและบริการ "nginx", "ตัวจัดการแคช" และ "คนงาน" เมื่อตรวจพบความผิดปกติ AppKeeper จะรีสตาร์ทบริการโดยอัตโนมัติและหากไม่ได้ผลก็จะรีบูตอินสแตนซ์ทั้งหมด ไม่มีการอ่านเพิ่มเติมผ่านบันทึกที่เจ็บปวดเพื่อระบุสาเหตุของความล้มเหลวหรือเพิ่มระดับให้กับนักพัฒนาเพื่อเริ่มบริการของคุณใหม่หรือค่าธรรมเนียมจ้างที่แพง AppKeeper มีฟังก์ชั่น "set-it-and-forget-it" เพื่อให้คุณมั่นใจได้ว่า NGINX webservers ของคุณปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดในการตรวจสอบ EC2 และทำงานอย่างถูกต้องหรือจะเริ่มต้นใหม่อย่างรวดเร็วหากพบปัญหาใด ๆ ทุกวันนี้ บริษัท หลายร้อย บริษัท พึ่งพา AppKeeper เพื่อให้สภาพแวดล้อมคลาวด์ของตนทำงานต่อไป เราขอเชิญคุณให้ดูวิดีโอด่วนนี้เพื่อสาธิตวิธีที่ AppKeeper ปกป้องเว็บเซิร์ฟเวอร์ NGINX หากคุณต้องการทดลองใช้ SIOS AppKeeper ด้วยตัวคุณเองเราขอเสนอการทดลองใช้ฟรี 14 วัน เพียงคลิกที่นี่เพื่อสมัคร
กรกฎาคม 12, 2020	Amazon CloudWatch คืออะไร Amazon CloudWatch คืออะไร คุณสามารถทำอะไรกับ CloudWatch และอุปสรรคบางอย่างที่ต้องพิจารณา ด้วย AWS ที่มีส่วนแบ่งที่โดดเด่นของตลาดคลาวด์หลาย บริษัท กำลังโยกย้ายระบบในสถานที่ของพวกเขาไปยังคลาวด์กับ Amazon AWS ดังนั้นระบบที่ทำงานในสภาพแวดล้อม AWS ควรได้รับการจัดการอย่างไร ในโพสต์บล็อกนี้เราจะแนะนำคุณสมบัติของ Amazon CloudWatch ซึ่งเป็นบริการตรวจสอบโดย AWS รวมถึงความท้าทายในการติดตั้งและวิธีแก้ไขปัญหา ใช้ Amazon CloudWatch เพื่อตรวจสอบสภาพแวดล้อม AWS ของคุณอย่างใกล้ชิด เพื่อให้แน่ใจว่าคุณมีสภาพแวดล้อมคลาวด์ที่มั่นคงเป็นสิ่งสำคัญในการตรวจสอบความผิดปกติ (“ ความบกพร่องของระบบ”) ได้อย่างรวดเร็วและตอบสนองในเวลาที่เหมาะสม การตรวจสอบกลายเป็นงานที่สำคัญและจำเป็นสำหรับองค์กรใดก็ตามที่ย้ายไปยังคลาวด์ สิ่งนี้ไม่แตกต่างจากถ้าคุณจัดการแอปพลิเคชันและโครงสร้างพื้นฐานในสถานที่ ดังนั้นคุณควรตรวจสอบสภาพแวดล้อม AWS อย่างไร ทางเลือกหนึ่งคือใช้ Amazon CloudWatch ซึ่งตรวจสอบการใช้งาน CPU หน่วยความจำและดิสก์และแจ้งให้คุณทราบเมื่อเกินเกณฑ์ที่กำหนดไว้ล่วงหน้า นอกจากนี้คุณสามารถตั้งค่าการวัดของคุณเองเพื่อตรวจสอบรายการต่าง ๆ เช่นบันทึกแอปพลิเคชัน ส่วนที่ดีที่สุดเกี่ยวกับ Amazon CloudWatch คือบริการโดย AWS มีความสัมพันธ์สูงกับ Amazon EC2 และบริการ AWS อื่น ๆ ดังนั้นจึงสามารถตอบสนองต่อการทำงานส่วนขยายและการเปลี่ยนแปลงข้อกำหนดได้อย่างรวดเร็วและสามารถรองรับการปรับขนาดอัตโนมัติ AWS ซึ่งเพิ่มหรือลดทรัพยากรโดยอัตโนมัติตามโหลด Amazon CloudWatch ให้การตรวจสอบที่แม่นยำซึ่งปรับให้เหมาะสมกับสถานการณ์เฉพาะของแต่ละสภาพแวดล้อม ความท้าทายในการติดตั้ง Amazon CloudWatch ในขณะที่ Amazon CloudWatch เหมาะสมอย่างยิ่งสำหรับองค์กรที่มีวิศวกรระบบคลาวด์ที่มีประสบการณ์และทีม DevOps มีบางสิ่งที่ผู้ใช้ทั่วไปควรระวัง Amazon CloudWatch มีประสิทธิภาพสำหรับการตรวจสอบสภาพแวดล้อม AWS ขององค์กร แต่ต้องใช้ทักษะและความรู้ระดับหนึ่งเพื่อกำหนดค่าและปรับใช้ โดยเฉพาะอย่างยิ่งเมื่อคุณตั้งค่าการวัดของคุณเองกำลังตั้งค่าการแจ้งเตือนหรือคำนึงถึงการปรับขนาดอัตโนมัติความซับซ้อนที่เพิ่มขึ้น ตัวอย่างเช่นหากคุณกำลังตั้งค่าการติดตามมันเป็นเรื่องง่าย แต่ถ้าคุณกำลังตั้งค่าอีเมลการรีบูตการปรับขนาดอัตโนมัติ ฯลฯ ขึ้นอยู่กับสถานการณ์ทรัพยากรอาจเป็นเรื่องยาก หากคุณต้องการให้กระบวนการกู้คืนโดยอัตโนมัติพร้อมคำแนะนำเช่น "รีสตาร์ทเซิร์ฟเวอร์เมื่อเกิดข้อผิดพลาด" คุณต้องสร้างสถานการณ์การกู้คืนด้วยสคริปต์ AWS Lambda ที่ให้คำอธิบายโดยละเอียดเกี่ยวกับเงื่อนไขและการดำเนินการ ทีมของคุณคุ้นเคยกับ AWS Lambda อย่างไร ข้อได้เปรียบที่สำคัญของ Amazon CloudWatch คือคุณสามารถตรวจสอบสภาพแวดล้อมของคุณได้อย่างใกล้ชิด แต่เพื่อที่จะทำเช่นนั้นคุณจะต้องออกแบบล่วงหน้าอย่างถูกต้องสำหรับแต่ละระบบว่ารายการใดที่จะต้องตรวจสอบและเมื่อใด งานออกแบบเหล่านี้อาจใช้เวลานาน แน่นอนว่าระบบภารกิจสำคัญของคุณจะต้องได้รับการตรวจสอบอย่างใกล้ชิดด้วยวิธีนี้ แต่รายละเอียดและความซับซ้อนในระดับนี้ไม่เหมาะสมสำหรับทุกระบบ สำหรับบางอย่างเช่นเว็บไซต์ภายในหรือเซิร์ฟเวอร์ WordPress คุณจะต้องลดค่าใช้จ่ายในการดำเนินงานและแรงงานของคุณ ในกรณีเช่นนี้เราขอแนะนำให้คุณพิจารณาเครื่องมือที่สามารถใช้งานและจัดการได้ง่ายขึ้น SIOS AppKeeper สำหรับตรวจสอบระบบปฏิบัติการและบริการแอพพลิเคชันที่ทำงานบน AWS สำหรับแอปพลิเคชั่นที่ไม่ได้เป็นภารกิจสำคัญเราขอแนะนำ SIOS AppKeeper จาก SIOS Technology AppKeeper ง่ายต่อการติดตั้งและกำหนดค่าและตรวจสอบบริการ (กระบวนการ) ของแอปพลิเคชันที่ทำงานบนอินสแตนซ์ EC2 AppKeeper จะรีสตาร์ทบริการโดยอัตโนมัติเมื่อตรวจพบข้อผิดพลาดและรีสตาร์ทอินสแตนซ์หากจำเป็น แม้แต่ผู้ใช้ที่ย้ายไปยังคลาวด์เป็นครั้งแรกสามารถตั้งค่า AppKeeper เพื่อตรวจสอบอินสแตนซ์ของ EC2 และกู้คืนโดยอัตโนมัติโดยไม่จำเป็นต้องมีทักษะการเขียนสคริปต์ที่ซับซ้อน ด้วย AppKeeper ไม่จำเป็นต้องเลือกบริการส่วนบุคคลที่จะตรวจสอบ คุณเพียงแค่เริ่มต้นด้วยการเลือกอินสแตนซ์ EC2 ที่จะตรวจสอบและการกระทำที่คุณต้องการให้ดำเนินการโดยอัตโนมัติ คุณสามารถรับข้อมูลที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับบริการที่จะตรวจสอบและวิธีการ แต่ AppKeeper ได้รับการออกแบบให้ง่ายต่อการกำหนดค่านอกกรอบ เมื่อตรวจพบข้อผิดพลาดหรือเรียกคืนโดยอัตโนมัติบันทึกของความล้มเหลวจะถูกบันทึกและจัดเก็บเพื่อให้สามารถตรวจสอบสาเหตุของความล้มเหลวได้ในภายหลัง แทนที่จะใช้ Amazon CloudWatch เพื่อตรวจสอบทุกอย่างในสภาพแวดล้อม AWS ของคุณอย่างใกล้ชิดเราขอแนะนำให้คุณนำสินค้าคงคลังของสภาพแวดล้อมของคุณตาม SLA และข้อกำหนดการกู้คืนของคุณและใช้ SIOS AppKeeper เพื่อตรวจสอบระบบและแอพพลิเคชั่นที่คุณต้องการลดค่าใช้จ่าย คอยติดตามการโพสต์บล็อกในอนาคตที่เราจะเข้าไปดูรายละเอียดที่มากขึ้นเปรียบเทียบการตั้งค่า CloudWatch และ AppKeeper เพื่อทำหน้าที่เดียวกัน เรียนรู้เพิ่มเติมเกี่ยวกับ SIOS AppKeeper ลงทะเบียนเพื่อทดลองใช้ฟรีของ SIOS AppKeeper
กรกฎาคม 8, 2020	ระบบทดสอบ / ควบคุมคุณภาพเป็นส่วนสำคัญของความพร้อมใช้งานขององค์กร ระบบทดสอบ / ควบคุมคุณภาพเป็นส่วนสำคัญของความพร้อมใช้งานขององค์กร “ ฉันสามารถจูบคุณได้” นั่นเป็นสิ่งที่เพื่อนโพล่งบอกฉันเมื่อเกือบสามทศวรรษที่แล้วเมื่อเธอวิ่งมาหาฉัน เธอทิ้งกกสำหรับแซกโซโฟนของเธอระหว่างทางไปหนึ่งในการแข่งขันวงดนตรีที่ยิ่งใหญ่ที่สุดในภูมิภาคของเรา ฉันไม่รู้ว่าพวกเขาเป็นใคร แต่เมื่อฉันเห็นพวงของกกบนที่นั่งบนรถบัสฉันมารับพวกเขาและพาพวกเขาไปกับฉันที่บริเวณอุ่นเครื่อง สามนาทีในการอบอุ่นร่างกายของเธอรอยร้าวครั้งแรกและเธอตื่นตระหนกขณะที่เธอเอื้อมมือไปที่กระเป๋าว่างเปล่าเพื่อทดแทน เมื่อฉันส่งเสียงพึมพำที่ฉันได้พบพวกเขาเธอโพล่งออกมา“ ฉันสามารถจูบคุณในขณะนี้” ในฐานะรองประธานฝ่ายประสบการณ์ลูกค้าที่ SIOS Technology Corp. ฉันมีความสุขที่ไม่เหมือนใครและแตกต่างจากการทำงานกับลูกค้าองค์กรและคู่ค้าที่ระยะต่าง ๆ ของสเปกตรัมว่าง บางครั้งฉันมีโอกาสทำงานกับลูกค้าปลายทางสำหรับการแก้ไขปัญหาการบรรเทาและการปรับปรุง ในบางครั้งทีมของเรากำลังทำงานร่วมกับคู่ค้าและลูกค้าเพื่อออกแบบและใช้งานความพร้อมใช้งานขององค์กรเพื่อปกป้องระบบของพวกเขาจากการหยุดทำงาน ประสบการณ์ของลูกค้าเมื่อไม่นานมานี้ทำให้ฉันนึกถึงบางสิ่งที่เกิดขึ้นเมื่อเกือบ 30 ปีก่อนเมื่อเพื่อนของฉันโพล่งออกมาว่า“ ฉันสามารถจูบคุณได้” ทีมของฉันและฉันโทรหาลูกค้า การโทรเริ่มต้นด้วยความเพลิดเพลินการแนะนำและภาพรวมของสภาพแวดล้อมองค์กรของลูกค้า สามสิบนาทีในการโทร สถาปัตยกรรมของพวกเขานั้นแข็งแกร่งมีน้ำใจและมีเอกสารที่ดี ทีมของพวกเขามีความรู้เสียงและประสบการณ์ แต่จากนั้นลูกค้าแจ้งว่าเนื่องจากการประหยัดต้นทุนพวกเขาจะไม่วางแผนที่จะรักษาระบบการทดสอบ / คุณภาพโดยเฉพาะ ฉันหายใจเข้าลึก ๆ ที่จริงแล้วมันเป็นเรื่องของการหายใจออกมากขึ้นเช่นการไหลของอากาศจากหมัดหมัด ฉันเตรียมที่จะตอบ แต่ก่อนที่ฉันจะได้ยินเสียง “ สาเหตุอันดับแรกของการหยุดทำงานคือการขาดกระบวนการ” สถาปนิกตัวแทนหุ้นส่วนร้องให้เราโทร หลังจากพูดเล่นสั้น ๆ ลูกค้าตกลงที่จะบำรุงรักษาระบบทดสอบ / QA และฉันเกือบโพล่งออกมาว่า“ ฉันจะจูบคุณ!” ในแนวหน้าของการปรับใช้ระดับองค์กรจำนวนมาก (ระบบใหม่การโยกย้ายศูนย์ข้อมูลและการอัปเดตระบบ) ทีมงานของฉันในการสนับสนุนและบริการได้เห็นปัญหามากมายที่อาจถูกสื่อโดยการใช้ระบบทดสอบ / คลัสเตอร์ ระบบทดสอบ / คุณภาพเป็นส่วนที่มีค่าของกลยุทธ์ HA เพื่อหลีกเลี่ยงการหยุดทำงาน งานทั่วไปที่เกี่ยวข้องกับการบำรุงรักษาการปรับใช้องค์กรเช่นแพทช์การอัพเดตและการเปลี่ยนแปลงการกำหนดค่ามีความเสี่ยง ความเสี่ยงมหาศาล ความเสี่ยงที่ระบุโดยทั่วไปของการทดสอบในการผลิตรวมถึงปัญหาร้ายแรงและความหายนะที่อาจเกิดขึ้นหลายประการ: ข้อมูลที่เสียหายหรือไม่ถูกต้อง ข้อมูลที่มีการป้องกันรั่วไหลออกไป การรับรู้รายได้ไม่ถูกต้อง (คำสั่งยกเลิก ฯลฯ ) ระบบโอเวอร์โหลด ผลข้างเคียงที่ไม่ตั้งใจหรือผลกระทบต่อระบบการผลิตอื่น อัตราความผิดพลาดสูงที่ตั้งค่าการเตือนและหน้าคนโทร การวิเคราะห์แบบเบ้ (ช่องทางการจราจรผลการทดสอบ A / B ฯลฯ ) บันทึกการใช้งานที่ไม่ถูกต้องเต็มไปด้วยกิจกรรมสคริปต์และบอท (a) หากลูกค้าพยายามใช้การเปลี่ยนแปลงที่มีความเสี่ยงในการผลิตผลลัพธ์อาจเป็นอันตรายได้ ด้านบนของรายการด้านบนมีความเสี่ยงเพิ่มขึ้นของการหยุดทำงานการทุจริตของการติดตั้งแอปพลิเคชันและในบางกรณีความเสียหายกลับไม่ได้ พิจารณากรณีของลูกค้า X (ร้านค้า SAP Enterprise ที่มีชื่อเสียงในอุตสาหกรรมการผลิต) หลังจากอ่านประกาศสำคัญจากเว็บไซต์ที่มีชื่อเสียงแล้วผู้ดูแลระบบปฏิบัติการได้ทำการอัปเดตโหนดการผลิตของเขาไปยังการอัพเดตเคอร์เนลล่าสุดอย่างรวดเร็ว ภายในไม่กี่ชั่วโมงโหนการผลิตจะเริ่มชุดของข้อขัดข้องและเคอร์เนลที่ไม่ได้ฝึกหัด เขารีบติดตั้งเคอร์เนลที่เข้ากันไม่ได้กับการกำหนดค่าของเขา การรวมกันของชุดแอปพลิเคชันที่มีอยู่อุปกรณ์ระบบไฟล์และแพ็คเกจที่เกี่ยวข้อง สิ่งนี้ทำให้เกิดการหยุดทำงานของการผลิตและการเพิ่มระดับความสำคัญสูงไปยังผู้ขายหลายราย เมื่อแพตช์ถูกนำไปใช้กับระบบทดสอบ / QA หรือแซนด์บ็อกซ์แพตช์และการแก้ไขที่สำคัญสามารถจัดการและตรวจสอบเพื่อลดการสูญเสียประสิทธิภาพการผลิตและการหยุดทำงานที่ไม่ได้วางแผนไว้ การทดสอบแอปพลิเคชันในสภาพแวดล้อมที่คล้ายการผลิตช่วยให้คุณระบุปัญหาที่ไม่คาดคิดและแก้ไขปัญหาก่อนที่จะส่งผลกระทบต่อการดำเนินงานของคุณ การออกแบบและทดสอบก่อนการผลิตช่วยลดปัญหาการหยุดชะงักทางธุรกิจค่าใช้จ่ายปรับปรุงประสบการณ์ของลูกค้าและปกป้องแบรนด์ของคุณ การใช้ระบบทดสอบ QA เพื่อปรับปรุงความพร้อมใช้งานและกระบวนการผลิต นี่คือพื้นฐานที่ใช้ระบบทดสอบ / ควบคุมคุณภาพสามารถให้บริการสำหรับการปรับปรุงความพร้อมใช้งานและกระบวนการผลิตของคุณ สภาพแวดล้อมที่ควบคุมซึ่งคล้ายกัน (ต้องคล้ายกับการผลิตให้ใกล้เคียงที่สุด) กับสภาพแวดล้อมการผลิตให้ความสามารถในการ: ทดสอบการอัพเดตเคอร์เนลและการอัพเดทความปลอดภัย ตรวจสอบการตั้งค่าและการปรับแต่งค่า สร้างปัญหาการผลิตซ้ำและทดสอบการปรับปรุงซอฟต์แวร์และโปรแกรมแก้ไข ตรวจสอบความเข้ากันได้ของเวอร์ชันของแอปพลิเคชันและลดความเสี่ยงของการหยุดทำงานเนื่องจากการเปลี่ยนแปลงที่เข้ากันไม่ได้ จัดให้มีพื้นที่ปลอดภัยในการฝึกซ้อมและแก้ไขกิจกรรมการใช้ชีวิตการบำรุงรักษาการหยุดทำงานและอื่น ๆ ขององค์กร อบรมพนักงานใหม่และสมาชิกในทีมโดยไม่ส่งผลกระทบต่อลูกค้าองค์กร หากคุณมีสภาพแวดล้อม Test / QA สำหรับการปรับใช้ซอฟต์แวร์ความพร้อมใช้งานระดับองค์กรที่สำคัญของคุณฉันสามารถจูบคุณได้ทันที การมีสภาพแวดล้อมนี้ช่วยให้ทีมของคุณมีความสามารถ“ ในการทดสอบตรวจสอบและยืนยัน (2)” สถาปัตยกรรมความต้องการทางธุรกิจสถานการณ์ของผู้ใช้และการรวมทั่วไปกับระบบหรือชุดของระบบที่ใกล้เคียงกับสภาพแวดล้อมการผลิตมากที่สุด ทำให้เงิน แน่นอนคุณจะต้องกำหนดเวลา windows เพื่อบำรุงรักษาระบบการผลิตของคุณและทำการทดสอบกับพวกเขาเช่นกัน แต่หลังจากขั้นตอนบัฟเฟอร์ที่ปลอดภัยเสร็จสมบูรณ์ในระหว่างนั้น – Cassius Rhue, VP, ประสบการณ์ของลูกค้า —– อ้างอิง: https://opensource.com/article/19/5/dont-test-production เข้าถึง 5/4/2020 https://www.softwaretestingclass.com/system-testing-what-why-how/ เข้าถึง 5/4/2020