LinuxJobs LinuxJobs (mobile)

SRE (Site Reliability Engineer) - full remote ou Lyon - H/F (télétravail)

Ajoutée le 24 juin 2022

waays

Lyon (Devops)

https://www.waays.fr


TLDR

  • expériences pro : +5 ans
  • équipe : 1 cto, 1 admin sys, 1 cos
  • lieu : télétravail ou Lyon (Bellecour)
  • contrat : cdi (50 à 75k€) ou freelance (400 à 700, en fonction du volume)
  • astreinte : pas d'astreinte en dehors des heures de bureau

Qui sommes-nous ?

Waays se positionne en qualité de Responsable d’Exploitation à «temps partagé». Nous avons la responsabilité des infrastructures que nous conseillons, montons et dont nous assurons les maintenances évolutives.

Waays accompagne aujourd’hui +35 clients qui nous confient au total leurs +800 serveurs (baremetals et virtuels). Ces clients sont des e-commerçants, des saas, des jeux vidéos ou des médias.

Quel est notre rôle auprès des clients ?

Waays apporte de la tranquillité.

Nous sommes force de proposition sur les choix techniques et aidons les développeurs sur leurs éventuels soucis d’exploitation.

Une panne d’un élément ne doit pas entraîner une panne de service. Comme dans l’aviation, nous préconisons de tripler tous les éléments critiques afin que la perte de l’un d’eux ne soit pas un problème.

Si il y a une indisponibilité auprès des utilisateurs finaux, c’est que nous n’avons pas su anticiper ledit problème.

C’est pour cela que nous scriptons nos installations, nous redondons les serveurs de production comme les sauvegardes.

Quelles seront tes principales missions chez Waays ?

Tu auras les missions suivantes :

  • contribuer à l’amélioration continue des infras, de nos outils, voire des outils des clients
  • intervenir en cas de panne (1 seul jour par semaine et en heures ouvrées uniquement)
  • résoudre les problèmes et apporter des solutions durables et reproductibles

Cette année 2022, nous travaillons ou allons travailler sur les chantiers suivants :

  • mise en place de SLO, avec les outils adéquats (via Prometheus ou non)
  • systématiser la centralisation des logs (probablement Loki, à étudier)
  • améliorer les vérifications des sauvegardes
  • industrialiser et améliorer la supervision de Kubernetes
  • revoir et améliorer tous les déploiements des Gitlab-Runner
  • déploiement et intégration d'Hashicorp Vault
  • industrialisation d'un système d'auto-health
  • amélioration de la documentation (runbooks)

Notre vision du rôle de SRE

Nous adhérons à 100% à l’itération : mesurer → analyser → modifier → recommencer.

La répartition de notre temps doit tendre vers cet objectif :

  • 50% amélioration des outils internes / composants réutilisables et réduction des tâches manuelles
  • 20% d’astreintes et analyses des problèmes
  • 20% d’échanges avec les développeurs
  • 10% divers

Ce qui est important à nos yeux est l’approche “responsable d’exploitation”. Afin d’atteindre des infras fiables et efficaces, nous nous devons d’être proches des développeurs et de nous appliquer la même rigueur qu’eux : merge requests, code review, tests, etc.

Il arrive forcément qu’il y ait des loupés, mais c’est l’occasion de faire évoluer les tests et/ou la supervision. Le droit à l’erreur est de mise.

Quelle est notre organisation et notre modèle d’accompagnement auprès des clients ?

Nous travaillons sur du temps réservé. Nos clients réservent de ½ journée à 10 jours chaque mois. Nous sommes flexibles et avons une vue de ce temps par trimestre.

L’équipe de Waays partage son temps sur l’ensemble des clients et mutualise ses livrables techniques en permanence.

Quelques éléments pour appréhender ton futur quotidien :

  • Nous n’avons pas besoin de vendre grâce à ce temps réservé (d’ailleurs, nous n’avons pas de commercial !)
  • Nous choisissons les technologies sur lesquelles nous souhaitons travailler. Nous utilisons l’open source, à 99% sous Debian
  • Nous ne travaillons pas pour un seul client. Au contraire, tu travailleras sur l’ensemble des 35 clients
  • Nous testons et déployons sur plusieurs clients en répartissant le temps / coût
  • Nous assurons une astreinte 24/7/365.
  • Tu assureras la gestion des alertes une journée par semaine pendant les heures ouvrées
  • Comme il peut n’y avoir “que” 2 ou 3 alertes par jour, cette journée est à jumelée avec la journée de R&D / interne.
  • Tu n’auras pas à intervenir en dehors de ces heures ouvrées, nous faisons appel à des prestataires pour cela

La répartition du temps dans le mois est :

  • 12 jours de travail dédiés à la production (70%)
  • 4 jours de R&D et/ou interne (20%)
  • 2 jours de synchronisation d’équipe (pour le point hebdo (1h) et le daily (15min / jour) (10%)

Nous gérons les demandes clients en suivant les principes Agile Kanban.

Pour la relation client, nous utilisons différents outils :

  • clickup : pour la gestion des demandes clients et les nôtres
  • mattermost : équivalent open source de Slack avec des chanels exclusivement d’équipe ou de projets
  • les emails : pour acter les prises de décisions importantes
  • la visio avec jitsi

Une documentation (via antora) permet aux clients d’avoir accès aux informations relatives à leurs infras. Dans le même temps, les processus internes sont décrits pour les collaborateurs et les intervenants externes.

Nous accordons une forte autonomie dans la réalisation des tâches clients et internes. Le résultat reproductible est le principal focus : on détruit et on relance le script et cela valide que tout fonctionne.

En contrepartie de l’autonomie, il est indispensable d’être en mesure de solliciter de l’aide en cas de blocage ou incompréhension des attendus. Tous les canaux sont bons pour le faire !

Dernier point et non des moindres : l’attitude. Nous pouvons évoluer dans un contexte de tension lié à des pannes. Même si on essaye de limiter celle-ci en anticipant, il arrive que cela ne soit pas possible. Nous prônons la transparence, la bienveillance et la communication auprès de toutes les parties.

Une tâche type pour toi chez Waays ?

Quelques exemples typiques :

  • mettre en place tout ce qu’il faut pour détruire/reconstruire une machine exploitant le service SFTPgo
  • adapter les scripts pour changer tous les mots de passe PostgreSQL sur la staging, pour la restauration hebdomadaire d’un backup de la prod
  • adapter la supervision pour migrer progressivement du plugin HAproxy de Netdata vers l’exporter open-metrics natif de HAproxy
  • adapter le bundle Percona-Server 5.7 pour la v8, qui apporte son lot de breaking changes
  • analyser le monitoring, puis recommander des améliorations (ou investigations)
  • débugger un problème de sessions PHP avec le client
  • aider un client à identifier les problèmes de contention d’un traitement mettant aujourd’hui 12 heures à tourner
  • migrer un service d’un hébergeur X sans industrialisation, vers un hébergeur Y avec industrialisation
  • répondre aux questions des développeurs concernant les bonnes pratiques / nos recommandations
  • rédiger la documentation pour telle ou telle problématique

Notre vision de la R&D ?

La R&D est indispensable autant en interne que pour les clients. Nous devons améliorer nos outils interne comme notre outil de supervision que les infras de nos clients.

Nous voyons donc deux façons de travailler sur des sujets innovants :

  • Nous consacrons 20% de notre temps à la R&D. Tu seras force de proposition sur ce qu’il faut améliorer. Une liste (non exhaustive) est dressée mais elle est complètement évolutive selon les besoins, les affinités et les priorités
  • Nous choisissons 50% du temps réservé de nos clients pour faire évoluer leurs infras. Ainsi, nous pouvons là aussi faire de la R&D tant que ça nous semble pertinent

Nous ne sommes attachés à aucune technologie, mise à part Git et Debian.

Deux seuls impératifs à toujours garder à l’esprit : la reproductibilité et l’observabilité.

Notre approche GitOps

Nous prenons le temps de bien faire les choses car nous visons le long terme pour garantir la stabilité et la reproductibilité des infrastructures.

Notre approche Infra as code se veut déclarative plutôt que itérative. C’est à dire que nous préférons déclarer dans Git le but à atteindre, l’objectif souhaité, plutôt que des scripts devant être exécutés dans un ordre et contexte précis (charge ensuite à nos outils d’effectuer la «réconciliation», de calculer comment atteindre le but en question).

Ainsi nous utilisons Git avant tout pour :

  • la traçabilité : c'est ce qui nous permet de savoir pourquoi et quand une modification a été faite
  • le travail en équipe : rien de plus formateur que de voir comment les collègues travaillent et résolvent tel ou tel problème
  • l'amélioration continue / réutilisabilité : c'est par cette volonté de tout scripter qu'une amélioration continue et régulière des infras est possible. C’est comme cela, que toutes les infras profitent régulièrement des améliorations issues des autres infras

Bref, comme des développeurs.

La reproductibilité et l’observabilité

Nous mettons l'accent sur la capacité de reproduire chacune des 800 machines que nous gérons. Chaque machine doit pouvoir être remplacée par un script. Et étant donné que nous passons beaucoup de temps à optimiser les infras, nous avons de gros besoin d'observabilité : nous exploitons un petit cluster Prometheus de 9To, que nous améliorons très régulièrement.

La supervision est utilisée comme des tests unitaires : chaque nouveau problème doit faire l'objet de la création d'une nouvelle sonde Prometheus/Alertmanager, afin d'accélérer la découverte du problème futur et partager la connaissance avec les collaborateurs.

Notre stack technique

Nous travaillons exclusivement avec des technos open source :

  • HAproxy, NginX, Varnish, Apache
  • MariaDB (Galera ou non), MySQL, PostgreSQL, Neo4j, Redis, Memcached
  • RabbitMQ, ElasticSearch, SphinxSearch
  • une majorité d’app en PHP et d’autres en Python, NodeJS ou Ruby
  • des Kubernetes (qu'on souhaite gérer exclusivement via FluxCD ou ArgoCD)
  • des clusters Ceph (oui oui), et un peu de MinIO
  • Prometheus, Grafana, Loki, ELK, Graylog

La quasi-totalité du parc utilise des Debian (v11, v10, v9, et v8), ainsi qu'une dizaine d'instances Ubuntu.

Le parc est à 80% hébergé chez OVH (dans tous leurs datacenters non US). Le reste étant chez GCP, Vultr, DigitalOcean, Linode, ou encore Scaleway, Gandi et D-Lake pour les français.

Qui se cache derrière l’équipe Waays ?

Il y a 3 collaborateurs de Waays :

Olivier Bonvalet, gérant et fondateur de Waays (depuis 2006)

Romain P, Architecte Admin Sys (depuis 2022)

Olivier Giry, Bras droit du dirigeant / CTO (Olivier Bonvalet (depuis 2019)

Nous avons également trois personnes (en freelance) pour gérer les astreintes de Niveau 1 en heure non ouvrée.

Quels environnements de travail nous fournissons ?

Nous sommes historiquement basés à Lyon. Nous avons des bureaux Place Bellecour. Un de nos collaborateurs est en télétravail à Marseille.

Nous fournissons le package suivant :

Nous sommes ouvert sur l’aspect contractuel : cdi ou freelance.

Pour le Contrat type “Cdi”, nous offrons les éléments suivants :

  • Rtt : 18 jours, selon nombre de jours ouvrés annuels
  • Mutuelle
  • salarié + enfant(s) : pris en charge à 100%
  • conjoint(e) : 52€ / mois
  • Prévoyance : oui, prise en charge à 100%
  • Titre de transport en commun : 50%
  • Panier repas : forfait mensuel de 100€, sous forme de frais professionnel
  • Au choix : mise à disposition d’un téléphone portable et forfait mobile ou un dédommagement de 10€ mensuel (dans le cadre d’installer les applications Aircall de téléphonie via IP et PagerDuty pour l’astreinte de journée)

Quel est le processus de recrutement ?

Il y a deux échanges, en visio ou présentiel :

  • un échange “technique” : 60/90 minutes avec Olivier Bonvalet présentation de Waays et notre stack technique présentation de ton parcours et expériences échange libre
  • un échange “humain”
    présentation de Waays au quotidien “non tech” échange libre
LinuxJobs Twitter LinuxJobs Diasporas Twitter RSS LinuxJobs Journal du hacker