โดย Yuri Kudryavcev ที่ปรึกษาจากบริษัท Cornerstone
เมื่อไม่นานมานี้ฉันได้มีโอกาสใช้งานระบบที่มีขนาดใหญ่มากอย่าง TM1 และหนึ่งในเพื่อนร่วมงานของฉันก็ถามขึ้นมาว่า ‘เราสามารถเรียนรู้อะไรจากมันได้บ้าง?’
คำถามนี้ทำให้ฉันฉุกคิดขึ้นมาว่าแล้วฉันทำอะไรได้บ้าง และนั่นก็คือที่มาของบล็อกนี้ค่ะ
ฉันคิดว่าสิ่งที่แตกต่างในการใช้งาน TM1 สำหรับโครงการที่ต้องมีการทำงานร่วมกันมากกว่า 1-2 คนขึ้นไป คือพวกเขาไม่ต้องทุ่มเทให้กับการทำงานอย่างหนักในกระบวนการที่พัฒนาซอฟต์แวร์ แบบดั้งเดิม ไม่ต้องใช้ภาษา Visual Basic ในการเขียนโค้ด (Visual Basic for Applications, VBA) ศักยภาพต่างๆ ที่จะฉันอธิบายต่อไปนี้จะทำให้คุณเห็นว่า มันคุ้มค่าต่อการลงทุนเพื่อพัฒนาอย่างเห็นได้ชัด
มาดูกันว่ามีอะไรบ้าง:
Parallel TI Execution framework
ซึ่งเป็นที่รู้จักกันดี
TM1 ไม่ได้มีการทำงานของกระบวนการในลักษณะคู่ขนานแบบนอกกรอบ ดังนั้นคุณจำเป็นต้องดำเนินการผ่านการ RunTIs หรือ RunProcess
ฉันเคยอธิบายว่าปกติฉันใช้งานมันอย่างไรก่อนหน้านี้ แต่พอได้เห็นของ IBM เมื่อไม่นานมานี้ ก็อยากแนะนำให้คุณลองเข้าไปดูก่อนที่จะเริ่มดำเนินการ เพราะมีการอธิบายฟีเจอร์ต่างๆ ค่อนข้างครอบคลุมและสามารถทำตามได้
หวังเป็นอย่างยิ่งว่า RunProcess จะพัฒนากระบวนการให้เปลี่ยนจากวิธี “เซมาฟอร์ของไฟล์ (file semaphores)” มาเป็นวิธีแบบตรงมากขึ้น
เวอร์ชันโค้ด (Code versioning)
เวอร์ชันแบบดั้งเดิม
TM1 ยังขาดโมเดลแบบบิวท์อินของระบบจัดเก็บการเปลี่ยนแปลงที่เกิดขึ้นกับไฟล์ (version control paradigm) ซึ่งเป็นสิ่งจำเป็น ทำให้ฉันเลือกใช้ Git integration เพราะสามารถใช้จัดเตรียมวิธีการและดูแลโค้ด ‘ขั้นพื้นฐานสำหรับอุตสาหกรรม’ ได้ ในทุกวันมีคนใช้งานจำนวนหลายล้านคน เพราะ Git มีการพัฒนาของระบบนิเวศที่ดี
ฉันมักจะเห็นโฟลเดอร์พิเศษ เวอร์ชันโค้ด และคอมเมนต์แบบเก่าในรูปพื้นฐาน
สิ่งที่ฉันอยากให้มีก็คือ code editor เพราะยังไม่เห็นที่ไหนสร้างให้สามารถนำไปใช้งานได้อย่างเหมาะสม ซึ่งอาจเกิดขึ้นได้ในอนาคต สิ่งที่น่าสนใจก็คือ IBM จะขยับขยาย PaW editors เป็น ‘versioning-aware’ และหากเป็นปลั๊กอิน VSCode ได้จะดีมาก ในขณะเดียวกัน การรวมสิ่งแวดล้อมสำหรับการพัฒนาแบบเบ็ดเสร็จ (Integrated Development Environment, IDE) เข้ากับฐานผู้ใช้งานและระบบนิเวศของปลั๊กอินขนาดใหญ่ อาจเป็นการพัฒนาด้านทรัพยากรที่ไม่คุ้มค่านัก
วิธีการพัฒนาและโปรโมท
นี่เป็นปี 2020 แล้ว แต่เรายังคงใช้ไฟล์ก๊อบปี้กันอยู่
โดยมักจะเป็นการใช้สเปรดชีต Excel และสร้างโฟลเดอร์ ‘โปรโมชั่น’ ซึ่งเป็นการรีสตาร์ทเซิร์ฟเวอร์ และพัฒนาขึ้นมาเป็นระบบ ดึงจากแหล่งที่มา หยุด คัดลอก หรือสตาร์ทแบบอัตโนมัติ
ในขณะนี้ฉันยังไม่เจอเครื่องมือด้านโปรโมชั่นที่มีประสิทธิภาพดีเยี่ยม (โดยไม่ต้องรีสตาร์ท) แต่ยังฝากความหวังไว้กับ Git integration ฉันชอบ Transfer specifications ใน Performance Modeler ที่ออกมาแล้วสักพัก และได้เรียนรู้ว่ามันเป็นอย่างไร
ทดสอบความสมบูรณ์และกระบวนการอัตโนมัติ
มาถึงจุดหนึ่ง คุณต้องเริ่มแยก ‘การทดสอบ’ ออกจาก ‘การพัฒนา’ ใน TM1 อาจจะเป็นการวิเคราะห์ทางธุรกิจและการจัดทำรายงานกระทบยอด จากนั้นพัฒนาให้สามารถดำเนินการได้แบบอัตโนมัติ เพื่อเป็นการให้ไฟเขียวว่าทุกอย่างเรียบร้อยดีแล้ว การสร้างการเปรียบเทียบให้เกิดขึ้นแบบอัตโนมัตินั้นง่ายขึ้นด้วย REST API โดยคุณสามารถกำหนดกฎต่างๆ ได้ ในระบบที่มีขนาดใหญ่มากๆ ศักยภาพของคุณในการประเมินผลกระทบของการพัฒนาใหม่ๆ นั้นจะลดลงอย่างมาก ฉันเลยเลือกใช้สองระบบไปพร้อมๆ กันแบบคู่ขนานเพื่อทำการทดสอบ ทำให้สามารถรันระบบเดียวกันได้ในสองทาง (ที่มาข้อมูลและข้อมูลในคิวบ์เหมือนกัน) และแตกต่างเพียงแค่โค้ดใหม่เท่านั้น สิ่งนี้จะทำให้คุณแน่ใจได้ว่าความแตกต่างระหว่างสองระบบเป็นสิ่งที่คุณ ‘คาดว่า/พยายามที่จะจัดการ’ และไม่ใช่สิ่งแปลกใหม่ เป็นการเพิ่มความมั่นใจให้กับฉันและทำให้การสนับสนุนส่งเสริมไม่เครียดอย่างที่เคย
การตรวจสอบเซิร์ฟเวอร์และการแจ้งเดือน
เนื่องจากฐานผู้ใช้งานและเซิร์ฟเวอร์ขยายตัวขึ้นเรื่อยๆ คุณเริ่มที่จะตั้งคำถามว่า ‘ทำไม X ถึงทำงานล่าช้า’ ซึ่งก็มีหลายสาเหตุด้วยกัน คุณอาจจะดูที่ CPU / เมมโมรี่ / ดิสก์ในแต่ละครั้งก็ได้ แต่น่าจะดีกว่าถ้าคุณสามารถดูได้ผ่านบริการของ TM1 เซิร์ฟเวอร์อันหลากหลาย พร้อมทั้งกระบวนการที่เกี่ยวข้องอื่นๆ
นอกจากนี้ คุณต้องการที่จะรู้ว่าดิสก์สำหรับบันทึกใกล้เต็มเมื่อไหร่เพื่อเป็นการแจ้งเตือนด้วย
องค์กรของคุณน่าจะมีเครื่องมือที่ยอดเยี่ยมบางเครื่องมือที่ครอบคลุมการทำงานของส่วนนี้อยู่แล้ว เพียงแค่ต้องพูดคุยกับทีมโครงสร้างเพื่อค้นหาวิธีที่ดีที่สุดในการจัดตั้งขึ้นมา
หากเซิร์ฟเวอร์ของคุณอยู่บนคลาวด์ การตรวจสอบขั้นพื้นฐานก็สามารถทำได้ง่ายมาก รวมทั้งส่วนของการแจ้งเตือนก็ถูกบิวท์อินไว้เรียบร้อยแล้วด้วย
สถาปัตยกรรมด้านการกระจายคำร้องของผู้ใช้งาน (Load balancing)
เซิร์ฟเวอร์ของ TM1 ยังไม่ได้เป็นการออนไลน์ตลอดเวลา (high-availability) อย่างแท้จริง แต่เซิร์ฟเวอร์ของแอปพลิเคชันเมนูหน้าจอแสดงผลลูกค้า (client-facing) ที่มีการกระจายคำร้องของผู้ใช้งาน (load balancing) ก็คือ: Tm1web และ Planning Analytics Workspace
การวิเคราะห์ข้อมูล (Log analysis)
ฉันได้เขียนเกี่ยวกับการวิเคราะห์รายการข้อมูล (transaction log analysis) เล็กน้อยไว้ที่นี่ แต่การวิเคราะห์ข้อมูลของ tm1server.log ก็ต้องใช้ความพยายามในระดับหนึ่งหากข้อมูลค่อนข้างซับซ้อน
คำถามอย่างเช่น ‘กระบวนการอัปเดต P&L ใช้เวลานานแค่ไหนเมื่อคืนที่ผ่านมาหรือวันก่อนหน้า? เทรนด์สำหรับปีนี้เป็นอย่างไร? UAT vs การผลิตต้องใช้เวลานานแค่ไหน?’ หรือ ‘กระบวนการไหนที่เราดำเนินไปพร้อมๆ กันเมื่อคืนนี้ที่ใช้เวลานานกว่ากัน’ ซึ่งเป็นคำถามที่หาคำตอบได้ยาก โดยเฉพาะถ้าคุณต้องการเชื่อมโยงกับล็อกที่โหลดในเซิร์ฟเวอร์
ทุกคนสร้างคิวบ์ TM1 เพื่อจัดเก็บเวลา TI ที่รันตั้งแต่ต้น แต่โซลูชันนี้มีข้อจำกัดบางอย่าง (การจัดเก็บจำเป็นต้องเพิ่มขั้นตอน ‘เริ่ม/จบ’ ในกระบวนการ, เซิร์ฟเวอร์หลากหลาย, เวอร์ชวลไลเซชั่น) ที่คุณจะเริ่มเจอหลังจากที่ใช้งานไปสักพัก
ฉันหวังว่าจะมีโอกาสได้ใช้ ELK (หรืออาจจะเป็น Splunk) สักวัน เพราะการค้นหาแบบ full–text ที่รวดเร็วจะมีประโยชน์มาก รวมทั้งศักยภาพของการ ‘แจ้งเตือน’ เกี่ยวกับเทรนด์ต่างๆ ด้วย (เช่น การโหลดข้ามคืนของเราเมื่อวานนี้ใช้เวลานานกว่าค่าเฉลี่ยประมาณ 20%) ซึ่งช่วยประหยัดเวลาในการวิเคราะห์พร้อมทั้งมีชาร์ทแสดงผลอีกด้วย
การจัดการโครงแบบของเซิร์ฟเวอร์
หากคุณมีเซิร์ฟเวอร์จำนวนมากในหลายระบบ (เช่น มากกว่า 10 เครื่อง) และพบว่าการจัดการควบคุมเป็นไปได้ยาก การมองหาเครื่องมือสำหรับจัดการโครงแบบของเซิร์ฟเวอร์จะช่วยให้คุณ:
มีแหล่งที่มาเดียวสำหรับองค์ประกอบไฟล์ต่างๆ ของคุณ (tm1s.cfg, BI, tm1web configs) และทำให้แน่ใจว่าเซิร์ฟเวอร์มีการอัปเดตและเสถียร
เพื่อให้สามารถอัปเดตได้อัตโนมัติ
นี่คือสิ่งที่ทำให้ฉันยุ่งตลอด 6 เดือนที่ผ่านมา การสร้างศักยภาพจากการที่ ‘ต้องการระบบ UAT ใหม่’ หรือ ‘ต้องการแพ็คถาวรใหม่จากเซิร์ฟเวอร์เหล่านี้’ โดยไม่ทำแบบแมนนวล แต่เป็นการใช้โค้ดสำหรับโครงแบบและโครงสร้าง!
แต่เดิม บล็อกนี้ถูกโพสบน Applied Dimensionality
