My Deletion Experience

Original link: https://www.kawabangga.com/posts/4693

After reading an article about my own experience in deleting databases , I felt the same:

But, as far as I know, no one ever asked why a junior developer had access to a production database. I probably did need read access, but why write access? And if I did need write access, did I really need permission for a destructive command like TRUNCATE ?

Blameless’s accident review is so important that without it, we would focus more on human mistakes than on system vulnerabilities: why would junior engineers have write permissions? Why is TRUNCATE not banned? Why can’t I restore a backup from a table?

The only time I deleted a library was when I deleted an offline test library. Here’s the thing.

Not long after I joined the last company, I pulled the code of the project and found that it was a mess and was almost unmaintainable (not what I thought was unmaintainable in my personal taste, but objectively unmaintainable code, if you read it, you can Imagine the quality of these codes).

So my plan is:

1. Fix the unit tests first, so that every commit passes the unit tests;
2. Gradually and team refactoring code;

It was a Django-based project, and the previous unit tests could not be started due to configuration problems. After fixing these issues, I ran the test command: python manage.py test .

After a few minutes, the test library was found to be deleted. It was discovered that there was also a problem with the database configuration in the previous code. The database connected to the test environment and the name of the unit test definition (which did not need to be defined, django will generate it by itself) are the same database name. When Django runs the test, if --keepdb is not specified, Django will delete the test library after running the test.

Although it is an offline test library, it has caused many problems:

1. We have written a lot of configuration data into the database directly through the shell, and there is no backup in the code;
2. DBA is not responsible for maintaining offline libraries and cannot restore backups;

So in the end, the data can only be recovered by relying on memory.

This also exposed many problems:

1. In order to speed up the development of this project, there are many places where the development of this project does not comply with the specifications, such as directly saving important data in a database without SLA guarantee; (later I found that many internal projects in this company do this, to The offline environment is the main one, because the approval process for each release and modification in the online environment is too complicated, and it takes at least 40 minutes to change only one line of code and publish it online. In the eyes of many people, the quality of internal projects is not important, only It is enough to have some screenshots of the system when you need a promotion defense.)
2. Data modification should use Django’s Data migration, so that the data written by non-business will be persisted in the code base, as well as historical records;
3. The project has dangerous configuration errors;
4. Unit tests never run successfully;

The project also ended up being unmaintainable, and we ended up rewriting a project to replace it.

The post My Deletion Experience first appeared on Kawa Banga! .

This article is reprinted from: https://www.kawabangga.com/posts/4693
This site is for inclusion only, and the copyright belongs to the original author.