Operations

Il s’agit du livre de référence dans le domaine, celui qui a lancé et donné son nom – enfin je crois – à la discipline visant à mettre le software engineering au service de la production ou des opérations. Avant cela, il y avait les développeurs en charge de concevoir les applications et ceux que l’on appelait les administrateurs s’occupaient de les déployer et de les superviser en production. Le problème avec ce modèle est que les uns ne connaissent rien – ou presque – au travail des autres et le résultat était au mieux chaotique et au pire donnait lieu à des querelles assez animées qui se transformaient vite en guerre de tranchées. Ça semble aberrant, mais c’était le modèle et c’est cette fracture que la mouvance DevOps s’est efforcée de résorber. Difficile de différencier clairement les deux mouvances, mais je dirais – ce n’est que mon point de vue – que le DevOps peut être atteint en constituant des équipes mixtes (développeurs + administrateurs) alors que les SRE possèdent des compétences mixtes (développement et administration), et mettent l’une au service de l’autre, l’Infrastructure as Code en est le parfait exemple. ...

Juste une courte note à propos de ce livre que j’ai utilisé dans le cadre de mon travail. Tout d’abord deux points positifs. Le premier est qu’il traite des sujets monitoring, alerting et reporting en général, c’est-à-dire indépendamment de l’outillage utilisé. C’est à la fois un point fort et un point faible puisqu’il pourrait être utile d’identifier des familles d’outils adaptés à chaque usage. Cette volonté de s’écarter des outils est assez rare pour être soulignée. Cette prise de recul permet d’introduire de la structure – je pense par exemple à l’organisation du monitoring en stacks qui est absolument cruciale –, des notions et des définitions générales et applicables en toutes circonstances – ou presque. Et on en vient au deuxième point fort, les définitions donc. Il est essentiel dans le cadre professionnel de s’appuyer sur des définitions précises qui permettent d’encadrer des concepts que la plupart des gens ont une fâcheuse tendance à confondre comme monitoring et alerting par exemple. ...

Ce livre est simple et bien conçu. Il aborde les thèmes essentiels auxquels il est nécessaire de s’intéresser si l’on veut construire, déployer et opérer des applications à grande échelle. Les voici, je n’invente rien, ce sont les cinq sections du livre: Disponibilité: Comment rendre les systèmes hautement disponibles et comment s’assurer qu’ils le sont via la mise en place de mesures. Gestion des risques: Comment construire une analyse de risques et mener des actions de remédiation. Services et microservices: Prendre conscience de l’intérêt (et des travers) de ce découpage, adapter son organisation en fonction. Scaling: Comment découper les services, leur dépendances et savoir comment s’organiser pour les opérer. Cloud: Quels sont les services offerts dans le cloud, comment sont-ils organisés et opérés quels sont les avantages et les inconvénients. Lee Atchinson parvient très bien a offrir un panorama de tous ces sujets. Sans rentrer dans les détails, il donne des points essentiels, des incontournables. Il constitue donc une très bonne entrée en matière pour les néophytes, mais il peut aussi être utilisé comme une référence car il fournit des définitions simples et assez bien faites appelant le consensus. Au delà des définitions je m’en suis servi plusieurs fois comme boîte à outil par exemple pour construire une analyse de risques ou pour établir une cartographie des services avec leurs dépendances et leur criticité (notion de Tiers). Dans le cadre de ces figures imposées, il donne toute l’ossature, il n’y a plus qu’à suivre le guide. ...