+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
  1. #21
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 149
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 149
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par xarkam Voir le message
    Oui, enfin, le minimum requis c'est d'avoir un prompt bien distinct avec coloration différente selon que tu es sur prod ou réplication, voir même carrément le background xterm en rouge sur la/les machine(s) de prod.
    j'adore, il en faut au moins deux pour faire l'erreur.

  2. #22
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS
    Inscrit en
    avril 2013
    Messages
    1 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 467
    Points : 4 895
    Points
    4 895
    Billets dans le blog
    6

    Par défaut

    Avant de faire mes commandes sur SSH je verifie toujour le nom de la machine affiché en haut à gauche de la fenêtre putty, ça évite ce genre de problème
    merci de me mettre des quand mes messages sont pertinent, et pour les pas contents voici mon service client pour eux

    [Projet en cours] Strategy(nom provisoire) - Advance wars like
    cordova-plugin-file-hash Plugin cordova servant à obtenir le hash d'un fichier

  3. #23
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 111
    Points : 48 013
    Points
    48 013

    Par défaut

    Citation Envoyé par xarkam Voir le message
    Oui, enfin, le minimum requis c'est d'avoir un prompt bien distinct avec coloration différente selon que tu es sur prod ou réplication, voir même carrément le background xterm en rouge sur la/les machine(s) de prod.
    Je vois pas en quoi ça changerais grand chose. Sauf si t'es du genre à ne jamais faire la moindre opération sur tes serveur de production. Ca n'évitera jamais l'espace coincé dans une commande, le script qui perd les pédales, le mauvais dossier courant, les mauvais caractères de substitution. Les erreur ça arrive. Et sur la production, ça peux faire du dégât. On peux mitiger au maximum (ne jamais être root, avertissements dans le terminal) mais on n'évitera jamais l'erreur humaine ou la distraction.

    Je ne considère personnellement pas le prompt coloré comme un minimum requis. D'abord parce que toutes les consoles ne supportent pas nécessairement la coloration, que ton opérateur peut être daltonien ou simplement que ça peut être incompatibles avec certains outils ou certains modes de connexion. De plus rien ne nous dit que ce n'était pas le cas ici. Ce n'est pas une solution magique
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

  4. #24
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 148
    Points : 357
    Points
    357

    Par défaut

    Dans certaines boites il n'y a pas de garde fou pour parer aux loupés des admins et l'usage de sudo devient alors la règle et il est devenu quoi cet admin téméraire ?

  5. #25
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 907
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 907
    Points : 64 413
    Points
    64 413

    Par défaut GitLab revient sur la panne qui l'a frappé le 31 janvier dernier

    GitLab revient sur la panne qui l'a frappé le 31 janvier dernier
    et indique les mesures prises pour garantir que cela ne se reproduise plus

    Le 31 janvier dernier, la plateforme de gestion des développements collaboratifs GitLab a été indisponible pendant plusieurs heures. Sur son portail, les utilisateurs pouvaient lire « GitLab.com est actuellement hors ligne en raison de problèmes avec notre base de données de production. Nous travaillons dur pour résoudre le problème rapidement. Suivez GitLabStatus pour les dernières mises à jour ».

    Un problème qui est survenu alors qu’un administrateur système de GitLab a entamé une procédure de réplication des données de production pour les utiliser à d'autres fins. Un incident qui a conduit à la suppression de plus de 300 Go de données en production. GitLab a indiqué avoir perdu plus de 6 heures de données qui ont atterri sur sa plateforme, ce qui signifie qu’environ 4613 projets réguliers, 74 forks, et 350 importations ont été effacés. Elle s’est attelée à restaurer le maximum de données possible.

    Dans un billet de blog, GitLab a reconnu que « perdre des données de production est inacceptable. Pour garantir que cela ne se reproduise plus, nous travaillons à de multiples améliorations à nos opérations et procédures de récupération pour GitLab.com ». Aussi, avant de présenter son analyse (notamment ce qui s’est mal passé, ce qui a été fait pour restaurer les données et les décisions prises pour éviter ce genre d’incident à l’avenir), le PDG de GitLab a tenu à présenter ses excuses à tous les utilisateurs personnellement et également au nom de toute l’équipe.

    Pour analyser la cause première de ces problèmes, GitLab a utilisé la règle des « 5 why ». L’incident a été divisé en deux problèmes principaux : GitLab.com en panne et la grosse quantité de temps que cela a coûté pour restaurer GitLab.com.

    Problème 1: GitLab.com était en panne pendant 18 heures environ.

    1. Pourquoi GitLab.com était-il en panne ? Le répertoire de la base de données primaire a été supprimé par accident, au lieu de supprimer le répertoire de base de données secondaire.
    2. Pourquoi le répertoire de base de données a-t-il été supprimé? La réplication de base de données s'est arrêtée, nécessitant la réinitialisation / reconstitution du secondaire. Ceci nécessite à son tour que le répertoire de données PostgreSQL soit vide. Sa restauration doit être faite en manuel, car le processus n’est pas automatisé. De plus ce processus n’a pas été convenablement documenté.
    3. Pourquoi la réplication a-t-elle cessé ? Un pic de chargement de la base de données a provoqué l'arrêt du processus de réplication de la base de données. Cela était dû au retrait primaire des segments WAL avant que le secondaire ne puisse les reproduire.
    4. Pourquoi la charge de la base de données a-t-elle augmenté ? Cela a été causé par deux événements se produisant en même temps : une augmentation du spam, et un processus visant à supprimer un employé GitLab et les données associées.
    5. Pourquoi un employé de GitLab devait-il être retiré ? L'employé a été signalé par un troll pour abus. Le système actuel utilisé pour répondre aux rapports d'abus facilite la négligence des détails concernant ceux qui ont été signalés. Par conséquent, l'employé a été accidentellement programmé pour un retrait.

    Problème 2 : la restauration de GitLab.com a pris plus de 18 heures.

    1. Pourquoi la restauration de GitLab.com a-t-elle duré si longtemps? GitLab.com a dû être restauré en utilisant une copie de la base de données intermédiaire. Cette dernière était hébergée sur des machines virtuelles plus lentes d'Azure dans une région différente.
    2. Pourquoi la base de données intermédiaire était nécessaire pour restaurer GitLab.com? Les snapshots de disque Azure n'étaient pas activés pour les serveurs de base de données et les sauvegardes de bases de données périodiques à l'aide de pg_dump ne fonctionnaient pas.
    3. Pourquoi ne pas se tourner vers l'hôte de base de données secondaire ? Les données de la base de données secondaire ont été effacées dans le cadre de la restauration de la réplication de la base de données. En tant que telle, elle ne pouvait donc plus être utilisée pour la restauration.
    4. Pourquoi ne pas utiliser une procédure standard de sauvegarde ? La procédure de sauvegarde standard utilise pg_dump pour effectuer une sauvegarde logique de la base de données. Cette procédure a silencieusement échoué, car elle utilisait PostgreSQL 9.2, tandis que GitLab.com s'exécute sur PostgreSQL 9.6.
    5. Pourquoi la procédure de sauvegarde a-t-elle silencieusement échoué ? Des notifications ont été envoyées après l’échec. Cependant, à cause du rejet des courriels, il n'y avait aucune indication d'échec. L'envoi était un processus automatisé sans autre moyen de signaler des erreurs.
    6. Pourquoi les courriels ont-ils été rejetés ? Les courriels ont été rejetés par le serveur mail à cause des courriels qui n’étaient pas signés en utilisant DMARC.
    7. Pourquoi les snapshots de disque Azure n'ont-ils pas été activés ? Nous avons supposé que nos autres procédures de sauvegarde étaient suffisantes. En outre, la restauration de ces snapshots peut prendre des jours.
    8. Pourquoi la procédure de sauvegarde n'a-t-elle pas été testée régulièrement ? Parce qu'il n'y avait pas de propriétaire assigné, par conséquent personne n'était responsable pour les tests de cette procédure.

    L’entreprise a décidé de travailler à corriger et améliorer ses diverses procédures de restauration. Voici comment elle a réparti ses tâches :
    • mettre à jour PS1 sur tous les hôtes pour différencier plus clairement les hôtes et les environnements (# 1094) ;
    • surveiller les sauvegardes Prometheus (# 1095) ;
    • Définir max_connections de PostgreSQL sur une valeur rationnelle (# 1096) ;
    • étudier la restauration ponctuelle et l'archivage continu de PostgreSQL (# 1097) ;
    • effectuer des snapshots LVM horaires des bases de données de production (# 1098) ;
    • effectuer des snapshots de disque Azure des bases de données de production (# 1099) ;
    • restauration des répliques de production (# 1101) ;
    • tests automatisés de récupération des sauvegardes de bases de données PostgreSQL (# 1102) ;
    • améliorer la documentation de réplication PostgreSQL (# 1103) ;
    • recherchez pgbarman pour créer des sauvegardes PostgreSQL (# 1105) ;
    • étudier l'utilisation de WAL-E comme moyen de sauvegarde de base de données et de réplication en temps réel (# 494) ;
    • création de la restauration en continu de la base de données ;
    • affecter un propriétaire pour la durabilité des données.

    Source : GitLab

    Et vous ?

    Que pensez-vous de ces mesures ? Sont-elles suffisantes pour endiguer ce type de problème à l'avenir ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  6. #26
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    494
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 494
    Points : 787
    Points
    787

    Par défaut

    Merci GitLab : C'est la première fois que je vois une entreprise être aussi transparente et c'est une chose extraordinairement bien. Je pense que les erreurs sont courantes en entreprise mais en général les entreprises se contentent de dire "Cela ne se reproduira pas. Nous avons fais ce qu'il faut". Sous entendu, "nous avons mis la pression et virer 2-3 personnes responsables.".

    J'apprécie les détails techniques que nous avons là et même si tous le monde ne les comprendra pas, ils apportent un sérieux et une véritable transparence.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  7. #27
    Membre chevronné
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 292
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 292
    Points : 2 101
    Points
    2 101

    Par défaut

    "L'employé a été signalé par un troll pour abus.
    ... par conséquent, l'employé a été accidentellement programmé pour un retrait."

    hein! Des robots?
    Si la réponse vous a aidé, pensez à cliquer sur +1

  8. #28
    Membre chevronné
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    356
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : janvier 2014
    Messages : 356
    Points : 1 928
    Points
    1 928

    Par défaut

    Enfin du coup tout ça c'est une belle pub pour Github, parce que au moins Github ça marche.
    D'ailleurs peu être qu'on découvrira que l'informaticien responsable de ce désastre à été payé par Github ?
    A moins que ça soit un coup des russes ?



  9. #29
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 1 959
    Points
    1 959

    Par défaut

    Rien ne permet d'être sûr qu'un truc pareil n'arrivera pas chez GitHub.

    Un cas typique de clusterfuck. Généralement, quand un problème se produit, ça peut se régler assez facilement. C'est quand il y a plusieurs problèmes qui se produisent en même qu'on peut assez rapidement se retrouver coincé...

  10. #30
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 587
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 587
    Points : 8 466
    Points
    8 466
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par Traroth2 Voir le message
    Rien ne permet d'être sûr qu'un truc pareil n'arrivera pas chez GitHub.

    Un cas typique de clusterfuck. Généralement, quand un problème se produit, ça peut se régler assez facilement. C'est quand il y a plusieurs problèmes qui se produisent en même qu'on peut assez rapidement se retrouver coincé...
    Certes, mais quand on gratte un peu, on se rend souvent compte que c'est pas un hasard que ça arrive sur certains projets et pas d'autres. Perso, je pense que ce genre de problèmes en chaîne ne relève pas du hasard mais est symptomatique d'une accumulation de négligences. Ce qui est résumé - selon moi - par cette phrase :

    Parce qu'il n'y avait pas de propriétaire assigné, par conséquent personne n'était responsable pour les tests de cette procédure.
    c'est exactement l'impression que m'a donné Gitlab quant à la façon de gérer les issues : au petit bonheur la chance ! Pour avoir aussi déjà reporté (une fois) un problème à Github, j'ai pu voir la différence ! Hyper réactivité d'un côté pour un sujet mineur, pas de nouvelles de l'autre pour un vrai problème de config (LDAP).

    Ca m'a donné l'impression qu'ils se sont égarés dans une course aux fonctionnalités au détriment de la rigueur et de la qualité. Et je suis bien content que cet événement se soit passé ainsi, car au final ils s'en tirent bien et ça fait office d'électro-choc sur leur façon de gérer les issues. Enfin, c'est ce que j'espère, car c'est un outil que j'apprécie beaucoup !

  11. #31
    Membre confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2013
    Messages
    164
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2013
    Messages : 164
    Points : 553
    Points
    553

    Par défaut

    Citation Envoyé par abriotde Voir le message
    Merci GitLab : C'est la première fois que je vois une entreprise être aussi transparente et c'est une chose extraordinairement bien. Je pense que les erreurs sont courantes en entreprise mais en général les entreprises se contentent de dire "Cela ne se reproduira pas. Nous avons fais ce qu'il faut". Sous entendu, "nous avons mis la pression et virer 2-3 personnes responsables.".

    J'apprécie les détails techniques que nous avons là et même si tous le monde ne les comprendra pas, ils apportent un sérieux et une véritable transparence.
    Contrairement aux autres entreprise dont on nous relate souvent les exploits en matière d'incompétence informatique, GitLab est une entreprise dont les services sont destinés à des informaticiens. La clientèle étant tout aussi compétente qu'eux dans le domaine en question, ils se doivent d'être un minimum transparent s'ils veulent pas avoir l'air de gros charlots.

  12. #32
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 1 959
    Points
    1 959

    Par défaut

    @Aurelien.Regat-Barrel : Ça se défend, ce que tu dis.

  13. #33
    Futur Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2015
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2015
    Messages : 2
    Points : 5
    Points
    5

    Par défaut

    Pourquoi la réplication a-t-elle cessé ? Un pic de chargement de la base de données a provoqué l'arrêt du processus de réplication de la base de données. Cela était dû au retrait primaire des segments WAL avant que le secondaire ne puisse les reproduire.
    Un contributeur au système de réplication de PG explique en réponse dans un post qu'il est fort probable que si le mec n'avait pas touché à la réplication, le problème aurait fini par se résoudre une fois l'attaque passée.

    I’m not sure there was any action needed at all. The replication delay was caused by the huge write spike on the database that came about because of the denial of service attempts from hackers. It would likely have reduced back to lower levels quite quickly.
    source : https://blog.2ndquadrant.com/dataloss-at-gitlab/

  14. #34
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    5 798
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 5 798
    Points : 15 894
    Points
    15 894
    Billets dans le blog
    1

    Par défaut

    Bonjour

    Moi quand je bossais sour Sun j'avais l'habitude de purger /tmp. Je tapais donc la commande cd /tmp; rm -fr * .* et ça fonctionnait super.

    Un jour j'ai voulu aller plus vite et j'ai tapé rm -fr /tmp/* /tmp/.*. Et là, la commande ne m'a pas rendu la main. Je fronce les sourcils et je commence à me demander ce qui se passe. Et d'un coup j'ai compris que dans "/tmp/.*" il y avait "/tmp/.." (*) !!!
    Bon plutôt que d'investiguer sur les dégats j'ai préféré réinstaller ma machine. Alors certes ce n'était pas une machine de prod mais une machine de dev donc les dommages étaient locaux mais c'est pour dire que parfois, même quand on maitrise, ben des conneries on en fait quand-même. D'ailleurs bien plus récemment (en 2012) avec des copains on j'avait créé une maquette de démo avec bdd Postgres (c'est moi qui m'était occupé de la bdd). Et le jour de la démo devant des clients acheteurs, 2h avant la démo ; une mauvaise redirection et j'écrase le dump de la bdd. Bon là j'ai immédiatement prévenu mes potes pour limiter les dégats. Je leur ai proposé de rentrer chez-moi récupérer un dump que j'avais conservé (1h30 aller/retour mais c'était faisable) mais mon pote (qui était l'analyste du groupe) a préféré recréer le contenu de la bdd avec les infos qu'il avait en tête et dans ses fichiers (10mn).
    Donc voilà, tout le monde fait des conneries (mais c'est dommage que les backup aient foirés).

    (*) Aujourd'hui sous Linux la commande est protégée et rm .* bloque la remontée sur ".." mais à l'époque...
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site

Discussions similaires

  1. [Lyon] Administrateur Systèmes/Développeur web
    Par akurosa dans le forum Demandes
    Réponses: 0
    Dernier message: 26/07/2007, 11h00
  2. Réponses: 9
    Dernier message: 22/10/2006, 21h03
  3. Administrateur système-réseau : on y fait quoi?
    Par Nasky dans le forum Emploi
    Réponses: 12
    Dernier message: 19/04/2006, 08h59
  4. Réponses: 5
    Dernier message: 05/07/2005, 19h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo