Get best of the week

Sept archétypes de transformation DevOps

La question "comment mettre en œuvre un devopae" n'est pas la première année, mais il n'y a pas tant de bons matériaux. Parfois, vous devenez victime de la publicité des consultants pas très intelligents qui ont besoin de vendre leur temps, peu importe comment. Parfois, ce sont des mots obscurs et extrêmement généraux sur la façon dont les navires des mégacorporations labourent les étendues de l'univers. La question se pose: qu'en est-il de nous? Cher auteur, pouvez-vous formuler clairement vos idées avec une liste?

Tout cela vient du fait qu’il n’ya pas beaucoup de pratique réelle accumulée et de compréhension des résultats des transformations de la culture de l’entreprise. Les changements de culture sont des choses qui durent longtemps et dont les résultats n'apparaîtront pas dans une semaine ni dans un mois. Nous avons besoin de quelqu'un d'assez ancien pour voir comment les entreprises ont été créées et se sont effondrées au fil des ans.



John Willis- L'un des pères de DevOps. Derrière John - des dizaines d'années de travail avec un grand nombre d'entreprises. Récemment, John a commencé à remarquer par lui-même des schémas spécifiques qui se produisent en travaillant avec chacun d'eux. À l'aide de ces archétypes, John guide les entreprises sur la véritable voie de la transformation DevOps. En savoir plus sur ces archétypes dans la traduction de son rapport de la conférence DevOops 2018.



À propos du conférencier:

Plus de 35 ans dans la gestion informatique, participé à la création du prédécesseur d'OpenCloud dans Canonical, participé à 10 startups, dont deux ont été vendues par Dell et Docker. Il est actuellement vice-président de DevOps et des pratiques numériques chez SJ Technologies.

Vient ensuite le récit au nom de John.

Je m'appelle John Willis et le moyen le plus simple de me trouver sur Twitter est @botchagalupe . J'ai le même alias sur Gmail et GitHub. Et sur ce lien, vous pouvez trouver des vidéos de mes rapports et présentations.

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 DevOps, et tous ceux qui essaient de leur expliquer parlent d'autre chose. Une autre plainte courante est que DevOps ne fonctionne pas, bien qu'il semble que les administrateurs fassent tout ce qui leur a été expliqué. Nous parlons de grandes entreprises qui ont plus de cent ans. Après avoir parlé avec eux, je suis arrivé à la conclusion que pour de nombreux problèmes, ce ne sont pas les technologies de pointe, mais les solutions relativement peu technologiques qui conviennent le mieux. Pendant des semaines, je viens de discuter avec des gens de différents départements. Ce que vous voyez dans la toute première photo de l'article est mon dernier projet, la pièce ressemblait à ceci après trois jours de travail.

Qu'est-ce que DevOps?


En effet, si vous demandez à 10 personnes différentes, elles vous donneront 10 réponses différentes. Mais ce qui est intéressant: toutes ces dix réponses seront correctes. Il n'y a pas de mauvaise réponse ici. J'ai étudié DevOps assez profondément, pendant environ 10 ans, j'ai été le premier Américain le premier DevOpsDay. Je ne dirai pas que je suis plus intelligent que tous ceux impliqués dans DevOps, mais il n'y a pratiquement personne qui ait consacré autant d'efforts à cela. Je crois que DevOps survient lorsque le capital humain et la technologie sont combinés. Nous oublions souvent la dimension humaine, bien que nous parlions beaucoup de toutes sortes de cultures.



Maintenant, nous avons beaucoup de données, cinq ans de recherche universitaire, la vérification des théories a été établie à l'échelle industrielle. Ces études nous disent ce qui suit: si vous combinez certains modèles de comportement dans une culture organisationnelle, vous pouvez obtenir une accélération de 2000 fois. Cette accélération correspond à la même amélioration de la stabilité. Il s'agit d'une mesure quantitative des avantages que DevOps peut apporter à toute entreprise. Il y a quelques années, j'ai parlé de DevOps à un PDG de Fortune 5000. Lorsque je me préparais pour la présentation, j'étais très nerveux parce que je devais exposer mes nombreuses années d'expérience en 5 minutes.

J'ai fini par donner la définition suivante de DevOps: Il s'agit d'un ensemble de pratiques et de modèles qui permettent de transformer le capital humain en capital organisationnel hautement productif. Un exemple est la façon dont Toyota travaille depuis 50 ou 60 ans.



