Làm thế nào để bảo vệ triển khai Ansible để giảm thiểu tai nạn?


12

Gần đây, Amazon S3 đã bị ngừng hoạt động ở khu vực đông-1. Có vẻ như nó có khả năng gây ra lỗi chính tả khi chạy sổ bảo trì trong Ansible hoặc một công cụ tương tự. Bạn có thể đặt một trình bao bọc kịch bản lệnh shell xung quanh ansible-playbook để trông giống như:

#!/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 "$@"

Nhưng một số cách khác bạn sử dụng để cải thiện sự an toàn và giảm nguy cơ lỗi gây ra sự cố mất điện lớn cho công ty của bạn.


1
Tôi đang bỏ phiếu để đóng câu hỏi này dưới chủ đề vì nó sẽ phù hợp hơn với unix.stackexchange.com hoặc superuser.com
Romeo Ninov

4
Cơ sở hạ tầng dưới dạng mã, là một trong những thành phần quan trọng để có được hàng trăm triển khai mỗi ngày. Có thể bảo mật các công cụ cung cấp tốc độ này từ việc tạo ra sự cố ngừng hoạt động trong các hoạt động dường như đối với tôi như một chủ đề có liên quan. Tôi có thể sai, tất nhiên. Tôi đánh giá cao quan điểm của bạn mặc dù. Bạn có muốn tham gia cuộc thảo luận này về các câu hỏi chủ đề trong và ngoài trong Meta không?
Jiri Klouda

Ví dụ: câu hỏi này dường như được chấp nhận như trên chủ đề: devops.stackexchange.com/questions/98/iêu
Jiri Klouda

Jiri, bạn có làm cho sự khác biệt giữa câu hỏi của bạn và khác mà bạn đề cập?
Romeo Ninov

5
Nếu những loại câu hỏi này phù hợp với siêu người dùng, sẽ không cần phải có devops.se. Đây chắc chắn là chủ đề ở đây. Hoạt động và giảm thiểu lỗi của con người là cốt lõi của DevOps.
Evgeny

Câu trả lời:


6

Chúng tôi đang sử dụng các công việc trong jenkins để kích hoạt triển khai. Nó đảm bảo rằng bất kể ai thực hiện triển khai, lệnh ansible được chạy sẽ giống nhau. Một phần thưởng tuyệt vời là bản ghi nhật ký xây dựng khi các triển khai được kích hoạt, người đã kích hoạt chúng và chính xác những gì đã xảy ra trong quá trình triển khai.

Nó chắc chắn không thể đánh lừa được, nhưng đó là một cải tiến tốt đẹp so với việc chạy các vở kịch ansible bằng tay.

Đối với những thay đổi lớn hơn / rủi ro hơn, nên kết hợp lý tưởng với một số hình thức quản lý thay đổi để thay đổi chỉ được thực hiện sau khi một người / nhóm khác xem xét thay đổi và cách tiếp cận thay đổi để giúp xác định và giải quyết sớm các vấn đề tiềm ẩn.

Ngoài ra, sẽ không bao giờ đau lòng khi có một đồng đội hiểu được sự thay đổi mà bạn đang có mặt và theo dõi trong khi bạn thực hiện những thay đổi lớn để họ có thể theo dõi và giúp ngăn ngừa những sai lầm khi thực hiện thay đổi.


4

Danh mục lỗi

Có hai cách để xem xét các yếu tố con người dẫn đến các vấn đề và tai nạn:

  1. Bạn có thể xem lỗi của con người là nguyên nhân của một rủi ro. Trong trường hợp này "lỗi của con người", dưới bất kỳ nhãn hiệu nào, mất nhận thức về tình huống, vi phạm thủ tục, thiếu sót về quy định, thiếu sót trong quản lý là kết luận điều tra của bạn.
  2. Bạn có thể thấy lỗi của con người là triệu chứng của rắc rối sâu sắc hơn. Trong trường hợp này, lỗi của con người là điểm khởi đầu cho cuộc điều tra của bạn. Bạn sẽ thăm dò lỗi của con người được kết nối một cách có hệ thống với các tính năng của các công cụ, nhiệm vụ và môi trường hoạt động / tổ chức của mọi người.

Đầu tiên được gọi là phương pháp của con người , và thứ hai là phương pháp hệ thống .

Để giải thích thất bại bằng cách sử dụng phương pháp của con người, bạn sẽ tìm kiếm thất bại và tìm ra những đánh giá không chính xác của mọi người, những quyết định sai lầm hoặc những đánh giá tồi tệ.

