Pourquoi les ingénieurs ne se soucient-ils pas de la surveillance des applications?

Tous avec vendredi! Mes amis, nous continuons aujourd'hui une série de publications consacrées au cours DevOps Practices and Tools , car les cours du nouveau groupe du cours commenceront à la fin de la semaine prochaine. Commençons donc!



La surveillance est simple . C'est un fait connu. Soulevez Nagios, exécutez NRPE sur le système distant, configurez Nagios sur le port TCP NRPE 5666 et vous avez la surveillance.

C'est tellement facile que ce n'est pas intéressant. Vous disposez maintenant des métriques de base pour le temps processeur, le sous-système de disque, la RAM, qui viennent par défaut dans Nagios et NRPE. Mais en réalité, il ne s'agit pas de «surveillance» en tant que telle. Ce n'est que le début.

(Habituellement, ils installent PNP4Nagios, RRDtool et Thruk, configurent des notifications dans Slack et vont directement à nagiosexchange, mais pour l'instant laissent aller).

Une bonne surveillance est en fait assez compliquée, vous devez vraiment connaître les internes de l'application que vous regardez.

La surveillance est-elle difficile?

Tout serveur, qu'il soit Linux ou Windows, par définition, aura une fonction. Apache, Samba, Tomcat, stockage de fichiers, LDAP - tous ces services sont plus ou moins uniques à un ou plusieurs égards. Chacun a sa propre fonction, ses propres caractéristiques. Il existe différentes façons d'obtenir des métriques, KPI (indicateurs de performance clés), intéressantes pour vous lorsque le serveur est sous charge.


Photo de Luke Chesser sur Unsplash


(Je voudrais que mes tableaux de bord soient peints dans des couleurs bleu néon - en soupirant rêveusement - ... hmm ...)

Tout logiciel qui fournit des services doit disposer d'un mécanisme de collecte des métriques. Apache possède un module mod-status qui affiche la page d' mod-status du serveur. Nginx a stub_status . Tomcat dispose de JMX ou d'applications Web spéciales qui affichent des mesures clés. MySQL a la commande «afficher l'état global», etc.
Alors pourquoi les développeurs n'intègrent-ils pas de tels mécanismes dans les applications qu'ils créent?

Les développeurs ne font-ils que cela?

Un certain niveau d'indifférence à intégrer des métriques ne se limite pas aux développeurs. J'ai travaillé dans des entreprises où j'ai développé des applications à l'aide de Tomcat et je n'ai produit aucune de mes mesures, aucun journal d'activité de service, à l'exception des journaux d'erreur généraux de Tomcat. Certains développeurs génèrent une abondance de journaux qui ne signifient rien pour l'administrateur système, qui n'a pas eu la chance de les lire à 3 h 15 du matin.


Publié par Tim Gouw sur Unsplash

Les ingénieurs système qui autorisent la sortie de tels produits devraient également être responsables de la situation. Peu d'ingénieurs système ont le temps et le soin d'essayer d'obtenir des métriques significatives à partir des journaux, sans le contexte de ces métriques et la capacité de les interpréter à la lumière de l'activité de l'application. Certains ne comprennent pas quels avantages ils peuvent en retirer, à l'exception d'indicateurs tels que "quelque chose ne va pas (ou va bientôt)".

Un changement de pensée concernant le besoin de métriques devrait se produire non seulement parmi les développeurs, mais aussi parmi les ingénieurs système.

Pour tout ingénieur système qui doit non seulement répondre aux événements critiques, mais également garantir leur absence, l'absence de métriques est généralement un obstacle à cela.

Cependant, les ingénieurs système ne creusent généralement pas le code, ce qui fait de l'argent pour leur entreprise. Ils ont besoin de développeurs de premier plan qui comprennent l'importance de la responsabilité d'un ingénieur système dans la détection des problèmes, la sensibilisation aux problèmes de performances, etc.

Cette chose devops

La mentalité des devops décrit la synergie de la pensée des développeurs (devs) et de l'exploitation (ops). Toute entreprise qui prétend «faire des devops» devrait:

1. pour dire ce qu'ils ne font probablement pas (une allusion au mème du film "Princess Bride" - "Je ne pense pas que cela signifie ce que vous pensez que cela signifie!")
2. promouvoir une position d'amélioration continue des produits.

Vous ne pouvez pas améliorer un produit et savoir qu'il a été amélioré si vous ne savez pas comment il fonctionne actuellement. Vous ne pourrez pas savoir comment fonctionne un produit si vous ne comprenez pas comment fonctionnent ses composants, les services dont il dépend, ses principaux points faibles et ses goulots d'étranglement.
Sauf si vous observez des goulots d'étranglement potentiels, vous ne pouvez pas suivre la technique des cinq pourquoi lors de l'écriture de l'autopsie. Vous ne pouvez pas tout rassembler sur un seul écran pour voir comment le produit fonctionne ou pour savoir à quoi il ressemble «normal et heureux».

Décalage à gauche, GAUCHE, DIT-JE, NOOOOOOOO—

Pour moi, l'un des principes clés de Devops est le «décalage à gauche». Un décalage vers la gauche dans ce contexte signifie un changement dans la capacité ( pas la responsabilité , mais seulement la capacité) de faire ce que les ingénieurs système se soucient habituellement, par exemple, de créer des mesures de performances, d'utiliser les journaux plus efficacement, etc., vers la gauche dans le cycle de vie de la livraison de logiciels ( Cycle de vie de la livraison de logiciels).


Photo de NESA par Makers sur Unsplash

Les développeurs de logiciels devraient être en mesure d'utiliser et de connaître les outils de surveillance que l'entreprise utilise pour surveiller sous toutes ses formes, les mesures, la journalisation, les interfaces de surveillance et, plus important encore, observer le fonctionnement de leur produit en production . Vous ne pouvez pas forcer les développeurs à investir du temps et des efforts dans la surveillance jusqu'à ce qu'ils puissent voir les métriques et influencer leur apparence, la façon dont le propriétaire du produit présentera ses CTO lors du prochain briefing, etc.

Bref

1. Amenez le cheval à l'eau. Montrez aux développeurs combien de problèmes ils peuvent éviter eux-mêmes, aidez-les à identifier les bons indicateurs de performance clés et les mesures pour leurs applications afin qu'il y ait moins de cris de la part du propriétaire du produit que le CTO. Apportez-les à la lumière, doucement et calmement. Si cela ne fonctionne pas, soudoyez, menacez et persuadez eux ou le propriétaire du produit afin d'obtenir rapidement ces mesures à partir des applications, puis dessinez des diagrammes. Cela sera difficile, car il ne sera pas considéré comme une priorité, et de nombreux projets générateurs de revenus attendent d'être mis en œuvre dans la feuille de route des produits. Par conséquent, vous aurez besoin d'une analyse de rentabilisation pour justifier le temps et l'argent consacrés à la mise en œuvre de la surveillance dans le produit.
2. Aidez les ingénieurs système à dormir suffisamment. Montrez-leur qu'il est bon d'utiliser une liste de vérification des versions pour tout produit. Et vérifier que toutes les applications en production sont couvertes de métriques vous aidera à passer une bonne nuit de sommeil, permettant aux développeurs de voir ce qui fonctionne et où cela ne fonctionne pas. Cependant, la bonne façon d'agacer et de contrarier tout développeur, propriétaire de produit et CTO est de pousser les bâtons dans les roues et de résister. Ce comportement affectera la date de sortie de tout produit si vous attendez à nouveau jusqu'à la dernière minute, alors à nouveau déplacez-vous vers la gauche et incluez ces problèmes dès que possible dans le plan de projet. Si nécessaire, rendez-vous aux réunions de produits. Portez une fausse moustache et du feutre ou quelque chose comme ça, cela n'échoue jamais. Signalez vos préoccupations, montrez des avantages évidents et évangélisez.
3. Assurez-vous que les développeurs (dev) et les opérations (ops) comprennent la signification et les conséquences du déplacement des métriques de produit dans la zone rouge. Ne laissez pas le fonctionnement comme seul gardien des performances du produit; assurez-vous que les développeurs y participent également (#productsquads).
4. Les journaux sont une bonne chose, mais les mesures aussi. Combinez-les et ne laissez pas vos bûches devenir des ordures dans une énorme boule de futilité enflammée. Expliquez et montrez aux développeurs pourquoi personne à part eux ne comprendra leurs journaux, montrez-leur ce que cela fait de regarder des journaux inutiles à 3h15 du matin.

Photo de Marko Horvat sur Unsplash

C’est tout. Du nouveau matériel sera publié la semaine prochaine. Si vous souhaitez en savoir plus sur le cours, nous vous invitons à une journée portes ouvertes , qui se tiendra le lundi. Et maintenant, nous attendons traditionnellement vos commentaires.