Quelles sont les implémentations (ou exemples) possibles du principe des quatre yeux?


22

Michael Grünewald a récemment publié ce commentaire :

Une méthode très importante que vous ne mentionnez pas est le «principe des quatre yeux» qui est utilisé dans la finance - soit comme une obligation réglementaire, soit comme un garde-fou. Dans l'industrie du logiciel, il est mis en œuvre de diverses manières, comme par exemple les revues de code, mais peut également être utilisé pour valider des commandes affectant des systèmes en direct.

Corrigez-moi si je me trompe, mais on m'a appris que le "principe des quatre yeux" concerne quelque chose qui est "approuvé pour se produire", après qu'au moins 2 êtres humains (et / ou processus automatisés) ont donné leur bénédiction préalable. Ou pour utiliser la formulation (légèrement corrigée) sur la "règle des deux (wo) hommes" de Wikipedia :

La règle des deux hommes est un mécanisme de contrôle conçu pour atteindre un niveau élevé de sécurité pour le matériel ou les opérations particulièrement critiques. En vertu de cette règle, tous les accès et actions nécessitent la présence de deux personnes autorisées à tout moment.

Les obligations réglementaires sont, bien sûr, hors sujet ici, mais dans le contexte du "garde-fou", quelles sont les implémentations conceptuelles possibles de ce principe à quatre yeux, qui pourraient probablement s'appliquer à n'importe quelle plate-forme / OS / matériel utilisé?

Réponses:


11

L'une des implémentations sur le code est le modèle Pull Request (PR) popularisé par GitHub.

Le principal raisonnement derrière est que seul un petit ensemble de responsables du produit sera autorisé à fusionner le code dans la branche de publication. Chaque nouvelle fonctionnalité / correction de bug se produira sur une nouvelle branche et une fois terminée sera définie comme une demande de pull.

Cela permet de tester automatiquement la fusion du code de sortie (maître) réel avec le code du PR (Travis étant le plus populaire pour les projets publics) et de donner un premier retour sur la qualité du code. Travis CI (par exemple) peut s'exécuter sur le résultat du maître réel avec le code de la demande d'extraction fusionné dedans, il échouera donc si la fusion est impossible, ou si les commandes définies dans le travisci.yml renvoient une sortie non nulle code

Une fois les tests automatiques réussis, pour le principe des 4 yeux, il faut toujours un nombre configurable de personnes pour réviser et approuver le changement avant qu'il ne soit fusionné évidemment au moins 1 personne (qui n'est pas l'auteur des RP) pour appliquer 4 yeux examinant le changements.

Il existe un large éventail d'options pour fusionner automatiquement une fois que le quorum des réviseurs est atteint ou encore nécessiter une fusion manuelle par un responsable.

Les autorisations de révision et de fusion peuvent être séparées, ce qui permet de donner à plus de personnes le droit de «voter» sur le statut de la fusion tout en gardant la possibilité de restreindre qui peut réellement effectuer la fusion.


Veuillez vérifier la modification mineure de votre réponse (erreurs typographiques). Si vous ne les aimez pas, restaurez ou rééditez, ok? De plus, je n'avais pas pensé à ces relations publiques, donc certainement très applicable je pense. Je vais marquer cette réponse comme acceptée (j'en ai "appris" quelque chose, les choses dans ma propre réponse que je connaissais bien sûr moi-même). Bien que je ne garantisse pas à l'avenir, je pourrais changer d'avis (refus) si une réponse encore meilleure était publiée. À propos de: "Cela permet de tester automatiquement la fusion à partir du code de sortie (maître) réel avec le code du PR", je ne comprends pas, dois-je poster une nouvelle question?
Pierre.Vriens

@pierre vous êtes libre de changer d'avis aussi souvent que vous le souhaitez :) Pour le test du code proposé, Travis CI (par exemple) peut fonctionner sur le résultat du maître réel avec le code de demande de pull fusionné, donc il échouent si la fusion est impossible ou si les commandes définies dans travisci.yml renvoient un code de sortie non nul. FWIW, googler son la meilleure approche à mon humble avis, le sujet est grand
Tensibai