Để giải thích sự thất bại khi sử dụng phương pháp hệ thống, bạn không cố gắng tìm nơi mọi người đã sai. Thay vào đó, hãy tìm cách đánh giá và hành động của mọi người có ý nghĩa vào thời điểm đó, dựa vào hoàn cảnh xung quanh họ.

Ví dụ, Donald Berwick thuộc Viện Cải thiện Y tế (IHI) lập luận rằng việc cải thiện an toàn cho bệnh nhân đòi hỏi phải thay đổi thiết kế hệ thống :

... Chúng ta là con người và con người sai lầm. Mặc dù phẫn nộ, bất chấp đau buồn, bất chấp kinh nghiệm, bất chấp những nỗ lực tốt nhất của chúng tôi, bất chấp những mong muốn sâu sắc nhất của chúng tôi, chúng tôi được sinh ra dễ sai lầm và sẽ vẫn như vậy. Cẩn thận giúp đỡ, nhưng nó mang lại cho chúng ta không nơi nào gần hoàn hảo ... Biện pháp khắc phục là thay đổi hệ thống công việc. Biện pháp khắc phục là trong thiết kế. Mục tiêu phải cực kỳ an toàn. Tôi tin rằng chúng ta nên an toàn trong bệnh viện như chúng ta đang ở trong nhà. Nhưng chúng ta không thể đạt được mục tiêu đó thông qua sự hô hào, nhường nhịn, phẫn nộ và xấu hổ. Chúng ta có thể đạt được nó chỉ bằng một cam kết thay đổi, do đó, các lỗi thông thường của con người có thể không liên quan đến kết quả, liên tục được tìm thấy và được giảm nhẹ một cách khéo léo.

Donald M Berwick. Không lập lại! BMJ 2001


Loại bỏ các lỗi từ hệ thống

Một cách tuyệt vời để tìm (và sửa) những cách khác nhau thất bại xảy ra sau thực tế, là tìm kiếm nguyên nhân gốc rễ mà không đổ lỗi cho mọi người. Điều này thường được gọi là "hậu quả đáng trách" và Mã Etsy khi bài đăng trên blog của Craft mở rộng về khái niệm này. Mọi người ở Etsy đã trình bày và viết thêm về nó trên các diễn đàn và blog khác.

Để ngăn ngừa sai lầm ở nơi đầu tiên, một số đặc điểm văn hóa là phải. Các thủ tục và các tạo tác khác nhau được tạo ra trong hệ thống phải kiểm tra rằng việc sử dụng chúng bởi con người là rất rõ ràng và tự giải thích. Thông thường những người tạo ra không phải là những người tiêu thụ, dẫn đến mất kết nối và thiếu rõ ràng. Hệ thống sau đó không an toàn để vận hành vì người duy nhất biết tất cả các giả định là người tạo ra nó (và không ai khác).

Các biện pháp kiểm soát hiệu quả

Đặt các biện pháp kiểm soát hiệu quả để ngăn chặn quá trình khi xảy ra lỗi. Đây là bằng chứng sai lầm. Các biện pháp kiểm soát hiệu quả là những thay đổi thiết kế ngăn chặn hoặc ngăn chặn các quá trình tiếp tục khi xảy ra lỗi bằng cách đưa ra lỗi quy trình

Thí dụ:

Năm 1896, Sakichi Toyoda đã phát minh ra máy dệt công suất đầu tiên của Nhật Bản có tên là máy dệt năng lượng hơi nước Toyoda. Sự phát triển này đã tăng năng suất lên gấp hai mươi lần và chất lượng hàng dệt được cải thiện và gây ra một cuộc cách mạng trong ngành dệt may tại Nhật Bản. Nhưng đây là khám phá và nguyên tắc tinh tế nhưng rất quan trọng:

Khi kim gãy, máy dừng lại.

Sakichi Toyoda đã tạo ra một sự đổi mới cho Loom mà sau này trở thành một trong những trụ cột trong Hệ thống sản xuất Toyota (Lean). Đó là trụ cột mà bây giờ chúng ta gọi là Jidoka, đôi khi được gọi là tự động hóa thông minh với sự tự động của con người.

Phần lớn, Andon (dừng lại ở khuyết điểm đầu tiên) và Poka-Yoke (chứng minh sai lầm) là những phát triển sau đó tìm thấy ảnh hưởng của họ từ Loom.

