사고를 완화하기 위해 Ansible 배치를 보호하는 방법?

최근 Amazon S3는 us-east-1 리전에서 큰 정전 을 겪었습니다 . Ansible 또는 유사한 도구에서 유지 관리 플레이 북을 실행할 때 철자 오류로 인해 발생한 것 같습니다. 다음과 같이 셸 스크립트 래퍼를 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 "$@"

그러나 안전을 개선하고 회사의 주요 중단을 야기하는 오류 가능성을 줄이기 위해 사용하는 다른 방법은 무엇입니까?

우리는 jenkins의 작업을 사용하여 배포를 트리거하고 있습니다. 배포를 수행하는 사람에 관계없이 실행되는 ansible 명령이 동일하게됩니다. 배포가 트리거 될 때 빌드 로그 레코드, 누가 트리거했는지, 배포 중에 정확히 무슨 일이 있었는지에 대한 좋은 보너스가 있습니다.

확실하지는 않지만 손으로 ​​플레이 북을 실행하는 것보다 크게 개선되었습니다.

규모가 크거나 위험 부담이 큰 변경의 경우 변경 관리 형식과 이상적으로 결합해야하므로 다른 사람 / 팀이 변경 사항과 변경 사항을 검토 한 후에 만 ​​잠재적 문제를 식별하고 해결하는 데 도움이되도록 변경해야합니다.

또한 큰 변화를 겪으면서 변화를보고 지켜보고 변화를 실행하는 동안 실수를 방지하는 데 도움이되는 팀원이있는 것은 결코 아프지 않습니다.

오류 범주

문제와 사고로 이어지는 인적 요소를 보는 두 가지 방법이 있습니다.

1. 인적 오류를 사고의 원인으로 볼 수 있습니다. 이 경우 상황 인식 상실, 절차 위반, 규제 부족, 관리상의 결함 상실 등 모든 라벨에서 "인적 오류"가 조사의 결론입니다.
2. 인적 오류는 더 심각한 문제의 증상으로 볼 수 있습니다. 이 경우 인적 오류가 조사의 시작점입니다. 인적 오류가 사람들의 도구, 작업 및 운영 / 조직 환경의 기능에 체계적으로 연결되는 방법을 조사합니다.

첫 번째는 인간 접근 방식이고 두 번째는 시스템 접근 방식입니다.

휴먼 접근 방식을 사용하여 실패를 설명하려면 실패를 찾고 사람들의 부정확 한 평가, 잘못된 결정 또는 잘못된 판단을 찾습니다.

시스템 접근 방식을 사용하여 실패를 설명하기 위해 사람들이 잘못한 곳을 찾으려고하지 않습니다. 대신, 사람들을 둘러싼 상황을 고려할 때 당시 사람들의 평가와 행동이 어떻게 합리적 이었는지 찾아보십시오.

예를 들어, IHI (Institute for Healthcare Improvement)의 도널드 버윅 (Donald Berwick)은 환자 안전을 개선하려면 시스템 설계를 변경 해야한다고 주장 합니다 .

... 우리는 인간이며, 인간은 실수합니다. 분노에도 불구하고 슬픔에도 불구하고 경험에도 불구하고 최선의 노력에도 불구하고 우리의 가장 깊은 소망에도 불구하고 우리는 타락한 상태로 태어날 것입니다. 주의를 기울이면 도움이되지만 완벽에 가까운 곳은 없습니다. 해결책은 변화하는 업무 체계에 있습니다. 해결책은 디자인에 있습니다. 목표는 극도로 안전해야합니다. 우리는 가정 에서처럼 병원에서 안전해야한다고 생각합니다. 그러나 우리는 권고, 비난, 분노 및 수치심을 통해 그 목표에 도달 할 수 없습니다. 우리는 변화에 대한 약속을 통해서만 그 결과에 도달 할 수 있으므로 결과와 관련이없고 지속적으로 발견되며 기술적으로 완화되는 정상적인 인간의 실수가 발생할 수 있습니다.

도널드 엠 버윅 다시는 아니야! BMJ 2001

시스템에서 실수 제거

실패 후에 발생하는 다양한 방식을 찾아서 (정확한) 가장 좋은 방법은 사람들을 비난하지 않고 근본 원인을 찾는 것입니다. 이것을 "무책임한 사후 부"라고하며, Craft 블로그 게시물 인 Etsy Code는 이 개념을 확장합니다. Etsy의 사람들은 다른 포럼 과 블로그 에서 이에 대해 더 많은 것을 발표하고 썼습니다 .

우선 실수를 방지하려면 일부 문화적 특성이 필수적입니다. 시스템에서 생성 된 절차와 다양한 인공물은 사람이 사용하는 것이 매우 명확하고 자명한지 테스트해야합니다. 종종 창조하는 사람들은 소비하는 사람들이 아니기 때문에 연결이 끊어지고 선명도가 떨어집니다. 모든 가정을 아는 유일한 사람은 시스템을 만든 사람이고 다른 사람은 없기 때문에 시스템은 작동하기에 안전하지 않습니다.

효과적인 통제 조치

오류 발생시 프로세스를 중지하기위한 효과적인 제어 수단을 마련하십시오. 이것은 실수 방지입니다. 효과적인 제어 수단은 프로세스 실패를 도입하여 오류가 발생한 경우 프로세스가 계속 진행되는 것을 방지하거나 중지하는 설계 변경입니다.

예:

1896 년, 사키치 토요다는 "도요다 증기 동력 직기"라고 불리는 일본 최초의 동력 직기를 발명했습니다. 이 개발로 20 배의 생산성이 향상되었으며 섬유의 품질이 향상되어 일본의 섬유 산업에 혁명을 일으켰습니다. 그러나 여기에 미묘하지만 매우 중요한 발견과 원칙이 있습니다.

바늘이 부러 졌을 때 기계가 멈췄습니다

Sakichi Toyoda는 Loom의 혁신을 만들어 나중에 Toyota Production System (Lean)의 기둥 중 하나가되었습니다. 이 기둥을 이제 Jidoka라고하며 때때로 "인간의 손길을 통한 스마트 자동화"또는 "자동화"라고합니다.

대체로 Andon (처음에는 멈추지 않음)과 Poka-Yoke (실수 방지)는 Loom에서 영향을받는 이후의 개발입니다.

단일 포인트 약점 제거

단일 포인트 취약점이라는 용어는 시스템의 중복성을 만들어 시스템 안정성을 향상시키는 방법입니다. 이중화는 프로세스와 관련된 시스템 또는 개인의 수를 늘려서 생성됩니다. 더 많은 백업 시스템 또는 더 많은 검사 (더블, 트리플 또는 그 이상)가 있으면 프로세스가 올바르게 진행될 가능성이 높아집니다.

이에 대한 한 가지 좋은 예는 "모든 비즈니스 의사 결정과 거래에서 CEO와 CFO의 승인이 필요합니다. CFO가 CEO에게보고하지 않기 때문에 독립적 인 통제 메커니즘이 있습니다." .

^{출처 : https://en.wikipedia.org/wiki/Two-man_rule}

위험을 명백하게

위험이 명백하거나 도달하기 어려운 경우, 인간은 실수를 할 수 없습니다. 예를 들어, 색상 코딩은 실수를보다 명확하게하는 일반적인 방법입니다. 또는 여러 가지 방법으로 삽입 할 수있는 다양한 컴퓨터 소켓을 생각한다면

몇몇 훌륭한 책들이 그 주제에 관해 이야기하고 있으며, 그것들을 언급하지 않으면 좋은 대답이되지 않을 것입니다 :

• Sidney Dekker의 '인간 오류'이해를위한 현장 안내서
• 사이트 안정성 엔지니어링 : Google이 프로덕션 시스템을 운영하는 방법
• 제로 품질 관리 : Shigeo Shingo의 소스 검사 및 Poka-Yoke 시스템

@bradim이 CI / CD 도구를 사용하여 수동 기반 명령 대신 배포를 시작하는 것은 일반적으로 준비 단계 (또는 새로 생성 된) 환경에서 배포 스크립트를 테스트하는 파이프 라인에 테스트를 추가하는 것과 같이 일반적으로 좋은 단계입니다. 더 일찍 버그를 선택할 수 있습니다.

또한 ansible 스크립트를 직접 호출하는 대신 Ansible Tower 와 같은 도구를 흐름에 추가 하여 더 쉽게 실행 된 변경 사항을 추적하고 추가 보안 단계를 제공 할 수 있습니다. 흐름.