@pierre et pour l'édition, un seul point, le principe des 4 yeux est d'avoir 1 personne de plus à revoir, ce qui signifie que 2 personnes ont vu le changement (l'auteur ne l'a pas revu), d'où le singulier sur le nombre variable de personne ( car il ne peut en être qu'un, et en français peut-être un seul est singulier: p). Je ne parle pas aussi bien l'anglais que je le souhaiterais, mais je pense que le premier point est valide (2 lecteurs, 2 l'ont vu en faire une seule critique), pour le second, je peux être biaisé :)
Tensibai

aha, c'est ce que tu veux dire, maintenant je comprends (et j'ai pris la liberté de copier / coller la clarification supplémentaire dans votre réponse). BTW: ex a mple (en EN), pas ex e mple (comme en FR) ...
Pierre.Vriens

@ Pierre.Vriens blâme la correction automatique en double langue :)
Tensibai

9

Revues de code

Il s'agit de demander à au moins une autre personne de regarder le code écrit par quelqu'un, par exemple pour évaluer s'il répond à certains critères prédéfinis comme:

  • Normes de codage (indentations, etc.).
  • Documentation en ligne.
  • Maintenabilité du code.
  • La gestion des erreurs.
  • Exhaustivité (par exemple, if/then/elseou les case/whenconstructions couvrent tous les cas possibles).

Approbations pour mettre à jour certains environnements cibles

Il s'agit d'avoir au moins 2 confirmations d'une personne et / ou d'un système automatisé avant qu'il ne soit autorisé à mettre à jour un environnement cible (qui peut être actif, ou peut être quelque chose comme un fichier maître / une bibliothèque de base). Certains exemples sont:

  • Seul un ensemble limité d'avertissements est autorisé lors de la transformation (construction) de composants source en composants exécutables.
  • Certains ensembles de tests automatisés doivent avoir été exécutés sans aucun problème.
  • Certains êtres humains doivent avoir indiqué leur approbation préalable (et sans cela, toute tentative de mise à jour des environnements cibles échouera automatiquement).

6

Ce sont des stratégies / modèles auxquels je peux penser:

Séparation des fonctions

DevOps, à mon avis du moins, ne signifie pas incarner à la fois les dev et les ops en une seule personne. Il est donc toujours possible de séparer le devoir de telle sorte que celui qui écrit le code (dev) n'est pas celui qui l'exécute (ops).

Par exemple, si une instruction SQL doit être exécutée sur l'environnement réel, l'une écrit le SQL et l'autre l'exécute. Cela présuppose que celui qui exécute doit également avoir une compréhension du SQL et ne pas simplement l'exécuter.

Déployer le déclencheur

Bien qu'il y ait du mérite à se déployer en continu. L'équipe d'une industrie plus réglementée peut désigner une autre partie (distincte) pour déclencher le déploiement au lieu de se déployer automatiquement. Liste de contrôle, tests automatisés, sommes de contrôle sont des vérifications possibles avant de déclencher le déploiement.

Une fois déclenchée, l'automatisation peut aller de l'avant pour exécuter le déploiement.

Programmation en binôme

Personnellement, je n'ai pas cité cette technique comme méthode à suivre par l'auditeur pour satisfaire au principe du contrôle et de l'équilibre. Mais potentiellement, je pense que cela peut être une stratégie.

MFA

Je vais peut-être m'étirer un peu avec celui-ci, mais il est possible que, pour une raison quelconque, vous ne souhaitiez pas une entrée unilatérale dans un système, quelqu'un puisse détenir le mot de passe et une autre personne détienne le jeton ou l'appareil pour un code temporel. Pour que 2 personnes soient présentes pour évaluer le système.


Merci pour ces variations intéressantes! Jamais entendu parler de cette "programmation par paire" auparavant, cela ressemble vraiment à une variation de jouer un piano à "4 mains"!
Pierre.Vriens

1
J'ai récemment interviewé une entreprise qui propose la forme de programmation de paires la plus intensive que j'ai jamais vue. Ils avaient des configurations «pod» avec deux machines, chacune avec un moniteur dédié et un moniteur partagé. TOUS les développements ont été effectués par paires. Ce n'est pas pour tout le monde, mais selon tous les rapports, cela fonctionne bien pour eux.
Dave Swersky
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.