วางระบบคลาวด์และดูแลต่อเนื่อง

เลือกคลาวด์จากลักษณะงาน ไม่ใช่จากชื่อแบรนด์

GCP, Azure, AWS และ DigitalOcean ทำงานพื้นฐานได้เหมือนกันเกือบทั้งหมด สิ่งที่ต่างกันจริงคือรายละเอียดที่มีผลกับงานของคุณ เช่น องค์กรผูกอยู่กับ Microsoft 365 หรือ Google Workspace อยู่แล้วหรือไม่ ต้องการศูนย์ข้อมูลใกล้ผู้ใช้ในไทยแค่ไหน งานเป็นการประมวลผลตามรอบหรือรับทราฟฟิกตลอดเวลา ต้องใช้ GPU หรือบริการฐานข้อมูลแบบจัดการให้หรือเปล่า และทีมที่จะรับช่วงดูแลต่อคุ้นกับเครื่องมือของเจ้าไหน เราจึงไล่คำถามเหล่านี้ให้จบก่อน แล้วค่อยเลือกผู้ให้บริการ บางงานลงตัวกับเซิร์ฟเวอร์ขนาดเล็กบน DigitalOcean มากกว่าบริการแบบจัดการให้ที่ซื้อมาเผื่อโหลดซึ่งยังไม่เกิด

• เริ่มจากลักษณะงาน ทั้งปริมาณทราฟฟิก รอบการประมวลผล และความต้องการ GPU
• ดูว่าองค์กรผูกกับระบบเดิมของเจ้าไหนอยู่แล้ว เช่น Microsoft 365 หรือ Google Workspace
• พิจารณาที่ตั้งศูนย์ข้อมูลและข้อกำหนดว่าข้อมูลต้องเก็บอยู่ที่ใด
• ประเมินว่าทีมภายในจะดูแลต่อบนเครื่องมือชุดไหนได้จริง
• ใช้หลายเจ้าร่วมกันได้ ถ้าแยกงานแล้วคุ้มกว่ารวมไว้ที่เดียว

เปิดเฉพาะประตูที่จำเป็นต้องเปิด

ผังเครือข่ายคือการตัดสินใจว่าอะไรมองเห็นอะไรได้บ้าง เราวางให้ฐานข้อมูล คิวงาน และบริการภายในอยู่บนเครือข่ายส่วนตัวโดยไม่มีที่อยู่สาธารณะ แล้วเหลือทางเข้าจากอินเทอร์เน็ตทางเดียวคือ reverse proxy ที่เป็นจุดถือใบรับรอง TLS ส่วนพอร์ตบริหารระบบอย่าง SSH เปิดเฉพาะจากที่อยู่ที่ระบุไว้ ใบรับรองใช้ Let's Encrypt ต่ออายุอัตโนมัติ และต้องตรวจด้วยว่ารอบต่ออายุทำงานจริง เพราะใบรับรองหมดอายุกลางดึกคือเหตุขัดข้องที่ป้องกันได้ทั้งหมด

จุดที่พลาดกันบ่อยที่สุดคือแอปที่ผูกกับทุกอินเทอร์เฟซ ถ้าแอปฟังอยู่บนทุกอินเทอร์เฟซแทนที่จะเป็น 127.0.0.1 พอร์ตนั้นจะเข้าถึงได้จากอินเทอร์เน็ตโดยตรง ไม่ผ่าน TLS ไม่ว่า reverse proxy จะตั้งค่าไว้อย่างไรก็ตาม เราจึงผูกทุกแอปไว้กับ loopback ให้ proxy เป็นประตูเดียวจริง ๆ และใส่กฎปฏิเสธชุดเดียวกันในทุกโดเมน สำหรับหน้าเอกสาร API ที่เฟรมเวิร์กเปิดไว้ให้เองและไฟล์ที่ขึ้นต้นด้วยจุด

• ฐานข้อมูลและบริการภายในอยู่บนเครือข่ายส่วนตัว ไม่มีที่อยู่สาธารณะ
• reverse proxy เป็นทางเข้าเดียวจากอินเทอร์เน็ต และเป็นจุดที่ถือ TLS
• แอปผูกกับ 127.0.0.1 ไม่ใช่ผูกกับทุกอินเทอร์เฟซ
• SSH และพอร์ตบริหารระบบเปิดเฉพาะจากที่อยู่ที่ระบุไว้
• ใบรับรอง Let's Encrypt ต่ออายุอัตโนมัติ และหนึ่งใบครอบคลุมได้หลายชื่อโดเมน
• กฎปฏิเสธชุดเดียวกันทุกโดเมน ปิดหน้าเอกสาร API และไฟล์ที่ขึ้นต้นด้วยจุด

สำรองข้อมูลที่กู้คืนได้จริง และรู้ตัวก่อนลูกค้าโทรมา

การสำรองข้อมูลที่ไม่เคยกู้คืนคือความหวัง ไม่ใช่แผนสำรอง เราจึงตั้งรอบสำรองพร้อมระบุว่าย้อนกลับได้ไกลแค่ไหน เก็บสำเนาไว้คนละที่กับระบบต้นทาง แล้วซ้อมกู้คืนขึ้นบนเครื่องแยก เพื่อจับเวลาที่ใช้จริงและตรวจว่าข้อมูลครบ ก่อนจะเชื่อว่าใช้ได้

ฝั่งเฝ้าระวัง เราตรวจถึงระดับพอร์ตว่าบริการยังรับการเชื่อมต่อได้จริง ไม่ใช่แค่ดูว่าโปรเซสยังอยู่ เพราะโปรเซสที่ค้างก็ยังนับว่ามีชีวิตทั้งที่ไม่ตอบอะไรแล้ว นอกจากนี้ยังเฝ้าดูพื้นที่ดิสก์ หน่วยความจำ วันหมดอายุใบรับรอง และรวมบันทึกของทุกบริการไว้ที่เดียวเพื่อย้อนดูตอนเกิดเหตุ

เรื่องสิทธิ์เข้าถึง เราทำทะเบียนว่าใครถือกุญแจอะไร ใช้บัญชีรายคนแทนบัญชีกลางที่ใช้ร่วมกัน เก็บความลับไว้นอกโค้ดเสมอ และเขียนขั้นตอนถอนสิทธิ์ไว้ล่วงหน้า เพราะวันที่ต้องใช้จริงคือวันที่ไม่มีเวลานั่งคิด

• รอบสำรองข้อมูลที่ระบุได้ว่าย้อนกลับได้ไกลแค่ไหน และเก็บคนละที่กับระบบต้นทาง
• ซ้อมกู้คืนบนเครื่องแยก เพื่อรู้เวลาที่ใช้และความครบถ้วนของข้อมูล
• ตรวจสุขภาพถึงระดับพอร์ต ไม่ใช่แค่ดูว่าโปรเซสยังอยู่
• เฝ้าดูพื้นที่ดิสก์ หน่วยความจำ และวันหมดอายุใบรับรอง
• รวมบันทึกของทุกบริการไว้ที่เดียวสำหรับย้อนดูตอนเกิดเหตุ
• บัญชีรายคน ทะเบียนกุญแจ และขั้นตอนถอนสิทธิ์ที่เขียนไว้ก่อนถึงวันใช้งาน

ค่าใช้จ่ายบนคลาวด์เป็นผลของการออกแบบ ไม่ใช่ใบแจ้งหนี้ที่รอรับ

บิลคลาวด์ที่บานปลายมักไม่ได้มาจากราคาต่อหน่วย แต่มาจากการตัดสินใจตอนออกแบบ เช่น เครื่องที่เปิดค้างไว้ทั้งที่งานจริงใช้แค่ไม่กี่ชั่วโมง ค่ารับส่งข้อมูลออกที่ไม่มีใครนับ บริการแบบจัดการให้ที่ซื้อเผื่อโหลดซึ่งยังไม่เกิด และดิสก์กับสแนปช็อตที่ลืมลบ เราจึงประเมินค่าใช้จ่ายไปพร้อมกับการออกแบบสถาปัตยกรรม แยกให้เห็นว่าส่วนไหนจ่ายคงที่และส่วนไหนแปรตามการใช้งาน ติดป้ายกำกับทรัพยากรเพื่อให้สาวได้ว่าค่าใช้จ่ายแต่ละบรรทัดมาจากระบบใด แล้วตั้งงบพร้อมแจ้งเตือนเมื่อยอดวิ่งเกินแนวโน้มปกติ

เมื่อระบบนิ่งแล้ว เราส่งมอบทั้งสคริปต์ที่ใช้ติดตั้งจริง เอกสารผังระบบ และขั้นตอนที่ทีมคุณทำตามเองได้ การติดตั้งที่เป็นสคริปต์สำคัญกว่าที่หลายคนคิด เพราะขั้นตอนที่ทำด้วยมือจะเพี้ยนไปทีละนิดทุกครั้งที่ทำซ้ำ ส่วนสคริปต์ให้ผลเหมือนเดิมและอ่านย้อนได้ว่าตอนนั้นทำอะไรไปบ้าง

• ประเมินค่าใช้จ่ายไปพร้อมกับการออกแบบ ไม่ใช่หลังได้บิลใบแรก
• แยกให้เห็นว่าส่วนไหนจ่ายคงที่ ส่วนไหนแปรตามการใช้งาน
• ติดป้ายกำกับทรัพยากร เพื่อสาวได้ว่าค่าใช้จ่ายมาจากระบบใด
• ตั้งงบและการแจ้งเตือนเมื่อยอดเกินแนวโน้มปกติ
• ปิดหรือลดขนาดสิ่งที่ไม่ได้ใช้ตลอดเวลา และเก็บกวาดดิสก์กับสแนปช็อตที่ค้างไว้
• ส่งมอบด้วยสคริปต์ติดตั้ง เอกสารผังระบบ และขั้นตอนสำหรับทีมภายใน