La philosophie « Build to Fail » de DevOps constitue-t-elle un risque pour la sécurité ?

En brisant la loi de Betteridge sur les gros titres , la réponse courte est oui. Mais comme tout ce qui touche à la technologie aujourd’hui, la réponse longue est un peu plus complexe que cela.

DevOps est devenu, je pense, assez répandu dans tous les secteurs. Même si toutes les organisations n’adoptent pas tous les aspects de cette approche ou n’appliquent pas ses principes avec la même zèle que Netflix, c’est assurément une « chose » qui se produit.

Bien que cela ne soit pas directement un point de preuve, lorsque nous avons demandé aux plus de 3 000 répondants comment la transformation numérique impactait leurs décisions application pour notre État de la livraison des application 2018, deux des trois principales réponses étaient « utiliser l'automatisation et l'orchestration des systèmes et processus informatiques » et « changer la façon dont nous développons des applications (par exemple, passer à l'agilité) ». Pour moi, ce sont deux réactions implicites à l’adoption d’au moins certaines parties d’une approche DevOps pour développer et fournir des applications dans des architectures modernes.

Ainsi, si les organisations adoptent certains outils et techniques liés à DevOps, on peut supposer qu’elles en adoptent également d’autres. L’une d’entre elles pourrait même être (musique dramatique) : construire pour échouer.

Cette expression est quelque peu imprécise, car personne ne se contente de concevoir des systèmes voués à l’échec. Ce qu’ils font, en revanche, c’est concevoir des systèmes qui résistent aux pannes. Cela signifie, par exemple, que si une instance (serveur) tombe en panne, le système doit être capable de gérer automatiquement la situation en supprimant l'instance morte et en en démarrant une nouvelle pour prendre sa place.

Voilà ! Conçu pour échouer.

Et même si cela constitue certainement une réaction souhaitable – en particulier lorsqu’un système est soumis à une charge et une demande importantes – cette approche comporte un risque qui doit être pris en compte et, espérons-le, traité par la suite.

Considérez la vulnérabilité de Cloudflare du début de l’année 2017 . Cloudflare, qui a fait preuve d’une transparence admirable dans son propre rapport sur le problème, note qu’il s’agissait essentiellement d’une fuite de mémoire (entraînant une fuite potentielle de données) causée par un défaut dans une extension d’un analyseur HTTP. Pour faire court, le bug a provoqué une fuite de mémoire qui a provoqué le plantage des instances. Ces instances ont été tuées et redémarrées car elles sont conçues pour échouer.    

Pour mémoire, il ne s'agit pas d'un article destiné à critiquer Cloudflare pour un bug. En tant que développeur, je suis très sensible au fait que les défauts de quelqu'un soient exposés aussi publiquement. Je suis moins compréhensif dans les situations où l'on se soucie peu de découvrir pourquoi quelque chose plante, perd de la mémoire ou échoue tout simplement.

C’est le but du post d’aujourd’hui. Parce que parfois, la philosophie DevOps laisse ses adeptes avec une approche de laisser-faire en matière d’investigation post-échec.

Il est parfaitement raisonnable de réagir à une panne de service/application en arrêtant et en redémarrant le service pour garantir sa disponibilité, à condition d’enquêter ensuite sur la panne pour déterminer sa cause. Les applications ne plantent pas sans raison. S'il tombait, c'est que quelque chose le poussait. Neuf fois sur dix, cela ressemble à une erreur non exploitable. Rien à écrire sur un article de blog. Mais la seule fois où il s’agit d’une vulnérabilité sérieuse qui attend d’être exploitée, cela vaut la peine de consacrer des efforts apparemment vains aux neuf autres. Parce que c’est quelque chose sur lequel il faut écrire un article de blog.

Il n’est pas raisonnable de l’ignorer.

La surveillance et l’alerte sur les pannes et autres problèmes constituent également un élément clé d’un programme DevOps complet. C'est le « S » dans les CAMS qui constituent une approche DevOps holistique : Culture, automatisation, mesure et partage. Damon et John (qui ont inventé l'acronyme en 2010) ne parlaient pas seulement de pizza et de bière (même si c'est une bonne façon d'encourager le « C » pour Culture of DevOps). Il s’agit également de données et de l’état des systèmes. Il s’agit de veiller à ce que ceux qui peuvent bénéficier du savoir le sachent. Et cela inclut une défaillance du système.

Une panne – en particulier un crash – ne doit pas rester impunie. Si un système dans le pipeline tombe en panne, quelqu'un doit le savoir et quelqu'un doit le vérifier. L’ignorer constitue un risque pour la sécurité. Pire encore, c’est un risque évitable car il s’agit de votre environnement, de vos systèmes et de votre code. Vous avez un contrôle total et n’avez donc aucune excuse pour l’ignorer.

Donc oui, en un mot, « construire pour échouer » peut exposer vos applications – et votre entreprise – à des risques de sécurité. La bonne nouvelle est que ces risques sont tout à fait gérables, si vous veillez à ce que la philosophie ne soit pas sur le papier « conçue pour échouer », mais qu’en pratique elle finisse par être « conçue pour ignorer un échec ».

Faites attention aux éléments qui plantent, même si vous les redémarrez, pour maintenir une disponibilité élevée. Vous pouvez vous épargner (ainsi qu'à votre entreprise) d'apparaître en tendance sur Twitter pour toutes les mauvaises raisons.