นักพัฒนาควรมีการเข้าถึงฐานข้อมูลเท่าใด [ปิด]


16

ดังนั้นฉันจึงทำงานในสถานที่ทำงานที่แตกต่างกันมากมายในฐานะนักพัฒนาและระดับการเข้าถึงฐานข้อมูลของฉันมีการเปลี่ยนแปลง โดยทั่วไปฉันไม่มีสิทธิ์เข้าถึงฐานข้อมูลการผลิต

เวลาส่วนใหญ่ของฉันมีการเข้าถึงฐานข้อมูลการทดสอบ แต่มันแตกต่างกันไป บางครั้งฉันสามารถทำได้และเปลี่ยนฐานข้อมูลและข้อมูลตามที่ฉันต้องการ แต่มักจะมีข้อตกลงอื่น ๆ เช่นเดียวกับฉันอาจเข้าถึงการอ่านข้อมูลได้เท่านั้น

ฉันทำงานในที่เดียวที่ทีม DBA จะจัดการฐานข้อมูลเราไม่สามารถเปลี่ยนแปลงได้เลยนอกจากว่าเราจะส่งแบบฟอร์มด้วยสคริปต์ sql สำหรับพวกเขาเพื่อ "ตรวจสอบ" โดยทั่วไปแล้วพวกเขาไม่มีอะไรเกี่ยวข้องกับโครงการมากนักเวลาส่วนใหญ่ก็แค่กด F5

สุจริตฉันสามารถเข้าใจว่าทำไมต้องแยงลง แต่ฉันชอบที่จะมีการเข้าถึงฐานข้อมูลมากในสภาพแวดล้อม dev และทดสอบ ฉันคิดว่า devs ส่วนใหญ่มีความสามารถพอสมควรที่จะรู้วิธีการของพวกเขารอบฐานข้อมูล แต่ฉันต้องการที่จะได้ยินความคิดเห็น นักพัฒนาควรมีการเข้าถึงฐานข้อมูลเท่าใด เราสามารถเชื่อถือได้หรือไม่ที่จะทำลายทุกสิ่งที่นั่น?


6
อาจคุณต้องการถามว่า " นักพัฒนาควรมีสิทธิ์เข้าถึงฐานข้อมูลการผลิตเท่าไร"
Mayank

@ Mayank คุณตีตะปูบนหัว ควรมีเซิร์ฟเวอร์ทดสอบเพื่อ 'เล่น' ด้วยแนวคิดใหม่เสมอ เซิร์ฟเวอร์ที่ใช้งานจริงควรเห็นเฉพาะรุ่นที่ปรับปรุง / ทดสอบ / พิสูจน์แล้วเท่านั้น ฉันจะพูดแบบเดียวกันกับเว็บไซต์ (แม้ว่าผู้พัฒนาเว็บส่วนใหญ่จะไม่ใช้)
Evan Plaice

@Mayank - ใช่ฉันต้องการจะได้ยินเกี่ยวกับการเข้าถึงฐานข้อมูลการผลิต แต่ยังต้องการที่จะฟังความคิดเห็นเกี่ยวกับการเข้าถึงในสภาพแวดล้อมที่แตกต่างกันเช่น DEV, INT ทดสอบ PREPROD ฯลฯ เกินไป
RoboShop

1
ถึงแม้ว่ามันจะถูกทำเครื่องหมายว่าซ้ำซ้อน แต่คำถามที่เกี่ยวข้องprogrammers.stackexchange.com/questions/246618/…นั้นเป็นส่วนเสริมที่น่าสนใจ
Eamon Nerbonne

คำตอบ:


16

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

ผู้พัฒนาไม่ควรมีสิทธิ์ในการเขียนข้อมูลการผลิตหรือสิทธิ์ในการสร้างวัตถุ ไม่มีอะไรที่จะไปแยงที่ไม่ได้เป็นส่วนหนึ่งของการเปิดตัวอย่างเป็นทางการ บ่อยครั้งที่ผู้คนทำการแก้ไขอย่างรวดเร็วในการกระทุ้งที่ไม่ทำงานทำให้กระทุ้งมีความผิดพลาดมากขึ้นหรือทำงานได้ แต่พวกเขาลืมใส่รหัสลงในเซิร์ฟเวอร์ dev / QA / Staging และยิ่งแย่ลงไปกว่าเดิม พื้นที่เก็บข้อมูลการควบคุมและรหัสจะถูกเขียนทับประมาณหนึ่งเดือนต่อมาในรุ่นอย่างเป็นทางการต่อไป

ฉันชอบ devs ที่จะมีสิทธิ์การควบคุมคุณภาพฐานข้อมูลเต็มรูปแบบเนื่องจากการปรับใช้กับเซิร์ฟเวอร์อื่นช่วยให้พวกเขาเห็นว่ามีช่องว่างในกระบวนการปรับใช้ของพวกเขาหรือไม่ (โอ๊ะลืมว่าฉันเปลี่ยนตารางนั้นเพื่อทำเช่นนั้นและเช่นนั้น ใช้ GUI และไม่ได้อยู่ในสคริปต์ในการควบคุมแหล่งซึ่งเป็นวิธีการเปลี่ยนแปลงโครงสร้างฐานข้อมูลใด ๆ ที่จะต้องเกิดขึ้น)

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

หนึ่งในสิ่งที่สำคัญที่สุดเกี่ยวกับการ จำกัด สิทธิ์การผลิตในฐานข้อมูลคือ devs นั้นจำเป็นต้องตรวจสอบให้แน่ใจว่างานของพวกเขาอยู่ในรูปแบบที่คนอื่นสามารถนำไปใช้งานได้ สิ่งนี้มีแนวโน้มที่จะปรับปรุงคุณภาพของงานเพราะพวกเขาไม่ได้พยายามแก้ไขในทันทีเพราะพวกเขาลืมบางสิ่งบางอย่างหรือบางสิ่งบางอย่างไม่ทำงานเพราะพวกเขาทำมันแตกต่างกันในการผลิตมากกว่าที่จะต้องพึ่งพาหน่วยความจำเพียงอย่างเดียว คุณยังสูญเสีย "โอ๊ะโอที่ฉันลบตารางผู้ใช้ทั้งหมดโดยไม่ได้ตั้งใจเพราะฉันลืมไฮไลต์ประเภทอุบัติเหตุ" เมื่อการใช้งาน prod ล้วนใช้สคริปต์ที่รันโดยไม่ใช้คำสั่งเพียงครั้งเดียวตามปกติเมื่อ devs ทำงานในสิ่งที่แยง ทีมที่มีสิทธิ์ จำกัด ในฐานข้อมูลแยงมีแนวโน้มที่จะเก็บการเปลี่ยนแปลงฐานข้อมูลในการควบคุมแหล่งเช่นกัน


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

8
"ผู้พัฒนาจำเป็นต้องมีสิทธิ์อ่านเพื่อเข้าถึงฐานข้อมูลทั้งหมดรวมถึงผลิตภัณฑ์" ไม่ว่าจะเป็นที่ใดในงานก่อนหน้านี้ของฉัน ข้อมูลแยงประกอบด้วยบันทึกทางการเงินและธุรกรรมของลูกค้าซึ่งเป็นความลับ
ohho

3
@ Ohho นั่นเป็นข้อยกเว้นที่ถูกต้อง แต่มันต้องทำให้มันแตกต่างอย่างแท้จริงในการแก้ไขปัญหาที่คุณไม่สามารถสร้างซ้ำได้ใน dev ทันที
HLGEM

7

ดีจริงๆคำถามของ "แวมไพร์ (โปรแกรมเมอร์) เมื่อเทียบกับมนุษย์หมาป่า (Sysadmins)" เจฟฟ์แอดได้ใส่ไว้ที่นี่


ไปทีมเอ็ดเวิร์ดฉันเดา
Joel Etherton

2
@Joel Etherton สำหรับพวกเราที่ไม่ได้ดูหนังเรื่องใดทีมหนึ่งคือเอ็ดเวิร์ด?
CaffGeek

1
@Chad ที่ดีที่คุณได้จริงไม่ได้เห็นว่า "ทไวไลท์" อึ อย่างน้อยคุณก็ไม่ต้องแกล้งทำเป็นไม่เห็นเหมือนฉัน ;)
Mayank

@Chad: ฉันไม่ได้ดูหนัง แต่เอ็ดเวิร์ดเป็นแวมไพร์ ฉันรู้ว่าเพราะการทิ้งระเบิดอย่างต่อเนื่องชั่วขณะหนึ่งโดยโฆษณาเบอร์เกอร์คิงและโง่ ๆ "ซื้ออึของเรากับทไวไลท์เปื้อนทั่ว" แคมเปญ Soy un programador
Joel Etherton

โอ้ฉันรู้ว่ามันดีฉันไม่ได้เห็นมัน และฉันจะไม่ทำ
CaffGeek

7

โดยปกติ (นั่นหมายความว่ามีความหรูหราในการตั้งค่าสภาพแวดล้อมแบบเต็ม) ผู้พัฒนาสามารถเข้าถึง

  • เซิร์ฟเวอร์ที่ใช้งานจริง
    • ไม่มี (SA / PM จะใช้สำหรับการตั้งค่าสคีมาผู้ใช้จะให้ข้อมูล init)
  • เซิร์ฟเวอร์ UAT
    • ไม่มี (SA / PM จะใช้สำหรับการตั้งค่าสคีมาและการเก็บข้อมูลตัวอย่าง)
  • เซิร์ฟเวอร์ทดสอบ / QA
    • โดยปกตินักพัฒนาซอฟต์แวร์จะส่งสคริปต์การตั้งค่าสคีมาให้ทีม QA และ QA สร้างตาราง
    • นักพัฒนาสามารถเข้าถึงฐานข้อมูลได้อย่างเต็มที่ แต่ไม่ค่อยมีการเปลี่ยนแปลง
    • นักพัฒนาอาจช่วยเพื่อนร่วมงานคุณภาพในการเพาะเมล็ด / แก้ไข / ลบข้อมูลบางส่วน
  • เซิร์ฟเวอร์การพัฒนา / localhost
    • การเข้าถึงแบบเต็ม

เหตุผลหลักที่อยู่เบื้องหลังว่าทำไมนักพัฒนาไม่ควรแตะเซิร์ฟเวอร์ที่ใช้งานจริงคือ: เมื่อมีอะไรผิดพลาดทีมปฏิบัติการจะต้องรับผิดชอบ แต่ไม่ใช่นักพัฒนา


2
นักพัฒนามีความรับผิดชอบอยู่เสมอแม้ว่าพวกเขาจะไม่สามารถสัมผัสระบบที่พวกเขาเป็นคนที่จบลงด้วยการแก้ไข
Erin

2
หากการแก้ไขคือการเปลี่ยนแปลงในฐานข้อมูลมันเป็นความรับผิดชอบของทีมพัฒนาในการผลิตการแก้ไขและทีมงานการดำเนินงานที่จะใช้มัน นอกจากนี้เพื่อเหตุผลด้านสุขภาพจิตฉันจะไม่อนุญาตให้นักพัฒนา "แก้ไข" ในทางใดทางหนึ่ง (ข้อมูลหรือโครงสร้าง) สภาพแวดล้อม QA การเปลี่ยนแปลงใด ๆ ในสภาพแวดล้อมนั้นควรได้รับการควบคุมเช่นเดียวกับสภาพแวดล้อมการผลิต
Soronthar

2
ถ้าคุณมีทีมงานที่มีการดำเนินงาน ...
มาร์ซี่

ฉันขอสิทธิ์เข้าถึงแบบอ่านอย่างเดียวบนเซิร์ฟเวอร์ที่ใช้งานจริง ทำให้การค้นหาข้อบกพร่องง่ายขึ้นมาก
Carra

@Carra: นั่นอาจมีปัญหาด้านกฎระเบียบเนื่องจากเซิร์ฟเวอร์ที่ใช้งานจริงสามารถมีข้อมูลที่ถูกต้องตามกฎหมาย (ตัวอย่างเช่นระบบการแพทย์ในสหรัฐอเมริกาต้องสอดคล้องกับ HIPAA) ฉันไม่เคยอยู่ในสถานที่ที่ใครก็ตามพยายาม จำกัด การเข้าถึงข้อมูลลับสด แต่อาจมีอยู่
David Thornley

2

ขั้นต่ำที่แน่นอนที่คุณต้องทำให้งานสำเร็จ

หากนักพัฒนาทั้งหมดได้รับการเข้าถึงฐานข้อมูลอย่างเต็มรูปแบบโอกาสที่จะโกรธ (หรือเมาหรือเหนื่อยมากหรือ ... ) และการทำความเสียหายร้ายแรงนั้นสูงกว่ามากหากพวกเขาสามารถอ่านได้จากฐานข้อมูลเท่านั้น

หากงานของคุณส่วนใหญ่สามารถทำได้โดยไม่ต้องเข้าถึงการเขียนฐานข้อมูล (และโดยส่วนใหญ่ฉันหมายถึงการร้องขอการเปลี่ยนแปลงไม่กี่ครั้งต่อสัปดาห์) คุณก็ไม่จำเป็นต้องมีสิทธิ์การเขียน


2

มี 2 ​​ความต้องการในการแข่งขันในทุกสภาพแวดล้อมการทำงาน

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

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

เพื่อสรุปถ้าคุณไม่ทราบว่าระบบ dev คุณไม่ควรมีการเข้าถึงระบบอื่น ๆ ได้อย่างง่ายดายกว่าที่ใด ๆ อีกครั้ง buildable ถ้าคุณทำรู้มากกว่าที่คุณรู้คุณไม่ควรจะเข้าถึงระบบใด ๆ ยกเว้นระบบ


2

นักพัฒนาควรมีสิทธิ์เข้าถึงฐานข้อมูล dev อย่างสมบูรณ์ (โดยปกติแล้วพวกเขาควรใช้เซิร์ฟเวอร์ภายในเครื่อง แต่ไม่สามารถทำได้ตลอดเวลา) พวกเขาควรมีสิทธิ์เข้าถึงฐานข้อมูล build / QA แต่ต้องเป็นข้อมูลเท่านั้น (ควรได้รับอนุญาต / ส่งตั๋วเพื่อเปลี่ยนโครงสร้าง) นักพัฒนาไม่ควรเข้าถึงฐานข้อมูลการผลิต (นอกเสียจากว่าจะเป็น บริษัท / โครงการขนาดเล็กและนักพัฒนาก็ให้การสนับสนุนด้านการผลิตด้วย)


1

ฉันคิดว่ากุญแจสำคัญในที่นี้คือระดับความรับผิดชอบที่นักพัฒนามี ในองค์กรขนาดใหญ่ที่มีนักพัฒนาจำนวนมากพวกเขามีแนวโน้มที่จะเข้าถึงการพัฒนาโดยมีการเข้าถึง QA / Test แบบอ่านอย่างเดียวเท่านั้น

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

ฉันทำงานในร้านไอทีขนาดใหญ่และเรามีการอ่านเพื่อเข้าถึงการผลิตสำหรับคนส่วนใหญ่ ฉันในฐานะนักพัฒนานำยังมีสิทธิ์ในฐานข้อมูลการผลิต ฉันยังคงต้องปฏิบัติตามแนวทางเดียวกันกับ sysadmins และ DBAs ในแง่ของกระบวนการและเอกสาร แต่ฉันสามารถแก้ไขได้อย่างเร่งด่วนหากจำเป็น


0

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

ดังนั้นนี่เป็นคำถามแรก อย่างที่สองต้องเป็นพนักงานที่มีอยู่ - ฉันทำงานที่ไซต์ที่มีระบบดูแลระบบซึ่งป้องกันสนามหญ้า แต่ก็ไม่ค่อยดีเท่าไหร่ (ซึ่งอาจเป็นเหตุผลว่าทำไมพวกเขาจึงเป็นดินแดน - พวกเขารู้ว่าพวกเขาจะร้อนมากถ้ามีคนมองไปรอบ ๆ ) บางครั้งคุณต้องเข้าถึงมากกว่าที่คุณต้องการ

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

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

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


0

ฉันเห็นด้วยกับคำตอบทั้งหมดโดยบอกว่า "เป็นสิทธิ์น้อยที่สุดสำหรับผู้พัฒนาบนฐานข้อมูลที่แยง" แต่บอกตามตรงว่าใครสามารถปฏิเสธการเข้าถึงฐานข้อมูลของนักพัฒนาหากพวกเขาต้องการได้รับมัน ด้วยความตั้งใจที่เพียงพอ (ไม่ว่าจะทางอาญาหรือเพื่อผลดี) พวกเขาจะได้รับการเข้าถึงที่จำเป็น

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.