Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Joseph Glorieux & Mathieu Brun Maintenant que mon delivery pipeline est en place, que faire de mon organisation?

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité

Consultez-les par la suite

1 sur 27 Publicité

Joseph Glorieux & Mathieu Brun Maintenant que mon delivery pipeline est en place, que faire de mon organisation?

Télécharger pour lire hors ligne

On réduit souvent DevOps au déploiement d’outils permettant le provisionning automatique de l’infrastructure et le déploiement rapide de nouvelles fonctionnalités. Cependant, ces nouvelles possibilités, couplées à l’introduction de nouvelles pratiques comme l’IaC, permettent de donner de l’ampleur à notre transformation DevOps.

Mais voilà, après quelques mois, la fréquence des livraisons est en chute libre et la tension entre les équipes s’est accrue : les Ops grognent à cause des 5 derniers déploiements ratés, et les Devs taclent les Ops pour leur ignorance de l’architecture microservice.

Une vague impression de déjà-vu peut-être… Et si nous avions oublié quelque chose…

Dans cette session, nous vous proposons de partager les modèles d’organisation mis en place ou observés ces dernières années au sein des entreprises pour lesquelles nous avons travaillé. Si tout ne s’est pas toujours déroulé comme prévu, ces changements organisationnels restent le catalyseur nécessaire pour faciliter la transformation DevOps et la pérenniser.

On réduit souvent DevOps au déploiement d’outils permettant le provisionning automatique de l’infrastructure et le déploiement rapide de nouvelles fonctionnalités. Cependant, ces nouvelles possibilités, couplées à l’introduction de nouvelles pratiques comme l’IaC, permettent de donner de l’ampleur à notre transformation DevOps.

Mais voilà, après quelques mois, la fréquence des livraisons est en chute libre et la tension entre les équipes s’est accrue : les Ops grognent à cause des 5 derniers déploiements ratés, et les Devs taclent les Ops pour leur ignorance de l’architecture microservice.

Une vague impression de déjà-vu peut-être… Et si nous avions oublié quelque chose…

Dans cette session, nous vous proposons de partager les modèles d’organisation mis en place ou observés ces dernières années au sein des entreprises pour lesquelles nous avons travaillé. Si tout ne s’est pas toujours déroulé comme prévu, ces changements organisationnels restent le catalyseur nécessaire pour faciliter la transformation DevOps et la pérenniser.

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (15)

Similaire à Joseph Glorieux & Mathieu Brun Maintenant que mon delivery pipeline est en place, que faire de mon organisation? (20)

Publicité

Plus par matteo mazzeri (12)

Plus récents (20)

Publicité

