Deploy ระบบอย่างไรไม่ให้ล่ม

Photo by rawpixel on Unsplash

สำหรับวีดีโอนี้ เราจะมาคุยกันเรื่องการ Deploy ระบบแบบให้มี High Availability คือผู้ใช้จะต้องสามารถใช้งานระบบของเราได้ตลอด และไม่ได้รับผลกระทบใดๆ เช่น ระบบช้าผิดปกติ หรือบาง Request ผิดพลาด

ส่วนแรกของวีดีโอจะคุยกันว่าระบบล่มเวลา Deploy ได้อย่างไร และส่วนที่สองจะอธิบายเรื่องการ Deploy แบบต่างๆและข้อดีข้อเสียของแต่ละแบบ

เขียนโปรแกรมไม่เป็น แต่ต้องคัดเลือกโปรแกรมเมอร์เข้าทีม

Photo by rawpixel on Unsplash

เมื่อวันก่อนมีน้องที่เป็น Project Manager โทรมาขอคำแนะนำเรื่องจะจ้างโปรแกรมเมอร์ใหม่เข้าทีม

แต่ความท้าทายคือในทีมไม่มีใครที่มีประสบการณ์เรื่องเขียนโปรแกรมเลย จะคัดเลือกคนยังไงดี

หลังจากคุยเสร็จ ก็รู้สึกว่านี่เป็นปัญหาสากลที่น่าจะมีหลายๆคนเจออยู่ แม้แต่คนที่เขียนโปรแกรมเป็น ถ้าต้องคัดเลือกคนที่ในด้านที่เราไม่มีทักษะทางด้านนั้นๆ (เช่น เขียน Frontend เป็นหลัก แต่ต้องช่วยทีมจ้าง Backend Developer หรือ Infra) เรื่องนี้ก็น่าจะยากอยู่ ยิ่งถ้านึกภาพว่าผมต้องไปสัมภาษณ์งานเพื่อคัดเลือกจ้าง Project Manager ผมเองก็คงไปไม่ถูกเหมือนกัน

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

ก็เลยเป็นที่มาของบทความนี้ครับ

มาทำความรู้จักกับ Serverless กัน

Photo by Nicolas J Leclercq on Unsplash

ช่วงสองปีที่ผ่านมา แนวคิดหนึ่งที่ผมจับตาดูอยู่คือเรื่องของ Serverless

ตามชื่อเลย Serverless คือไม่มีเซอร์เวอร์ ซึ่งจริงๆแล้วเซอร์เวอร์ก็ไม่ได้หายไปไหน เพียงแต่ทีมพัฒนาไม่ต้องสนใจมันเหมือนแต่ก่อนแล้ว

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

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

การนำ Agile มาใช้ในองค์กร

Photo by rawpixel on Unsplash

ผมรู้จักกับ Agile (อไจล์) เมื่อสิบกว่าปีที่แล้ว ตอนนั้นก็ไม่รู้หรอกว่ามันจะป๊อบขนาดนี้ สมัยนั้นอย่าพูดถึงอไจล์เลย ทีมไหนทำ Unit Testing ก็ถือว่าหรูแล้ว

ฝั่ง UK จะออกเสียงว่า อา-ไจล์, ฝั่ง US จะอ่านออกเสียว่า แอ-ไจล์ ในบทความนี้จะขอใช้ทับศัพท์ว่าอไจล์ซึ่งเป็นที่นิยมใช้กันนะครับ – https://dictionary.cambridge.org/pronunciation/english/agile

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

ผมเชื่อว่าผู้บริหารระดับสูงที่กล้าจะเลือกใช้อไจล์นั้นมีวิสัยทัศน์ที่ดี แต่เวลาปฏิบัติจริง ผมกลับเห็นว่าหลายที่ได้ผลลัพธ์เละเทะมาก สุดท้ายก็มาจบลงที่ว่าอไจล์ไม่ดี หรือไม่เหมาะกับองค์กร (ซึ่งก็อาจจะเป็นไปได้) หรือบางที่ก็เลือกที่จะซุกปัญหาไว้ใต้พรม แล้วทำ KPI ให้ดูสวยๆว่าผลลัพธ์ออกมาดี

สุดท้ายกลายเป็นตราบาปให้กับอไจล์ เป็นแผลเป็นให้กับพนักงานในบริษัท ที่ขยาดทุกครั้งที่ได้ยินคำนี้

ผมเลยอยากเขียนบทความนี้ไว้ให้ผู้บริหาร และหัวหน้าทีมพัฒนา (Technical Lead/ Team Lead) เพราะทัศนคติที่ถูกต้องต่ออไจล์จะส่งผลกระทบต่อการรับอไจล์เข้ามาในองค์กรมาก

บทความนี้จะพูดถึงข้อแนะนำ และตัวอย่างกรณีที่ดี/ไม่ดีแบบต่างๆ ในการนำอไจล์เข้ามาในองค์กร โดยผู้เขียนอนุมานว่าผู้อ่านรู้จักอไจล์และ Scrum แล้ว หากใครที่ยังไม่เข้าใจคำพวกนี้ แนะนำให้อ่านบทความอื่นก่อนครับ

วิ่งไล่ตามเทคโนโลยีไม่ทัน ทำยังไงดี

Photo by Andy Beales on Unsplash

พอโปรแกรมเมอร์มีประสบการณ์มากขึ้น ก็จะค้นพบว่าตัวเองมีสิ่งที่ยังไม่รู้มากขึ้น

ผมคิดว่าหลายๆคนก็คงคล้ายผม คือจะอยากอ่าน อยากรู้ และอยากลองไปซะทุกอย่าง

ในอดีต อาจจะทำแบบนี้ได้ เพราะเทคโนโลยีแต่ก่อนไม่ได้เติบโตเร็วแบบทุกวันนี้

ผมเองเป็นคนนึงที่พยายามตามเทคโนโลยีให้ได้มากที่สุด แต่พอถึงจุดนึงก็ต้องยอมรับ ว่าปัจจุบันเทคโนโลยีที่วิ่งเร็วกว่าเรามาก

ถ้าตามแบบไม่มีหลักอะไรเลย ตามยังไงก็ไม่ไหว