La question « comment implémenter le DevOps » se pose depuis des années, mais il n'existe pas beaucoup de bons documents. Parfois, vous êtes victime de publicités de consultants pas si intelligents qui ont besoin de vendre leur temps, peu importe comment. Parfois, ce sont des mots vagues et extrêmement généraux sur la façon dont les navires des mégacorporations sillonnent les étendues de l'univers. La question se pose : qu’est-ce que cela nous importe ? Cher auteur, pouvez-vous formuler clairement vos idées dans une liste ?
Tout cela vient du fait que peu de pratiques réelles et de compréhension des résultats des transformations de la culture d’entreprise ont été accumulées. Les changements de culture sont des choses à long terme dont les résultats n’apparaîtront pas en une semaine ou un mois. Nous avons besoin de quelqu’un suffisamment âgé pour avoir vu comment les entreprises se sont construites et ont échoué au fil des ans.
John Willis - l'un des pères du DevOps. John possède des décennies d'expérience de travail avec un grand nombre d'entreprises. Récemment, John a commencé à remarquer des schémas spécifiques qui se produisaient lorsqu'il travaillait avec chacun d'eux. En utilisant ces archétypes, John guide les entreprises sur la véritable voie de la transformation DevOps. Apprenez-en davantage sur ces archétypes dans la traduction de son rapport de la conférence DevOops 2018.
À propos de l'orateur :
Plus de 35 ans dans la gestion informatique, a participé à la création du prédécesseur d'OpenCloud chez Canonical, a participé à 10 startups, dont deux ont été vendues à Dell et Docker. Il est actuellement vice-président du DevOps et des pratiques numériques chez SJ Technologies.
Vient ensuite l'histoire du point de vue de John.
Je m'appelle John Willis et l'endroit le plus simple pour me trouver est sur Twitter, . J'ai le même alias sur Gmail et GitHub. UN vous pouvez trouver des enregistrements vidéo de mes rapports et présentations pour ceux-ci.
J'ai de nombreuses réunions avec les DSI de diverses grandes entreprises. Ils se plaignent très souvent de ne pas comprendre ce qu’est le DevOps, et tous ceux qui tentent de le leur expliquer parlent de quelque chose de différent. Une autre plainte courante est que DevOps ne fonctionne pas, même s'il semble que les administrateurs font tout comme on leur a expliqué. Nous parlons de grandes entreprises vieilles de plus de cent ans. Après avoir discuté avec eux, je suis arrivé à la conclusion que pour de nombreux problèmes, ce n'est pas la haute technologie qui est la mieux adaptée, mais plutôt des solutions relativement low-tech. Pendant des semaines, j'ai juste parlé à des gens de différents départements. Ce que vous voyez sur la toute première photo du post est mon dernier projet, voici à quoi ressemblait la pièce après trois jours de travail.
Qu’est-ce que DevOps ?
En effet, si vous posez la question à 10 personnes différentes, elles vous donneront 10 réponses différentes. Mais voici ce qui est intéressant : ces dix réponses seront toutes correctes. Il n’y a pas de mauvaise réponse ici. J'ai été assez passionné par le DevOps pendant environ 10 ans et j'ai été le premier Américain au premier DevOpsDay. Je ne dirai pas que je suis plus intelligent que toutes les personnes impliquées dans le DevOps, mais pratiquement personne n’y a consacré autant d’efforts. Je crois que DevOps se produit lorsque le capital humain et la technologie se rencontrent. On oublie souvent la dimension humaine, même si on parle beaucoup de toutes sortes de cultures.
Nous disposons désormais de beaucoup de données, de cinq années de recherche universitaire, de tests de théories à l’échelle industrielle. Ce que ces études nous disent, c'est que si vous combinez certains modèles de comportement dans une culture organisationnelle, vous pouvez obtenir une accélération de 2000 5000 fois. Cette accélération s’accompagne d’une amélioration égale de la stabilité. Il s’agit d’une mesure quantitative des avantages que DevOps peut apporter à toute entreprise. Il y a quelques années, je parlais de DevOps au PDG d'une entreprise Fortune 5. Lorsque je préparais la présentation, j'étais très nerveux car je devais résumer mes années d'expérience en XNUMX minutes.
Au final j'ai donné ce qui suit Définition du DevOps: C'est un ensemble de pratiques et de modèles qui permettent la transformation du capital humain en capital organisationnel performant. Un exemple est la façon dont Toyota a fonctionné au cours des 50 ou 60 dernières années.
(Ci-après, ces diagrammes sont fournis non pas à titre de matériel de référence, mais à titre d'illustrations. Leur contenu différera pour chaque nouvelle entreprise. Cependant, l'image peut être visualisée séparément et agrandie
L'une des pratiques de ce type les plus réussies est cartographie des flux. Plusieurs bons livres ont été écrits à ce sujet, dont les plus réussis sont ceux de Karen Martin. Mais au cours de la dernière année, je suis arrivé à la conclusion que même cette approche est trop high-tech. Il présente certainement de nombreux avantages et je l'ai beaucoup utilisé. Mais lorsque le PDG vous demande pourquoi son entreprise ne peut pas passer à de nouveaux rails, il est trop tôt pour parler de cartographie de la chaîne de valeur. Il existe de nombreuses questions bien plus fondamentales auxquelles il faut d’abord répondre.
Je pense que l'erreur que font beaucoup de mes collègues est de donner simplement à l'entreprise un guide en cinq points, puis de revenir six mois plus tard et de voir ce qui s'est passé. Même un bon système comme la cartographie de la chaîne de valeur comporte, disons, des angles morts. Après des centaines d'entretiens avec des dirigeants de diverses entreprises, j'ai développé un certain modèle qui nous permet de décomposer le problème en ses composantes, et nous allons maintenant discuter de chacune de ces composantes dans l'ordre. Avant d'appliquer des solutions technologiques, j'utilise ce motif et du coup, tous mes murs sont recouverts de schémas. Récemment, je travaillais avec un fonds commun de placement et je me suis retrouvé avec 100 à 150 projets de ce type.
La mauvaise culture mange les bonnes approches pour le petit-déjeuner
L’idée principale est la suivante : aucune approche Lean, Agile, SAFE et DevOps ne sera utile si la culture de l’organisation elle-même est mauvaise. C'est comme plonger dans les profondeurs sans équipement de plongée ou opérer sans rayons X. En d’autres termes, pour paraphraser Drucker et Deming : une mauvaise culture organisationnelle engloutira tout bon système sans s’étouffer avec lui.
Pour résoudre ce problème principal, vous devez suivre les étapes suivantes :
- Rendre tous les travaux visibles : vous devez rendre tout le travail visible. Non pas dans le sens où il doit nécessairement être affiché sur un écran, mais dans le sens où il doit être observable.
- Systèmes de gestion du travail consolidés : les systèmes de gestion doivent être consolidés. Dans le problème des connaissances « tribales » et des connaissances institutionnelles, dans 9 cas sur 10, le goulot d’étranglement vient des personnes. Dans le livre le problème venait d'une seule personne, Brent, qui a provoqué un retard de trois ans sur le projet. Et je rencontre ces « Brents » partout. Pour résoudre ces goulots d'étranglement, j'utilise les deux éléments suivants de notre liste.
- Méthodologie de la théorie des contraintes : Théorie des contraintes.
- Astuces de collaboration : hacks de collaboration.
- Toyota Kata (): Je ne parlerai pas beaucoup de la Toyota Kata. Si vous êtes intéressé, sur mon github sur presque chacun de ces sujets.
- Organisation orientée marché : organisation orientée vers le marché.
- Auditeurs Shift-gauche : audit dès les premiers stades du cycle.
Je commence à travailler avec une organisation très simplement : je vais dans l'entreprise et je parle avec les salariés. Comme vous pouvez le constater, pas de haute technologie. Tout ce dont vous avez besoin c'est de quelque chose sur quoi écrire. Je rassemble plusieurs équipes dans une même pièce et analyse ce qu'elles me disent du point de vue de mes 7 archétypes. Ensuite, je leur donne eux-mêmes un marqueur et je leur demande d'écrire au tableau tout ce qu'ils ont dit à voix haute jusqu'à présent. Habituellement, dans ce type de réunions, il y a une personne qui écrit tout, et au mieux, elle peut écrire 10 % de la discussion. Avec ma méthode, ce chiffre peut être porté à environ 40 %.
(Cette illustration peut être visualisée séparément )
Mon approche s'appuie sur les travaux de William Schneider. ). L’approche repose sur l’idée que toute organisation peut être divisée en quatre carrés. Pour moi, ce schéma est généralement le résultat d’une collaboration avec des centaines d’autres schémas qui surviennent lors de l’analyse d’une organisation. Supposons que nous ayons une organisation avec un niveau de contrôle élevé, mais avec peu de compétences. Il s’agit d’une option extrêmement indésirable : lorsque tout le monde suit la ligne, mais que personne ne sait quoi faire.
Une option légèrement meilleure est celle offrant un niveau élevé de contrôle et de compétence. Si une telle entreprise est rentable, elle n’a peut-être pas besoin de DevOps. Il est très intéressant de travailler avec une entreprise qui a un haut niveau de contrôle, peu de compétences et de coopération, mais en même temps un haut niveau de culture (cultivation). Cela signifie que l'entreprise compte de nombreuses personnes qui aiment y travailler et que la rotation de la main-d'œuvre est faible.
(Cette illustration peut être visualisée séparément )
Il me semble que les méthodes aux lignes directrices rigides finissent par faire obstacle à l’obtention de la vérité. Dans la cartographie des flux de valeur en particulier, il existe de nombreuses règles concernant la manière dont les informations doivent être structurées. Dans les premières étapes du travail, dont je parle maintenant, personne n’a besoin de ces règles. Si une personne avec un marqueur à la main décrit la situation réelle de l'entreprise au tableau, c'est la meilleure façon de comprendre l'état des choses. Ces informations ne parviennent pas aux administrateurs. À ce moment-là, il est stupide d'interrompre la personne et de dire qu'elle a mal dessiné une sorte de flèche. A ce stade, il est préférable d'utiliser des règles simples, par exemple : une abstraction multi-niveaux peut être créée simplement en utilisant des marqueurs multicolores.
Je le répète, pas de haute technologie. Le marqueur noir représente la réalité objective de la façon dont tout fonctionne. Avec un marqueur rouge, les gens marquent ce qu’ils n’aiment pas dans la situation actuelle. Il est important qu’ils écrivent ceci, pas moi. Lorsque je vais chez le CIO après une réunion, je ne propose pas de liste de 10 choses qui doivent être corrigées. Je m'efforce de trouver des liens entre ce que disent les gens de l'entreprise et les modèles existants et éprouvés. Enfin, un marqueur bleu suggère des solutions possibles au problème.
(Cette illustration peut être visualisée séparément )
Un exemple de cette approche est maintenant décrit ci-dessus. Au début de cette année, j'ai travaillé avec une banque. Les responsables de la sécurité étaient convaincus qu'ils ne devaient pas procéder à des révisions de conception et d'exigences.
(Cette illustration peut être visualisée séparément )
Et puis nous avons parlé à des personnes d'autres départements et il s'est avéré qu'il y a environ 8 ans, des développeurs de logiciels ont licencié des agents de sécurité parce qu'ils ralentissaient le travail. Et puis cela s’est transformé en une interdiction, qui était considérée comme allant de soi. Même si en réalité il n’y avait aucune interdiction.
Notre réunion s'est déroulée de manière extrêmement confuse : pendant environ trois heures, cinq équipes différentes n'ont pas pu m'expliquer ce qui se passait entre le code et l'assemblage. Et cela semble être la chose la plus simple. La plupart des consultants DevOps partent du principe que tout le monde le sait déjà.
Puis le responsable de la gouvernance informatique, resté silencieux pendant quatre heures, a soudainement repris vie lorsque nous avons abordé son sujet et nous a occupé très longtemps. A la fin, je lui ai demandé ce qu'il pensait de la rencontre et je n'oublierai jamais sa réponse. Il a déclaré : « Avant, je pensais que notre banque n’avait que deux façons de fournir des logiciels, mais maintenant je sais qu’il y en a cinq, et je n’en connaissais même pas trois. »
(Cette illustration peut être visualisée séparément )
La dernière réunion dans cette banque a eu lieu avec l'équipe des logiciels d'investissement. C'est avec elle qu'il s'est avéré qu'écrire des schémas avec un feutre sur une feuille de papier est mieux que sur un tableau, et encore mieux que sur un tableau intelligent.
Les photos que vous voyez montrent à quoi ressemblait la salle de conférence de l'hôtel le quatrième jour de notre réunion. Et nous avons utilisé ces schémas pour rechercher des modèles, c'est-à-dire des archétypes.
Alors, je pose des questions aux ouvriers, ils notent les réponses avec des feutres de trois couleurs (noir, rouge et bleu). J'analyse leurs réponses pour les archétypes. Parlons maintenant de tous les archétypes dans l'ordre.
1. Rendre visible tout le travail : Rendre le travail visible
La plupart des entreprises avec lesquelles je travaille ont un pourcentage très élevé de travaux inconnus. Par exemple, c’est lorsqu’un employé vient vers un autre et lui demande simplement de faire quelque chose. Dans les grandes organisations, il peut y avoir 60 % de travail non planifié. Et jusqu’à 40 % du travail n’est en aucun cas documenté. Si c’était Boeing, je ne monterais plus jamais dans leur avion de ma vie. Si seulement la moitié du travail est documenté, on ne sait pas si ce travail est effectué correctement ou non. Toutes les autres méthodes s'avèrent inutiles - cela n'a aucun sens d'essayer d'automatiser quoi que ce soit, car les 50 % connus peuvent être la partie la plus cohérente et la plus claire du travail, dont l'automatisation ne donnera pas de bons résultats, et tout le pire les choses sont dans la moitié invisible. En l'absence de documentation, il est impossible de trouver toutes sortes de hacks et de travaux cachés, ni de trouver des goulots d'étranglement, ces mêmes « Brents » dont j'ai déjà parlé. Il existe un livre merveilleux de Dominica DeGrandis . Elle révèle cinq "fuites temporelles" différentes (voleurs de temps):
- Trop de travaux en cours (WIP)
- Dépendances inconnues
- Travail imprévu
- Des priorités contradictoires
- Travail négligé
C’est une analyse très précieuse et le livre est génial, mais tous ces conseils sont inutiles si seulement 50 % des données sont visibles. Les méthodes proposées par la Dominique peuvent être utilisées si une précision supérieure à 90 % est atteinte. Je parle de situations où un patron confie à un subordonné une tâche de 15 minutes, mais cela lui prend trois jours ; mais le patron ne sait pas vraiment que ce subordonné dépend de quatre ou cinq autres personnes.
Le projet Phoenix est une merveilleuse histoire sur un projet qui est arrivé trois ans trop tard. L'un des personnages risque d'être licencié pour cette raison et il rencontre un autre personnage présenté comme une sorte de Socrate. Il aide à comprendre exactement ce qui n’a pas fonctionné. Il s'avère que l'entreprise a un administrateur système, nommé Brent, et que tout le travail passe d'une manière ou d'une autre par lui. Lors d'une des réunions, on demande à l'un des subordonnés : pourquoi chaque tâche d'une demi-heure prend-elle une semaine ? La réponse est une présentation très simplifiée de la théorie des files d'attente et de la loi de Little, et dans cette présentation, il s'avère qu'à 90 % d'occupation, chaque heure de travail prend 9 heures. Chaque tâche doit être envoyée à sept autres personnes, de sorte que cette heure devienne 63 heures, 7 fois 9. Ce que je dis, c'est que pour utiliser la loi de Little ou toute théorie complexe des files d'attente, vous devez au moins disposer de données.
Alors quand je parle de visibilité, je ne veux pas dire que tout est à l'écran, mais que vous avez au moins des données. Lorsqu’ils le font, il s’avère souvent qu’une très grande quantité de travail imprévu est envoyé d’une manière ou d’une autre à Brent alors que cela n’est pas nécessaire. Et Brent est un gars formidable, il ne dira jamais non, mais il ne dit à personne comment il fait son travail.
Lorsque l'œuvre est visible, les données peuvent être soigneusement classées (c'est ce que fait Dominika sur la photo), l'abstraction des cinq fuites temporelles peut être appliquée et l'automatisation peut être appliquée.
2. Consolider les systèmes de gestion du travail : gestion des tâches
Les archétypes dont je parle sont une sorte de pyramide. Si le premier est effectué correctement, le second est déjà une sorte de module complémentaire. Beaucoup d'entre eux ne fonctionnent pas pour les startups, ils doivent être gardés à l'esprit pour les grandes entreprises comme Fortune 5000. La dernière entreprise pour laquelle j'ai travaillé disposait de 10 systèmes de billetterie. Une équipe avait Remedy, une autre a écrit une sorte de son propre système, une troisième a utilisé Jira et certaines se sont contentées du courrier électronique. Le même problème se pose si l’entreprise possède 30 pipelines différents, mais je n’ai pas le temps de discuter de tous ces cas.
Je discute avec les gens de la manière exacte dont les tickets sont créés, de ce qui leur arrive ensuite et de la manière dont ils sont contournés. Le plus intéressant, c'est que les gens présents à nos réunions parlent avec beaucoup de sincérité. J'ai demandé combien de personnes avaient indiqué « impact mineur/aucun » sur des billets qui devraient en réalité avoir un « impact majeur ». Il s'est avéré que presque tout le monde fait cela. Je ne me lance pas dans la dénonciation et j’essaie par tous les moyens de ne pas identifier les personnes. Quand ils m’avouent sincèrement quelque chose, je ne révèle pas la personne. Mais lorsque presque tout le monde contourne le système, cela signifie que toute sécurité n’est essentiellement qu’une façade. Aucune conclusion ne peut donc être tirée des données de ce système.
Pour résoudre le problème des tickets, vous devez choisir un système principal. Si vous utilisez Jira, conservez-le Jira. S’il existe une alternative, que ce soit la seule. L’essentiel est que les tickets doivent être considérés comme une autre étape du processus de développement. Chaque action doit avoir un ticket, qui doit suivre le workflow de développement. Les tickets sont envoyés à l'équipe qui les affiche sur le storyboard et en prend ensuite la responsabilité.
Cela s’applique à tous les départements, y compris les infrastructures et les opérations. Dans ce cas, il est possible de se faire au moins une idée plausible de la situation. Une fois ce processus établi, il devient soudain facile d’identifier qui est responsable de chaque demande. Car désormais, nous recevons non pas 50 %, mais 98 % des nouveaux services. Si ce processus de base fonctionne, la précision s’améliore dans l’ensemble du système.
Pipeline de services
Encore une fois, cela ne s'applique qu'aux grandes entreprises. Si vous êtes une nouvelle entreprise dans un nouveau domaine, retroussez vos manches et travaillez avec votre Travis CI ou CircleCI. En ce qui concerne les entreprises Fortune 5000, un exemple typique s’est produit à la banque où je travaillais. Google est venu vers eux et leur a montré des schémas d'anciens systèmes IBM. Les gars de Google ont demandé avec confusion : où est le code source de cela ? Mais il n’y a pas de code source, pas même d’interface graphique. C’est la réalité à laquelle les grandes organisations doivent faire face : des relevés bancaires vieux de 40 ans sur un ordinateur central ancien. Un de mes clients utilise des conteneurs Kubernetes avec des modèles de disjoncteur, ainsi que Chaos Monkey, le tout pour l'application KeyBank. Mais ces conteneurs se connectent finalement à une application COBOL.
Les gars de Google étaient totalement convaincus qu'ils résoudraient tous les problèmes de mes clients, puis ils ont commencé à poser des questions : qu'est-ce qu'IBM Datapipe ? On leur dit : c'est un connecteur. A quoi est-il connecté ? Au système Sperry. Et qu'est-ce que c'est ? Et ainsi de suite. À première vue, il semble : quel type de DevOps peut-il y avoir ? Mais en fait, c'est possible. Il existe des systèmes de livraison qui vous permettent de confier le flux de travail aux équipes de livraison.
3. Théorie des contraintes : Théorie des contraintes
Passons au troisième archétype : le savoir institutionnel/« tribal ». En règle générale, dans toute organisation, plusieurs personnes savent tout et gèrent tout. Ce sont ceux qui sont dans l’organisation depuis le plus longtemps et qui connaissent toutes les solutions de contournement.
Lorsque cela apparaît sur le schéma, j'entoure spécifiquement ces personnes avec un marqueur : par exemple, il s'avère qu'un certain Lou est présent à toutes les réunions. Et c'est clair pour moi : c'est du Brent local. Quand le DSI choisit entre moi en T-shirt et baskets et le gars d'IBM en costume, je suis choisi parce que je peux dire au réalisateur des choses que l'autre gars ne veut pas dire et que le réalisateur n'aimerait peut-être pas entendre. . Je leur dis que le goulot d'étranglement dans leur entreprise est quelqu'un qui s'appelle Fred et quelqu'un qui s'appelle Lou. Ce goulot d'étranglement doit être dénoué, leurs connaissances doivent être obtenues d'eux d'une manière ou d'une autre.
Pour résoudre ce genre de problème, je peux par exemple suggérer d’utiliser Slack. Un réalisateur intelligent demandera : pourquoi ? Généralement, dans de tels cas, les consultants DevOps répondent : parce que tout le monde le fait. Si le réalisateur est vraiment intelligent, il dira : et alors. Et c'est là que se termine le dialogue. Et ma réponse à cette question est : parce qu'il y a quatre goulots d'étranglement dans l'entreprise, Fred, Lou, Susie et Jane. Pour institutionnaliser leurs connaissances, il faut d’abord introduire Slack. Tous vos wikis sont complètement absurdes car personne ne connaît leur existence. Si l'équipe d'ingénierie est impliquée dans le développement front-end et back-end et que tout le monde doit savoir qu'il peut contacter l'équipe de développement front-end ou l'équipe d'infrastructure pour toute question. C'est à ce moment-là que Lou ou Fred auront probablement le temps de rejoindre le wiki. Et puis, dans Slack, quelqu'un pourrait demander pourquoi, par exemple, l'étape 5 ne fonctionne pas. Et puis Lou ou Fred corrigeront les instructions sur le wiki. Si vous établissez ce processus, beaucoup de choses se mettront en place d’elles-mêmes.
C'est là mon point principal : pour recommander des technologies de pointe, vous devez d'abord en mettre de l'ordre dans les fondations, et cela peut être fait avec les solutions low-tech que nous venons de décrire. Si vous commencez par les hautes technologies et n'expliquez pas pourquoi elles sont nécessaires, cela ne se termine généralement pas bien. Un de nos clients utilise Azure ML, une solution simple et très bon marché. Environ 30 % de leurs questions ont reçu une réponse grâce à la machine d'auto-apprentissage elle-même. Et cette chose a été écrite par des opérateurs qui n'étaient pas impliqués dans la science des données, les statistiques ou les mathématiques. C’est important. Le coût d'une telle solution est minime.
4. Hacks de collaboration : Hacks de collaboration
Le quatrième archétype est la nécessité de lutter contre l’isolement. La plupart des gens le savent déjà : l’isolement engendre l’hostilité. Si chaque département est à son propre étage et que les gens ne se croisent d'aucune façon, sauf dans l'ascenseur, alors l'hostilité entre eux surgit très facilement. Mais si, au contraire, des personnes se trouvent dans la même pièce, elle s'en va immédiatement. Quand quelqu'un lance une accusation générale, par exemple, telle ou telle interface ne fonctionne jamais, il n'y a rien de plus simple pour déconstruire une telle accusation. Les programmeurs qui ont écrit l'interface doivent simplement commencer à poser des questions spécifiques, et il deviendra bientôt clair que, par exemple, l'utilisateur n'a tout simplement pas utilisé l'outil de manière incorrecte.
Il existe de nombreuses façons de surmonter l’isolement. On m'a demandé un jour de consulter une banque en Australie, mais j'ai refusé de le faire parce que j'ai deux enfants et une femme. Tout ce que je pouvais faire pour les aider, c'était de leur recommander une narration graphique. C’est quelque chose qui a fait ses preuves. Une autre méthode intéressante consiste à organiser des réunions Lean Coffee. Dans une grande organisation, c'est une excellente option pour diffuser les connaissances. De plus, vous pouvez organiser des devopsdays internes, des hackathons, etc.
5. Entraînement des Katas
Comme je l’avais prévenu au tout début, je n’en parlerai pas aujourd’hui. Si vous êtes intéressé, vous pouvez jeter un oeil .
Il y a aussi une bonne conférence sur ce sujet de Mike Rother :
6. Orienté marché : organisation orientée marché
Il y a différents problèmes ici. Par exemple, les personnes « I », les personnes « T » et les personnes « E ». Les gens du « je » sont ceux qui ne font qu’une seule chose. Ils existent généralement dans des organisations dotées de départements isolés. Un « T » signifie qu'une personne est bonne dans un domaine mais également bonne dans d'autres. "E" ou même "peigne" désigne le cas où une personne possède de nombreuses compétences.
La loi de Conway fonctionne ici (), qui, sous la forme la plus simplifiée, peut s'énoncer comme suit : si trois équipes travaillent sur le compilateur, alors le résultat sera un compilateur en trois parties. Par conséquent, s'il existe un niveau élevé d'isolement au sein d'une organisation, alors même Kubernetes, le disjoncteur, l'extensibilité des API et d'autres éléments sophistiqués dans cette organisation seront organisés de la même manière que l'organisation elle-même. Strictement selon Conway et malgré vous tous, jeunes geeks.
La solution à ce problème a été décrite à plusieurs reprises. Il existe par exemple les archétypes organisationnels décrits par Fernando Fernandez. Cette architecture problématique dont je viens de parler, avec isolation, est une architecture orientée fonction. Le deuxième type est le pire, une architecture matricielle, un gâchis des deux autres. Le troisième est ce que l’on observe dans la plupart des startups, et les grandes entreprises tentent également de correspondre à ce type. C'est une organisation orientée vers le marché. Ici, nous optimisons pour obtenir la réponse la plus rapide aux demandes des clients. C'est ce qu'on appelle parfois une organisation plate.
Beaucoup de gens décrivent cette structure de différentes manières, j'aime la formulation créer/diriger des équipes, chez Amazon, ils l'appellent deux équipes de pizza. Dans cette structure, toutes les personnes de type « I » sont regroupées autour d'un seul service, et progressivement elles se rapprochent du type « T », et si la bonne direction est en place, elles peuvent même devenir « E ». Le premier contre-argument ici est qu’une telle structure comporte des éléments inutiles. Pourquoi avez-vous besoin d’un testeur dans chaque département si vous pouvez avoir un département spécial de testeurs ? A quoi je réponds : les coûts supplémentaires dans ce cas sont le prix à payer pour que l'ensemble de l'organisation devienne à l'avenir de type « E ». Dans cette structure, le testeur apprend progressivement les réseaux, l'architecture, le design, etc. En conséquence, chaque participant de l’organisation est pleinement conscient de tout ce qui se passe dans l’organisation. Si vous souhaitez savoir comment ce dispositif fonctionne dans l'industrie, lisez .
7. Auditeurs Shift-gauche : audit en début de cycle. Affichage du respect des règles de sécurité
C'est à ce moment-là que vos actions ne passent pas le test de l'odorat, pour ainsi dire. Les gens qui travaillent pour vous ne sont pas stupides. Si, comme dans l’exemple ci-dessus, l’impact est mineur ou inexistant partout, que cela dure trois ans et que personne ne remarque rien, alors tout le monde sait parfaitement que le système ne fonctionne pas. Ou un autre exemple : un comité consultatif sur le changement, dont les rapports doivent être soumis tous les mercredis, par exemple. Il y a un groupe de personnes qui y travaillent (pas très bien payées, d'ailleurs) qui, en théorie, devraient savoir comment fonctionne le système dans son ensemble. Et au cours des cinq dernières années, vous avez probablement remarqué que nos systèmes sont incroyablement complexes. Et cinq ou six personnes doivent prendre une décision concernant un changement qu’elles n’ont pas fait et dont elles ne savent rien.
Bien entendu, cette approche ne fonctionne pas. Je dois me débarrasser de ce genre de choses parce que ces gens ne protègent pas le système. La décision doit être prise par l’équipe elle-même, car elle doit en être responsable. Sinon, une situation paradoxale survient lorsqu'un manager qui n'a jamais écrit de code de sa vie indique au programmeur combien de temps il devrait prendre pour écrire du code. Une entreprise avec laquelle j'ai travaillé avait 7 conseils différents qui examinaient chaque changement, y compris un conseil d'architecture, un conseil de produit, etc. Il y avait même un délai de carence obligatoire, même si un employé m'a dit qu'en dix ans de travail, personne n'avait jamais refusé un changement apporté par cette personne pendant ce délai obligatoire.
Il faut inviter les auditeurs à nous rejoindre, et non les éliminer. Dites-leur que vous écrivez des conteneurs binaires immuables qui, s'ils réussissent tous les tests, resteront immuables pour toujours. Dites-leur que vous avez un pipeline sous forme de code et expliquez ce que cela signifie. Montrez-leur le schéma suivant : un binaire immuable en lecture seule dans un conteneur qui réussit tous les tests de vulnérabilité ; et puis non seulement personne n’y touche, mais on ne touche même pas au système qui crée le pipeline, puisqu’il est aussi créé dynamiquement. J'ai des clients, Capital One, qui utilisent Vault pour créer quelque chose comme une blockchain. L'auditeur n'a pas besoin de montrer les « recettes » de Chef, il suffit de montrer la blockchain, à partir de laquelle il est clair ce qui est arrivé au ticket Jira en production et qui en est responsable.
selon , créé en 2018 par Sonatype, il y a eu 2017 milliards de demandes de téléchargement d'OSS en 87.
Les pertes subies en raison des vulnérabilités sont prohibitives. De plus, les chiffres que vous voyez ci-dessus n’incluent pas les coûts d’opportunité. Qu’est-ce que DevSecOps en quelques mots ? Permettez-moi de dire tout de suite que je ne suis pas intéressé à parler du succès de ce nom. Le fait est que, puisque DevOps a connu un tel succès, nous devrions essayer d’ajouter de la sécurité à ce pipeline.
Un exemple de cette séquence :
Ce n’est pas une recommandation pour des produits spécifiques, même si je les aime tous. Je les ai cités en exemple pour montrer que le DevOps, initialement basé sur le paradigme organisationnel de l'industrie, permet d'automatiser chaque étape du travail sur un produit.
Et il n’y a aucune raison pour que nous ne puissions pas adopter la même approche en matière de sécurité.
Total
En conclusion, je donnerai quelques conseils pour DevSecOps. Vous devez inclure les auditeurs dans le processus de création de vos systèmes et consacrer du temps à leur formation. Vous devez coopérer avec les auditeurs. Ensuite, vous devez mener une lutte absolument impitoyable contre les faux positifs. Même avec l'outil d'analyse des vulnérabilités le plus coûteux, vous pouvez finir par créer de très mauvaises habitudes parmi vos développeurs si vous ne connaissez pas votre rapport signal/bruit. Les développeurs seront submergés d’événements et les supprimeront simplement. Si vous avez entendu parler de l'histoire d'Equifax, c'est à peu près ce qui s'est passé là-bas, où le niveau d'alerte le plus élevé a été ignoré. De plus, les vulnérabilités doivent être expliquées de manière à montrer clairement leur impact sur l’entreprise. Par exemple, on pourrait dire qu’il s’agit de la même vulnérabilité que dans l’histoire d’Equifax. Les vulnérabilités de sécurité doivent être traitées de la même manière que les autres problèmes logiciels, c'est-à-dire qu'elles doivent être incluses dans le processus DevOps global. Vous devez travailler avec eux via Jira, Kanban, etc. Les développeurs ne devraient pas penser que quelqu'un d'autre fera cela - au contraire, tout le monde devrait le faire. Enfin, vous devez consacrer de l'énergie à la formation des personnes.
Liens utiles
Voici quelques exposés de la conférence DevOops qui pourraient vous être utiles :
- Sergey Berdnikov, Artyom Kalichkin - Success story, ou « Dev+DevOps+Ops » (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps à l'échelle : une tragédie grecque en trois actes (, )
- Alexandre Titov, Kirill Tolkachev -
- Timothée Lister -
Examiner DevOops 2020 Moscou — il y a aussi beaucoup de choses intéressantes là-bas.
Source: habr.com