(Ci-après, de tels schémas sont présentés non pas comme matériel de référence, mais comme illustration. Leur contenu sera différent pour chaque nouvelle entreprise. Néanmoins, l'image peut être visualisée et agrandie séparément par ce lien.)

L'une des pratiques les plus réussies est le flux de valeur cartographie. Plusieurs bons livres ont été écrits à ce sujet, l'auteur du plus réussi d'entre eux est 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 a certainement de nombreux avantages, je l'ai beaucoup utilisé. Mais lorsque le PDG vous demande pourquoi son entreprise ne peut pas passer à de nouvelles pistes, il est trop tôt pour parler de la cartographie des flux de valeur. Il y a beaucoup de questions beaucoup plus fondamentales auxquelles il faut d'abord répondre.

Il me semble que l'erreur de beaucoup de mes collègues est qu'ils donnent simplement à l'entreprise un guide en cinq points, puis reviennent six mois plus tard et regardent ce qui s'est passé. Même un bon circuit comme la cartographie des flux de valeur a, disons, des angles morts. Après des centaines d'entretiens avec des directeurs de diverses sociétés, j'ai élaboré un certain schéma qui nous permet de décomposer le problème en composants, et maintenant nous allons discuter de chacun de ces composants dans l'ordre. Avant d'appliquer des solutions technologiques, j'utilise ce modèle et, par conséquent, tous les murs sont suspendus avec des motifs. J'ai récemment travaillé avec un fonds commun de placement, et je me suis retrouvé avec 100-150 de ces régimes.

La mauvaise culture mange de bonnes approches de petit déjeuner


L'idée principale est la suivante: aucun Lean, Agile, SAFE et DevOps n'aidera si la culture de l'organisation est mauvaise. C'est la même chose que de plonger dans les profondeurs sans équipement de plongée ou de fonctionner sans radiographie. En d'autres termes, pour paraphraser Drucker et Deming: une mauvaise culture organisationnelle engloutira tout bon système et ne suffoquera pas.

Pour résoudre ce problème principal, vous devez suivre les étapes suivantes:

  1. Rendre tout le travail visible: rendre tout le travail visible. Pas dans le sens où elle doit être affichée sur n'importe quel écran, mais dans le sens où elle doit être observable.
  2. Consolidate Work Management Systems: . «» 9 10 . «Phoenix Project» - , , - . «» . c .
  3. Theory of Constraints Methodology: .
  4. Collaboration hacks: .
  5. Toyota Kata (Coaching Kata): Toyota Kata . , .
  6. Market Oriented Organization: .
  7. Shift-left auditors: .




Je commence à travailler avec l'organisation très simplement: je vais dans l'entreprise et je parle avec les employés. Comme vous pouvez le voir, pas de haute technologie. Il suffit d'écrire. Je rassemble plusieurs équipes dans une pièce et analyse ce qu'elles me disent du point de vue de mes 7 archétypes. Et puis je leur donne moi-même le marqueur et je leur demande d'écrire au tableau tout ce qu'ils ont dit jusqu'à présent à haute voix. Habituellement, lors de telles réunions, il y a une personne qui écrit tout, et dans le meilleur des cas, il peut enregistrer 10% de la discussion. Avec ma méthode, ce chiffre peut être porté à environ 40%.



(Pour une illustration séparée, voir le lien )

Mon approche est basée sur le travail de William Schneider, The Reengineering Alternative) L'approche est basée sur l'idée que toute organisation peut être décomposée en quatre carrés. Pour moi, ce schéma est généralement le résultat du travail avec ces centaines d'autres schémas qui surviennent lors de l'analyse d'une organisation. Supposons que nous ayons une organisation avec un haut niveau de contrôle, mais avec une faible compétence. C'est une option extrêmement indésirable: quand tout le monde marche le long de la ligne, mais personne ne sait quoi faire.

Une option légèrement meilleure avec un haut niveau de contrôle et de compétence. Si une telle entreprise réalise un profit, 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étence et de coopération, mais en même temps un haut niveau de culture (culture). Cela signifie que l'entreprise compte de nombreuses personnes qui aiment y travailler, le taux de rotation du travail est faible.



(Vous pouvez voir cette illustration séparément du lien )

