Как защитить развертывание Ansible от несчастных случаев?

Недавно у Amazon S3 произошел серьезный сбой в регионе США-Восток-1. Похоже, что это, вероятно, было вызвано орфографической ошибкой при запуске Playbook обслуживания в 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) утверждает, что повышение безопасности пациентов требует изменений в конструкции систем :

... Мы люди, а люди заблуждаются. Несмотря на возмущение, несмотря на горе, несмотря на опыт, несмотря на все наши усилия, несмотря на наши самые глубокие пожелания, мы рождены ошибочными и останемся таковыми. Быть осторожным помогает, но оно не приближает нас к совершенству ... Средство заключается в изменении системы работы. Средство находится в дизайне. Целью должна быть чрезвычайная безопасность. Я считаю, что мы должны быть в безопасности в наших больницах, как и в наших домах. Но мы не можем достичь этой цели через увещевание, осуждение, возмущение и стыд. Мы можем достичь этого только обязательством измениться, чтобы обычные человеческие ошибки можно было сделать несоответствующими результату, постоянно находить и умело смягчать.

Дональд М Бервик. Не снова! BMJ 2001

Удаление ошибок из системы

Отличный способ найти (и исправить) различные способы неудачи, произошедшие после свершившегося факта, - это найти причину, не обвиняя людей. Это часто называют «безупречной смертью», и Etsy Code как пост Craft расширяет эту концепцию. Люди в Etsy представили и написали больше об этом на других форумах и блогах.

Во-первых, чтобы избежать ошибок, некоторые культурные особенности просто необходимы. Процедуры и различные артефакты, созданные в системе, должны проверять, что их использование людьми очень понятно и самоочевидно. Часто те, кто создают, не являются потребителями, что приводит к разъединению и отсутствию ясности. В этом случае система не безопасна в эксплуатации, поскольку единственный человек, который знает все предположения, - это тот, кто ее создал (и никто другой).

Эффективные меры контроля

Принять эффективные меры контроля, чтобы остановить процесс при возникновении ошибки. Это защита от ошибок. Эффективные меры контроля - это изменения в конструкции, которые препятствуют или останавливают продолжение процессов при возникновении ошибки путем введения сбоя процесса.

Пример:

В 1896 году Сакичи Тойода изобрел первый в Японии ткацкий станок с электроприводом, названный «Ткацкий станок с паровым приводом Toyoda» Это развитие увеличило производительность труда в двадцать раз, а качество текстиля улучшилось и вызвало революцию в текстильной промышленности Японии. Но вот тонкое, но очень важное открытие и принцип:

когда сломалась игла, машина остановилась

Сакичи Тойода создал для Loom новшество, которое позже станет одним из столпов в производственной системе Toyota (Lean). Этот столп, который мы сейчас называем Джидока, иногда называют «умной автоматизацией с человеческим прикосновением» или «автономией».

По большей части, Andon (остановка на первом дефекте) и Poka-Yoke (исправление ошибок) являются более поздними разработками, которые находят свое влияние от Ткацкого станка.

Устранение одноточечных недостатков

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

Одним из ярких примеров этого является «принцип четырех глаз», который означает, что «все бизнес-решения и транзакции должны быть одобрены генеральным директором и финансовым директором. Поскольку финансовый директор не отчитывается перед генеральным директором, существует независимый механизм контроля». ,

^{источник: https://en.wikipedia.org/wiki/Two-man_rule}

Сделать опасности очевидными

Если опасность становится очевидной или недоступной, люди не могут совершать ошибки. Например, цветовое кодирование - это общий подход к тому, чтобы сделать ошибки более очевидными. Или если вы думаете о различных компьютерных разъемах, которые можно вставить только одним способом, а не другим, и т. Д.

Некоторые великие книги говорят о предмете, и это не будет хорошим ответом, если не упомянуть их:

• Полевое руководство по пониманию «человеческой ошибки» Сидни Деккера
• Разработка надежности сайта: как Google управляет производственными системами
• Нулевой контроль качества: проверка источника и система Poka-Yoke от Shigeo Shingo

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

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