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

12

Недавно у 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 "$@"

Но какие еще способы вы можете использовать для повышения безопасности и уменьшения вероятности ошибки, которая может привести к серьезным сбоям в работе вашей компании.

Иржи Клауда
источник
1
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что он больше подходит для unix.stackexchange.com или superuser.com
Ромео Нинов
4
Инфраструктура, как код, является одним из ключевых компонентов для доступа к сотням развертываний в день. Возможность защитить инструменты, обеспечивающие эту скорость, от значительного сбоя в работе, кажется мне актуальной темой. Я могу ошибаться, конечно. Я ценю ваше мнение, хотя. Хотели бы вы присоединиться к обсуждению вопросов по теме и вне темы в Meta?
Иржи Клуда
Например, этот вопрос, кажется, принят как по теме: devops.stackexchange.com/questions/98/…
Иржи Клуда
Иржи, ты делаешь разницу между своим и другим вопросом, который ты упоминаешь?
Ромео Нинов
5
Если такие вопросы подходят для суперпользователя, не будет необходимости в devops.se. Это определенно по теме здесь. Операции и смягчение человеческих ошибок лежат в основе DevOps.
Евгений

Ответы:

6

Мы используем задания в Jenkins для запуска развертываний. Это гарантирует, что независимо от того, кто выполняет развертывание, выполняемая команда ansible будет одинаковой. Приятным бонусом является запись в журналах сборки, когда были запущены развертывания, кто их инициировал и что именно произошло во время развертывания.

Это, конечно, не надежно, но это было приятное улучшение по сравнению с ручным управлением сборниками.

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

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

bradym
источник
4

Категории ошибок

Есть два способа взглянуть на человеческий фактор, который приводит к проблемам и несчастным случаям:

  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

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

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


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

Евгений
источник
1
Очень важный метод, который вы не упоминаете, - это «принцип четырех глаз», который используется в финансах - либо в качестве регулирующего обязательства, либо в качестве гарантии безопасности. В индустрии программного обеспечения это реализуется различными способами, например, для проверки кода, но также может использоваться для проверки команд, влияющих на работающие системы.
Михаэль Ле Барбье Грюневальд,
Я добавлю это к принципу SPW.
Евгений,
1
Отличное обсуждение ошибок, но в нем не говорится, как защитить себя от случайных развертываний.
Александр
1
Вопрос об Ansible задается конкретно. Этот ответ очень тщательный и хорошо проработанный, но он на шаг от проблемы реального мира.
Лесной Охотник
1
@Evgeny Когда я ответил на ваш вопрос о производительности AWS Lambda, сначала я не сказал, как проводить тесты, и вы указали на это. Вы были правы, и я исправил свой ответ. Я понимаю людей, которые голосуют здесь за ваш ответ. Ваш ответ был бы хорош для вопроса «Как подойти и уменьшить количество ошибок на нашем рабочем месте?». Здесь у OP есть вопрос об Ansible, и вы даже не упоминаете об этом. Хуже того, OP указывает на то, какое решение он ищет, и вы идете другим путем. Ваш ответ отличный (правда), но не на этот вопрос.
Александр
1

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

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

SztupY
источник