อ่านความเห็นหลายๆคนที่ทำงานด้านแบบ Software Infrastructure ที่ไทย ว่าแบบงานด้านนี้ 1) ระบบอะไรต่างๆล่มก็ไม่มีทางรู้ว่าอะไรจะเกิดขึ้นเมื่อไหร่ 2) ถ้าเว็บไม่ล่มก็ไม่มีใครว่ารู้ว่าสำคัญยังไง 3) ทำดีก็ไม่มีใครรู้เสมอตัว แล้วรู้สึกแปลกๆ
.
คือตอนนี้นับตั้งแต่ทำงาน Infra อยู่ที่ Quora (เลขล่าสุดคือเว็บมีคนใช้เดือนละ 200 ล้านคน เป็นเว็บที่คนเข้ามาสุดอันดับ 90 ของโลกตาม Alexa Rank) [1] มาก็ 2 ปีกว่าๆละ ย้ายมาทีม Infra เพียวๆเมื่อประมาณ 4 เดือนก่อน ทีมเก่าก็ทำ backend ลึกๆซึ่งก็ใกล้เคียง Infra มากๆ ก็ไม่เห็นจะรู้สึกว่ามันจะเป็นอะไรแบบนั้นเลย
.
จริงอยู่ที่ว่างานพวกนี้มันอาจจะดูเหมือนมีดวงมาเกี่ยวข้องเยอะอยู่ เพราะมันมีปัจจัยภายนอกเช่นถ้าเรามี Server, EC2/GCP instances หรืออะไรก็ตามอยู่เยอะมากๆ มันก็ต้องมีสักอันที่อยู่ดีๆก็พังบ้าง หรือแม้กระทั้งก็อาจจะมีอะไรที่อยู่นอกเหนือการควบคุมเรามากๆไปเลยเช่น service ชาวบ้านที่เราต้องใช้พังอะไรแบบนี้ แต่คือของพวกนี้มันก็ประเมิน back of envelope calculation อะไรแบบนี้ได้อยู่ รวมถึงถ้าเราเคยมีประสบการณ์ว่าอะไรมีปัญหามาก่อนแล้วเขียน service postmortem ไว้ก็สามารถเอา incident report เก่าๆมาดูได้ว่าอะไรเกิดบ่อยแค่ไหน มีผลกระทบอะไรบ้าง คือสุดท้ายมันก็ไม่กันได้ทั้งหมดหรอก แต่คือของแบบนี้สุดท้ายมันก็วัดได้ เช่น ถ้าพังครั้งเดียวมันก็อาจจะสุดวิสัย แต่ถ้าพังบ่อยๆเรื่องเดิมๆหลายๆครั้งเนี่ย มันก็น่าจะมีทางป้องกันอะไรสักอย่างได้แหละ เพราะสุดท้ายมันก็เป็นเรื่องของ probability หรือ risk assessment ไม่ใช่ว่าจะเป็นเพราะสิ่งศักดิ์สิทธิ์ดลบัลดาลให้ server ล่มสักหน่อย
.
ส่วนเรื่องที่ว่าถ้าเว็บไม่ล่มก็ไม่มีใครรู้ว่างาน infra สำคัญยังไงนี่ก็ยิ่งแปลก เพราะการสื่อสารให้คนที่ไม่ได้ทำงานในด้าน infra ฟัง ทั้งกับ software engineers ที่ทำด้านอื่นๆ หรือแม้กระทั้งกับพวก management เองส่วนตัวก็รู้สึกว่าสำคัญมากๆ คือการที่เค้าจ้าง infrastructure engineer มาคนนึงเนี่ย เค้าก็ต้องอยากรู้อยู่แล้วมั้ยว่าเรามีประโยชน์อะไร เพราะฉะนั้นเนี่ยการมีอยู่ของทีม infrastructure ก็ควรจะมี goal มี SLAs/SLOs (Service Level Agreement/Objective) ที่ชัดเจนเช่นว่าจะทำให้ services ที่มีอยู่ reliable ขนาดไหน เร็วขนาดไหน ลดค่าใช้จ่ายลงได้ขนาดไหน maintain ง่ายขึ้นมั้ย แล้วก็ใครหรือทีมไหนต้องมีส่วนรับผิดชอบ ต่อ goal หรือ SLA อันไหนบ้าง ซึ่งถ้ามีกำหนดชัดเจนแล้วถ้าเราทำได้ตามนั้นก็คือ impact แล้วปะ แต่ถ้าไม่มี goal หรือ metrics อะไรที่สามารถสื่อสารกับคนนอกทีมได้ นี่ก็ดูน่าจะมีปัญหาแล้วนะ
.
แล้วก็คือถ้าจะทำ project อะไรสักอย่างส่วนตัวคิดว่า ROI (Return of investment) ของ project สำคัญมากๆ ทุกอย่างที่ทำต้องระบุได้ว่าทำแล้วจะช่วยบริษัทได้ยังไง มีผลต่อ high-level goals ของทีมและของบริษัทยังไง บางงานถ้าตัวเองไม่เชื่อว่ามี ROI ต่อบริษัทจริงๆ ถึง manager สั่งให้ทำปกติก็เถียงกลับไปด้วยซ้ำ หรือถ้าถึงยังไงก็ต้องทำด้วยความจำเป็นอื่นๆถ้ามีงานที่รู้สึกว่า ROI สูงกว่าก็ไปทำอันนั้นแทนก่อน ซึ่ง ROI เนี่ยก็เหมือนเดิมคือบางอย่างมันก็บอกไม่ได้ 100% หรอก อย่างเช่นในทาง infrastruture พวก realibility หรือ security อะไรพวกนี้ที่มันเป็นเรื่องของของที่เป็นความเสี่ยง (คือแบบถ้าไม่ทำก็อาจจะไม่เกิดอะไรที่ไม่ดีขึ้นก็ได้) แต่มันก็ควรคำนวนหรือคาดการได้อยู่ดีมั้ย ส่วนตัวคิดว่าถ้าทำงานแล้วไม่สามารถระบุ ROI ของของที่ทำได้เนี่ยนอนอยู่บ้านเล่นเฟสยังดีกว่า
.
สุดท้ายคือเรื่องทำดีไม่มีใครรู้ อันนี้ก็แปลก คือปกติเนี่ยถ้าเราทำอะไร แทบจะมี rule of thumb เลยว่าเราต้อง quantify หา impact ของงานให้ได้ แม้กระทั่งการหา impact นั้นอาจจะใช้เวลา 50%-100% ของเวลาที่ทำงานด้วยซ้ำ (คือใช้เวลาอีกเท่าของเวลาที่ทำงานจริงๆ) สำหรับการทำงานในองค์กรแล้วเราถือคติว่า "ทำดีไม่มีใครรู้ = ไม่ทำ" เพราะฉะนั้นยิ่งถ้าทำอะไรที่มี impact เยอะๆ ยิ่งต้องให้คนรู้มากๆ ส่งเมล์มันให้หมดทั้งทีม หรือถ้าสิ่งที่เราทำมันสำคัญจริงๆก็ส่งมันทั้งบริษัทไปเลย
.
อันนี้จะเรียกว่าการเมืองในที่ทำงานหรืออะไรก็ตามใจ แต่ลองมองมุมบริษัทดู เค้าจ้างมาทำไม แล้วเค้าจะวัดผลเรา ขึ้นเงินเดือนเรา เลื่อนขั้นเรายังไงถ้าไม่รู้ว่างานที่เราทำมีผลอะไรบ้าง เราในที่นี้คือทั้งตัวเราเอง แล้วก็ทั้งทีมของเราด้วย
.
สรุปคือจะทำอะไรไม่ว่าจะ infra, backend, frontend อะไรก็เถอะถ้ามี goal ชัดเจน สื่อสารกับชาวบ้านดีๆ ประเมินความเสี่ยงดีๆเนี่ย มันก็ควรจะสามารถคาดการณ์อะไรได้ไม่มากก็น้อย แล้วเวลาทำดีคนก็จะรู้ได้ด้วยถึงเว็บจะไม่ล่ม จบ
.
[1] แต่ทุกอย่างในโพสนี้ความเห็นส่วนตัว ไม่เกี่ยวข้องกับบริษัทแต่อย่างใด
#มิตรสหายท่านหนึ่ง
