Jak zabezpieczyć wdrożenie Ansible w celu ograniczenia liczby wypadków?

Ostatnio Amazon S3 miał poważną awarię w regionie US-East-1. Wygląda na to, że przyczyną był prawdopodobnie błąd ortograficzny podczas uruchamiania podręcznika konserwacji w Ansible lub podobnym narzędziu. Możesz umieścić otoczkę skryptu powłoki w instrukcji Ansible-Playbook, aby wyglądać następująco:

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

Ale jakich jeszcze sposobów używasz do poprawy bezpieczeństwa i zmniejszenia prawdopodobieństwa błędu powodującego poważną awarię Twojej firmy.

Używamy zadań w Jenkins do uruchamiania wdrożeń. Zapewnia to, że bez względu na to, kto wykonuje wdrożenie, uruchamiane polecenie ansible będzie takie samo. Fajną zaletą jest zapis dzienników kompilacji po uruchomieniu wdrożeń, kto je uruchomił i co dokładnie wydarzyło się podczas wdrożenia.

Z pewnością nie jest niezawodny, ale stanowi dobrą poprawę w porównaniu z ręcznym uruchamianiem automatycznych podręczników.

W przypadku większych / bardziej ryzykownych zmian najlepiej byłoby to połączyć z pewną formą zarządzania zmianami, aby zmiany były wprowadzane dopiero po przejrzeniu zmiany przez inną osobę / zespół i podejściu do zmiany, aby pomóc wcześnie zidentyfikować i rozwiązać potencjalne problemy.

Ponadto nigdy nie boli się, aby członek drużyny, który rozumie dokonaną zmianę, był obecny i obserwował ją podczas wprowadzania dużych zmian, aby mogli obserwować zmiany i zapobiegać błędom w ich wykonaniu.

Kategorie błędów

Istnieją dwa sposoby patrzenia na czynniki ludzkie, które prowadzą do problemów i wypadków:

1. Możesz zobaczyć błąd ludzki jako przyczynę nieszczęścia. W tym przypadku „błąd ludzki” pod jakąkolwiek nazwą - utrata świadomości sytuacyjnej, naruszenie procedur, niedociągnięcia regulacyjne, braki menedżerskie to zakończenie dochodzenia.
2. Możesz zobaczyć błąd ludzki jako objaw głębszych kłopotów. W takim przypadku błąd ludzki jest punktem wyjścia dla twojego dochodzenia. Zbadasz, w jaki sposób błąd ludzki jest systematycznie powiązany z funkcjami narzędzi, zadań i środowiska operacyjnego / organizacyjnego ludzi.

Pierwsze nazywa się podejściem ludzkim , a drugie podejściem systemowym .

Aby wyjaśnić porażkę przy użyciu ludzkiego podejścia, szukałbyś porażki i znajdowałbyś niedokładne oceny ludzi, złe decyzje lub złe osądy.

Aby wyjaśnić błąd przy użyciu podejścia systemowego, nie próbujesz znaleźć, gdzie ludzie się mylili. Zamiast tego dowiedz się, jak oceny i działania ludzi miały wówczas sens, biorąc pod uwagę otaczające je okoliczności.

Na przykład Donald Berwick z Institute for Healthcare Improvement (IHI) twierdzi, że poprawa bezpieczeństwa pacjentów wymaga zmian w projekcie systemów :

... Jesteśmy ludźmi, a ludzie mylą się. Pomimo oburzenia, żalu, doświadczenia, pomimo naszych najlepszych starań, pomimo naszych najgłębszych życzeń, rodzimy się omylni i tak pozostanie. Ostrożność pomaga, ale nie zbliża nas do perfekcji ... Lekarstwem jest zmiana systemów pracy. Środek zaradczy jest w fazie projektowania. Celem powinno być ekstremalne bezpieczeństwo. Uważam, że powinniśmy być tak samo bezpieczni w naszych szpitalach, jak w naszych domach. Ale nie możemy osiągnąć tego celu poprzez napomnienie, wotum nieufności, oburzenie i wstyd. Możemy to osiągnąć tylko poprzez zobowiązanie do zmiany, dzięki czemu normalne ludzkie błędy mogą stać się nieistotne dla wyniku, stale wykrywane i umiejętnie ograniczane.

Donald M. Berwick. Nie znowu! BMJ 2001

Usuwanie błędów z systemu

