Як убезпечити розгортання з метою зменшення аварій?

Нещодавно у Amazon S3 відбувся серйозний збій у регіоні us-1-us. Схоже, це, ймовірно, було викликано орфографічною помилкою під час запуску технічної книги з технічного обслуговування в 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 "$@"

Але які ще інші способи ви використовуєте для підвищення безпеки та зменшення ймовірності помилок, що спричинить серйозні перебої у вашій компанії.

Ми використовуємо завдання в джинкінах для запуску розгортань. Це гарантує, що незалежно від того, хто виконує розгортання, команда ansible, яка виконується, буде однаковою. Приємним бонусом є запис журналів збирання при запуску розгортань, хто їх ініціював і що саме сталося під час розгортання.

Це, звичайно, не безглуздо, але це було приємне вдосконалення в порівнянні з керуванням рухомими іграми вручну.

Для більш великих / ризикованих змін це в ідеалі має поєднуватися з якоюсь формою управління змінами, тому зміни вносяться лише після того, як інша особа / команда перегляне зміни та підхід до змін, щоб допомогти завчасно визначити та вирішити потенційні проблеми.

Крім того, ніколи не зашкодить мати товариша по команді, який розуміє зміни, які ви вносите, і які вони спостерігають, коли ви робите великі зміни, щоб вони могли спостерігати і допомогти запобігти помилкам у виконанні зміни.

Категорії помилок

Існує два способи розгляду людських факторів, які призводять до проблем та аварій:

1. Ви можете бачити помилку людини як причину випадкових випадків. У цьому випадку "людська помилка" під будь-якою міткою - втрата поінформованості про ситуацію, порушення процедур, порушення законодавства, недоліки в управлінні - це висновок вашого слідства.
2. Ви можете бачити людську помилку як симптом глибшої неприємності. У цьому випадку людська помилка є відправною точкою для вашого розслідування. Ви дізнаєтеся, як людська помилка систематично пов’язана з особливостями інструментів, завдань та операційного / організаційного середовища людей.

Перший називається підходом людини , а другий - системним підходом.

Щоб пояснити невдачу за допомогою людського підходу, ви б шукали невдачі та знаходили неточні оцінки людей, неправильні рішення чи неправильні судження.

Щоб пояснити збій за допомогою системного підходу, ви не намагаєтесь знайти, де люди пішли не так. Натомість знайдіть, як оцінки та дії людей мали сенс у той час, враховуючи обставини, що їх оточували.

Наприклад, Дональд Бервік з Інституту вдосконалення охорони здоров'я (IHI) стверджує, що підвищення безпеки пацієнтів потребує змін у дизайні систем :

... Ми люди, а люди помиляємось. Незважаючи на обурення, незважаючи на горе, незважаючи на досвід, незважаючи на наші зусилля, незважаючи на наші найглибші побажання, ми народжуємося помилковими і залишимось такими. Обережність допомагає, але це ніде не досягає досконалості ... Засіб полягає у зміні систем роботи. Засіб - в дизайні. Мета повинна бути надзвичайною безпекою. Я вважаю, що ми повинні бути такими ж безпечними у своїх лікарнях, як і в наших будинках. Але ми не можемо досягти цієї мети через умовляння, осуд, обурення та сором. Ми можемо досягти цього лише зобов'язанням змінитись, щоб нормальні людські помилки могли бути невідповідними до результату, постійно їх знаходити та вміло пом'якшувати.

Дональд Бервік. Тільки не знову! BMJ 2001

Видалення помилок із системи

Прекрасний спосіб знайти (і виправити) різні способи невдачі після факту - це пошук першопричини, не звинувачуючи людей. Це часто називають "непорочними посмертними", і Etsy Code як повідомлення про блог Craft розширюється на концепції. Люди в Etsy представляли та писали більше про це на інших форумах та блогах.

Щоб запобігти помилкам, насамперед, деякі риси культури є обов'язковими. Процедури та різні артефакти, створені в системі, повинні перевірити, що використання ними людьми є дуже зрозумілим і зрозумілим. Часто ті, хто створюють, не є тими, хто споживає, що призводить до відключення та недостатньої ясності. Потім система не є безпечною для роботи, оскільки єдиною людиною, яка знає всі припущення, є той, хто її створив (і ніхто більше).

Ефективні заходи контролю

Введіть ефективні заходи контролю для зупинки процесу, коли виникає помилка. Це помилка. Ефективні заходи контролю - це зміни в дизайні, які запобігають або зупиняють продовження процесів, коли сталася помилка, вводячи помилку процесу

Приклад:

У 1896 р. Sakichi Toyoda винайшов перший в Японії електромобільний верстат під назвою "Тендерний верстат парового Toyoda". Цей розвиток збільшив продуктивність в двадцять разів, а якість текстилю покращилася і спричинила революцію в текстильній промисловості Японії. Але ось тонке, але дуже важливе відкриття та принцип:

коли голка зламалася, машина зупинилася

Sakichi Toyoda створив інновацію для верстата, який згодом стане одним із стовпів у виробничій системі Toyota (Lean). Цей стовп, який ми сьогодні називаємо Джидока, іноді називають "розумною автоматизацією з людським дотиком" або "автономністю".

Здебільшого Андон (зупинка на першому дефекті) та Пока-Йоке (доведення помилок) - пізніші розробки, які знаходять свій вплив із ткацького верстата.

Усунення одноточкових слабкостей

Термін одноточкова слабкість позначає створення надмірностей у системі як підхід до підвищення надійності системи. Надлишок створюється за рахунок збільшення кількості систем або осіб, які беруть участь у процесі. Наявність більшої кількості резервних систем або більше перевірок (подвійних, потрійних або більше) збільшує ймовірність того, що процес буде протікати правильно.

Одним чудовим прикладом цього є "принцип на чотири очі", який означає, що "всі бізнес-рішення та операції потребують схвалення генерального директора та фінансового директора. Оскільки фінансовий директор не звітує перед генеральним директором, існує незалежний механізм контролю". .

^{джерело: https://en.wikipedia.org/wiki/Two-man_rule}

Зробити небезпеки очевидними

Якщо небезпеки стануть очевидними або неможливо досягти, людина не може створювати помилок. Наприклад, кольорове кодування є загальним підходом до того, щоб зробити помилки більш очевидними. Або якщо ви думаєте про різні розетки для комп'ютерів, які можна вставити лише в один бік, а не в інший і т.д.

Деякі чудові книги говорять про цю тему, і це не буде гарною відповіддю, не згадуючи про них:

• Польовий посібник із розуміння "людської помилки" Сідні Деккер
• Інженерія надійності сайту: як Google працює з виробничими системами
• Нульовий контроль якості: інспекція джерел та система Poka-Yoke від Shigeo Shingo

Як @bradim сказав, що використання інструмента CI / CD для ініціювання розгортання замість команд, заснованих вручну, зазвичай є хорошим кроком вперед, як і додавання тестів у ваш конвеєр, які фактично перевіряють ваші сценарії розгортання у вашому стаціонарному (або щойно створеному) середовищі, де ви можете підбирати помилок раніше.

Я також додав би, що замість того, щоб безпосередньо викликати ваші відповідальні сценарії, ви також можете додавати у свій потік такі інструменти, як Ansible Tower , що дозволить вам відслідковувати зміни, які були запущені, і може дати додатковий крок безпеки у вашій потік.