จากเครื่องมือภายในสู่ SaaS: ทำระบบดาวน์โหลดรายการเดินบัญชีอัตโนมัติ
เราสร้างสคริปต์ดาวน์โหลดรายการเดินบัญชี Wise ของเราโดยอัตโนมัติ งานนี้ใช้เวลาเพียงบ่ายเดียว แต่คำถามที่น่าสนใจกว่าและใช้เวลาตอบนานกว่ามากคือ เครื่องมือเดียวกันจะช่วยธุรกิจอื่นที่มีปัญหาแบบเดียวกันได้หรือไม่ และต้องทำอะไรบ้างจึงจะเปลี่ยนผ่านได้อย่างรับผิดชอบ การพัฒนาจากสคริปต์ CLI บนแล็ปท็อปของนักพัฒนาไปเป็นบริการในคอนเทนเนอร์ที่แจ้งผลทางอีเมลเผยให้เห็นการตัดสินใจที่ควรบันทึกไว้ โดยเฉพาะสำหรับทีมที่กำลังประเมินว่าจะเปลี่ยนระบบอัตโนมัติภายในเป็นผลิตภัณฑ์หรือไม่
ปัญหาเดิม
Wise มี API สำหรับเข้าถึงข้อมูลบัญชี แต่ทีมการเงินส่วนใหญ่ยังเข้าสู่เว็บไซต์เพื่อดาวน์โหลดรายการเดินบัญชี CSV ด้วยตนเองทุกสิ้นเดือน สำหรับบัญชีเดียวและสกุลเงินเดียว ใช้เวลาสองนาที แต่เมื่อมีหลายสกุลเงินและหลายบัญชี Wise ซึ่งพบได้บ่อยในธุรกิจที่รับจ่ายเงินในหลายภูมิภาค งานนี้กลายเป็นภาระประจำที่ต้องมีคนจำ ทำให้สม่ำเสมอ และจัดเก็บให้ถูกต้อง
API ของ Wise มีปลายทางที่จำเป็น คุณเรียกดูรายการโปรไฟล์ ยอดคงเหลือแยกตามสกุลเงิน และขอส่งออกรายการเดินบัญชีเป็น CSV หรือ PDF สำหรับช่วงวันที่ใดก็ได้ การยืนยันตัวตนใช้โทเคนเข้าถึงส่วนบุคคลที่สร้างจากแดชบอร์ดนักพัฒนา Wise เมื่อกำหนดขอบเขตถูกต้อง โทเคนจะอ่านข้อมูลบัญชีได้อย่างเดียว จึงเก็บและใช้งานได้โดยไม่มีความเสี่ยงในลักษณะเดียวกับโทเคนที่สั่งโอนเงินได้
รุ่นแรกของเราเป็น Python ประมาณ 80 บรรทัด อ่านข้อมูลรับรองจากตัวแปรสภาพแวดล้อม วนผ่านโปรไฟล์และยอดคงเหลือแต่ละสกุลเงิน ขอรายการของเดือนก่อนหน้า แล้วเขียนไฟล์ลงไดเรกทอรีในเครื่อง เรายังสั่งรันเอง ซึ่งเพียงพอกับความต้องการในตอนนั้น
จากสคริปต์สู่บริการที่ทำงานตามกำหนด
การเปลี่ยนจาก “สั่งรันเอง” เป็น “รันอัตโนมัติ” ทำให้ต้องรับมือกับปัญหาอีกประเภท หากสคริปต์ที่รันเองล้มเหลวโดยไม่แจ้ง เราจะรู้ทันที แต่หากสคริปต์ตามกำหนดล้มเหลวเงียบ ๆ ในวันที่หนึ่งของทุกเดือน อาจไม่มีใครสังเกตเป็นเวลาหลายเดือน ทำให้คลังรายการเดินบัญชีขาดช่วง ซึ่งเพิ่งพบในวันตรวจสอบ
เราจึงย้ายสคริปต์เข้า คอนเทนเนอร์ Docker โดยมีจุดเริ่มทำงานที่เรียบง่าย และเพิ่มสคริปต์ครอบที่ส่งอีเมลเมื่อจบงานทั้งกรณีสำเร็จและล้มเหลว อีเมลสรุปบัญชีและสกุลเงินที่ประมวลผล จำนวนไฟล์และขนาดไฟล์ หากล้มเหลวจะแนบข้อความข้อผิดพลาด การเฝ้าติดตามเพียงเท่านี้ทำให้งานที่ไม่มีคนเฝ้ายังอยู่ภายใต้การกำกับ
เราใช้ GitHub Actions จัดตารางแทน cron ในคอนเทนเนอร์ โดยใช้ schedule กับเวิร์กโฟลว์ที่รันช่วงต้นเดือน โดยตาราง cron เพียงอย่างเดียวไม่สามารถกำหนดให้รันเฉพาะวันทำการได้ จึงต้องเพิ่มการตรวจสอบวันที่ในเวิร์กโฟลว์เพื่อข้ามวันหยุดสุดสัปดาห์และวันหยุดนักขัตฤกษ์ เวิร์กโฟลว์จะดึงโค้ดจากรีโพซิทอรี สร้างอิมเมจใหม่หากเปลี่ยน รันคอนเทนเนอร์พร้อมข้อมูลลับจาก GitHub Secrets และอัปโหลดไฟล์ผลลัพธ์เป็นอาร์ติแฟกต์ที่เก็บ 90 วัน จึงมีคลังไฟล์ที่เรียกคืนได้โดยไม่ต้องพึ่งที่เก็บไฟล์ในเครื่อง
GitHub Actions มีข้อได้เปรียบที่ใช้ได้จริงเหนือ cron บนเซิร์ฟเวอร์ คือมองเห็นการทำงานได้ ประวัติเวิร์กโฟลว์แสดงการรันทุกครั้ง ระยะเวลา รหัสจบงาน และไฟล์ผลลัพธ์ที่สร้าง ส่วน cron บนเซิร์ฟเวอร์ให้บันทึกที่ถูกมองข้ามได้ง่าย และต้องพึ่งความพร้อมของเซิร์ฟเวอร์ สำหรับงานรายเดือน ประวัติการทำงานที่ตรวจสอบย้อนหลังได้พร้อมนิยามเวิร์กโฟลว์ภายใต้การควบคุมเวอร์ชัน คุ้มกับภาระเล็กน้อยในการตั้งค่าเวิร์กโฟลว์
การรองรับผู้ใช้หลายองค์กรต้องมีอะไรบ้าง
หลังรุ่นคอนเทนเนอร์ทำงานได้อย่างเชื่อถือได้หลายเดือน เพื่อนร่วมงานในธุรกิจอื่นถามว่าจะใช้ได้หรือไม่ คำถามดูเรียบง่าย: คนอื่นใช้เครื่องมือของคุณได้ไหม แต่ที่จริง “คนอื่นใช้เครื่องมือของคุณ” ครอบคลุมรูปแบบดำเนินงานหลายแบบที่มีผลตามมาต่างกันมาก
รูปแบบที่ง่ายที่สุดคือแบ่งปันรีโพซิทอรีและเอกสาร ให้ผู้อื่นรันเองบน GitHub Actions หรือ Docker ของตน โดยเราไม่ให้ความช่วยเหลือในการใช้งาน นี่คือการเผยแพร่แบบโอเพนซอร์ส ไม่ใช่ผลิตภัณฑ์ SaaS ผู้ใช้รับภาระดำเนินงานทั้งหมดเอง
ขั้นต่อมาคือเราโฮสต์เครื่องมือ แล้วให้ผู้ใช้ส่งโทเคน API ของ Wise ของตนผ่านหน้าตั้งค่า ตอนนี้เราถือข้อมูลรับรองของผู้ใช้ ซึ่งสร้างหน้าที่ด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบทันที ในลักษณะที่ต่างจากการรันระบบอัตโนมัติส่วนตัวอย่างชัดเจน ต้องตอบให้ได้ว่าเก็บข้อมูลรับรองอย่างไร ใครเข้าถึงได้ จะเกิดอะไรขึ้นหากระบบจัดเก็บถูกเจาะ และเรามีความรับผิดอย่างไรหากบัญชี Wise ของผู้ใช้ถูกเข้าถึงผ่านแพลตฟอร์มของเรา
จากนั้นยังมีการเรียกเก็บเงิน การสนับสนุน ข้อตกลงระดับบริการและภาระดูแลโครงสร้างพื้นฐานสำหรับผู้ใช้หลายราย ไม่มีเรื่องใดเป็นอุปสรรคที่แก้ไม่ได้ แต่แต่ละเรื่องต้องตัดสินใจว่าจะลงทุนด้านวิศวกรรมเท่าไร และยอมรับต้นทุนดำเนินงานประจำได้แค่ไหน
การประเมิน SaaS
เราประเมินโดยแจกแจงข้อกำหนดของรุ่นขั้นต่ำที่รองรับผู้ใช้หลายองค์กร และคำนวณต้นทุนแต่ละส่วนอย่างตรงไปตรงมา เฉพาะการจัดการข้อมูลรับรอง ทั้งการเก็บโทเคน API ของ Wise ให้ปลอดภัย การมีส่วนติดต่อผู้ใช้สำหรับจัดการโทเคน และการกำหนดสิทธิ์เพื่อป้องกันการเข้าถึงข้ามองค์กร ก็ใช้เวลาวิศวกรรมหนึ่งสัปดาห์ก่อนแตะส่วนดาวน์โหลดรายการเดินบัญชี เมื่อเพิ่มการยืนยันตัวตนผู้ใช้ การเรียกเก็บเงิน บริการส่งอีเมลที่รองรับการยกเลิกรับ และการเฝ้าติดตามงานล้มเหลวแยกตามองค์กร ก็กลายเป็นผลิตภัณฑ์ที่ต้องลงทุนต่อเนื่องเพื่อดูแลอย่างปลอดภัย
ตลาดของเครื่องมือเฉพาะทางนี้ก็มีขอบเขต ธุรกิจที่ใหญ่พอจะใส่ใจการดาวน์โหลดรายการเดินบัญชีอัตโนมัติ มักใหญ่พอที่จะมีซอฟต์แวร์บัญชีเชื่อมกับ Wise โดยตรง หรือทีมการเงินที่แก้ปัญหาด้วยวิธีของตนแล้ว ตลาดที่เข้าถึงได้จึงเป็นกลุ่มตรงกลาง คือธุรกิจที่ใหญ่พอจะรู้สึกถึงภาระ แต่ยังไม่ได้ใช้ระบบบัญชีที่เชื่อมต่อกัน
เราสรุปว่าในช่วงนี้เครื่องมือไม่เหมาะเป็น SaaS สำหรับทีมเรา รายได้ที่เป็นไปได้ไม่คุ้มการลงทุนด้านวิศวกรรมและการดำเนินงาน การเผยแพร่แบบโอเพนซอร์สตอบโจทย์โดยไม่สร้างภาระที่เรารักษาไว้ไม่ได้
สิ่งที่เก็บไว้และสิ่งที่ปรับเปลี่ยน
เครื่องมือภายในยังทำงานอยู่ เราค่อย ๆ เพิ่มการรองรับ PDF นอกเหนือจาก CSV ส่งไฟล์รายการเดินบัญชีไปยังอีเมลโดยตรงแทนการเรียกคืนจากอาร์ติแฟกต์ของเวิร์กโฟลว์ และกำหนดช่วงวันที่ได้ เพื่อสั่งรันด้วยมือสำหรับคำขอเฉพาะกิจโดยไม่เปลี่ยนงานรายเดือนตามกำหนด
เวิร์กโฟลว์ GitHub Actions กลายเป็นวิธีนำระบบขึ้นใช้งานหลัก เราอธิบายไว้ใน README ของรีโพซิทอรีอย่างละเอียดพอให้คนที่ไม่ได้แตะเครื่องมือมาหกเดือนเข้าใจว่ามันทำอะไรและใช้งานอย่างไร นี่เป็นวินัยที่ควรใช้กับระบบอัตโนมัติภายในทุกตัว: เตรียมเครื่องมือภายในเสมือนว่าจะต้องส่งต่อให้คนอื่น เพราะในที่สุดก็ต้องทำเช่นนั้น
บทเรียนที่ใช้ได้ระยะยาวที่สุดจากโครงการนี้คือช่องว่างระหว่าง “ใช้ได้สำหรับเรา” กับ “ใช้ได้สำหรับคนอื่น” เครื่องมือภายในปรับให้เข้ากับข้อจำกัดเฉพาะของคุณ ทั้งวิธีจัดการข้อมูลรับรอง แนวทางเก็บไฟล์ และโครงสร้างพื้นฐานอีเมล การทำให้เครื่องมือยืดหยุ่นพอสำหรับคนอื่นไม่ใช่แค่เพิ่มไฟล์ตั้งค่า แต่ต้องแยกสมมติฐานเหล่านี้ออกจากตัวเครื่องมือ บางสมมติฐานคุณไม่รู้ด้วยซ้ำว่ามีอยู่ จนคนอื่นลองใช้แล้วติดปัญหา