Introduction De nombreuses entreprises informatiques ont adopté la pratique du service de garde. Un ingénieur est de service et son service dure un quart de travail. Habituellement, le quart de travail dure un jour ou une semaine. Il existe des cas d'augmentation ou de diminution de cette période, mais cela est rare. Les tâches de l'ingénieur dans ce rôle varient d'une entreprise à l'autre, mais il existe des points communs. Vous devez répondre aux questions qui arrivent dans l'équipe. Il est nécessaire de surveiller la performance des services dont l'équipe est responsable. Pour faire face aux incendies et incidents. Escaladez davantage l'incident si vous ne pouvez pas le comprendre. Nous parlerons de la façon d'être bien préparé pour le travail en tant qu'ingénieur dans cet article. Définition de l'ingénieur de service parfait Si des incidents ou des incendies se produisent pendant votre quart de travail dans un environnement de combat, cela ne signifie pas que vous êtes un mauvais ingénieur. Pour être un bon ingénieur de service, si des problèmes surviennent, vous devez les résoudre le plus rapidement et le plus économiquement possible. Un ingénieur bien formé comprend où il peut se débrouiller et où il vaut la peine d'aggraver davantage la situation. Il doit savoir quand et qui appeler pour obtenir de l'aide. Il ne doit pas permettre, si possible, que les mêmes problèmes se reproduisent. Vivre Il est utile de tirer parti de votre expérience et de celle de l'équipe pour mieux vous préparer au travail. C'est une bonne idée de commencer par regarder quelle documentation existe déjà pour gérer les incidents. Existe-t-il une documentation au niveau de l'entreprise ou de l'équipe ? Il est essentiel de savoir où il se trouve et de le connaître. S'il n'existe pas, pourriez-vous essayer d'initier le processus d'en créer un ? Ensuite, il vaut la peine de vérifier quels incidents se sont déjà produits et comment ils sont enregistrés dans le magasin de connaissances. Y a-t-il des post-mortems et y a-t-il des tâches à corriger ? Savez-vous si ces tâches sont effectuées ? Si des tâches de résolution de la situation sont créées, mais non mises en œuvre, c'est une raison d'en discuter lors d'une réunion avec votre responsable. Savez-vous si les fonctions de l'ingénieur de service sont enregistrées ? De quoi sont-ils responsables et de quoi ne l'est-il pas ? S'il n'y a pas de documentation ou de compréhension de ce type, il serait utile que toute l'équipe en ait une. Outils La boîte à outils de l'ingénieur de service est spécifique et quelque peu différente de la boîte à outils quotidienne du développeur. Les principales tâches qui surviennent lors de la lutte contre les incendies sont celles qui ne peuvent pas être résolues par les requêtes existantes Regardons ces outils plus en détail : Le principal outil technique du devoir, à l'aide duquel vous pouvez résoudre de nombreux problèmes, est bash. Si la connaissance de ce bel outil n'est pas encore dans votre arsenal - utilisez l'un des cours intensifs ( Souvent en mode incendie, vous devez effectuer certaines opérations avec la base de données des produits. La compétence de travailler avec la base de données via le terminal - psql pour PostgreSQL ou mongosh pour MongoDB aidera . Ces outils sont donnés à titre d'exemples, vous pouvez rechercher votre propre base de données. Pour de nombreuses bases de données, il existe des outils visuels avec lesquels travailler, mais le terminal est disponible partout, nécessite un minimum d'Internet et est très flexible. Pour le mode feu, cela peut être très utile. https://www.postgresguide.com/utilities/psql/ https://www.mongodb.com/docs/mongodb-shell/ curl est un outil qui vous permettra de faire un nombre considérable de requêtes, et lorsqu'il est combiné avec la connaissance de bash, vous deviendrez presque omnipotent. Ce sera très utile si vous avez sous la main un ensemble de scripts prêts à l'emploi au moment de l'incendie. Ils doivent être aussi simples et directs que possible. Oui, vous pouvez probablement les écrire très rapidement, mais lorsque vous disposez d'un temps limité, c'est formidable d'avoir un ensemble prêt à l'emploi qui vous permet de ne penser qu'au crash et non à la manière d'implémenter le même lien. Les scripts ci-dessous ne sont qu'une représentation de la structure potentielle de tels scripts. Bien sûr, votre code doit être testé avant l'incident et être aussi simple et direct que possible. Il est utile d'avoir les scripts suivants : Un script qui génère un fichier à partir des données fournies. Ceux-ci peuvent être obtenus à partir d'autres commandes ou en faisant une demande indépendante. Un exemple d'un tel script en Python est présenté ci-dessous. import csv def modify(filename): tmpFile = "tmp.csv" # Reading file with data and creation of output file with open(filename, "r") as file, open(tmpFile, "w") as outFile: # Create reader for initial file reader = csv.reader(file, delimiter=',') # Create writer for output file writer = csv.writer(outFile, delimiter=',') # Read header line header = next(reader) # Write header line writer.writerow(header) # Process initial file line by line for row in reader: colValues = [] # Process each column of each line for col in row: # Let for example transform all columns to lowercase colValues.append(col.lower()) # Write modified line to final file writer.writerow(colValues) filename = 'sample_data.csv' modify(filename) Un script qui appellera les points de terminaison requis avec le parallélisme spécifié. Cela ne doit pas être quelque chose de compliqué. Vous trouverez ci-dessous un exemple de code JavaScript simple qui générera un fichier sh avec le parallélisme spécifié qui peut vous aider. Oui, nous n'avons pas de gestion des résultats ici, mais ce n'est pas toujours nécessaire, et vous pouvez modifier votre boîte à outils avec une version de gestion des résultats si nécessaire. Par exemple, nous avons un fichier qui lit et écrit toutes les données, mais vous pouvez créer des scripts de flux pour des fichiers volumineux. const fs = require('fs'); const initialFilePath = 'sample_data.csv'; const outputFilePath = 'sample_script.sh'; const amountOfParallelRequests = 5; // Remember about the throughput and the bandwidth of your services const delimiterForCSV = ','; // Read the initial file and split it by lines // You could transform it to an object if it's relevant to your situation let initialFile = fs.readFileSync(initialFilePath).toString().split('\n'); // Prepare boilerplate for sh script let outputString = '#!/bin/bash\n\n'; // Write data with parallel execution // Skip header for CSV // The code for parallel requests was received from https://serverfault.com/questions/456490/execute-curl-requests-in-parallel-in-bash // and you could implement your version instead for (let i = 1; i < initialFile.length; i++){ let line = initialFile[i]; if (!line) { continue; } let processedLine = line.split(delimiterForCSV); // We don't implement processing of errors here // Let's suggest that the necessary for request value lies in second column let desiredValue = processedLine[1]; if (desiredValue === undefined) { console.error('We have a trouble ' + line); } outputString += `curl -s -o foo http://example.com/file${desiredValue} && echo "done with ${desiredValue}" &\n`; if (i % amountOfParallelRequests === 0 || i === initialFile.length - 1) { outputString += '\nwait\n\n'; } } fs.writeFileSync(outputFilePath, outputString); // Indicate the success console.log('Success'); Un script qui obtient quelque chose d'une base de données ou d'un service et remet le résultat converti ou appelle peut-être un autre point de terminaison. Je suggère de l'implémenter vous-même, sans oublier l'autorisation et les scénarios d'utilisation appropriés. Connaissances En plus des outils et de l'expérience, certaines connaissances sont utiles lorsque vous prenez vos fonctions. J'aimerais connaître les journaux et les métriques de vos services. Où vont-ils et comment s'y rendre ? Seriez-vous au courant de l'utilisation de ces outils ? Lorsque vous recevez un appel la nuit d'un service de garde qui vous indique que votre service est en panne, il est dans votre intérêt de découvrir rapidement ce qui ne va pas. Pour ce faire, vous devez savoir précisément où sont stockés vos métriques et journaux et quoi regarder en premier. Comment reporter les alertes ? Après analyse de l'incident, il ressort souvent que l'accident en cours attend peut-être le matin, il est donc bon de comprendre comment reporter l'alerte. Pas pour fermer, car dans le cas de certaines opérations vous serez à nouveau prévenus, mais justement pour reporter. Vous devez vous rappeler de traiter et de corriger la situation ou d'alerter dès que vous commencez votre journée de travail typique. Où se trouvent les contacts ou comment entrez-vous en contact avec des collègues ou des membres d'autres équipes ? Il doit y avoir un outil clair ou une connaissance dans votre tête - qui comprend/devrait être au courant de la situation au moment où elle s'est produite. Les experts peuvent vous aider à résoudre l'incident et les parties prenantes doivent savoir que quelque chose ne va pas. Vous devez avoir accès à leurs contacts, idéalement leur téléphone, car de nombreuses personnes désactivent les notifications des discussions de bureau en dehors des heures de bureau. Comment accéder à la production/base de données et augmenter l'accès si des niveaux d'accès existent ? Si vous n'y avez pas accès, vous devez savoir à qui vous adresser ou quoi faire pour obtenir l'accès souhaité. Comment mettre rapidement le code en production ? Parfois, des problèmes nécessitent une modification rapide du code de service en production. En général, cela est considéré à juste titre comme une mauvaise pratique, mais souvent en cas d'urgence, ce n'est pas le cas. Parfois, vous ne voulez pas attendre de longs tests E2E, mais vous devez intégrer rapidement le code dans l'environnement de production. J'aimerais que vous compreniez comment faire cela. Quelles données sont stockées dans la base de données ? Existe-t-il des schémas de déplacement des données au sein du produit et entre les services ? Si vous avez besoin d'interagir avec la base de données, il est bon de savoir comment les données sont organisées dans un service particulier, d'où elles proviennent et qui les utilise. Cela vous permettra de régler les problèmes, s'il y en a, plus tôt. En plus des outils et de l'expérience, certaines connaissances sont utiles lorsque vous prenez vos fonctions. J'aimerais connaître les journaux et les métriques de vos services. Où vont-ils et comment s'y rendre ? Savez-vous utiliser ces outils ? Lorsque vous recevez un appel la nuit d'un service de garde qui vous indique que votre service est en panne, il est dans votre intérêt de découvrir rapidement ce qui ne va pas. Pour ce faire, vous devez savoir précisément où sont stockés vos métriques et journaux et quoi regarder en premier. Comment reporter les alertes ? Après analyse de l'incident, il ressort souvent que l'accident récent attend peut-être le matin, il est donc bon de comprendre comment reporter l'alerte. Non pas pour fermer, car, dans le cas de certaines opérations, vous serez à nouveau prévenu, mais justement pour reporter. Il serait préférable que vous vous souveniez de traiter et de corriger la situation ou d'alerter dès que vous commencez votre journée de travail typique. Où se situent les contacts ou comment entrez-vous en contact avec des collègues ou des membres d'autres équipes ? Il doit y avoir un outil ou une connaissance précise dans votre tête - qui comprend/devrait connaître la situation au moment où elle s'est produite. Les experts peuvent vous aider à résoudre l'incident et les parties prenantes doivent savoir que quelque chose ne va pas. Vous devez avoir accès à leurs contacts, idéalement leur téléphone, car de nombreuses personnes désactivent les notifications des discussions de bureau en dehors des heures de bureau. Comment accéder à la production/base de données et augmenter l'accès si des niveaux d'accès existent ? Si vous avez besoin d'un accès, vous devez savoir à qui vous adresser ou quoi faire pour obtenir l'accès souhaité. Comment mettre rapidement le code en production ? Parfois, des problèmes nécessitent une modification rapide du code de service en production. En général, cela est considéré à juste titre comme une mauvaise pratique, mais souvent en cas d'urgence, ce n'est pas le cas. Parfois, vous souhaitez obtenir rapidement le code dans l'environnement de production avant de longs tests E2E. J'aimerais que vous compreniez comment faire cela. Quelles données sont stockées dans la base de données ? Existe-t-il des schémas de déplacement des données au sein du produit et entre les services ? Si vous avez besoin d'interagir avec la base de données, il est bon de savoir comment les données sont organisées dans un service particulier, d'où elles proviennent et qui les utilise. Cela vous permettra de régler les problèmes, s'il y en a, plus tôt. Conclusion Même dans les entreprises et les équipes ayant une excellente culture d'ingénierie, des accidents de travail et des incendies se produisent. Pour éviter cela, l'équipe doit tout mettre en œuvre pour améliorer les processus et les produits actuels. Pourtant, chaque ingénieur doit également être préparé à ce qu'un accident se produise et doit y faire face de toute urgence. Pour ce faire, il convient d'utiliser toute l'expérience personnelle et d'équipe accumulée. Connaître l'organisation et les services et avoir confiance en votre boîte à outils vaut la peine d'être connu. Liens utiles https://zach-gollwitzer.medium.com/the-ultimate-bash-crash-course-cb598141ad03 https://www.youtube.com/watch?v=oxuRxtrO2Ag https://www.postgresguide.com/utilities/psql/ https://www.mongodb.com/docs/mongodb-shell/

YouTube

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

Ingénieur de service parfait

Trop long; Pour lire

Company Mentioned

Alexey Sutyagin

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Ingénieur de service parfait

Trop long; Pour lire

Company Mentioned

Alexey Sutyagin

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES