Blog

10 erreurs opérationnelles courantes

par Tony Albanese 30 juin 2014 | 6 minutes de lecture

Mise à jour le 24/07/2014 : Cet article de blog a été mis à jour pour refléter plus précisément le discours d'Arup.

Arup Chakrabarti, responsable des opérations de PagerDuty, s'est rendu au siège social de Heavybit Industries pour discuter des plus grosses erreurs qu'une équipe d'exploitation peut commettre et de la manière de les éviter. Pour visionner la vidéo complète, rendez-vous sur Bibliothèque vidéo Heavybits .

1. Erreur dans la configuration de l'infrastructure

Créer des comptes

De nombreuses personnes utilisent des comptes personnels lors de la configuration des déploiements d'infrastructures d'entreprise. Créez plutôt de nouveaux comptes à l'aide d'adresses d'entreprise pour garantir la cohérence.

Soyez prudent quant à la manière dont vous stockez vos mots de passe. Les conserver dans votre dépôt Git pourrait vous obliger à effacer tout votre historique Git ultérieurement. Il est préférable d'enregistrer les mots de passe dans la gestion de la configuration afin de pouvoir les saisir selon les besoins.

Sélection des outils

Une autre bonne pratique pour les nouveaux déploiements : choisissez judicieusement vos outils. Par exemple, exploitez les outils PaaS aussi longtemps que possible. De cette façon, vous pourrez vous concentrer sur l'acquisition de clients plutôt que sur la construction d'infrastructures. Et n'ayez pas peur d'utiliser des produits « ennuyeux » comme Java. Une technologie bien établie et éprouvée peut vous permettre de faire des choses vraiment intéressantes.

2. Environnements de test mal conçus

Séparez les tests et la production

Vous ne voulez pas risquer que vos environnements de test et de production se mélangent de quelque façon que ce soit. Assurez-vous de configurer des environnements de test avec des comptes d'hébergement et de fournisseur différents de ceux que vous utilisez en production.

Machines virtuelles

Vous effectuez un développement local ? Il n'y a pas d'autre solution : les applications s'exécuteront différemment sur les machines locales et en production. Pour simuler au mieux un environnement de production, créez des machines virtuelles avec un outil comme Vagrant.

3. Gestion de configuration incorrecte

Ansible et Salt sont tous deux des outils très faciles à apprendre. Plus précisément, Ansible simplifie considérablement le déploiement de l'infrastructure en tant que code pour les équipes opérationnelles.

Qu'est-ce que l'infrastructure en tant que code ? Il s'agit essentiellement du processus de création d'une infrastructure de telle sorte qu'elle puisse être mise en place ou arrêtée rapidement et de manière cohérente. Les configurations de serveur vont être perturbées quel que soit l'endroit où votre infrastructure est exécutée, vous devez donc être prêt à restaurer vos serveurs dans les plus brefs délais.

Quel que soit l'outil que vous utilisez, en règle générale, il est préférable de limiter le nombre d'outils logiciels d'automatisation que vous utilisez. Chacun d'entre eux est une source de vérité dans votre infrastructure, ce qui signifie qu'il s'agit également d'un point de défaillance.

4. Déploiement incorrect

La cohérence est importante

Chaque élément de code doit être déployé de la manière la plus similaire possible. Mais il peut être difficile d'amener tous vos ingénieurs à pratiquer la cohérence.

Orchestrez vos efforts

Un logiciel d'automatisation puissant peut certainement contribuer à renforcer la cohérence. Mais les outils d'automatisation ne conviennent qu'aux déploiements de grande envergure. Par conséquent, lorsque vous débutez, Arup suggère d'exécuter le développement à l'aide de git et d'utiliser un outil d'orchestration. Par exemple, Capistrano pour Rails, Celery pour Python ou Ansible et Salt pour l'orchestration et la gestion de la configuration.

5. Ne pas gérer correctement les incidents

Avoir un processus en place

Créer et documenter un processus de gestion des incidents est absolument nécessaire, même si le processus n'est pas parfait.

Vous devez également être prêt à réviser régulièrement le document de gestion des incidents. Si vous subissez de nombreuses interruptions de service, ces révisions ne seront pas vraiment nécessaires.

Mettre tout le monde en alerte

Il est de moins en moins courant pour les entreprises de disposer d'équipes d'astreinte dédiées. Au lieu de cela, toute personne qui touche au code de production est censée être joignable en cas d'indisponibilité.

Cela nécessite une plate-forme (comme PagerDuty) capable de notifier différentes personnes de différentes manières. Ce qui compte vraiment, c'est de joindre les bonnes personnes au bon moment.

6. Négliger la surveillance et l’alerte

Commencez n'importe où

L’outil spécifique que vous utilisez pour le suivi est moins important que la simple mise en place de quelque chose. PagerDuty utilise StatsD de concert avec Datadog ; Les outils open source comme Nagios peuvent être tout aussi efficaces.

Si vous avez les moyens, un outil de gestion des performances des applications comme New Relic peut être une bonne solution. Mais ce qui compte le plus, c'est que vous disposiez d'un outil de surveillance.

'Vous n'avez aucune excuse pour ne pas avoir de surveillance et d'alerte sur votre application, même lors de votre premier lancement' - Arup Chakrabarti, responsable de l'ingénierie, PagerDuty

7. Ne pas conserver les sauvegardes

Systématiser les sauvegardes et les restaurations

Tout comme la surveillance et les alertes, la sauvegarde de vos données n'est pas négociable. La planification de sauvegardes régulières sur S3 est aujourd'hui une pratique courante dans le secteur.

Vous devez essayer de restaurer votre ensemble de données de production dans un environnement de test pour confirmer que vos sauvegardes fonctionnent comme prévu au moins une fois par mois.

8. Ignorer les principes de haute disponibilité

«Multiple» est le mot d'ordre

Disposer de plusieurs serveurs à chaque couche, de plusieurs serveurs d'applications sans état et de plusieurs équilibreurs de charge est une évidence. Ce n'est qu'avec plusieurs options de basculement que vous pouvez vraiment dire que vous avez optimisé la haute disponibilité.

La conception du datastore est également importante

Les magasins de données (comme Cassandra) sont essentiels car avec les clusters de données multimaîtres, des nœuds individuels peuvent être supprimés sans aucun impact sur le client. Les magasins de données en cluster sont idéaux dans les environnements de déploiement à évolution rapide pour cette raison.

9. Tomber dans les pièges courants de la sécurité

S'appuyer uniquement sur SSH

Utilisez des passerelles au lieu de SSH sur vos serveurs de base de données et vos équilibreurs de charge. Vous pouvez exécuter des proxys via ces passerelles et bloquer le trafic si vous suspectez une incursion.

Ne pas configurer les comptes d'utilisateurs individuels

Lorsqu'un employé quitte votre entreprise, il est agréable de pouvoir révoquer rapidement son accès. Mais il existe d'autres raisons pour lesquelles il est important de créer des comptes d'utilisateur pour vos différents outils. L'ordinateur portable d'une personne peut être perdu. Une personne peut avoir besoin de réinitialiser son mot de passe. Il est beaucoup plus facile, note Arup, de révoquer ou de réinitialiser le mot de passe d'un utilisateur que le mot de passe d'un compte principal.

Impossible d'activer le cryptage dans dev

L'intégration du chiffrement dans le cycle de développement vous aide à détecter les bugs liés à la sécurité dès le début du développement. De plus, forcer les développeurs à penser constamment à la sécurité est tout simplement une bonne pratique.

10. Ignorer les besoins informatiques internes

Ce n’est pas strictement un problème opérationnel, mais…

L'informatique ne concerne pas toujours les opérations. Mais sur certains sujets, les deux équipes sont parties prenantes. Par exemple :

  • Points communs dans les équipements :Si un ingénieur perd son ordinateur portable fabriqué sur mesure, combien de temps faudra-t-il pour lui en procurer un de remplacement ? Efforcez-vous d'assurer la cohérence du matériel afin de rationaliser les déploiements de machines.

  • Accorder l'accès aux bons outils :Les documents d’intégration sont un bon moyen de partager les informations de connexion avec les nouveaux employés.

  • Imagerie des machines locales :Avec les images de disque stockées sur USB, l'approvisionnement ou le réapprovisionnement de l'équipement est un jeu d'enfant.

  • Activation du chiffrement du disque :Avec le cryptage, pas besoin de s'inquiéter si une machine est perdue.

Il existe des millions d’erreurs supplémentaires que les équipes opérationnelles peuvent commettre. Mais ces 10 ont tendance à être les plus fréquemment observés, même dans des entreprises comme Amazon, Netflix et PagerDuty.

Vous avez une erreur d'Ops que vous aimeriez partager. Faites-le nous savoir dans les commentaires ci-dessous.