Data and databases are at the heart of any business endeavour to work with DevOps, development and operations working closer to one another and embracing automation. Data equal business value and it has to be safeguarded against corruption as well as data loss.
When DBMaestro reached out to 244 IT professionals they learned plenty about the way of working with databases in DevOps oriented workplaces. The top three risks reported for when deploying database changes were: Downtime, Performance impact, and Database / application crash.
But this then leads us to the question: What are the top three reasons for errors when making database changes? Well, based on the survey responses it turns out that accidental overrides, invalid code and conflicts between different teams are the three major sources of errors.
Speaking with CTO and co-founder Yaniv Yehuda from DBMaestro, we get some more insight into how these errors occur.
“Overrides of database objects – such as procedures or functions etc, when multiple people are accessing and introducing changes at the same time, on a shared database. For example – a developer starts to fix a bug in a database package, while the DBA adds another piece of code to that package. The last one to introduce the change, will override the previous one.
This was a challenge for code development decades ago, and was solved by introducing a check out/in process, and revision management. The problem still persists for shared database development.” When it comes to recovery times, most errors are fixed within one hour (51%), closely followed by errors that are handled in 1-5 hours.
DBAs are still mostly in control, but the balance is shifting!
Also, DBAs are still ruling their databases and 59% report that database changes are made by the DBA, versus 20% reporting that the DevOps can do the same. This does of course not mean that you as a Linux engineer should refrain from learning about database maintenance. Especially so since DBAs may be the bottleneck in critical business workflows. I wonder whether DBAs turn out to be bottlenecks in rapid Kanban/SCRUM workflows and on this topic, Yaniv Yehuda from DB Maestro adds “The fact that the process is being done by a person – adds overhead to an automated process.”
He continues with a real life example: “In large enterprises, if a developer wants to change something in the DB, he submits a request ticket – and the DBA takes it forward. That process can take days (just because people are busy…). Whenever you get that process automated, and each developer can do what he is entitled to – he can push several changes a day, without waiting for anyone else.
DBA may be required to review changes, but that should but be at the stage that a developer is striving to be agile. Errors – they can rise from the manual nature of the process (forgot to do something before or after, connected to the wrong environment, run the wrong script etc etc)”
Automation still an ongoing effort
The survey also showed that database scripts are mostly used to make changes to databases (51%), followed by build/submit scripts using automation tools (34%). The survey was based on a group of 244 IT professionals from around the world, ranging from CTOs to DBAs.
/ P-C Markovski