Świetnym sposobem na znalezienie (i poprawienie) różnych przyczyn niepowodzenia po fakcie jest poszukiwanie przyczyny bez obwiniania ludzi. Jest to często nazywane „nienaganną sekcją zwłok”, a Etsy Code jako post na blogu Craft rozwija tę koncepcję. Ludzie z Etsy prezentowali i pisali o tym więcej na innych forach i blogach.

Aby przede wszystkim uniknąć błędów, niektóre cechy kultury są koniecznością. Procedury i różne artefakty tworzone w systemie muszą sprawdzać, czy używanie ich przez ludzi jest bardzo jasne i zrozumiałe. Często ci, którzy tworzą, nie są tymi, którzy konsumują, co prowadzi do rozłączenia i braku jasności. System nie jest zatem bezpieczny w obsłudze, ponieważ jedyną osobą, która zna wszystkie założenia, jest ten, który go stworzył (i nikt inny).

Skuteczne środki kontroli

Wprowadź skuteczne środki kontroli, aby zatrzymać proces w przypadku wystąpienia błędu. Jest to zabezpieczenie przed błędami. Skuteczne środki kontroli to zmiany w projekcie, które uniemożliwiają lub zatrzymują kontynuowanie procesów po wystąpieniu błędu przez wprowadzenie awarii procesu

Przykład:

W 1896 r. Sakichi Toyoda wynalazł pierwszy w Japonii krosno elektryczne o nazwie „krosno elektryczne Toyoda Steam”. Rozwój ten zwiększył wydajność dwudziestokrotnie, a jakość tekstyliów poprawiła się i spowodowała rewolucję w przemyśle tekstylnym w Japonii. Ale oto subtelne, ale bardzo ważne odkrycie i zasada:

kiedy igła pękła, maszyna zatrzymała się

Sakichi Toyoda stworzył innowację dla Krosna, która później stanie się jednym z filarów w Toyota Production System (Lean). Ten filar, który nazywamy teraz Jidoka, czasami nazywany „inteligentną automatyzacją z ludzkim dotykiem” lub „autonomią”.

W dużej mierze Andon (zatrzymaj się przy pierwszej usterce) i Poka-Yoke (zabezpieczenie przed błędami) to późniejsze osiągnięcia, które znajdują swój wpływ z Krosna.

Usuwanie słabości jednopunktowych

Termin słabość jednopunktowa odnosi się do tworzenia zwolnień w systemie jako podejścia do poprawy niezawodności systemu. Redundancję tworzy się poprzez zwiększenie liczby systemów lub osób zaangażowanych w proces. Posiadanie większej liczby systemów tworzenia kopii zapasowych lub większej liczby kontroli (podwójne, potrójne lub więcej) zwiększa prawdopodobieństwo, że proces będzie przebiegał poprawnie.

Doskonałym tego przykładem jest „zasada czterech oczu”, co oznacza, że ​​„wszystkie decyzje biznesowe i transakcje wymagają zatwierdzenia przez CEO i CFO. Ponieważ CFO nie zgłasza się do CEO, istnieje niezależny mechanizm kontrolny” .

^{źródło: https://en.wikipedia.org/wiki/Two-man_rule}

Uczyń zagrożenia oczywistymi

Jeśli zagrożenia są oczywiste lub niemożliwe do osiągnięcia, ludzie nie mogą popełniać błędów. Na przykład kodowanie kolorami jest powszechnym podejściem do uczynienia błędów bardziej oczywistymi. Lub jeśli myślisz o różnych gniazdach komputerowych, które można wkładać tylko w jedną stronę, a nie w drugą stronę itp.

Kilka świetnych książek mówi o tym temacie i nie wspominając o nich, nie byłby dobrą odpowiedzią:

• Field Guide to Understanding „Human Error” autorstwa Sidneya Dekkera
• Inżynieria niezawodności witryny: jak Google obsługuje systemy produkcyjne
• Zero kontroli jakości: kontrola źródła i system Poka-Yoke autorstwa Shigeo Shingo

Jak powiedział @bradim, użycie narzędzia CI / CD do zainicjowania wdrożenia zamiast ręcznych poleceń jest zwykle dobrym krokiem naprzód, podobnie jak dodanie testów w potoku, które faktycznie testują skrypty wdrażania w środowisku testowym (lub świeżo utworzonym), w którym możesz zbierać błędy wcześniej.

Dodałbym również, że zamiast bezpośrednio wywoływać skrypty ansible, możesz również dodać narzędzia takie jak Ansible Tower do swojego przepływu, co pozwoli ci łatwiej śledzić zmiany, które zostały uruchomione, i da ci dodatkowy krok bezpieczeństwa pływ.