Joseph Glorieux & Mathieu Brun Maintenant que mon delivery pipeline est en place, que faire de mon organisation?

  1. 1. Joseph Glorieux Groupe Pictet 2020-02-24 Maintenant que mon delivery pipeline est en place, que faire de mon organisation?
  2. 2. About Us Nouvellement responsable de la transition vers le cloud au sein du groupe Pictet, Joseph a passé ses 10 dernières années sur des transformations d’organisation IT vers de nouvelles façons de faire jglorieux@pictet.com Cloud Transition Architect @Pictet Département Infrastructure Joseph Glorieux Architecte auprès de Kleis Technology,Mathieu s'évertue à réduire les actions manuelles des développeurs depuis 10 ans mbrun@kleis.ch Architecte Kleis Technology SA Mathieu Brun Pictet Group 2
  3. 3. 202 Billion Assets under Management Billion Assets under Management or custody Asset Management Wealth Management Asset Services The Pictet Group A partnership of 7 partners Specialist investment Management for institutions And investment funds Private banking Wealth Solutions Family Office Services Custody Fund solutions Trading Services Billion Assets under Management 234 186
  4. 4. 4,694 employees 7petabytes of block storage data 2,400 databases ≈650 IT guys
  5. 5. Repartons de l’abstract du talk On réduit souvent DevOps au déploiement d’outils permettant le provisionning automatique de l’infrastructure et le déploiement rapide de nouvelles fonctionnalités… Mais voilà, après quelques mois, la fréquence des livraisons est en chute libre et la tension entre les équipes s’est accrue : les Ops grognent à cause des 5 derniers déploiements ratés, et les Devs taclent les Ops pour leur ignorance de l’architecture microservice. Une vague impression de déjà-vu peut-être… Et si nous avions oublié quelque chose… 5Pictet Group
  6. 6. 3 niveaux de changements à travailler 6Pictet Group Individu Equipe Département Software craftsmanship Software factory Continuous deployment T-shaped Livrer fréquemment Egoless Decoupled architecture Logging et monitoring Infrastructure as Service Coopération Amélioration continue Autonomie et responsabilité Servant leadership Communauté de pratique Organisation des équipesManagement visuel Feedback Product management Maturité
  7. 7. Un monde parfait ? 7Pictet Group Illustration by https://undraw.co/illustrations Didier Développeur Pauline Product owner Ophélie Infrastructure
  8. 8. Pourquoi parler d’organisation quand on parle de DevOps? Photo by John Robert Marasigan on Unsplash 8Pictet Group
  9. 9. L’organisation comme levier ou frein au changement 9Pictet Group Conway’s Law « les organisations qui conçoivent des systèmes [...] sont contraintes de produire des designs qui sont des copies de la structure de communication de leur organisation. »
  10. 10. L’organigramme comme squelette 10Pictet Group Direction Business line 1 Business line 2 IT Solution Infrastructure Cloud? organisation
  11. 11. Penser une organisation au service d’un objectif partagé DevOps vise une amélioration du processus de software delivery (développement, évolution et opération) en termes de qualité (NFR, sécurité, stabilité) et de time to market. 11Pictet Group Analyse du besoin Spécification Design Développement Test Déploiement Opération Zone potentielle d’amélioration Business Analyste Architecte Développeur Testeur Intégrateur Ops Département business Département étude Département infrastructure
  12. 12. Disclaimer › Pas de silver bullet › Pas de modèle Spotify › Rarement un unique modèle déployé au sein d’une entreprise › Attention aux faux amis – effet Canada dry › Partage de cas comme source d’inspiration pour déployer vos propres modèles 12Pictet Group Henrik Kniberg & Anders Ivarsson, https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
  13. 13. Rex 1 : do DevOps yourself Description: L’équipe a ressenti le besoin d’expertise sur la partie automatisation des déploiements et a décidé de recruter un Ops et de l’incorporer dans l’équipe. 13Pictet Group Contexte: Produit dans le domaine du digital à destination des clients de la banque sur les sujets d’advisory. Architecture & tools Microservice Zéro downtime Rundeck Puppet Atlassian Culture & pratique Autonomisation des équipes Exigence Agile Pros & Cons: - Automatisation du déploiement - Incident management - Partage avec l’infrastructure - Autonomie partiel devs Techleads Ops Architecte BA Product manager Product owners Testeur Infosec Scrum master
  14. 14. Rex 2 : DevOps team Description: Création d’une équipe DevOps pour bootstrapper des ressources communes concernant les environnements et le déploiement. 14Pictet Group Contexte: Produit dans le domaine de l’IoT vendu en mode SaaS ou on premises construit par une dizaine d’équipes sur 5 sites différents. Architecture & tools Architecture API Hardware et software Cloud Multitenancy Cloud foundation AWS suite Code commit/code pipeline Culture & pratiques Ingénieur Hardware plus que software SAFe Pros & Cons: devs Techlead Ops Product owner System Testeur Infosec Scrum master - Convergence du pipeline - Accélérateur - Vision éphémère - Partage - Pas concerné par le run - Pas de vision plateforme - Les autres équipes
  15. 15. Rex 3 : Product team Description: Equipe produit intégrant l’ensemble des compétences nécessaires pour gérer le produit du design au run (piquet inclus). 15Pictet Group Contexte: Equipe produit en charge de proposer une solution de business process outsourcing concernant la sécurité. Après un bilan très mitigé sur l’industrialisation du MVP, la refactoring en profondeur du produit est l’occasion de reposer une nouvelle organisation. Architecture & tools Multitenant Multipackage Openstack Ansible puppet Culture & pratiques Ingénieur Sécurité Maturité Ops Agile Pros & Cons:Devs Techlead Ops Architecte Product owner Scrum master Testeur Infosec Product manager opération UX - Internalisation et dédication - Maitrise du produit - Montée en compétence - Réplication - Hors IT - Scalabilité
  16. 16. Rex 4 : Component team Ops Description: Equipe composant pluridisciplinaire en charge de fournir et d’opérer une capacité/une plateforme pour des clients. 16Pictet Group Contexte: Suite à une réorganisation massive des équipes d’infrastructure et dans la cadre de l’adoption du cloud, mise en place d’équipe produit fournissant des capacités ou plateforme : Database As a service. Architecture & tools Oracle, postgre, microsoft AWS et azure stack Ansible Puppet Culture & pratiques Externalisation Early adopter L’argent n’est pas un problème Pros & Cons: Externes Techlead Ops Architecte Product owner client client client Scrum master client - As a service - Product ownership et vision produit - Capitalisation - Retour sur investissement - Bottleneck
  17. 17. Rex 5 : Organisation produit Description: Equipe produit pluridisciplinaire en charge du build et du run s’appuyant sur une plateforme fournie par une équipe pluridisciplinaire en charge du build et du run s’appuyant… 17Pictet Group Contexte: Dans le cas d’une solution de cloud managé basée sur un cloud provider pour les différentes lignes métiers de la banque, une équipe produit a été mise en place pour s’occuper de ce cloud managé. Les équipes utilisatrices ont pour la plupart suivi le même chemin. Architecture & tools Cloud hybrid Terraform Gitlab Atlantis Go Cloud provider tools Culture & pratiques Autonomisation des équipes Agile Intrapreneurship Sécurité Pros & Cons: - Security by design - Time to market - Autonomie et responsabilité des équipes - Greenfield - À voir sur la durée Cloud provider
  18. 18. Rex 6 : No Ops volume 1 Description: L’infrastructure, c’est du «plug and play», on n’a pas besoin d’Ops. 18Pictet Group Contexte: Dans la cadre de MVP fonctionnel de startup, un tooling de haut niveau a été préféré afin d’accélérer le déploiement. A ce titre, «aucune» compétence Ops n’a été nécessaire. Architecture & tools Cloud &Service managé Low code ou No code: Wix, .bubble, base de données (AirTable, Google Sheets, …), formulaires (TypeForm, Google Form), workflows (Zapier, Ifttt, …), du mailing(mailchimp, mailjet, …) Culture & pratiques Startup Pas IT Pros & Cons: Product owner Scrum master Testeur Designer UX Growth hacker Analyste - Time to market - Tester le marché - Time to market - Scalabilité - Cout - Souplesse et couverture
  19. 19. Rex 7 : No Ops volume 2 Description: L’Ops n’est plus un sujet et a été dilué du fait de la maturité des équipes engineering et de s’appuyer essentiellementsur des services managés externes. 19Pictet Group Contexte: Après plusieurs années de fonctionnement, sur la base de formation, de pratique et de partage, le rôle d’Ops ainsi que d’autres rôles ont été dilués au sein de tous les membres de l’équipe. Architecture & tools Cloud first Service managé Microservice Culture & pratiques Startup Pérennité des équipes Agile Pros & Cons: Product owner UX Team members - Résilience - Montée en compétence - Recrutement - Cout - Variabilité (business, socle)
  20. 20. Rex 8 : SRE Description: Google s’appuie sur des SRE (site reliability engineering) pour le run de ces applications. Les SRE ne travaillent pas au sein des équipes produit mais sont mutualisés sur les produits. 20Pictet Group Contexte: Dans le cadre de développement produit au sein de cet acteur, un processus de handover se met en place dépendant de la maturité du produit et des équipes. Ce handover est bidirectionnel. Architecture & tools Stack GCloud Culture & pratiques Tech Cloud native Mesure Expertise Innovation Pros & Cons: Stabilité Hand-off SRE SRESelf-run Hand-back Hand-off SRE@Google: thousandsod DevOPS Since 2004 - Accompagnement - Responsabilisation - «Choix» - Architecture non standard - Ingénieur Google
  21. 21. Tentative de mise en équation 21Pictet Group ApplicationInfrastructure Interface Infrastructure de type plateforme standardisée Asset déployable et exploitable Produit Do the right product Do the product right As a service Delivery pipeline Alerting, logging, monitoring du produit Provisioning… Build de la plateforme Assurer les SLA Billing… OPS
  22. 22. Roadmap 22Pictet Group Point de départ - Do it yourself - DevOps team - Communauté de pratique Transition - Equipe produit - Equipe plateforme - Enabler team - 30 days blitz Cible - SRE? - Organisation produit? - No Ops? - Ça dépend?
  23. 23. 3 niveaux de changements à travailler 23Pictet Group Individu Equipe Département Software craftsmanship Software factory Continuous deployment Infrastructure as Code T-shaped Livrer fréquemment Egoless Decoupled architecture Logging et monitoring Infrastructure as Service Coopération Amélioration continue Autonomie et responsabilité Servant leadership Communauté de pratique Organisation des équipesManagement visuel Feedback Product management Maturité
  24. 24. Faites une cuisine adaptée à votre culture 24Pictet Group «Culture eats strategy for breakfast» Peter Drucker
  25. 25. Pictet ; a 215 year-old start-up investing for the next 215 years. We are hiring: https://www.group.pictet/careers

×