Каковы возможные реализации (или примеры) принципа четырех глаз?

22

Михаэль Грюневальд недавно опубликовал этот комментарий :

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

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

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

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

Pierre.Vriens
источник

Ответы:

11

Одной из реализаций кода является модель Pull Request Model (PR), популяризованная GitHub.

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

Это позволяет автоматически проверять слияние с реальным (основным) кодом с кодом в PR (Travis является самым популярным для публичного проекта) и дает первую обратную связь по качеству кода. Travis CI (например) может работать на результате фактического мастера с кодом из запроса извлечения, слитым в него, поэтому он потерпит неудачу, если объединение невозможно или если команды, определенные в travisci.yml, возвращают ненулевой выход код

После того, как автоматические тесты пройдены, для принципа 4 глаза все еще требуется настраиваемое количество людей, чтобы рассмотреть и утвердить изменение, прежде чем оно будет объединено, очевидно, по крайней мере, 1 человек (который не является автором PR), чтобы принудить 4 глаза пересмотреть меняется.

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

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

Tensibai
источник
Пожалуйста, проверьте незначительное редактирование вашего ответа (опечатки). Если они вам не нравятся, просто откат или повторное редактирование, хорошо? Кроме того, я не думал об этих PR, так что я думаю, что они очень применимы. Я собираюсь пометить этот ответ как принятый (я «чему-то научился», то, что в моем собственном ответе я, конечно, знал сам). Хотя я не гарантирую в будущем, я мог бы передумать (не принять), если будет опубликован еще лучший ответ. О: «Это позволяет автоматически проверять слияние с реальным релизным (основным) кодом с кодом в PR», я не понимаю, стоит ли публиковать новый вопрос?
Pierre.Vriens
@pierre, вы можете менять свое мнение так часто, как пожелаете :) Для тестирования предложенного кода Travis CI (например,) может работать на результате реального мастера с объединенным в него кодом запроса на извлечение, поэтому он будет потерпеть неудачу, если объединение невозможно или если команды, определенные в travisci.yml, возвращают ненулевой код выхода. FWIW, гуглить звук лучший подход ИМХО, тема большая
Tensibai
@pierre и для редактирования, только один пункт, 4 глаза принцип должен иметь еще 1 человека, чтобы просмотреть, что означает, что 2 человека действительно просмотрели изменение (автор не рассматривал его), следовательно, единственное число на переменное количество человек ( как это может быть только один, а на французском языке, может быть, только один является единственным: р). Я не так свободно говорю по-английски, как хотелось бы, но я думаю, что первый пункт верен (2 читателя, 2 просмотрели его, сделав один обзор), во-вторых, я могу быть предвзятым :)
Тенсибай
ага, это то, что вы имеете в виду, теперь я понял (и позволил себе скопировать / вставить дополнительные пояснения в ваш ответ). КСТАТИ: экс mple (ЕН), а не бывший е mple (как в FR) ...
Pierre.Vriens
@ Pierre.Vriens обвиняют в автокоррекции с двойным языком :)
Tensibai
9

Код Отзывы

Речь идет о том, чтобы хотя бы еще один человек посмотрел на код, написанный кем-то, например, чтобы оценить, соответствует ли он некоторым заранее определенным критериям, таким как:

  • Стандарты кодирования (отступы и т. Д.).
  • Встроенная документация.
  • Ремонтопригодность кода.
  • Обработка ошибок.
  • Полнота (например, if/then/elseили case/whenконструкции охватывают все возможные случаи).

Одобрения для обновления некоторых целевых сред

Речь идет о наличии как минимум 2 подтверждений от какого-либо человека и / или автоматизированной системы, прежде чем будет разрешено обновить какую-либо целевую среду (которая может быть активной или может быть чем-то вроде некоторого основного файла / базовой библиотеки). Вот некоторые примеры:

  • При преобразовании (построении) исходных компонентов в исполняемые компоненты допускается только ограниченный набор предупреждений.
  • Некоторый набор автоматических тестов должен быть выполнен без каких-либо проблем.
  • Некоторые люди должны были указать свое предварительное одобрение (и без этого любые попытки обновить целевые среды автоматически потерпят неудачу).
Pierre.Vriens
источник
6

Это стратегии / модели, которые я могу придумать:

Разделение обязанностей

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

Например, если оператор SQL должен выполняться в реальной среде, один записывает SQL, а другой выполняет его. Это предполагает, что тот, кто выполняет, должен также иметь представление о SQL, а не просто выполнять.

Развернуть триггер

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

После запуска автоматизация может выполнить развертывание.

Парное программирование

Лично я не привел этот метод в качестве метода для аудитора, чтобы удовлетворить принцип проверки и баланса. Но потенциально я думаю, что это может быть стратегия.

МИД

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

kenchew
источник
Мерси за эти интересные вариации! Никогда раньше не слышал об этом «парном программировании», это действительно похоже на вариацию игры на пианино «4 руками»!
Pierre.Vriens
1
Недавно я брал интервью у компании, которая занимается самой интенсивной формой парного программирования, которую я когда-либо видел. У них были установки «под» с двумя компьютерами, каждый с одним выделенным монитором и одним общим монитором. ВСЕ разработки проводились парами. Это не для всех, но по всем отчетам это работает хорошо для них.
Дэйв Сверски