Reprise du message précédent :

 
Pas la peine de se faire embaucher. Je leur file le conseil gratuit : Don't do it, been there, done that.
J'ai pas la taille de FB mais pousser en prod un service de routage vite fait, bien fait, à peine testé, ça fait du dégât c'est tout

"Tester c'est douter"©

Moi j'ai beaucoup aimé le coup de la page de status qui est hébergée sur leur infra  

 
De ce que j'ai entendu dire, les seuls techs qui devaient intervenir sur le matos n'avaient pas d'accès physiques aux bâtiments pour corriger les confs mal passés sur les routeurs.

Alors ça c'est classique.

J'avoue, le truc ou les gars peuvent pas rentrer sur site à cause du contrôle d'accès en vrac

 
C'est assez malheureusement classique quand tu fourres tout dans le même network qui vient de péter Mais j'ai aucune leçon à donner hein, avec mon infra qui tient dans un seul rack (et les 3/4 sont du labo )

Je dois être resté 15 siècles en arrière, pour moi les contrôle d'accès c'est du réseau isolé, avec une gestion des badges sur des vieux PC sous win 98.

C'est pas assez devops, ya pas de plugin Terraform ou Ansible pour Win 98

 
En vrai, parfois il y a des choses purement incompatibles (ou très difficiles à marier). Un management out of the band : très important mais facilement un point faible en terme de sécu de ton infra (parce qu'indépendant, donc ne profite pas d'un SSO ou d'un 2FA en mode « dégradé »).
 
C'est compliqué l'IT

Et ca fini toujours par retomber sur la faute du réseau, question de principe

C'est mon pet peeve ça, le "faut mettre un management out of band pour en cas de panne§§§" que quand tu te demandes concrètement quels sont les implications tu te dis qu'en fait on va peut-être plutôt passer du temps sur la documentation, la suppression du legacy et les tests, ça réduira tout autant les emmerdes sur le long terme

 
On a bien vu, c'est toujours la faute du DNS (même quand c'est BGP en fait )

 
User en dur avec un mot de passe quoi, ta intérêt à ce que ça soit grave secure ET en même temps facilement accessible. Bref, chiant

La démarche devop j’ai vraiment du mal.  
Je suis peut être vieux con, mais le dev et le système et réseau c’est des expertises et des compétences différentes.
Pour moi le devops c’est un concept marketing pour faire de la merde vite fait mal fait.

 
un motard informaticien en colère qui s’est dit que ce serait amusant de pourrir l’AS de facebook

 
le dns , il a bon dos    

 
C'est après avoir migré vers des FQDN leurs peers BGP qui annonçaient les préfixes portant leurs serveurs DNS qu'ils se sont rendus compte du problème

 
met un AS dans les pattes d’un millennial voilà ce qui arrive  

Bof. Un p'tit annuaire dédié admin, MFA par certif par une p'tite pki simple dans un coin sur un laptop au coffre, une paire de firewall pour monter l'ipsec depuis la station d'admin...
Y'a moyen de faire un truc pour pas si cher. Même en restant sur du "double alimenté, format DC, toussa".

Tout ça entièrement OOB ? Ça me parait pas si trivial pour avoir 0 dépendance avec le reste… (plus t'ajoute de briques plus c'est possible d'avoir des interdépendances très difficiles à imaginer). C'est plus ça le soucis que la solution technique en elle-même.

edit : plus la maintenance/MAJ de tout ça. Vu que c'est ultra sensible en plus.

edit 2 : perso j'ai mesuré que statistiquement j'avais plus vite fait d'aller au data en cas de soucis qui nécessite un accès OOB.

 
fucking DNS    
 

En soit, le plus chiant/cher c'est d'avoir une commut OOB physiquement dédiée partout pour pas être impacté par un incident de conf switching
Mais ouai, ça fait un peu de taff MCO. Mais au final, les modèles sont les même que pour le SI standard donc tu peux redéployer des choses équivalentes.

Après pour l'accès physique... Si c'est possible/pratique/pas gênant en terme de délai, ça reste le plus efficace
Ça doit pas t'empêcher d'avoir des mesures de protection physique sur les équipements par contre

 
faut voir ce que tu appelles concretement devops parcequ'ajd c'est a la mode et on met un peu tout et n'importe quoi la dedans

Dire réseau, c'est vague, ca englobe un peu tout
 

Tu veux en déployer au boulot? Vous êtes déjà bien site de test pour le reste

La faute des indiens

Non, aujourd'hui on fait du DevSecOps, DevOps c'est has been

Tu dis ça car t'arrive pas à être DevOps    

L'impression que c'est juste le mec couteau suisse capable de démerder une situation vite fait, monter rapidement un truc, capable de coder un bout de code, dépanner un oracle foireux, déployer du linux, mettre le papier dans l'imprimante, te scripter le taf de la secrétaire, upgrader un firware SAN, démerder une panne réseau sérieuse, mais le tout en faisant ça de façon dégueulasse pour aller vite, et en foutant un gros MERDE à la doc car bon, pas le temps pour ca, et je me souviens de ce que je fais.

Oui bon mon script fait un appel à mon repo github perso, et alors ? Tant que ça fonctionne on s'en fout  
 
(true story)

Pet vs Cattle

La démarche DevOps telle qu'elle est abusivement utilisée de nos jours c'est essentiellement pondre des scripts, faire des pipelines, monter de la ci/cd et automatiser à outrance.
Alors oui, il y a du code, m'enfin tu vas pas faire une architecture hexagonale pour déployer un serveur LAMP MEAN nginx.

Rien à voir avec la démarche DevOps initiale qui était essentiellement d'impliquer au maximum les dev dans l'ops (voir faire du NoOps comme chez Netflix).

Tu as raison

Non je suis RSSI

Après en général on n'a pas le temps pour tout, donc il reste que le n'importe quoi

Tu devrais être content, tu peux faire de la revue de sécu avant de déployer.
Voir même il y a des outils qui le font pour toi, et t'as juste à cliquer sur le bouton approve  

Le "tant que ca fonctionne on s'en fout" semble résumer assez bien l'esprit devops

bah le probleme du cloud et devops c'est qu'effectivement en mode de base, tu réduits les couts car tu adaptes tes besoins en les réduisants sur des petites instances
 
avant, l'ingé linux, bon il monte une archi, il fait ça une fois tous les 5 voir 10 ans, et apres son quotidien c'est de changer les disques durs et des alims qui petent, et resizer les partitions qui saturent.  
mais en cloud, pas besoin, c'est magik, du coup le mec il aurait plus de taf a faire de sa journée
 
du coup, on a inventer le devops et k8s, et vu que le devops faut bien le payer à dévopser toute la journée, bah il va passer sa journée a créer 5000 instances, et tout probleme se résoud a coup de 50 instance et 2000 containers avec load balancer, ingress controlleur et autre machin réinventé a la con alors qu'a la base il s'agit d'une appli back office de merde qui était faite sur AS400  pour a peine 20 cycles CPU y'a 40 ans
 
et magie, la le cloud te coute 2 fois le prix d'avant  

Après le devops vint le sre qui doit s'assurer que tout ce bordel tourne et scale bien

le SRE c'était avant le devops je pense, SRE c'était pour scaler chez Google
 
mais ensuite google pour vendre sa plateforme et sa techno a convaincu le reste du monde que tout le monde avait besoin d'une archi mondiale qui peut servir 100 millions de clients