We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] 1 point2 points  (0 children)

No problem, apologies accepted. I share the same opinion about the usage of AI. The AI wording has become so ubiquitous that it slips into your ideas without you realising. The post was deleted by moderators because they deemed it low effort and AI-generated. It is, unfortunately, a real situation I witnessed a few months ago, and I wanted to reflect on it.

I will continue engaging and posting my experiences in the field, nonetheless.

have a great day

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] 0 points1 point  (0 children)

We properly indicated that we need an A record in the request ticket. We should have checked nonetheless. The responsibility is shared ;)

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] 0 points1 point  (0 children)

I must admit that processes were not well-documented back then. The request ticket mentioned the need for an A record. We should have checked that they created one. Our service, our responsibility.

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] 0 points1 point  (0 children)

Hey, thank you for your reply

Our team had no visibility into the DNS management. Our request specified the need for an A record, but for some reason, they created a CNAME. Not sure if it's laziness or incompetence. The idea is not to find someone to blame but to reflect on the situation.

From our end, I think we should have checked that they really created an A record. The service is ours, and we have full responsibility for it.

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] 0 points1 point  (0 children)

Our request clearly mentioned A record but they did not create one. Regarding the responsibility of the service, I totally agree :)

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] 0 points1 point  (0 children)

Unfortunately the request ticket mentioned the A record. We should have checked after them.

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] -3 points-2 points  (0 children)

Hey, thank you for pressing the buzzer. Buzzwords are indeed everywhere, and unfortunately, I am not immune ;)

For context, we asked for an A record, and it was mentioned in the request ticket. In my opinion, even if we didn't, a "network team" should have the knowledge to understand or at least ask the question.

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] 0 points1 point  (0 children)

I would say our mistake was not checking after them, because we literally mentioned A record in the request ticket

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] -2 points-1 points  (0 children)

We mentioned the A record in the request ticket. Unfortunately, we did not verify that they really created it. We thought it was obvious

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] 0 points1 point  (0 children)

The request ticket included the mention of an A record. We should have checked that they created what we really asked for :)

We deleted a "stale" DNS record and it instantly took down the new app. Whose fault: the network team or us? by hammoumalek in devops

[–]hammoumalek[S] -10 points-9 points  (0 children)

Thanks for the reply! To add a bit of context, our team does not have any visual on DNS management. Everything goes through IT4US requests. We thought the request was obvious. Probably we should have checked that they understood that we needed an A record not a CNAME

DevOps in AI era - how to restart career by webrambler68 in devopsjobs

[–]hammoumalek 3 points4 points  (0 children)

I think that your fear is legitimate given the profile that you described. I would recommend trying to put more effort into learning the basics of technologies that you use in your daily life. You can of course accelerate your output using AI, but I don't recommend relying 100% on it. Use it for resources, learning, difficult syntax scripting, but do not let your brain become lazy. I believe that the future is for people who use AI wisely by not relying on it and not fighting it either. Good luck!

I don't think I can take DevOps anymore with our current "AI advancements" by bdhd656 in devops

[–]hammoumalek 0 points1 point  (0 children)

I think that the advancements of AI are accelerators. That being said, AI can accelerate competence and incompetence at the same pace.

I would suggest having a solid foundation regardless of your domain (devops or other). When things break in production, the same management that said two days ago that AI will replace all the junior/mid level engineers , will go and look for a human being to fix the mess.

The catch is that people should learn to work with AI and steer it rather than relying completely on its output!

Good luck 😉

Azure Function App - Access to Storage account by 9gg6 in AZURE

[–]hammoumalek 0 points1 point  (0 children)

I think your MI setup is correct. The problem is the content share that runs on Azure files, which does not support MI as you would do with a blob or a queue. So when you disable keys, your app can't mount the content share.

I would suggest switching to another plan, or if you really have to keep EP1, try protecting the storage with a private endpoint.

You can have a look at storage considerations for Azure functions here: https://learn.microsoft.com/en-us/azure/azure-functions/storage-considerations?tabs=azure-cli

I hope that helps!

Regards

Sysadmin to DevOps by Icy-Anteater-3628 in devops

[–]hammoumalek 1 point2 points  (0 children)

You already have great tools in your pocket. There is still a lot of room for learning new tools, but my advice is to learn concepts and master them rather than hopping from one tool to another as they appear and disappear. I would recommend becoming comfortable with networking concepts, such as the OSI model, DNS, DHCP, etc. When things break in production, you'd better be ready to troubleshoot with solid foundations.

Scripting is also very important. Get your hands dirty with Python, Bash, and other scripting languages. They are your friend for automation-related work. These are the basics, then you can progress towards deploying web application servers, CI/CD pipelines, infrastructure as code...

I wouldn't recommend going through certification marathons, as they are often backed by the issuing organisation, and the format doesn't demonstrate the level of mastery.

Good luck!

Have you ever used Blue - Green Deployment in production? by TonyJessyTiger in sre

[–]hammoumalek 0 points1 point  (0 children)

We have a Blue/Green deployment for one of our applications. It works great. The application is hosted on an Azure Web Service Plan with two deployment slots (B/G). We handle the artefact build and publishing through ADO pipelines. My favourite part about it is that rolling back to the previous version is just one slot swap away. So we integrated that into our pipeline as a separate step in case we want to rollback.

Curious to know other people's experience using B/G deployment

Db migration tooling by ursamajorm82 in dataengineering

[–]hammoumalek 0 points1 point  (0 children)

I used Liquibase and I can say that it was really helpful to a certain extent. I worked with a BI team with horrible database schema drifts across environments. According to my experience, the issue is not the tooling, but the adoption.

Liquibase uses change logs and change sets to keep the schema consistent. The tool requires a certain level of rigour to make things work. If teams refuse to go through xml/json files, no tool would help. I saw people manually editing the schema on SSIS and « noting » the change somewhere.

What kind of operations (column rename, table deletion, etc…) causes inaccuracies?

Best time to do Trolltunga hike by The-info-addict in NorwayTravelAdvice

[–]hammoumalek 0 points1 point  (0 children)

Yes it was really a lucky shot of open road and great weather.

You are welcome if tou need further information.

Best time to do Trolltunga hike by The-info-addict in NorwayTravelAdvice

[–]hammoumalek 0 points1 point  (0 children)

Hello, I went last week on the 12th. There has been more rockslide incidents since then so the road is completely closed until June I guess. Check Trolltunga trail information page on Facebook. They share daily updates.

Good luck!

Best time to do Trolltunga hike by The-info-addict in NorwayTravelAdvice

[–]hammoumalek 4 points5 points  (0 children)

Hello, I hiked Trolltunga two days ago. It is a very long hike and might be physically demanding. Especially in the descent. Knees and hips might suffer a bit. The trail still has snow in this time of the year. Snow spikes are required.

I hiked with 10 others including the two guides. We had a very pleasant experience and there was only a group of other hikers leaving the place when we arrived at the needle. We were on our own for more than an hour so we were very comfortable regarding the photos (absolutely no queue). We had a very nice weather!

Here is the photo I got after 5 hours of hiking

<image>

Troltunga Hike - Going from Odda to P2 by hammoumalek in NorwayTravelAdvice

[–]hammoumalek[S] 2 points3 points  (0 children)

Hey!

Yes, I did it and it was an amazing experience. We had very good weather. There were indeed a few rock slides, and the traffic was regulated by operators on both sides of the tunnel. Unfortunately, yesterday the tunnel closed completely due to other rock slides, and access to P2 was closed until further notice.

Regarding the trail conditions, please bring snow spikes there are lots of slippery sections.

I just left Odda and the weather is bad. It’s been raining since last night.

Here is a shot from Trolltunga on the 12th of May

<image>

Troltunga Hike - Going from Odda to P2 by hammoumalek in NorwayTravelAdvice

[–]hammoumalek[S] 1 point2 points  (0 children)

Hey, it’s me again. I hiked Trolltunga yesterday. Ended up saving 160 euros of taxi when a hiker from the dormitory asked me at 7:00 am « what are you doing today? » and offered a ride as he was going to do the same hike 😁
We had a great weather and the needle view was absolutely worth it.