Tech Talk

การวางระบบที่มีความสำคัญมากๆ มักมาพร้อมกับการวางแผนสำรองข้อมูลเป็นเรื่องปกติ แต่แผนสำรองข้อมูลส่วนมากกลับวางแผนไว้เพื่อเตรียมพร้อมกรณีฮาร์ดแวร์เสียหายเป็นหลัก เราจึงมักเห็นเซิร์ฟเวอร์แอปพลิเคชั่นต่างๆ ติดตั้งซอฟต์แวร์สำรองข้อมูลเอาไว้ เพื่อสำเนาข้อมูลไปยังที่ต่างๆ ทั้งไดร์ฟภายนอกและบริการคลาวด์ แนวทางนี้เรียกว่า push backup เป็นการส่งข้อมูลสำรองออกไปจากเครื่องหลัก ปัญหาของ push backup คือหากแอปพลิเคชั่นเซิร์ฟเวอร์ถูกแฮก หรือถูกโจมตีด้วยมัลแวร์ต่างๆ ในเซิร์ฟเวอร์มักมีรหัสผ่านหรือกุญแจสำหรับเข้าถึงเซิร์ฟเวอร์และสตอเรจต่างๆ ที่ใช้เก็บข้อมูลสำรองไปด้วย ในยุค ransomware เช่นทุกวันนี้ ตัวมัลแวร์เริ่มมีความสามารถมากขึ้นรวมถึงบางครั้งมีการทำงานร่วมกับแฮกเกอร์ที่สั่งการโดยตรง (human operated ransomware) ทำให้การทำ push backup ยังเหลือความเสี่ยงอยู่พอสมควร อีกแนวทางหนึ่งคือการทำ pull backup ที่ซอฟต์แวร์สำรองข้อมูลไปติดตั้งอยู่บนเครื่องเก็บข้อมูลสำรอง จากนั้นสร้าง user บนแอปพลิเคชั่นเซิร์ฟเวอร์เพื่อให้ซอฟต์แวร์สำรองข้อมูลสามารถเข้ามากวาดข้อมูลออกไปได้ แนวทางนี้มีข้อดีคือเราสามารถจำกัดสิทธิ์ของ user สำหรับสำรองข้อมูลให้เข้าถึงข้อมูลบนแอปพลิเคชั่นเซิร์ฟเวอร์ได้อย่างจำกัด เช่น สามารถอ่านได้อย่างเดียว ทำให้แม้เซิร์ฟเวอร์สำรองข้อมูลอาจจะถูกแฮก คนร้ายก็ไม่สามารถทำลายข้อมูลในแอปพลิเคชั่นเซิร์ฟเวอร์ได้ ซอฟต์แวร์สำรองข้อมูลจำนวนมากมีทั้งโหมด push และ pull สำหรับลินุกซ์ ผู้ดูแลระบบสามารถเขียนสคริปต์โดยใช้ rsync รวมกับ OpenSSH ได้ คำสั่งจะอยู่ในรูปแบบ rsync -avz backupagent@appserver:/localbackups/ /remotebackups/ จะเป็นการดึงข้อมูลจากแอปพลิเคชั่นเซิร์ฟเวอร์ ในโฟลเดอร์ `/localbackups` มายังเซิร์ฟเวอร์สำรองข้อมูล การออกแบบระบบสำรองข้อมูลมีความสำคัญ การออกแบบที่ดีลดความเสี่ยงกรณีต่างๆ ไปได้มาก นอกจากนั้นแล้วผู้ดูแลระบบควรพิจารณาซักซ้อมกู้คืนระบบเป็นระยะ รวมถึงอาจสำรองข้อมูลในสตอเรจที่แยกออกไปต่างหากไม่เชื่อมต่อกับเน็ตเวิร์คไว้อีกชั้น – – – โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC

ปี 2020 หากไม่เกิด COVID เสียก่อน เราอาจจะได้เห็นธีมเทคโนโลยีของปีนี้ว่าเป็นปีแห่ง Kubernetes ของโลกองค์กร ความนิยมในเทคโนโลยี Kubernetes ที่องค์กรจำนวนมากมองว่าเป็นโอกาสที่จะรวมแพลตฟอร์มที่กระจัดกระจายเข้าเป็นแพลตฟอร์มมาตรฐาน แม้จะใช้ Kubernetes หลากหลายยี่ห้อก็มีโอกาสจัดการได้ด้วยเครื่องมือชุดเดียวกัน ผู้เล่นรายใหญ่อย่าง IBM ซื้อ Red Hat แทบจะเรียกได้ว่าซื้อ OpenShift แถม Linux เพราะสิ่งที่ IBM น่าจะมองเห็นจริงๆ คือโลกองค์กรทั้งหมดในอนาคตจะย้ายโหลดงานขึ้นไปอยู่บน Kubernetes แทบทั้งสิ้น การใช้ Kubernetes ทำให้การสร้าง deploy แอปพลิเคชั่นไม่ว่าจะเป็น on-premise หรือคลาวด์ใดๆ สามารถใช้คอนฟิกชุดเดียวกันได้เสมอ ปีนี้ VMware กำลังลงมาเล่นตลาดนี้เต็มตัวด้วย Tanzu บริษัทซอฟต์แวร์สำหรับองค์กรรายใหญ่ล้วนกำลังก้าวไปยัง Kubernetes ทั้งสิ้น Elasticsearch นั้นรองรับ Elastic Cloud ตั้งแต่ปีที่แล้ว ผมเองได้ลองใช้งานแล้วก็ต้องยอมรับว่าสะดวกกว่าเซ็ตอัพเองมาก แม้กระบวนการอัพเกรดซอฟต์แวร์ที่ลองแล้วยังมีปัญหาอัพเกรดแล้วค้างไปกลางทาง คำถามคือในโลกองค์กรที่เราเห็นเริ่มใช้ Kubernetes กันเรื่อยๆ แล้วยังมีตลาดอีกมากแค่ไหน โพลล์ของ Red Hat แสดงให้เห็นโลกความเป็นจริงว่าตลาด Kubenetes เกิดการแบ่งฝั่ง ระหว่างกลุ่มผู้ใช้และกลุ่มที่ยังไม่ใช้ โลกของสตาร์ตอัพหรือองค์กรที่มีความพร้อมสูงอาจจะสามารถย้ายโหลดงานทั้งหมดขึ้นไปยัง Kubernetes ได้อย่างรวดเร็ว โดยเฉพาะองค์กรที่ย้ายโหลดไปเป็นคอนเทนเนอร์มาก่อนหน้านี้แล้ว อีกด้านองค์กรที่ยังตามไปไม่ทัน โหลดงานแทบทั้งหมดยังเป็น Virtual Machine (หรือแม้แต่เซิร์ฟเวอร์จริงๆ!) องค์กรเหล่านี้อาจจะไม่พร้อมแม้กระทั่งการย้ายโหลดงานขึ้นคลาวด์หรือการแปลงโหลดงานเป็นคอนเทนเนอร์ ยังคงเป็นตลาดที่ Kubernetes สามารถขยายตัวเข้าไปได้อีกมาก กระแสตอนนี้ค่อนข้างชัดเจนว่า Kubernetes กำลังจะกลายเป็นระบบจัดการโหลดไม่ว่าจะเป็นคอนเทนเนอร์หรือ VM ก็ตามจากการที่ OpenShift รองรับ VM เมื่อต้นปีที่ผ่านมา ความเป็นไปได้คือองค์กรที่โหลดยังเป็น VM อยู่บางองค์กร อาจจะย้ายแอปของตัวเองเข้า Kubernetes ไปเลยทีเดียว โดยใช้แนวทางว่าส่วนไหนทำเป็นคอนเทนเนอร์ได้ก็ทำ ส่วนไหนทำไม่ได้ก็ย้ายเข้า Kubernetes ไปทั้ง VM เลยทีเดียว – – – โดยวสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC

นาทีนี้หากจะมีองค์กรใดวางระบบไอที หากเป็นไปได้องค์กรเหล่านั้นมักวางระบบบนคลาวด์แทบทั้งหมด ด้วยเหตุผลสำคัญจากการลดระยะเวลาการพัฒนาบริการใหม่ๆ ที่องค์กรไม่ต้องเสียเวลาจัดซื้อเซิร์ฟเวอร์, วางโครงสร้างเน็ตเวิร์ค และการประเมินความเสี่ยงในระยะยาวอื่นๆ ที่ผ่านมาบริการคลาวด์เหล่านี้กระทบรายผู้ให้บริการวางระบบไอทีไปไม่น้อย จากเดิมที่องค์กรต่างๆ มักต้องวางระบบไอทีด้วยตัวเอง มีการจัดซื้อฮาร์ดแวร์และซอฟต์แวร์จำนวนมาก มาเป็นการซื้อสร้างเซิร์ฟเวอร์ทีละน้อยๆ และขยายตามโหลดที่จำเป็นต่อการใช้งานได้ทันที การวางระบบขนาดใหญ่ๆ เพื่อรองรับการใช้งานทีละ 3-5 ปีข้างหน้าจึงหายไปในกลุ่มองค์กรที่ใช้งานคลาวด์ไปแล้ว Naver Cloud Platform คลาวด์จากเกาหลีใต้ที่ประกาศว่าจะเข้าไทย ก็ประกาศให้บริการ On-Premise Cloud แล้ว อีกจุดสำคัญของธุรกิจคลาวด์คือการทำให้สินค้าสำหรับองค์กรกลายเป็นสินค้าสำหรับผู้บริโภคทั่วไปได้อย่างน่าทึ่ง กระบวนการ “ทำราคา” ที่ออกแบบราคาสำหรับลูกค้าแต่ละรายตามขนาดการสั่งซื้อกลายเป็นการนำเสนอราคาอย่างเปิดเผย ทุกวันนี้เราสามารถดูราคาของเซิร์ฟเวอร์ใน AWS, Azure, หรือ Google Cloud ได้ทั้งหมด ไม่ว่าจะเป็นเครื่องเริ่มต้นเดือนละร้อยกว่าบาท หรือเครื่องขนาดใหญ่เดือนละหลายแสนบาทก็ตามที การเปิดเผยราคาเช่นนี้ทำให้ผู้ให้บริการคลาวด์ทุกรายต้องทำราคาแข่งกันอย่างหนัก เมื่อผู้ให้บริการรายหนึ่งประกาศปรับราคาสินค้าตัวใดลง รายอื่นๆ ก็มักจะประกาศปรับราคาให้เท่าๆ กันภายในไม่กี่วัน ไม่นับว่าบริการเหล่านี้พยายามทำตลาดอย่างหนักด้วยการให้โควต้าใช้งานฟรีจำนวนมาก การแข่งขันกันเช่นนี้บีบให้ส่วนแบ่งของตัวแทนจำหน่ายบริการคลาวด์ทุกรายต่ำกว่าการขายสินค้า On-Premise เดิมๆ ไม่ว่าจะเป็นเซิร์ฟเวอร์, สตอเรจ, หรือระบบเน็ตเวิร์คอื่นๆ แต่องค์กรจำนวนมากก็ยังคงต้องรักษาระบบในองค์กรเอาไว้จากความจำเป็นด้านความปลอดภัย, กฎหมาย, หรือเงื่อนไขอื่นๆ ทำให้ที่ผ่านมาธุรกิจ SI ยังคงสามารถทำกำไรจากลูกค้ากลุ่มนี้ได้ แต่ในช่วงปีที่ผ่านมา ผู้ให้บริการคลาวด์หลายรายเปิดบริการคลาวด์แบบติดตั้งในศูนย์ข้อมูลขององค์กรกันมากขึ้นเรื่อยๆ โดยอาศัยชื่อเสียงและความเชี่ยวชาญที่สร้างจากการให้บริการคลาวด์ขนาดใหญ่ ออกแบบระบบขนาดเล็กลงโดยอาจจะเหลือเพียงตู้เซิร์ฟเวอร์เดียว แล้วนำไปติดตั้งในศูนย์ข้อมูลขององค์กร ที่เข้ามาทำตลาดในไทยก่อนเพื่อน เช่น Cloud@Customer ของ Oracle และตอนนี้ก็ยังมี AWS Outpost เพิ่มเริ่มเข้ามาทำตลาดในไทย แนวทางที่โลกระบบไอทีองค์กรอาจจะไม่เคยเห็นนัก คือการเปิดเผยราคาบนเว็บ แม้แต่เซิร์ฟเวอร์ตู้ละ 50 ล้านบาท คลาวด์ในองค์กรลดข้อได้เปรียบสำคัญของคลาวด์คือการเริ่มจากระบบขนาดเล็กๆ ไป การติดตั้งคลาวด์ในองค์กรทำให้มองค์กรมีภาระผูกพันว่าต้องใช้งานตามขนาดเครื่องที่ซื้อมา เช่น AWS Outpost นั้นเริ่มต้นที่ราคาประมาณ 8 ล้านบาท ขึ้นไปจนถึง 50 ล้านบาท แม้จะมีทางเลือกให้จ่ายรายเดือนได้ตลอดระยะเวลาสามปี แต่ทั้งหมดแล้วองค์กรก็ยังคงมีภาระผูกพันในการจ่ายค่าเซิร์ฟเวอรตามขนาดที่เลือกมาแล้วอยู่ดี ไม่สามารถลดขนาดได้แม้โหลดจะต่ำลงก็ตาม อย่างไรก็ดีองค์กรจำนวนมากกลับให้ความสนใจกับ On-Premise Cloud เหล่านี้ด้วยชื่อเสียงของผู้ให้บริการคลาวด์ที่สามารถรักษาเสถียรภาพของบริการได้ค่อนข้างดี อีกทั้งการใช้ On Premise Cloud เหล่านี้ยังสามารถเข้าถึงซอฟต์แวร์และบริการบางตัวแบบจ่ายเงินตามการใช้งานจริง เช่น บริการระบบฐานข้อมูลสำเร็จรูป RDS, หรือบริการ Kubernetes ทำให้แม้องค์กรจะเสียเงินค่าฮาร์ดแวร์เป็นก้อนใหญ่ แต่ค่าซอฟต์แวร์เฉพาะก็ยังจ่ายเงินตามการใช้งานจริงต่อไป ตัวอย่างเช่น Amazon EKS นั้นคิดค่าบริการ 0.1 ดอลลาร์ต่อคลัสเตอร์ต่อชั่วโมง โดยไม่ต้องซื้อไลเซนส์ราคาแพงล่วงหน้า หรือ Amazon RDS เองก็คิดค่าบริการตามขนาดเซิร์ฟเวอร์ฐานข้อมูล โดยไม่ต้องมีสัญญาการใช้งานซอฟต์แวร์ขั้นต่ำ ธุรกิจ SI กำลังพบความท้าทายจากผู้ให้บริการรายใหญ่เหล่านี้ หากทุกอย่างเป็นไปตามที่ผู้ให้บริการคลาวด์โฆษณาไว้ เซิร์ฟเวอร์เหล่านี้จะซ่อมบำรุงตรงจากผู้ให้บริการคลาวด์รายใหญ่แทบทั้งหมด การทำกำไรจากการติดตั้งฮาร์ดแวร์และซอฟต์แวร์น่าจะทำได้ลำบากขึ้นในอนาคต แม้แต่บริการซัพพอร์ต AWS Outpost เองก็บังคับขายพร้อมกับบริการ AWS Enterprise Support ของตัวเอง ธุรกิจ SI จะอยู่เดินหน้าได้อย่างไร ในยุคที่ Cloud กำลังครอบครองทุกพื้นที่แม้แต่ในศูนย์ข้อมูลลูกค้า เช่นนี้ ความเป็นไปได้อย่างหนึ่งคือการให้บริการที่ระดับสูงขึ้นไป การ Optimize โครงสร้างพื้นฐานเพื่อให้รองรับ peak load ได้ทุกช่วงเวลาอย่างแท้จริง ขณะเดียวกันก็สามารถออกแบบระบบให้ใช้งานทรัพยากรได้เต็มที่จนอาจจะลดต้นทุน กรณี On-Premise Cloud อาจจะต้องวิเคราะห์ได้ว่า

แนวทางการวางระบบไอทีในองค์กรคงมีขั้นตอนหนึ่งคือการประเมินการใช้ทรัพยากรของแอปพลิเคชันใหม่ที่เรากำลังติดตั้งว่าต้องใช้ซีพียู แรม หรือเน็ตเวิร์คมากน้อยแค่ไหน ซึ่งการประเมินให้ถูกต้องเป็นเรื่องที่แทบเป็นไปไม่ได้ องค์กรต่างๆ จึงมักมีทรัพยากรเหลือๆ ไม่ได้ใช้งานจำนวนมาก หรือแอปพลิเคชันบางส่วนทำงานแค่บางช่วงเวลาก็มักถูกกันทรัพยากรเตรียมไว้ให้ โดยที่ไม่มีแอปพลิเคชันอื่นมาใช้งานได้ การใช้งานคลาวด์ช่วยให้การจัดสรรทรัพยากรทำได้สะดวกขึ้นในช่วงหลังเนื่องจากองค์กรไม่ต้องซื้อฮาร์ดแวร์มาเตรียมการไว้ล่วงหน้า แต่สั่งใช้งานเพิ่มได้ทันทีที่ต้องการ แต่กระนั้นหากแอปพลิเคชันไม่ได้ออกแบบให้เตรียมพร้อมสำหรับการขยายตามโหลดที่ใช้งานจริง องค์กรก็มักต้องเสียค่าใช้จ่ายทรัพยากรสิ้นเปลืองไปเป็นปกติแม้จะใช้คลาวด์ก็ตาม แนวทางการพัฒนาแบบ Serverless จึงเริ่มเป็นที่น่าสนใจสำหรับองค์กรขึ้นเรื่อยๆ ในช่วงหลัง โดยแนวทางนี้คือการที่โค้ดถูกเก็บไว้บนเซิร์ฟเวอร์รอที่จะรัน โดยไม่ต้องจองทรัพยากรใดๆ ล่วงหน้า หากมีเหตุการณ์ (event) ที่เกี่ยวข้องกับโค้ดนั้น เช่น การเรียกใช้งานเว็บ ตัวโค้ดจึงถูกเรียกขึ้นมา จองแรมและซีพียู และประมวลผลข้อมูลเพื่อตอบกลับ บริการคลาวด์ส่วนมากมีบริการ Serverless ให้บริการ เช่น AWS Lambda หรือ Google Cloud Run โดยบริการเหล่านี้คิดค่าใช้งานอย่างละเอียด เช่น การใช้ซีพียูและแรมเป็นวินาที แม้ว่าราคาอาจจะดูแพงหากคิดการเปิดเซิร์ฟเวอร์ตลอดเวลา แต่หากไม่มี event เรียกใช้งานโค้ดเลยก็จะแทบไม่มีค่าใช้จ่ายใดๆ ในองค์กรเอง การใช้เฟรมเวิร์ค เช่น KNative มาสร้างบริการ Serverless ภายในองค์กรเริ่มเป็นตัวเลือกที่น่าสนใจ เพราะการที่ไม่มีแอปพลิเคชันจองทรัพยากรไว้ไม่ว่าจะใช้งานหรือไม่ ทำให้องค์กรสามารถประหยัดทรัพยากรโดยรวมลงได้ อัตราการใช้งานเซิร์ฟเวอร์คุ้มค่ามากขึ้น ข้อจำกัดของ Serverless คือแอปพลิเคชันที่มีอยู่เดิมอาจจะต้องปรับแก้เยอะหรือบางกรณีอาจจะต้องพัฒนาใหม่แต่ต้น และการใช้งานหลายครั้งก็ผูกติดกับผู้ให้บริการคลาวด์อย่างแนบแน่น อาจจะทำให้การย้ายแอปพลิเคชันออกไปยังคลาวด์อื่นทำได้ยาก นับเป็นความท้าทายในการตัดสินใจแนวทางการพัฒนาต่อไป – – –โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาลChief Technology Officer, MFEC

ภัยไซเบอร์กลายเป็นความเสี่ยงทางธุรกิจอย่างมากในช่วงหลายปีมานี้ หลายคนอาจจะคิดว่าการโจมตีไซเบอร์นั้นแฮกเกอร์ต้องสร้างโปรแกรมพิเศษมาเจาะเข้าเครือข่าย เข้าถึงข้อมูลในเซิร์ฟเวอร์ ไปจนถึงแอบดูข้อมูลทุกอย่างในเครื่องเราได้ แต่การโจมตีส่วนใหญ่แล้วมาจากการส่งเมลหลอก หรือฟิชชิ่ง (phishing) ที่ไม่จำเป็นต้องอาศัยความรู้ทางเทคนิคอะไรมากมายนัก แต่อาศัยการปรับแต่งอีเมลและสร้างเว็บให้แนบเนียน เพื่อหลอกเอาข้อมูลเท่านั้น ฟิชชิ่งสมัยก่อนนั้นมักอาศัยการส่งอีเมลหว่าน โดยปลอมตัวว่าเป็นอีเมลจากบริการยอดนิยม ไม่ว่าจะเป็นเฟซบุ๊ก, ทวิตเตอร์, อีเมลฟรี, หรือธนาคารดัง เพื่อหลอกให้ผู้ใช้ยอมใส่รหัสผ่าน และแม้แต่ OTP ที่ส่งมาทาง SMS ก็ตาม ผู้ใช้อินเทอร์เน็ตในช่วงหลายปีมานี้เริ่มปรับตัวกันมากขึ้น และผู้ใช้ก็ไม่ค่อยตกเป็นเหยื่ออีเมลฟิชชิ่งกันบ่อยนัก แต่คนร้ายก็ปรับตัวไป โดยมุ่งเป้าไปที่การส่งอีเมลปลอมอย่างเจาะจงมากยิ่งขึ้น ทำให้อีเมลหลอกมักอยู่ในรูปแบบที่น่าเชื่อถือ บางทีเป็นการพูดคุยต่อเนื่องกับบทสนทนาของตัวจริง เรียกการโจมตีแบบนี้ว่า spear phishing เปรียบกับการจับปลาแบบใช้หอกพุ่งตรงไปยังตัวปลาแทนที่จะหว่านแหไป ตัวอย่างของการโจมตี เช่น คนร้ายปลอมตัวเป็นซัพพลายเออร์ที่บริษัทซื้อสินค้าอยู่เป็นประจำ ส่งอีเมลแจ้งเรียกเก็บเงินเหมือนทุกครั้งที่ผ่านมา พร้อมกับโน้ตสั้นๆ ว่าขอเปลี่ยนหมายเลขบัญชีรับเงิน เจ้าหน้าที่ฝ่ายจัดซื้อก็อาจจะพลาดยอมโอนเงินไปยังบัญชีของคนร้ายโดยไม่รู้ตัว การปลอมตัวอาจจะใช้ข้อมูลที่หาได้โดยง่าย เช่น ชื่อของพนักงานที่ทำหน้าที่เรียกเก็บเงินแล้วสร้างอีเมลใหม่ปลอมชื่อ หรือบางครั้งอาจจะผสมกับการแฮกอีเมลพนักงานจริงแล้วใช้ส่งอีเมลหลอกเพิ่มความแนบเนียนไปอีกขั้น การโจมตีคล้ายๆ กันนี้เราอาจจะพบเรื่อยๆ เช่นการแฮกเฟซบุ๊กแล้วส่งข้อความไปยังเพื่อนของเหยื่อเพื่อขอยืมเงิน แต่การแฮกเฟซบุ๊กนั้นคนร้ายอาจจะได้เงินไปปริมาณไม่มากนัก แต่ละครั้งอาจจะหลายพันหรือหลายหมื่นบาท ในกรณี Spear Phishing กับองค์กรความเสียหายอาจจะหลายล้านบาทเลยทีเดียว การป้องกันการโจมตีเช่นนี้มีตั้งแต่มาตรการทางเทคนิค เช่น การเตือนผู้ใช้ว่ากำลังส่งข้อความหรืออีเมลหาใครอยู่ ให้แยกให้ออกอย่างชัดเจนแม้ชื่ออีเมลจะดูคล้ายกัน, ติดตั้งระบบคัดกรองและแจ้งเตือนอีเมลมุ่งร้าย ตลอดจนวางนโยบายการทำงานให้รัดกุมความเปลี่ยนแปลงบางอย่าง เช่น การเปลี่ยนเลขบัญชีจ่ายเงินออก ต้องมีการตรวจสอบข้อมูลเพิ่มเติม เป็นต้น – – –โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาลChief Technology Officer, MFEC

กระบวนการพัฒนาซอฟต์แวร์แบบเดิมๆ นั้นหากมีการควบคุมคุณภาพ เราก็มักจะรวบรวมฟีเจอร์ต่างๆ จากทีมพัฒนาเข้ามารวมกันเป็นรอบๆ แล้วส่งทีมควบคุมคุณภาพเพื่อทดสอบและหาบั๊กในโค้ดที่กำลังพัฒนาต่อไป กระบวนการเช่นนี้ทำให้โปรแกรมเมอร์อาจจะต้องรอเป็นเวลานาน กว่าจะรับรู้ว่าฟีเจอร์ที่ตัวเองพัฒนาไปนั้นไปสร้างบั๊กให้กับโครงการโดยรวมในจุดอื่นๆ หรือไม่ ทำให้แนวทาง Continuous Integration (CI) ได้รับความสนใจขึ้นมามากในช่วงหลัง แนวทาง CI คือการสร้างระบบที่รวบรวมโค้ดจากนักพัฒนาเข้ามาเป็นชุดเดียวกันอย่างต่อเนื่อง โดยไม่ปล่อยให้โค้ดที่อยู่ในมือนักพัฒนาแต่ละคนต่างกันนานเกินไป แนวทางนี้มักรวบเข้ากันกระบวนการทดสอบซอฟต์แวร์โดยอัตโนมัติ (automated test) ที่ทำให้โค้ดที่ถูกรวมเข้าไปถูกทดสอบว่าสามารถทำงานตามเงื่อนไขได้อย่างถูกต้อง ซอฟต์แวร์ CI มักเชื่อมต่อกับระบบเก็บซอร์สโค้ด เมื่อมีการส่งโค้ดเข้าโครงการ เช่น นักพัฒนาคนหนึ่งส่ง pull request เข้ามาเพื่อส่งฟีเจอร์ใหม่ ระบบจะนำโค้ดนั้นไปคอมไพล์และรันทดสอบว่าผ่านดีหรือไม่โดยอัตโนมัติ ผู้ดูแลโครงการสามารถเห็นรายงานเบื้องต้นว่าคุณภาพโค้ดยอมรับได้ ตัวซอฟต์แวร์ที่ทำงานเช่นนี้มีหลายตัวในตลาด ระบบจัดเก็บซอร์สโค้ดอย่าง GitLab นั้นมีฟีเจอร์ CI ในตัว หรือบริการคลาวด์หลายตัวก็เริ่มให้บริการ CI บ้างแล้ว เช่น Azure Pipelines หรือแพลตฟอร์ม Kubernetes อย่าง OpenShift ก็มีฟีเจอร์ OpenShift Pipelines การจัดหาซอฟต์แวร์ที่เหมาะสมก็เป็นความท้าทายอย่างหนึ่ง แต่การพัฒนาซอฟต์แวร์ที่จะใช้ประโยชน์จากแนวทาง CI ได้อาจจะต้องปรับตัวกันตั้งแต่กระบวนการออกแบบซอฟต์แวร์ที่เปิดให้สร้างระบบทดสอบอัตโนมัติได้โดยง่าย และหน้าที่ของคนในทีมที่ต้องทำงานโดยมองระบบอัตโนมัติเป็นสำคัญ – – – โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC

งาน dashboard เป็นงานที่เกิดขึ้นเสมอๆ โดยแพลตฟอร์มข้อมูลต่างๆ มักมีระบบสร้าง dashboard ที่เหมาะกับตัวเอง เช่น Kibana ที่ออกแบบมาสำหรับใช้ร่วมกับ Elasticsearch เฉพาะ แต่ซอฟต์แวร์ dashboard อย่าง Grafana สามารถเชื่อมต่อข้อมูลได้หลายแหล่ง ทำให้ใช้งานได้หลากหลาย รูปแบบของ Grafana นั้นมองฐานข้อมูลต่างๆ เป็นแหล่งข้อมูล (data source) โดยสามารถรวมเอาข้อมูลจากหลายๆ แหล่งมาแสดงในหน้าจอ dashboard เดียวกันได้ ข้อดีสำคัญของ Grafana คือการทำงานที่ค่อนข้างรวดเร็ว เมื่อเทียบกับ dashboard อย่าง Kibana การใช้งานแสดงผลทันใจกว่ามาก และมีฟีเจอร์จัดการการแจ้งเตือนที่สามารถส่งข้อความแจ้งเตือนเข้าอีเมล, Microsoft Teams หรือบริการอื่นเมื่อค่าที่ตั้งไว้เกินกำหนดได้ ฟีเจอร์เช่นนี้ dashboard หลายตัวไม่มีให้ หรือมีก็ต้องติดตั้งส่วนเสริมเอง ไปจนถึงต้องเป็นเวอร์ชั่นจ่ายเงินเพิ่มเติม แต่ Grafana นั้นใช้งานได้จากเวอร์ชั่นโอเพนซอร์สเลย ตัวซอฟต์แวร์ Grafana เป็นโอเพนซอร์ส และดูแลโดยบริษัท Grafana Labs ที่ให้บริการ Grafana Cloud และซอฟต์แวร์เวอร์ชั่นองค์กร Grafana Enterprise ไปพร้อมกัน โดยเพิ่มการซัพพอร์ตระยะยาว ทำให้องค์กรไม่ต้องเร่งอัพเดตเวอร์ชั่นให้ทันอยู่ตลอดเวลา, เพิ่มความสามารถในการจัดการผู้ใช้ที่ซับซ้อนขึ้น Grafana เพิ่งออกเวอร์ชั่น 7.0 หน้าตาสวยงามขึ้นหลายจุด ก็นับเป็นระบบ dashboard ที่น่าสนใจให้ทีมงานฝึกฝนกันไว้ – – – โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC