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

18

ฉันจะวางไพ่ไว้บนโต๊ะ: ฉันเป็นนักพัฒนาและทำงานทั้งใน "DevOps" และไม่ใช่วัฒนธรรม ต้องกังวลเกี่ยวกับโครงสร้างพื้นฐานและการเผยแพร่และ QA และพิธีที่เกี่ยวข้องเป็นสิ่งที่ทำให้ไขว้เขวจากการเขียนรหัสที่ดี

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

process devops

— เบน
แหล่งที่มา

4

คุณกำลังบอกว่าคุณภาพรหัสของคุณลดลงเพราะคุณทำสิ่งอื่น ๆ หรือปริมาณรหัสของคุณลดลง

— Caleth

1

ได้โปรดถอดการ์ดของคุณออกจากโต๊ะด้วย นี่เป็นเพียงแค่อ่านเหมือนการร้องเรียนตามที่เป็นอยู่

— svidgen

7

@svidgen หากคำถามนี้เป็นการพูดจาโผงผางอย่างหมดจดนั้นจะแตกต่างกัน แต่ OP มีสิทธิ์ที่จะแสดงความคิดเห็นของพวกเขาเช่นเดียวกับการถามคำถามที่ถูกต้องสมบูรณ์

— Robbie Dee

1

@robbie แน่นอน คุณจะสังเกตเห็นว่าฉันตอบไปแล้ว ... แต่ส่วน "ความเห็น" ของคำถามนี้กินเนื้อความไปครึ่งส่วนประกบระหว่างคำถามพื้นฐานเดียวกันซ้ำแล้วซ้ำอีกและมันจะหันเหความสนใจของคำถามพื้นฐานในกรณีนี้ แต่ใช่ ยังคงคุ้มค่าการตอบ ..

— svidgen

19

เหตุผลหลักคือคลาวด์

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

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

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

ฉันสงสัยว่าการค้าขายนั้นคุ้มค่าบ่อยเท่าที่คนทำออกมา

— Telastyn
แหล่งที่มา

2

คุณทำให้ฉันที่ " เหตุผลหลักคือก้น "

— tedder42

15

มีเหตุผลที่แตกต่างกันมากมายสำหรับองค์กรต่างๆที่จะย้ายไปที่ DevOps
ฉันจะพยายามเขียนสิ่งที่เกิดขึ้นบ่อย ๆ

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

ปัญหาซอฟต์แวร์และฮาร์ดแวร์
จำการ์ตูนของ Bugs Bunny ที่ Bugs and Daffy โต้เถียงไม่ว่าจะเป็นฤดูเป็ดหรือฤดูกระต่าย? ทีนี้ลองนึกดูว่าเราได้สร้างมันขึ้นมาพร้อมกับผู้พัฒนาและการดำเนินการที่นักพัฒนาให้เหตุผลว่ามันเป็นปัญหาฮาร์ดแวร์ สำหรับผู้ใช้ปลายทางนี่คือความแตกต่างที่ไม่มีความแตกต่าง พวกเขาแค่ต้องการแก้ไข
ด้วยการรวมนักพัฒนาและการดำเนินงานเข้าด้วยกันพวกเขาจะต้องแก้ไขปัญหา และมันอาจกลายเป็นปัญหาซอฟต์แวร์และฮาร์ดแวร์

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

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

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

— มิเกลแวนเดอลาร์
แหล่งที่มา

4

+1 - เนื่องจากเป็นเรื่องเกี่ยวกับผู้ใช้ไม่ใช่เฉพาะรหัส

— JeffO

3

การเขียนโค้ดคุณภาพไม่เพียงพอ คุณเป็นส่วนหนึ่งของปัญหาหรือเป็นส่วนหนึ่งของการแก้ปัญหา

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

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

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

— JeffO
แหล่งที่มา

2

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

— Ben

2

@Ben: ไม่มี "และตอนนี้"; สิ่งเหล่านี้เป็นสิ่งที่ผู้พัฒนาที่ดีทำมาหลายสิบปีก่อนที่ใครบางคนคิดว่า DevOps เป็นสิ่งใหม่และประกาศเกียรติคุณ งานของคุณในฐานะนักพัฒนาคือการแก้ปัญหาที่เพิ่มขึ้นจากความต้องการของใครบางคนในการแก้ปัญหาเพื่อให้แน่ใจว่าคนที่ต้องจัดการกับรหัสของคุณหลังจากที่คุณเขียนมันไม่ได้ยาก ปล่อยทิ้งไว้บนมันและไม่มีใครใส่ใจว่าหมุดสี่เหลี่ยมจัตุรัสของคุณนั้นสวยงามเพียงใดหากพวกเขาต้องการเลื่อนขนาดสิบปอนด์เพื่อขับเคลื่อนพวกมันให้เป็นรูกลม

— Blrfl

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

— Richard Tingle

2

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

— Blrfl

ไม่แม้แต่จะพยายามตอบคำถาม -1

— RubberDuck

2

มันเป็นสิ่งที่จับมือกับ Agile & Scrum ไม่มีบทบาทงานที่กำหนดไว้อย่างชัดเจนอีกต่อไป - ทุกคนเป็น "นักพัฒนา"

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

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

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

บริษัท ที่มีความคิดก้าวหน้าและก้าวหน้ามากขึ้นในที่สุดก็เริ่มตระหนักว่าคนรูปตัว Tเป็นสิ่งที่ดี อย่างไรก็ตามมีความแตกต่างระหว่างการคิดว่าพวกเขาเป็นสิ่งที่ดีและคาดหวังว่าสิ่งนี้จะเกิดขึ้นอย่างน่าอัศจรรย์ที่วัฒนธรรมดั้งเดิมได้นำมาใช้ก่อนหน้านี้

— Robbie Dee
แหล่งที่มา

-1 "ไม่ได้กำหนดบทบาทไว้อย่างชัดเจนอีกต่อไป - ทุกคนเป็นนักพัฒนา" นั่นไม่จริงเลย ทีมการต่อสู้ควรจะประกอบด้วยกลุ่มคนที่หลากหลายซึ่งรวมถึงนักพัฒนาศิลปินกราฟิคพวกไอที ฯลฯ บทบาทไม่ได้หายไปไหน แต่ความคิดตอนนี้พวกเขาทั้งหมดอยู่ในทีมเดียวไม่ใช่ แยกแผนก

— Andy

1

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

— Robbie Dee

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

— Andy

0

ฉันแน่ใจว่ามีมากกว่าเหตุผลที่ดีไม่กี่สำหรับนักพัฒนาเพื่อยังจัดการการดำเนินงานและการควบคุมคุณภาพ (บางครั้ง) นี่คือสามของพวกเขา:

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

... และด้วยเหตุผลอื่นฉันแน่ใจ

— svidgen
แหล่งที่มา

0

"ต้องกังวลเกี่ยวกับโครงสร้างพื้นฐานและการเผยแพร่และ QA และพิธีที่เกี่ยวข้องเป็นสิ่งที่ทำให้ไขว้เขวจากการเขียนรหัสที่ดี"

หัวใจของฉันคิดว่า DevOps บอกว่ากังวลเกี่ยวกับโครงสร้างพื้นฐานและการเผยแพร่และ QA IS เขียนรหัสที่ดี

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

ตอนนี้คุณสามารถยืนยันว่าความเชี่ยวชาญที่เพิ่มขึ้นทั้งฝั่ง Dev และ Ops ช่วยให้เราสามารถเอาชนะสิ่งเหล่านี้ได้ แต่ยังมีอีกมากที่สามารถแก้ไขได้ผ่านการแบ่งปันความรู้และการทำงานระหว่างทีมของเรา

— แมตต์ freake
แหล่งที่มา

0

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

จากวิกิพีเดีย :

DevOps (การรวมกันของการพัฒนาและการดำเนินการที่ถูกตัด) เป็นวัฒนธรรมการเคลื่อนไหวหรือการปฏิบัติที่เน้นการทำงานร่วมกันและการสื่อสารของทั้งผู้พัฒนาซอฟต์แวร์และผู้เชี่ยวชาญด้านเทคโนโลยีสารสนเทศ (IT) อื่น ๆ โดยอัตโนมัติในขณะที่กระบวนการส่งซอฟต์แวร์

ดังนั้นในความเห็นของฉันจริง ๆ แล้วถ้าคุณในฐานะนักพัฒนามีความรับผิดชอบแบบเดิมและตอนนี้ยังมีความรับผิดชอบในการดำเนินงานซึ่งดูเหมือนว่าจะผิดในส่วนการจัดการ โดยอัตโนมัติสิ่งที่เป็นไปได้ค่อนข้างที่คุณจะต้องน้อยคน Ops และดังนั้นจึงมีการประหยัดต้นทุนจริง แต่ DevOps ไม่ได้แปลว่า "มากำจัดคน Ops ทั้งหมดและปล่อยให้ Devs ทำงานเพิ่มเติม"

บ่อยครั้งที่มี Buzzwords การกระจายความหมายเกิดขึ้นและทันใดนั้นผู้คนคิดว่า "ให้เราสร้าง Devs ทำ Ops ด้วยและฉันคิดว่าเราสามารถประหยัดเงินได้ ... "

— jhyot
แหล่งที่มา