Il me semble que les méthodes avec des recommandations codées en dur interfèrent finalement avec la réalisation de la vérité. En particulier, le mappage de flux de valeur a de nombreuses règles concernant la façon de structurer les informations. Au début du travail dont je parle maintenant, personne n'a besoin de ces règles. Si une personne avec un marqueur dans les mains décrit la situation réelle de l'entreprise au tableau, c'est la meilleure façon de comprendre la situation. Ces informations ne parviennent pas aux administrateurs. En ce moment, il est stupide de couper une personne et de dire qu'elle a dessiné une mauvaise flèche. À ce stade, il est préférable d'utiliser des règles simples, par exemple: une abstraction à plusieurs niveaux peut être créée simplement à l'aide de marqueurs multicolores.

Je le répète, pas de haute technologie. Un marqueur noir représente la réalité objective, comment tout fonctionne. Les gens marquent avec un marqueur rouge ce qu'ils n'aiment pas exactement dans l'état actuel des choses. Il est important qu'ils l'écrivent, pas moi. Quand je vais chez le directeur des technologies de l'information après la réunion, je ne propose pas une liste de 10 choses qui doivent être corrigées. Je m'efforce de trouver un lien entre ce que disent les membres de l'entreprise et les modèles existants et éprouvés. Enfin, un marqueur bleu suggère des solutions possibles au problème.



(Séparément, cette illustration peut être consultée sur le lien )

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 travailleurs du service de sécurité étaient convaincus qu'ils ne devaient pas venir vérifier les exigences et la conception (conception et revue des exigences).



(Vous pouvez voir cette illustration séparément du lien )

Et puis nous avons parlé à des gens d'autres départements et il s'est avéré qu'il y a environ 8 ans, les développeurs de logiciels ont mis à pied des agents de sécurité parce qu'ils ralentissaient. Et puis cela s'est transformé en une interdiction, qui était tenue pour acquise. Bien qu'il n'y ait en fait aucune interdiction.

Notre réunion a été 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'assemblée. Et cela, semble-t-il, est la chose la plus simple. La plupart des consultants DevOps supposent à l'avance que tout le monde le sait déjà.

Puis le responsable de la gouvernance informatique, qui est resté silencieux pendant quatre heures, a soudainement pris vie lorsque nous sommes arrivés à son sujet et nous a occupés pendant très longtemps. Finalement, je lui ai demandé ce qu'il pensait de la réunion et je n'oublierai jamais sa réponse. Il a déclaré: "Avant, je pensais qu'il n'y avait que deux façons de fournir des logiciels dans notre banque, et maintenant je sais qu'il y en a cinq, et je n'en soupçonnais même pas environ trois".



(Séparément, cette illustration peut être consultée sur le lien )

La dernière réunion dans cette banque a été avec l'équipe des logiciels d'investissement. C'est avec elle qu'il s'est avéré qu'écrire des circuits de marqueurs avec un marqueur sur une feuille est mieux que d'écrire sur un tableau, et encore mieux que d'écrire sur un smartboard.



Les photographies que vous voyez sont à quoi ressemblait la salle de conférence de l'hôtel le quatrième jour de notre réunion. Et nous avons utilisé ces modèles pour rechercher des modèles, c'est-à-dire des archétypes.

Alors, je pose des questions aux employés, ils écrivent des réponses avec des marqueurs de trois couleurs (noir, rouge et bleu). J'analyse leurs réponses pour les archétypes. Voyons maintenant tous les archétypes dans l'ordre.

1. Rendre tout le travail visible: rendre le travail visible.


La plupart des entreprises avec lesquelles je travaille ont un pourcentage très élevé d'emplois inconnus. Par exemple, c'est quand un employé vient à un autre et 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 documenté d'aucune façon. Si c'était un Boeing, alors dans ma vie je n'aurais plus jamais embarqué dans leur avion. Si seulement la moitié du travail est documentée, on ne sait pas si ce travail est effectué correctement ou non. Toutes les autres méthodes s'avèrent inutiles - il est inutile d'essayer d'automatiser quelque chose, car les 50% bien connus peuvent être juste la partie la plus cohérente et la plus claire du travail, dont l'automatisation ne donnera pas de grands résultats, et la plus terrible - dans la moitié invisible. En l'absence de documentation, il est impossible de trouver toutes sortes de hacks et de travaux cachés, pas de trouver des goulots d'étranglement,ces mêmes "Brents" dont j'ai déjà parlé. Il y a un beau livre de Dominique De Grandis (Dominique DeGrandis)"Rendre le travail visible . " Il identifie cinq « voleurs de temps» différents:

  • Trop de travaux en cours (WIP)
  • Dépendances inconnues
  • Travail imprévu
  • Priorités contradictoires
  • Travail négligé