Loại bỏ điểm yếu một điểm

Thuật ngữ điểm yếu duy nhất đề cập đến việc tạo ra các dự phòng trong hệ thống như một cách tiếp cận để cải thiện độ tin cậy của hệ thống. Dự phòng được tạo ra bằng cách tăng số lượng hệ thống hoặc cá nhân tham gia vào quá trình. Có nhiều hệ thống sao lưu hoặc nhiều kiểm tra hơn (gấp đôi, gấp ba hoặc nhiều hơn) làm tăng khả năng quá trình sẽ tiến hành chính xác.

Một ví dụ tuyệt vời cho điều này là "nguyên tắc bốn mắt", có nghĩa là "tất cả các quyết định và giao dịch kinh doanh đều cần sự chấp thuận của CEO và CFO. Vì CFO không báo cáo cho CEO, nên có một cơ chế kiểm soát độc lập" .

nguồn: https://en.wikipedia.org/wiki/Two-man_rule

Làm cho mối nguy hiểm trở nên rõ ràng

Nếu các mối nguy hiểm được làm rõ ràng hoặc không thể đạt được, con người không thể tạo ra sai lầm. Ví dụ, mã màu là một cách tiếp cận phổ biến để làm cho sai lầm rõ ràng hơn. Hoặc nếu bạn nghĩ về các ổ cắm máy tính khác nhau chỉ có thể được chèn theo một cách chứ không phải cách khác, v.v.


Một số cuốn sách tuyệt vời đang nói về chủ đề này, và nó sẽ không phải là một câu trả lời hay nếu không đề cập đến chúng:


1
Một phương pháp rất quan trọng mà bạn không đề cập đến là nguyên tắc bốn mắt của người dùng được sử dụng trong tài chính - như là một nghĩa vụ pháp lý hoặc là một người bảo vệ an toàn. Trong công nghiệp phần mềm, nó được triển khai theo nhiều cách khác nhau, ví dụ như đánh giá mã nhưng cũng có thể được sử dụng để xác nhận các lệnh ảnh hưởng đến các hệ thống trực tiếp.
Michael Le Barbier Grünewald

Tôi sẽ thêm nó vào nguyên tắc SPW.
Evgeny

1
Thảo luận tuyệt vời về các lỗi, nhưng nó không nói làm thế nào để bảo vệ chống lại việc triển khai tình cờ.
Alexandre

1
Câu hỏi hỏi về Ansible cụ thể. Câu trả lời này rất kỹ lưỡng và được nghiên cứu kỹ lưỡng nhưng nó là một bước được loại bỏ khỏi vấn đề thực tế.
Thợ săn rừng

1
@Evgeny Khi tôi trả lời câu hỏi về hiệu suất AWS Lambda của bạn, ban đầu tôi không nói cách chạy thử nghiệm của bạn và bạn đã chỉ ra điều đó. Bạn đã đúng, và tôi điều chỉnh câu trả lời của tôi. Tôi hiểu những người đang bỏ phiếu trả lời của bạn ở đây. Câu trả lời của bạn sẽ tốt cho câu hỏi về "Cách tiếp cận và giảm lỗi tại nơi làm việc của chúng tôi?". Ở đây, OP có một câu hỏi về Ansible và bạn thậm chí không đề cập đến nó. Tồi tệ hơn, OP đưa ra một dấu hiệu về loại giải pháp mà anh ấy đang tìm kiếm và bạn đang đi theo một cách khác. Câu trả lời của bạn là rất tốt (thực sự), nhưng không phải cho câu hỏi này.
Alexandre

1

Như @bradim đã nói sử dụng công cụ CI / CD của bạn để bắt đầu triển khai thay vì các lệnh dựa trên tay thường là bước tiến tốt, cũng như việc thêm các kiểm tra trong đường ống thực sự kiểm tra các tập lệnh triển khai của bạn trên môi trường dàn dựng (hoặc được tạo mới), trong đó bạn có thể nhận lỗi trước đó.

Tôi cũng sẽ nói thêm rằng thay vì gọi trực tiếp các tập lệnh ansible của bạn, bạn cũng có thể thêm các công cụ như Ansible Tower vào luồng của mình, điều này sẽ cho phép bạn theo dõi các thay đổi đã được chạy dễ dàng hơn và có thể cung cấp cho bạn một bước bảo mật bổ sung vào lưu lượng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.