I’ve previously mentioned that Data Guardians have three key technical areas to spend their time: Data Availability, Data Performance and Data Security.

I’ve also stated that we spend our effort between reactive unplanned work and proactive planned work.

Today, we will focus the lens on how these concepts apply to Data Availability.

Defining Data Availability

When talking about Data Availability, the first place to start is that the database is available for users and applications to put data in and get data out.

That is the very basics for Data Availability, and High Availability and Disaster Recovery must be addressed for any critical environments.

But the definition of ‘available’ extends beyond whether the server is up.

Data can be unavailable if a table is being modified to a new structure through a schema migration that is blocking.

Data can also be unavailable if there are networking issues between the application and the database.

Or if application user credentials are misconfigured.

Or even if replication is lagging beyond defined thresholds that puts the data at risk of being too stale.

Data Firefighters

Without good systems in place, it is easy for the Data Guardian to find themselves doing constant unplanned work around availability.

The Data Guardian who is in reactive mode regarding Data Availability is like a Firefighter.

Firefighters are first responders, and often thought of as heroes. They literally can be life or death to people trapped in a burning building.

There is a certain amount of heroism to being able to put out “fires” in the data environment.

After all, if your critical data environment becomes corrupt and unrecoverable, your business would be severely damaged.

But the Data Guardian will know that fighting fires all day will lead to burnout.

They will work to put in systems to prevent future fires, similar to how a firefighter will tell you to keep smoke detectors working and have a fire extinguisher near by.

Data Guardians in proactive mode

The Data Guardian that does that well starts to move into proactive mode.

Rather than being firefighters, they transition more towards becoming a Fire Marshal for Data Availability.

Fire Marshals implement and enforce safety codes to try to prevent fires in the first place.

While they do investigate the cause of fires, which is reactive, they will look to use that information to prevent similar issues in the future.

A Data Guardian in this mode will implement systems and monitors to detect situations like outages, table blocking, and replication lag.

They will test their backups to make sure they are viable in case it becomes necessary to use them.

And they will run field tests of their availability strategy to ensure it is working.

Conclusion

You can easily find yourself in reactive fire-fighting mode regarding Data Availability.

It may even be tempting to stay there, because it’s easy to show how valuable you are when you put out those fires.

But Data Guardians should strive to be Fire Marshals of the data environment, toreduce stress and avoid burn out.

And they know companies value the true heroes that prevent fires in the first place.