Il s'agit d'une analyse très précieuse, et le livre est merveilleux, mais tous ces conseils sont inutiles si seulement 50% des données sont visibles. Vous pouvez appliquer les méthodes proposées par la Dominique si la précision est atteinte au-dessus de 90%. Je parle de situations où le patron donne au subordonné une tâche de 15 minutes, et cela lui prend trois jours; mais le patron ne sait pas vraiment que ce subordonné dépend de quatre ou cinq autres personnes.



The Phoenix Project est une belle histoire sur un projet qui a trois ans de retard. L'un des héros est menacé de licenciement à cause de cela, et il rencontre un autre personnage qui est présenté comme une sorte de Socrate. Il aide à comprendre ce qui s'est exactement passé. Il s'avère que l'entreprise a un administrateur système, dont le nom est Brent, et que tout le travail passe par elle. Lors de l'une des réunions, un des subordonnés est demandé: pourquoi chaque tâche d'une demi-heure prend-elle une semaine? En réponse, une exposition très simplifiée de la théorie des files d'attente et de la loi de Little suit, et dans cette exposition, il s'avère qu'à 90% d'emploi, chaque heure de travail prend 9 heures. Chaque tâche doit être envoyée à sept autres personnes, donc cette heure se transforme en 63 heures, 7 fois 9. Je dis ceci,Pour utiliser la loi de Little ou toute théorie de mise en file d'attente complexe, vous devez au moins disposer de données.

Donc, quand je parle de visibilité, je ne veux pas dire que tout était à l'écran, mais qu'il faut au moins avoir des données. Lorsqu'ils le sont, il s'avère souvent qu'il y a une très grande quantité de travail imprévu, qui pour une raison quelconque est envoyé à Brent, bien que ce ne soit 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 le travail est visible, vous pouvez classer avec précision les données (c'est ce que fait Dominika sur la photo), vous pouvez appliquer l'abstraction de cinq fuites de temps et l'automatiser.

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 fait correctement, le second est déjà une sorte de module complémentaire. Beaucoup d'entre eux ne travaillent pas pour les startups, il faut en tenir compte dans le cas des grandes entreprises, comme celles qui figurent sur la liste Fortune 5000. La dernière entreprise où j'ai travaillé avait 10 systèmes de billetterie. Remedy faisait partie d'une équipe, une autre a écrit une sorte de système qui lui est propre, un troisième a utilisé Jira et quelqu'un d'autre s'est débrouillé par courrier électronique. Le même problème se pose si la société dispose de 30 pipelines différents, mais je n'ai pas le temps de discuter de tous ces cas.

Je discute avec les gens exactement de la façon dont les tickets sont créés, de ce qui leur arrive ensuite, de la façon dont ils sont contournés. La chose la plus intéressante est que les gens à nos réunions parlent très sincèrement. J'ai demandé combien de personnes avaient mis en place un «impact mineur / sans impact» pour les tickets qui auraient vraiment dû être «impact majeur». Il s'est avéré que presque tout le monde le fait. Je ne m'engage pas dans les dénonciations et j'essaie de toutes façons de ne pas identifier les gens. Quand ils m'admettent sincèrement quelque chose, je ne trahis personne. Mais lorsque presque tout le monde contourne le système, cela signifie que toute sécurité, par essence, est une décoration. Par conséquent, aucune conclusion ne peut être tirée des données de ce système.

Pour résoudre le problème des tickets, vous devez sélectionner un système principal. Si vous utilisez Jira, que ce soit seulement Jira. S'il y a une alternative, que ce soit seulement cela. L'essentiel est que les tickets doivent être considérés comme une autre étape du processus de développement. Toute action doit avoir un ticket qui doit passer par le workflow de développement. Les billets sont envoyés à l'équipe, qui les place sur le storyboard, puis en est responsable.

Cela s'applique à tous les départements, y compris l'infrastructure et les opérations. Dans ce cas, vous pouvez au moins vous faire une idée plausible de la situation. Lorsque ce processus est établi, il s'avère soudainement que vous pouvez facilement déterminer qui est responsable de chaque application. Parce que maintenant, nous n'obtenons pas 50%, mais 98% de nouveaux services. Si ce processus de base fonctionne, la précision s'améliore dans tout le système.

Services de pipelines


Encore une fois, cela ne s'applique qu'aux grandes sociétés. Si vous êtes une nouvelle entreprise dans un nouveau domaine, retroussez vos manches et travaillez avec votre Travis CI ou CircleCI. Quant aux entreprises Fortune 5000, le cas qui s'est produit avec la banque où je travaillais était indicatif. Ils leur sont venus de Google et on leur a montré des diagrammes avec d'anciens systèmes IBM. Les gars de Google avec un malentendu ont demandé - où est le code source pour cela? Et il n'y a pas de code source, pas même une interface graphique. C'est la réalité avec laquelle les grandes organisations doivent travailler: des dossiers bancaires vieux de 40 ans sur un ancien ordinateur central. Un de mes clients utilise des conteneurs Kubernetes avec des modèles de disjoncteurs, ainsi que Chaos Monkey, tous pour KeyBank. Mais ces conteneurs finissent par se connecter à l'application COBOL.

Les gars de Google étaient convaincus qu'ils allaient résoudre tous les problèmes de mon client, puis ils ont commencé à poser des questions: qu'est-ce que le datapipe IBM? On leur répond: c'est un connecteur. À quoi se connecte-t-il? Vers le système Sperry. Et c'est quoi ça? Etc. À première vue, il semble: quel type de DevOps peut-il s'agir? Mais en fait, c'est possible. Il existe des systèmes de livraison qui vous permettent de transférer le flux de travail aux équipes de livraison.

3. Théorie des contraintes: Théorie des contraintes


Passons au troisième archétype: la connaissance institutionnelle / «tribale». En règle générale, dans toute organisation, plusieurs personnes savent tout et gèrent tout. Ce sont ceux qui travaillent le plus longtemps dans l'organisation et qui connaissent toutes les solutions.



Lorsque cela est révélé sur le schéma, je dessine spécialement un marqueur autour de ces personnes: par exemple, il s'avère qu'un certain Lou est présent à toutes les réunions. Et pour moi, c'est clair: c'est le Brent local. Lorsque le CIO choisit entre moi dans un T-shirt et des baskets et un gars vêtu d'un costume d'IBM, ils me choisissent parce que je peux dire au réalisateur des choses que l'autre ne racontera pas et dont le réalisateur peut ne pas aimer entendre parler. Je leur dis qu'il y a un goulot d'étranglement dans leur entreprise, c'est quelqu'un nommé Fred et quelqu'un nommé Lu. Ce goulot d'étranglement doit être délié, leurs connaissances doivent être obtenues d'une manière ou d'une autre auprès d'eux.

Pour résoudre ce genre de problème, je peux, par exemple, suggérer d'utiliser Slack. Un réalisateur intelligent demande pourquoi? Dans de tels cas, les consultants DevOps répondent généralement: parce que tout le monde le fait. Si le réalisateur est vraiment intelligent, il dira: alors quoi. Et c'est là que le dialogue se termine. Et je réponds à cela: parce que l'entreprise a quatre goulots d'étranglement, Fred, Lou, Susie et Jane. Pour institutionnaliser leurs connaissances, vous devez d'abord introduire Slack. Tous vos wikis sont complètement absurdes car personne ne connaît leur existence. Si l'équipe d'ingénieurs est engagée dans le développement externe et interne et tout le monde doit savoir que vous pouvez contacter l'équipe de développement externe ou l'équipe d'infrastructure pour des questions. À ce moment-là, Lou ou Fred auront probablement le temps de se connecter au wiki. Et puis chez Slack, quelqu'un pourrait demanderpourquoi cela ne fonctionne pas, disons, étape 5. Et puis Lou ou Fred corrigeront les instructions sur le wiki. Si vous établissez ce processus, beaucoup de choses se mettront en place.

C'est mon idée principale: pour recommander certaines technologies de pointe, vous devez d'abord mettre en place les bases de celles-ci, et vous pouvez le faire avec les solutions low-tech qui viennent d'être décrites. Si vous commencez par la haute technologie et n'expliquez pas pourquoi elles sont nécessaires, alors, en règle générale, cela ne se termine pas par quelque chose de bon. Un de nos clients utilise Azure ML, une solution très économique et simple. Quelque part, 30% des questions ont été répondues par la machine d'auto-apprentissage elle-même. Et les opérateurs qui ne s'occupaient pas de science des données, de statistiques ou de mathématiques ont écrit cette chose. C'est indicatif. Le coût d'une telle solution est minime.

4. Hack de collaboration: Hack 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'inimitié. Si chaque département est à son propre étage et que les gens ne se croisent en aucune façon, sauf dans l'ascenseur, l'hostilité entre eux se produit très facilement. Et si, au contraire, les gens sont dans la même pièce, elle part immédiatement. Quand quelqu'un jette une certaine accusation générale, par exemple, telle ou telle interface ne fonctionne jamais - il n'y a rien de plus facile à déconstruire une telle accusation. Il suffit que les programmeurs qui ont écrit l'interface commencent à poser des questions spécifiques, et il devient vite clair, par exemple, que l'utilisateur a simplement mal utilisé l'outil.

Il existe de nombreuses façons de surmonter l'isolement. On m'a demandé une fois de conseiller une banque en Australie, j'ai refusé de le faire car j'ai deux enfants et une femme. Tout ce que je pouvais faire, c'était leur recommander une narration graphique. C'est une chose qui fonctionne prouvablement. Une autre façon intéressante est les réunions au format café maigre. Dans une grande organisation, c'est un excellent moyen de diffuser les connaissances. De plus, vous pouvez organiser des jours de développement internes, des hackathons, etc.

5. Coaching Kata


Comme je l'avais déjà prévenu au tout début, je n'en parlerai pas aujourd'hui. Si vous êtes intéressé, vous pouvez voir certaines de mes présentations .

Il y a aussi un bon rapport sur ce sujet de Mike Rother:



6. Orienté vers le marché: une organisation orientée vers le marché


Il y a divers problèmes ici. Par exemple, les gens «I», les gens «T» et les gens «E». Les gens "je" sont ceux qui sont engagés dans une seule chose. Habituellement, ils existent dans les organisations avec des unités isolées. «T» est si une personne connaît bien une chose, mais excelle également dans d'autres choses. Un «E» ou même un «peigne», c'est quand une personne a beaucoup de compétences. La loi de Conway



fonctionne ici , qui sous la forme la plus simplifiée peut être formulée comme suit: si les trois équipes sont impliquées dans le compilateur, le résultat sera un compilateur en trois parties. Par conséquent, si l'organisation a un niveau élevé d'isolement, même Kubernetes, Disjoncteur, extensibilité API et autres choses à la mode 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, les jeunes geeks.

La solution à ce problème a été décrite à plusieurs reprises. Il existe, par exemple, des archétypes organisationnels décrits par Fernando Fernandez. L'architecture du problème dont je viens de parler avec l'isolement est une architecture orientée fonction. Le deuxième type est le pire, l'architecture matricielle, il y a un gâchis des deux autres. Le troisième est ce que l'on voit dans la plupart des startups, et les grandes entreprises tentent également de faire correspondre ce type. Il s'agit d'une organisation orientée vers le marché. Voici l'optimisation pour obtenir la réponse la plus rapide aux demandes des clients. Ceci est parfois appelé organisation plate.

Beaucoup de gens décrivent cette structure de différentes manières, j'aime le libellé des équipes de construction / exécution , en Amazon, ils l'appellent deux équipes de pizza. Dans cette structure, toutes les personnes de type «I» sont regroupées autour d'un service, et progressivement elles se rapprochent du type «T», et si la bonne gestion est établie, même «E» peut devenir. Le premier contre-argument ici est qu'il y a des éléments superflus dans une telle structure. Pourquoi avons-nous 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 surcoûts dans ce cas sont le prix à payer pour qu'à l'avenir toute l'organisation devienne de type «E». Dans cette structure, le testeur apprend progressivement les réseaux, l'architecture, la conception, etc. En conséquence, chaque membre de l'organisation est pleinement conscient de tout ce qui se passe dans l'organisation. Si vous voulez savoir comment ce circuit fonctionne dans l'industrie, consultez Mike Rother, Toyota Kata .

7. Auditeurs de quart de gauche: audit aux premiers stades d'un cycle. Conformité aux règles de sécurité


C'est quand vos actions ne passent pas, pour ainsi dire, un test d'odeur. Les gens qui travaillent pour vous ne sont pas stupides. S'ils, comme dans l'exemple ci-dessus, présentent partout un impact mineur / nul, cela dure trois ans et que personne ne remarque rien, alors tout le monde sait que le système ne fonctionne pas. Un autre exemple est le comité consultatif sur le changement, où chaque environnement, par exemple, doit être signalé. Un groupe de personnes y travaille (soit dit en passant, pas trop bien payé), qui devrait en théorie 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 décider d'un changement qu'elles n'ont pas fait et dont elles ne savent rien.

Bien sûr, cette approche ne fonctionne pas. Je dois me débarrasser de telles 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 l'équipe doit en être responsable. Sinon, une situation paradoxale survient lorsque le gestionnaire, qui n'a jamais écrit de code de sa vie, indique au programmeur combien de temps il faut pour écrire le code. Dans une entreprise avec laquelle j'ai travaillé, il y avait 7 conseils différents qui examinaient chaque changement, y compris une architecture, un produit, etc. Il y avait même une période d'attente obligatoire, même si un employé m'a dit qu'en dix ans de travail, personne au cours de cette période obligatoire n'avait jamais rejeté les modifications apportées par cette personne.

Les auditeurs doivent être appelés à eux-mêmes et ne pas s'en débarrasser. Dites-leur que vous écrivez des conteneurs binaires immuables qui, si tous les tests réussissent, restent inchangés 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: binaire immuable en lecture seule dans un conteneur qui réussit tous les tests de vulnérabilité; et puis, non seulement personne ne le touche - il ne touche même pas le système qui crée le pipeline, car il est également créé dynamiquement. J'ai des clients, Capital One, qui utilisent Vault pour créer quelque chose comme une blockchain. Vous ne pouvez pas montrer les «recettes» du chef à l'auditeur, 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 le rapportcréé par Sonatype en 2018, il y a eu 87 milliards de demandes de téléchargement OSS en 2017.



Les vulnérabilités encourues sont prohibitives. De plus, les chiffres que vous voyez ci-dessus n'incluent pas les coûts d'opportunité. En un mot sur ce qu'est DevSecOps. Je veux dire tout de suite que je ne suis pas intéressé à parler du succès de ce nom. Le fait est que, comme DevOps a connu un grand succès, vous devez essayer d'ajouter de la sécurité à ce pipeline.

Un exemple d'une telle séquence:


ce n'est pas une recommandation pour certains produits, même si je les aime tous. Je les ai cités en exemple pour montrer que DevOps, basé initialement sur le paradigme d'organisation dans l'industrie, vous 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 vais donner quelques conseils pour DevSecOps. Vous devez inclure des auditeurs dans le processus de création de vos systèmes, consacrer du temps à leur formation. Il est nécessaire de coopérer avec les auditeurs. De plus, il est nécessaire de mener une lutte absolument impitoyable contre les faux positifs. Même avec l'outil d'analyse de vulnérabilité le plus cher, vous pouvez finir par créer de très mauvaises habitudes pour vos développeurs si vous ne savez pas quel est le rapport signal / bruit. Les développeurs seront surchargés d'événements et ils les supprimeront simplement. Si vous avez entendu parler de l'histoire avec Equifax, alors c'est ce qui s'est passé là-bas, le signal du plus haut niveau de danger y a été ignoré. De plus, les vulnérabilités doivent être expliquées afin de savoir clairement comment elles affectent l'entreprise. Par exemple, nous pouvons dire que c'est la même vulnérabilité que dans l'histoire d'Equifax. Vulnérabilités de sécuritéVous devez considérer la même manière que les autres problèmes avec le logiciel, c'est-à-dire qu'ils doivent être inclus dans le processus DevOps global. Vous devez travailler avec eux via Jira, Kanban, etc. Les développeurs ne doivent pas penser que quelqu'un d'autre le fera, au contraire, tout le monde devrait le faire. Enfin, vous devez dépenser de l'énergie pour éduquer les gens.

Liens utiles


Voici quelques présentations de la conférence DevOops qui pourraient vous être utiles:



Jetez un œil au programme DevOops 2020 Moscou - il y a aussi beaucoup de choses intéressantes là-bas.

More articles:


All Articles