:roll: j'adore, il en faut au moins deux pour faire l'erreur. :lol:Citation:
Envoyé par xarkam
Version imprimable
:roll: j'adore, il en faut au moins deux pour faire l'erreur. :lol:Citation:
Envoyé par xarkam
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
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.Citation:
Envoyé par xarkam
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 :)
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 ?
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.
- 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.
- 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é.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 ?
:fleche: Que pensez-vous de ces mesures ? Sont-elles suffisantes pour endiguer ce type de problème à l'avenir ?
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.
"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?
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 ?
:dehors:
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 :Citation:
Envoyé par Traroth2
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).Citation:
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.
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 !
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.Citation:
Envoyé par abriotde
@Aurelien.Regat-Barrel : Ça se défend, ce que tu dis.
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.Citation:
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.
source : https://blog.2ndquadrant.com/dataloss-at-gitlab/Citation:
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.
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...:aie: