I accidentally deleted the company's database, but I still survived.

Focus on the "lab building" and share a project tutorial every day

Most of us are "narrowly escaped" ...

Text total: 2568 words

Estimated reading time: 7 minutes

Editor's note: Developers always think that they mistakenly deleted the data is a big thing. True, but "sin is not Dead". The author of this article Zachary Kuhn share his personal experience, and that it is not important to make mistakes, it is important to have income.

Last week I had a short talk with my colleagues about a career-related mess. It does make a mockery of others, but it brings us precious lessons. The important thing is that we should share those mistakes so that others can learn from them. The following are examples of recent occurrences in my body.
Why there are so many mistakenly deleted production database things happen.

A few months ago, Reddit an article about a junior developer who deleted the production database on the first day of work. We are all very 憷 to read this kind of article that makes such a big mistake that can't be forgotten. Because we are not far from these, and most people are "narrowly escaped".

In my first job, a senior database administrator mistakenly deleted the production database on the first day of work. This kind of storyline abounds. The team recovered the error he caused from the one-week backup and let him continue to work. Ten years later, they still use it as a point of laughter.

Earlier this year, I was sent to check a customer's production data for problems. They conducted a small, private test, resulting in no content being displayed on the site. I want to check if there is a loophole or vulnerability problem that leads to this result.

I passed the signature link on the production machine and then opened the database. The Content Library (articles table) is empty. This confirms that what we see on the website is true.

User data still exists in the user library (users table). That's strange. So the situation is we lost everything, but at least the user's information still exists. The explanation we gave is that this is a test behavior, so these things can happen.

The next few minutes were chaotic. I don't remember what I did. I don't think I'm stupid. The action to delete a user library was performed on the console. But that's how it happened, and now there's no content library or user library in the background. It really gave me a big jump.

Then my brain began to spin and think about how to solve the problem. Did I really erase the user library? Yes. Did we save the backup? No. How should we tell the customer about this thing. I don't know.

I remember walking to the project manager, sitting next to her and explaining to her what was going on. Because there is no content in our content library, that's why the site is empty. At the same time, I also deleted the user library. They now need to re-invite all the users if they can figure out who is who.

I returned to my office, dejected.

However, I still do not accept this matter. How we lost these things at first.

I began to keep thinking deep in my head. Half is to deny this thing, half is want to save face. Soon, I noticed some important things.

There are 5 other databases on the server. One of the databases has the same name as the database I just saw.

When I looked at the database, I found that all the content was there. The user library is also safe. It turns out that a configuration change inadvertently changed the production settings and made the site point to a completely new database. What is the user information that I have seen before? Seed data.

Oh, thank goodness. The nerves and stomach acid in the morning made me feel uncomfortable, but we "recovered" the data and found the real problem before the bad news spread.

There are a lot of lessons to be learned from the matter. One point is the simplest principle: we are always doing the backup, perhaps the developer's most effective salvage medicine.
Keep moving, but don't rush past.

A mistake I made recently is not very noticeable. In fact, this is a small error caused by small errors eventually led to a chaotic story.

We are faced with a time-pressing project.

At the first meeting, our team agreed that it would take one more time to complete it than scheduled. This deadline started to have an impact on us, allowing me to easily pass the identity certification section and leave more time to focus on the functional design that the customer is actually concerned about.

I just tested the authentication tests on a single page, but I didn't know how they would be grouped together.

It was a wrong decision I made. I overlooked a few important things:

The user loads the content from the cookie after landing, but the page tries to load without any waiting. Depending on the order in which the event occurred, the user would receive a response from the server, saying that it was unauthorized.

Authentication also does not check whether the token expires. If the user does not visit this site frequently. Then when it is visited again, the site needs to log out and log in before running.

Tokens should be updated on a per-request basis, but I never took the time to understand the rules before and after their occurrence. So, this has created a time problem. If we send several requests at the same time, depending on the order in which they are returned, the user will get the token that cannot be used in subsequent requests.

We hurried to the project, but we still spent one more time than the rules. The difference is that there are more vulnerabilities and it takes more time to track and fix these vulnerabilities.

It made me feel embarrassed. Then I felt ashamed of myself in public because the whole thing had gotten worse.

I want to say is: After this, I spent time to study the certification process. I now understand the OAuth, JWT, refresh token, and expiration behavior. I've looked at the authentication code that other people have written. I can construct the authentication program in different languages and frameworks. Turn failure into future success

That's what I've learned from the bad things that have been done. If you want, then almost all good results will come.

If anyone can learn from his mistakes, he will be better than he is now. I try not to hit the teammates who made the mistake for the first time. They usually know they're messing things up.

I'm also trying not to put pressure on those who keep making the same mistakes. They still deserve sympathy.

If you do these 4 points in your mistake, you will grow:

Laugh at yourself.

Learn from the lessons learned.

Correct the error.

Share your mistakes and let others reap.

Finally, I want to tell an anecdote about the wrong value. At the beginning of 20th century, IBM CEO Thomas F. J. Watson had met an employee who had a huge price to pay for a series of poor decisions made by the employee. When asked if he would dismiss the employee, Watson replied:

"No, I just spent 600,000 dollars on him training fees. Why let other people pick up the cheap in vain. ”

Translator: Wooden Wooden son

Source: 36kr

Link: https://36kr.com/p/5129182.html

Original link: https://medium.freecodecamp.org/the-times-ive-messed-up-as-a-developer-3c0bcaa1afd6

Learn More

Building +"python actual Combat", "linux and DevOps actual combat" preferential registration-from Tencent, Intel, IBM and other Internet manufacturers of the first line of Daniel, take you 12 weeks to get through Python, Linux, the governor of the two veins.

Click on the link below for more information:

What kind of experience is it for three months to knock on Python?

11 weeks to get through the Linux ren du two veins, the Experimental Building Technology Sky Regiment to take you fly.