จะป้องกันการปรับใช้ Ansible เพื่อลดอุบัติเหตุได้อย่างไร


12

เมื่อเร็ว ๆ นี้ Amazon S3 มีไฟดับครั้งใหญ่ในภูมิภาคตะวันออกเฉียงใต้ ดูเหมือนว่ามีสาเหตุมาจากข้อผิดพลาดในการสะกดคำเมื่อเรียกใช้ Playbook การบำรุงรักษาใน Ansible หรือเครื่องมือที่คล้ายกัน คุณสามารถใส่ shell สคริปต์ wrapper รอบ ansible-playbook ให้มีลักษณะดังนี้:

#!/bin/bash
/usr/bin/ansible-playbook "$@" --list-hosts --list-tasks
read -p "Are you sure? (y/n) " answer
test "$answer" = "y" || exit 0
exec /usr/bin/ansible-playbook "$@"

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


1
ฉันลงคะแนนให้ปิดคำถามนี้เป็นหัวข้อนอกเพราะจะเหมาะสมกว่าสำหรับunix.stackexchange.comหรือsuperuser.com
Romeo Ninov

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

ตัวอย่างเช่นคำถามนี้ดูเหมือนจะได้รับการยอมรับในหัวข้อ: devops.stackexchange.com/questions/98/…
Jiri Klouda

Jiri คุณสร้างความแตกต่างระหว่างคำถามของคุณกับคำถามอื่นที่คุณพูดถึงหรือไม่?
Romeo Ninov

5
หากคำถามประเภทนี้เหมาะสำหรับผู้ใช้ระดับสูงจะไม่มีความจำเป็นในการ devops นี่คือหัวข้อแน่นอนที่นี่ การปฏิบัติการและการบรรเทาความผิดพลาดของมนุษย์เป็นหัวใจสำคัญของ DevOps
Evgeny

คำตอบ:


6

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

แน่นอนว่ามันไม่สามารถป้องกันความผิดพลาดได้ แต่เป็นการปรับปรุงที่ดีกว่าการเล่น playbooks ที่ต้องใช้มือ

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

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


4

หมวดหมู่ของข้อผิดพลาด

มีสองวิธีในการดูปัจจัยมนุษย์ที่นำไปสู่ปัญหาและอุบัติเหตุ:

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

ครั้งแรกเรียกว่าวิธีการของมนุษย์และที่สองเป็นวิธีการระบบ

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

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

ตัวอย่างเช่นโดนัลด์เบอร์วิคจากสถาบันเพื่อการดูแลสุขภาพที่ปรับปรุง (IHI) ระบุว่าการปรับปรุงความปลอดภัยของผู้ป่วยต้องมีการเปลี่ยนแปลงในการออกแบบระบบ :

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

Donald M Berwick ไม่มีอีกครั้ง! BMJ 2001


การลบข้อผิดพลาดออกจากระบบ

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

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

มาตรการควบคุมที่มีประสิทธิภาพ

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

ตัวอย่าง:

ในปี 1896 Sakichi Toyoda ได้คิดค้นเครื่องทอผ้าพลังแรกของญี่ปุ่นที่เรียกว่า "เครื่องทอผ้าพลังไอน้ำ Toyoda" การพัฒนานี้ช่วยเพิ่มผลผลิตยี่สิบเท่าและคุณภาพของสิ่งทอก็ดีขึ้นและก่อให้เกิดการปฏิวัติในอุตสาหกรรมสิ่งทอในญี่ปุ่น แต่นี่คือการค้นพบและหลักการที่ละเอียดอ่อน แต่สำคัญมาก:

เมื่อเข็มแตกเครื่องก็หยุด

Sakichi Toyoda สร้างนวัตกรรมให้กับ Loom ซึ่งต่อมาจะกลายเป็นหนึ่งในเสาหลักในระบบการผลิตแบบโตโยต้า (ลีน) เสาที่เราเรียก Jidoka บางครั้งเรียกว่า "ระบบอัตโนมัติอัจฉริยะด้วยการสัมผัสของมนุษย์" หรือ "การปกครองตนเอง"

