ปีที่ผ่านมาความรับผิดชอบหนึ่งของผมใน MFEC คือการดู centralized log ทั้งบริษัท โดยทั่วไปการใช้ ELK (Elasticsearch + Logstash + Kibana) ก็เป็นแนวทางมาตรฐาน แม้จะทำงานได้ดีแต่ก็มีส่วนที่ไม่ชอบหลายอย่าง เช่น

• ผมไม่เคยอัพเกรด Elasticsearch สำเร็จเลย หลังๆ เลยยอมลง cluster ใหม่แล้วชี้ Logstash ออกไปที่ใหม่ชัวร์กว่ามาก
• ภาษา query ค่อนข้างเฉพาะตัว คนไม่เคยใช้งงแน่นอน
• ทั้ง Stack เป็น Java กินแรมเริ่มต้นค่อนข้างสูง
• จากปัญหากินแรม ใน edge จริงๆ ฝั่ง ELK เลยมักใช้ filebeat ไปกวาดข้อมูลขึ้น logstash แต่จะเจอว่า filebeat มันจำกัดมาก process อะไรกับ log แทบไม่ได้เลย

ผมเองเห็น fluentd มาพักใหญ่ๆ แล้วได้ลองมาพักหนึ่งแต่ไม่เคยเอาขึ้น production จริงจัง พอดีมีโปรเจคใหม่กำลังขึ้นเลยจะขอลอง พออ่านไปอ่านมาก็เจอว่า fluentbit มันเล็กกว่า แม้จะมีฟีเจอร์น้อยกว่า fluentd มาก แต่รวมๆ ก็ถือว่าเยอะกว่า filebeat อยู่ดี (มี stream processor ด้วยซ้ำไป)

จุดสำคัญคือ PostgreSQL นั้นมีคนเข้าใจมันเยอะกว่า Elasticsearch มาก งาน operation ทั่วๆ ไป การ query ข้อมูล, backup, restore, upgrade นั้นมักมีคนได้เป็นเรื่องปกติ ส่วนจุดขายของ ELK จะเป็นการทำงานกับข้อมูลแบบไม่มี schema ที่เหมาะกับ log มากกว่า แต่ PostgreSQL เองก็รองรับข้อมูลแบบ JSON/JSONB มาตั้งแต่เวอร์ชั่น 9.4

fluentbit รองรับ postgesql ในตัว โดยตารางที่เขียนข้อมูลมีแค่ 3 column คือ time, tag, data แล้วใส่ตัว data ไว้เป็น JSONB

พอลองเล่นแล้วพบว่าเวิร์คกว่าที่คิด จุดประหลาดที่สุดคงเป็น Grafana ที่คุมให้กราฟมันออกอย่างที่อยากได้ยากกว่า ELK แม้ ELK จะ alien กว่าตอนเริ่มต้น แต่พอทำงานจริงๆ แล้วจะพบว่ามันคิดอะไรให้เยอะแล้ว พวกกด drill down ข้อมูล ELK ทำได้ดีกว่ามากกดเงื่อนไขเพิ่มจากในกราฟได้เลย นับเป็นข้อได้เปรียบของการใช้ UI ที่ผูกกับ data source เดียว

ในแง่ประสิทธิภาพผมยังไม่ได้ทดสอบเองแต่เจอว่า Postgres เสียเปรียบเรื่องการกินพื้นที่ดิสก์มาก แต่ประสิทธิภาพการคิวรีดีกว่า InfluxDB ไว้มีเวลาแล้วค่อยเอา data ชุดเดียวกันมาเทียบอีกที (ยังหา benchmark เทียบกับ elasticsearch ไม่เจอ)

The Net หนังที่ได้ดูตั้งแต่สมัยเด็กๆ และจำได้ว่ามันเท่มาก พอกลับมาบน Netflix เลยนั่งดูดีๆ อีกรอบ ทำให้เห็นว่าเนื้อเรื่องหลักของมันคือซอฟต์แวร์รักษาความปลอดภัยที่ชื่อว่า Gatekeeper ตอนเด็กๆ ดูแล้วไม่เข้าใจอะไร แค่รู้สึกว่ามันพิมพ์ๆ เจาะๆ แล้วเท่

ตัว Gatekeeper เองถ้ามองสมัยนี้มันคงเป็น WAF (Web Application Firewall) ที่ช่วยดูแลไม่ให้เว็บโตนเจาะ แต่ตัวมันดันวาง backdoor ให้คนรู้รหัสพิเศษเข้าไปได้

ในโลกยุคกูเกิล (และ shodan) การวางลิงก์พิเศษไว้มุมจอดูไร้สาระ แต่ข้อจำกัดของหนัง จะให้บอกว่าต้องเข้าผ่าน curl -X POST https://host/gatekeeper_backdoor/ แบบนั้นคงยากเกินไป (ยกเว้นหนังที่ใช้ฉากแฮกประกอบสั้นๆ เช่น The Matrix)

จุดที่ไม่สมจริงมากๆ คืออยู่ๆ คนทั่วไปก็เชื่อในบริษัทซอฟต์แวร์รักษาความปลอดภัยบริษัทหนึ่งขึ้นมาพร้อมกันไปทั้งหมด ทนายตอนคุยกับนางเอกยังเชื่อว่าระบบโดนแฮกไม่ได้เพราะลงซอฟต์แวร์ตัวนี้ โลกความเป็นจริงคนทั่วไปแทบไม่สนใจหรอกว่าใช้ซอฟต์แวร์ตัวไหนยังไง มีแต่ CIO/CISO ที่นั่งคิดนั่งดูกันเอง

โลกความเป็นจริงการวางซอฟต์แวร์ Security ก็ไม่ได้สมบูรณ์ หลายครั้งไฟร์วอลล์เองก้มีช่องโหว่จนแฮกเกอร์ใช้เป็นจุดรันโค้ดโจมตีในองค์กรเรื่อยๆ

ชีวิตนี้ไป MOSCONE CENTER มาแล้ว กลับไปดูในหนังอีกทีแล้วรู้สึกเจ๋งมาก ที่เราสมัยเด็กๆ ได้แต่มองงานคอนเฟอร์เรนซ์ระดับโลกแค่ไหนหนัง แล้วถึงเวลามีโอกาสได้ไป

คิดว่าควรเขียนถึงแอป Contact Tracing สักที หลังจากตอนนี้ค่อนข้างชัดแล้วว่า “ไทยชนะ” กำลังกลายเป็นบริการมาตรฐานสำหรับทุกที่ หลังจากที่ก่อนนี้มีโครงการแข่งกันทั้ง หมอชนะ, Thai.Care, และไทยชนะเอง (ที่จริงมีกลุ่มยิบย่อยอีกมาก แต่คงไม่พูดถึง)

หมอชนะเป็นตัวแรกที่เปิดตัวใหญ่โต แม้จะบอกว่าเป็น Contact Tracing บอกว่าให้คะแนนไม่เกินสีส้มหรืออะไรก็ตาม แต่ต้องพูดให้ชัดว่าแอปหมอชนะเป็น Social Scoring พยายามบอกว่าใครเสี่ยงหรือไม่เสี่ยงโดยเอาแนวคิดจากจีนเป็นหลัก โดยส่วนตัวแล้วยินดีที่หมอชนะไม่ถูกเลือกมาใช้งานจากการกวาดข้อมูลผู้ใช้ที่มากเกินไป ในแง่ของฟีเจอร์ Contact Tracing แล้วหมอชนะกวาดข้อมูลจำนวนมาก ทั้ง location, การเข้าใกล้กัน, รวมไปถึงรูปภาพ (ทีมงานบอกว่าไม่แน่ใจว่าแค่ไหนถึงพอ) ในแง่เทคนิคแล้วการทำ Contact Tracing ของหมอชนะเปิดให้มีการติดตามตัวผู้ใช้จาก third party ได้

ไทยชนะดูแล้วมีแนวทางออกแบบให้ “พอๆ” กับ logbook ตามหน้าร้าน แนวคิดคล้ายกัน และกระบวนการตรวจสอบก็ไม่ต่างกันมาก คือไม่ตรวจสอบอะไรเลยนอกจาก “ลงชื่อ” แล้ว ข้อดีคือลงเบอร์คนอื่นได้ ลดความยุ่งยากในหลายกรณี เช่น เบอร์กลางของบ้าน แม้จะไม่ได้ตั้งใจปิดบังตัวตน แต่การใช้หมายเลขโทรศัพท์อื่นได้ก็ลดความเสี่ยงไปมาก ผมเองก็ใช้เบอร์ที่ “ตามตัว” ได้ แต่ไม่ใช่เบอร์โทรหลัก

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

ไทยชนะนั้นเก็บข้อมูลการเช็คอินซึ่งก็คือพิกัดอย่างหยาบ ข้อดีมากคือไม่มีข้อมูลสถานที่ส่วนตัว (บ้าน, เส้นทางเดินทาง ฯลฯ) มีแต่จุด check-in เท่านั้น แต่ก็ต้องนับว่าเป็นข้อมูลพิกัดอยู่ดี หากรั่วไหลออกมาผู้ใช้ก็อาจจะถูกตามตัวได้ว่าไปร้านหรือห้างใดมาบ้าง ข้อมูลเช่นนี้ในชาติตะวันตกหลายชาติก็มองว่ามากเกินไปแล้ว

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

เทียบกับ Exposure Notification API แล้ว ข้อมูลที่อยู่บนเซิร์ฟเวอร์จริงๆ จะมีเพียง contact ของผู้ที่ยืนยันว่าติดเชื้อเท่านั้น การ breach จะแทบไม่มีผลอะไรมากนัก เพราะไม่มีข้อมูลพิกัด แม้แต่พิกัดอย่างหยาบ ข้อมูลที่อัพโหลดมีเพียง ID ที่ต้องการแจ้งเตือนเท่านั้น

จุดสำคัญอีกจุดคือการใช้งานได้จริง ศบค. ระบุว่าหากผู้ใช้ไทยชนะได้รับแจ้งเตือนจะได้ตรวจ COVID ฟรี แต่คำถามคือเกณฑ์การแจ้งเตือนจะเป็นอย่างไร เพราะพื้นที่ที่ลงทะเบียนไทยชนะนั้นมีตั้งแต่ร้านชาไข่มุกที่ไม่มีที่นั่ง ไปยันห้างสรรพสินค้าขนาดยักษ์ เช่น Central World นั้นมีความจุเต็มพื้นที่เกือบแสนคน หากมีคน checkin แล้วป่วยจริง เราจะกวาดคนทั้งห้างไปตรวจทั้งหมด? หรือหากไม่ไหวก็อาจจะควรพิจารณาลดการลงทะเบียนให้เหลือแค่พื้นที่เล็กพอ (ร้านไม่เกิน 1,000 คน?) ส่วนพื้นที่ใหญ่กว่านั้นใช้มาตรการจำกัดคนเข้าออก นับคนเร็วๆ ไม่ให้แน่นเกินไปก็น่าจะพอแล้ว