ในส่วนใหญ่ Andon (หยุดที่ข้อบกพร่องแรก) และ Poka-Yoke (พิสูจน์อักษรผิดพลาด) เป็นการพัฒนาภายหลังที่พบอิทธิพลของพวกเขาจากลุ่ม

การลบจุดอ่อนจุดเดียว

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

ตัวอย่างที่ดีสำหรับเรื่องนี้คือ "หลักการสี่ตา" ซึ่งหมายความว่า "การตัดสินใจทางธุรกิจและการทำธุรกรรมทั้งหมดต้องได้รับการอนุมัติจาก CEO และ CFO เนื่องจาก CFO ไม่ได้รายงานไปยัง CEO จึงมีกลไกการควบคุมที่เป็นอิสระ" .

แหล่งที่มา: https://en.wikipedia.org/wiki/Two-man_rule

ทำอันตรายอย่างชัดเจน

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


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


1
วิธีการที่สำคัญมากที่คุณไม่ได้กล่าวถึงคือ "หลักการสี่ตา" ซึ่งใช้ในด้านการเงิน - ไม่ว่าจะเป็นข้อผูกพันด้านกฎระเบียบหรือในฐานะที่ปลอดภัย ในอุตสาหกรรมซอฟต์แวร์นั้นมีการใช้งานในรูปแบบต่าง ๆ เช่นการตรวจสอบโค้ด แต่ยังสามารถใช้ในการตรวจสอบคำสั่งที่มีผลต่อระบบจริง
Michael Le Barbier Grünewald

ฉันจะเพิ่มเข้าไปในหลักการ SPW
Evgeny

1
การอภิปรายที่ดีเกี่ยวกับข้อผิดพลาด แต่ไม่ได้บอกวิธีป้องกันการปรับใช้โดยไม่ตั้งใจ
Alexandre

1
คำถามถามเกี่ยวกับ Ansible โดยเฉพาะ คำตอบนี้เป็นคำตอบที่ละเอียดถี่ถ้วนและได้รับการวิจัยเป็นอย่างดี แต่เป็นขั้นตอนเดียวที่จะถูกนำออกจากปัญหาโลกแห่งความจริง
Woodland Hunter

1
@Evgeny เมื่อฉันตอบคำถามประสิทธิภาพ AWS Lambda ของคุณตอนแรกฉันไม่ได้พูดถึงวิธีการทดสอบและคุณชี้ให้เห็น คุณพูดถูกและฉันปรับคำตอบของฉัน ฉันเข้าใจคนที่ไม่ลงคะแนนในคำตอบของคุณที่นี่ คำตอบของคุณจะดีสำหรับคำถามเกี่ยวกับ "วิธีการเข้าถึงและลดข้อผิดพลาดในที่ทำงานของเรา?" ที่นี่ OP มีคำถามเกี่ยวกับ Ansible และคุณไม่ต้องพูดถึง แย่ลง OP แสดงสิ่งที่เขากำลังมองหาและคุณกำลังไปในทางอื่น คำตอบของคุณดีมาก (จริง ๆ ) แต่ไม่ใช่สำหรับคำถามนี้
Alexandre

1

ดังที่ @bradim กล่าวว่าการใช้เครื่องมือ CI / CD ของคุณเพื่อเริ่มต้นการปรับใช้แทนที่จะเป็นคำสั่งที่ใช้มือเป็นขั้นตอนที่ดีไปข้างหน้าเช่นเดียวกับการเพิ่มการทดสอบในไปป์ไลน์ของคุณที่ทดสอบสคริปต์การปรับใช้ของคุณ คุณสามารถรับข้อบกพร่องก่อนหน้านี้

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

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