Česky na konci článku.

A busy database team can look like a productive database team.

There are tickets every day.

Production alerts.

Performance problems.

Backup checks.

Access requests.

Database changes.

Emergency calls.

Developers asking for help.

Management asking for reports.

The DBA team is constantly doing something.

From the outside, this can look like a sign of importance and productivity.

But there is another possibility:

The database team is busy because the database environment is too dependent on manual work.

This distinction matters.

A strong database team should not simply be busy.

It should be effective.

---

Being Busy Is Not the Same as Creating Value

Imagine two database teams.

Team A

The team handles 100 database tickets every month.

They manually:

• create users
• check backups
• investigate alerts
• restart services
• perform maintenance
• answer repetitive questions
• fix recurring performance problems

Everyone is busy.

Team B

The team handles only 30 tickets.

Most routine operations are automated.

Developers can provision standard databases themselves.

Monitoring detects problems before customers notice them.

Backups are automatically validated.

Runbooks handle common incidents.

The DBA team spends its time improving architecture and reliability.

Which team is better?

The answer is obvious.

The team with fewer repetitive tasks may be delivering much more value.

---

A Busy DBA Team Can Hide Technical Debt

Technical debt is not limited to application code.

Databases accumulate operational debt too.

For example:

• manual provisioning
• outdated scripts
• inconsistent configurations
• undocumented procedures
• old database versions
• untested backups
• manual failover
• excessive permissions
• missing monitoring
• complicated recovery procedures

Each individual problem may appear manageable.

Together, they create a system that requires constant human attention.

The DBA team becomes the mechanism that compensates for weaknesses in the platform.

---

The Human Firewall

One of the most dangerous situations is when experienced DBAs become a human firewall around the database environment.

Every important change goes through them.

Every unusual alert goes through them.

Every new database goes through them.

Every production problem goes through them.

Developers ask:

“Can you check this query?”

Operations asks:

“Can you check replication?”

Management asks:

“Can you confirm the backup?”

Security asks:

“Can you review this database access?”

Soon, the database team becomes a bottleneck.

The problem is not that the DBAs are too slow.

The problem is that too many processes depend on them personally.

---

The Goal Is Not to Make DBAs Less Important

This is an important distinction.

The answer is not:

“We need fewer database engineers.”

The better question is:

“How can we use database expertise where it creates the most value?”

A senior DBA should be involved in:

• architecture
• reliability
• performance strategy
• disaster recovery
• security
• capacity planning
• automation
• database platform design
• major migrations

They should not spend most of their day answering questions that a well-designed platform could answer automatically.

---

Repetitive Questions Are Signals

Consider how often the same questions appear:

Is the database healthy?

Did the backup complete?

Is replication working?

How much storage is available?

Which database is primary?

Can I get access?

How do I create a database?

What is the correct connection string?

These are not necessarily DBA problems.

They may be platform design problems.

If people repeatedly ask the same question, the organization should ask:

Why does someone need to ask this question manually?

Perhaps the information should be visible in monitoring.

Perhaps the process should be automated.

Perhaps the answer should be documented.

Perhaps developers should have a self-service interface.

---

The First Step Is Visibility

Before changing the operating model, measure what the database team actually does.

For several weeks, categorize incoming work.

For example:

Then ask:

How much time is spent on each category?

The result can be surprisingly revealing.

A team may discover that 40% of its time is spent on repetitive operational tasks.

That is a huge opportunity.

---

Move From Tickets to Capabilities

A traditional database organization often works like this:

A modern platform can work differently:

The DBA is still responsible for the standards.

But the DBA no longer has to manually execute every standard operation.

This is a fundamental change.

The organization moves from people performing tasks to people building capabilities.

---

Standardization Comes Before Automation

Automation is powerful.

But automating a bad process does not make it good.

Suppose five DBAs create PostgreSQL databases in five different ways.

Before automating the process, define the standard.

For example:

• approved PostgreSQL version
• standard configuration
• backup policy
• monitoring
• security settings
• resource limits
• maintenance policy
• recovery requirements

Once the standard is clear, automation becomes much easier.

---

Not Every Database Needs the Same Service

Another reason database teams become overloaded is that everything is treated as equally important.

It shouldn’t be.

A development database does not necessarily need the same level of protection as a payment database.

A reporting database may have different recovery requirements from a transactional system.

A small internal application may not require the same availability as a customer-facing platform.

A mature database organization defines service levels.

For example:

Tier 1 — Critical

Customer-facing or revenue-generating.

High availability.

Strict recovery requirements.

Continuous monitoring.

Regular recovery testing.

Tier 2 — Important

Business-critical but not immediately revenue-generating.

Standard HA and backup.

Defined recovery targets.

Tier 3 — Standard

Internal or lower-risk applications.

Simpler architecture.

Lower operational cost.

This approach helps the database team focus effort where it matters most.

---

The Database Team Should Measure Outcomes

Counting tickets is easy.

It is not necessarily useful.

Better metrics include:

• database availability
• recovery time
• recovery success rate
• backup restore success
• replication health
• number of recurring incidents
• percentage of automated operations
• time spent on manual work
• database provisioning time
• change failure rate
• customer impact

These metrics tell a much better story.

For example:

Database provisioning decreased from two days to 20 minutes.

That is a meaningful improvement.

Or:

70% of routine database operations are now automated.

Again, meaningful.

---

Reliability Creates Capacity

There is another important benefit.

Automation doesn’t just save time.

It creates organizational capacity.

Imagine a team of five database engineers.

If each person spends 30% of their time on repetitive operational work, that represents the equivalent of:

1.5 full-time people.

Those engineers are effectively unavailable for strategic improvements.

If automation reduces repetitive work to 10%, the team recovers a significant amount of engineering capacity.

That capacity can be used to:

• improve performance
• modernize infrastructure
• reduce technical debt
• improve disaster recovery
• support business growth
• build better platforms

Reliability therefore becomes a productivity strategy.

---

A Quiet Database Team Can Be a Sign of Success

There is a strange perception in IT.

A team that is constantly responding to incidents can look important.

A team that prevents incidents can look quiet.

But quiet is often the result of good engineering.

When:

• monitoring works
• automation works
• backups are tested
• documentation is current
• architecture is resilient
• developers have self-service tools

the database team may actually have fewer emergencies.

That is not a lack of work.

It is the result of eliminating unnecessary work.

---

The Best DBA Work Often Happens Before the Incident

A traditional approach asks:

“How quickly did we fix the problem?”

A reliability-focused approach also asks:

“Why did we need someone to fix it manually?”

The first question measures response.

The second question measures engineering maturity.

Both matter.

But the second question is where long-term improvement begins.

---

From DBA Operations to Database Platform Engineering

The evolution can be simple:

At the beginning, people operate databases.

Later, they build systems that operate databases consistently.

That is the fundamental shift toward modern Database Reliability Engineering.

---

What Should You Automate First?

A practical starting point is simple.

Look for work that is:

Frequent.

Predictable.

Well understood.

Low risk when properly validated.

Examples include:

• database provisioning
• user provisioning
• health checks
• backup validation
• standard maintenance
• monitoring configuration
• routine reporting
• environment configuration

Do not start with the most complicated process.

Start with the process that happens often enough to make a measurable difference.

---

The Real Goal

The goal is not to make the database team invisible.

The goal is to make the database platform dependable.

A mature database organization should gradually move from:

“Ask the DBA.”

to:

“Use the standard platform.”

And from:

“The DBA knows how to fix it.”

to:

“The organization knows how to recover.”

And finally:

“The system prevents or handles the problem automatically.”

That is progress.

---

Final Takeaway

A database team that is constantly busy is not necessarily a successful database team.

Sometimes it is a warning sign.

It can indicate:

• too much manual work
• insufficient automation
• weak documentation
• inconsistent standards
• poor self-service
• technical debt
• fragile architecture

The goal should not be to keep DBAs busy.

The goal should be to make the database environment reliable enough that DBAs can focus on the problems that truly require their expertise.

The best database team is not the team that solves the most repetitive problems.

It is the team that makes those problems disappear.

---

About the Author

Tomas Solar
Principal Database Reliability Engineer

20+ years of experience with Oracle, PostgreSQL, SQL Server, MySQL and MongoDB.

Specialized in database reliability, high availability, disaster recovery, performance engineering, automation, migrations and database architecture.

15+ years working remotely with teams across EMEA.

A mature database team is not measured by how busy it is, but by how much unnecessary work it has eliminated.

Proč je váš databázový tým stále zaneprázdněný – a proč to může být problém

Zaneprázdněný databázový tým může na první pohled působit jako produktivní databázový tým.

Každý den přicházejí tickety.

Produkční alerty.

Problémy s výkonem.

Kontroly záloh.

Požadavky na přístupy.

Změny v databázích.

Nouzová volání.

Vývojáři potřebují pomoc.

Management chce reporty.

DBA tým neustále něco řeší.

Zvenčí to může vypadat jako známka důležitosti a produktivity.

Existuje ale i jiná možnost:

Databázový tým je zaneprázdněný proto, že databázové prostředí je příliš závislé na manuální práci.

A právě tento rozdíl je důležitý.

Silný databázový tým by neměl být pouze zaneprázdněný.

Měl by být efektivní.

---

Být zaneprázdněný není totéž jako vytvářet hodnotu

Představme si dva databázové týmy.

Tým A

Tým řeší každý měsíc 100 databázových ticketů.

Ruční práce zahrnuje:

• vytváření uživatelů
• kontrolu záloh
• vyšetřování alertů
• restartování služeb
• údržbu
• odpovídání na opakující se dotazy
• opravu opakujících se problémů s výkonem

Všichni jsou zaneprázdnění.

Tým B

Tým řeší pouze 30 ticketů.

Většina rutinních operací je automatizovaná.

Vývojáři si mohou standardní databáze vytvořit sami.

Monitoring odhalí problémy dříve, než si jich zákazníci všimnou.

Zálohy se automaticky ověřují.

Runbooky řeší běžné incidenty.

DBA tým tráví čas zlepšováním architektury a spolehlivosti.

Který tým je lepší?

Odpověď je poměrně jasná.

Tým s menším počtem opakujících se úkolů může vytvářet výrazně větší hodnotu.

---

Zaneprázdněný DBA tým může skrývat technický dluh

Technický dluh se netýká pouze aplikačního kódu.

Databáze si také vytvářejí provozní dluh.

Například:

• manuální provisioning
• zastaralé skripty
• nekonzistentní konfigurace
• nezdokumentované postupy
• staré verze databází
• neotestované zálohy
• manuální failover
• příliš rozsáhlá oprávnění
• chybějící monitoring
• komplikované recovery postupy

Každý jednotlivý problém může vypadat zvládnutelně.

Dohromady ale vytvářejí systém, který vyžaduje neustálou lidskou pozornost.

DBA tým se pak stává mechanismem, který kompenzuje slabiny platformy.

---

Lidský firewall

Jednou z nejnebezpečnějších situací je, když se zkušený DBA stane lidským firewallem kolem databázového prostředí.

Každá důležitá změna jde přes něj.

Každý neobvyklý alert jde přes něj.

Každá nová databáze jde přes něj.

Každý produkční problém jde přes něj.

Vývojář se ptá:

„Můžeš zkontrolovat tento SQL dotaz?“

Operations se ptá:

„Můžeš zkontrolovat replikaci?“

Management se ptá:

„Můžeš potvrdit, že máme zálohu?“

Security se ptá:

„Můžeš zkontrolovat přístup k této databázi?“

A databázový tým se postupně stává úzkým hrdlem celé organizace.

Problém není v tom, že jsou DBAs pomalí.

Problém je v tom, že příliš mnoho procesů závisí přímo na konkrétních lidech.

---

Cílem není udělat z DBA méně důležitého člověka

To je důležité rozlišovat.

Řešením není:

„Potřebujeme méně databázových inženýrů.“

Lepší otázka zní:

„Jak můžeme využít databázové znalosti tam, kde vytvářejí největší hodnotu?“

Seniorní DBA by měl být zapojen především do:

• architektury
• spolehlivosti
• strategie výkonu
• disaster recovery
• bezpečnosti
• capacity planningu
• automatizace
• návrhu databázové platformy
• velkých migrací

Neměl by většinu dne odpovídat na otázky, na které by měla umět odpovědět dobře navržená platforma.

---

Opakující se otázky jsou signál

Přemýšlejte, jak často se opakují stejné otázky:

Je databáze zdravá?

Proběhla záloha?

Funguje replikace?

Kolik máme volného storage?

Která databáze je primary?

Můžu získat přístup?

Jak vytvořím databázi?

Jaký je správný connection string?

To nemusí být DBA problémy.

Mohou to být problémy návrhu platformy.

Pokud se lidé stále ptají na stejnou otázku, organizace by se měla zeptat:

Proč musí tuto otázku někdo řešit ručně?

Možná má být informace viditelná v monitoringu.

Možná má být proces automatizovaný.

Možná má být odpověď zdokumentovaná.

Možná by vývojáři měli mít self-service rozhraní.

---

První krok je viditelnost

Než začnete měnit způsob fungování týmu, změřte, co databázový tým skutečně dělá.

Několik týdnů kategorizujte přicházející práci.

Například:

Potom se zeptejte:

Kolik času zabere každá kategorie?

Výsledek může být překvapivý.

Tým může zjistit, že například 40 % jeho času padne na opakující se provozní činnosti.

To je obrovská příležitost.

---

Od ticketů ke schopnostem

Tradiční databázová organizace často funguje takto:

Moderní platforma může fungovat jinak:

DBA stále odpovídá za standardy.

Ale nemusí ručně provádět každou standardní operaci.

To je zásadní změna.

Organizace přechází od lidí provádějících jednotlivé úkoly k lidem vytvářejícím opakovatelné schopnosti platformy.

---

Standardizace musí předcházet automatizaci

Automatizace je velmi silný nástroj.

Ale automatizace špatného procesu z něj neudělá dobrý proces.

Představme si, že pět DBA vytváří PostgreSQL databáze pěti různými způsoby.

Nejdříve je potřeba definovat standard.

Například:

• schválená verze PostgreSQL
• standardní konfigurace
• politika zálohování
• monitoring
• bezpečnostní nastavení
• limity zdrojů
• maintenance policy
• požadavky na obnovu

Jakmile je standard jasný, automatizace je mnohem jednodušší.

---

Ne každá databáze potřebuje stejnou úroveň služby

Dalším důvodem přetížení databázových týmů je skutečnost, že se ke všem databázím přistupuje stejně.

To není správně.

Vývojová databáze nemusí mít stejnou úroveň ochrany jako platební databáze.

Reportingová databáze může mít jiné recovery požadavky než transakční systém.

Malá interní aplikace nemusí potřebovat stejnou dostupnost jako služba pro zákazníky.

Vyspělá databázová organizace proto definuje service levels.

Tier 1 – Kritické

Systémy orientované na zákazníky nebo generující příjmy.

• vysoká dostupnost
• přísné recovery požadavky
• nepřetržitý monitoring
• pravidelné testování obnovy

Tier 2 – Důležité

Business-critical systémy, které ale negenerují okamžitý příjem.

• standardní HA a zálohování
• definované recovery cíle
• aktivní monitoring

Tier 3 – Standardní

Interní nebo méně rizikové aplikace.

• jednodušší architektura
• nižší provozní náklady
• základní monitoring

Tento přístup pomáhá databázovému týmu soustředit úsilí tam, kde má největší význam.

---

Databázový tým by měl měřit výsledky

Počet ticketů se snadno měří.

Není ale vždy užitečný.

Mnohem lepší metriky jsou například:

• dostupnost databází
• doba obnovy
• úspěšnost recovery
• úspěšnost obnovy ze záloh
• stav replikace
• počet opakujících se incidentů
• procento automatizovaných operací
• čas strávený manuální prací
• čas potřebný k provisioningu databáze
• change failure rate
• dopad na zákazníky

Tyto metriky vyprávějí mnohem lepší příběh.

Například:

Provisioning databáze jsme zkrátili ze dvou dnů na 20 minut.

To je skutečné zlepšení.

Nebo:

70 % rutinních databázových operací je nyní automatizovaných.

Opět velmi konkrétní výsledek.

---

Spolehlivost vytváří kapacitu

Existuje ještě jeden důležitý přínos.

Automatizace pouze nešetří čas.

Vytváří organizační kapacitu.

Představme si tým pěti databázových inženýrů.

Pokud každý z nich tráví 30 % času opakující se provozní prací, znamená to:

1,5 člověka na plný úvazek, který je efektivně nedostupný pro strategické zlepšování.

Pokud automatizace sníží tento podíl na 10 %, tým získá zpět významnou část engineering kapacity.

Tuto kapacitu může využít na:

• zlepšení výkonu
• odstranění technického dluhu
• modernizaci infrastruktury
• zlepšení disaster recovery
• podporu růstu firmy
• budování lepší platformy

Spolehlivost se tak stává také strategií produktivity.

---

Klidný databázový tým může být známkou úspěchu

V IT existuje zvláštní vnímání.

Tým, který neustále řeší incidenty, může působit důležitě.

Tým, který incidentům předchází, může působit klidně.

Jenže klid je často výsledkem dobrého engineeringu.

Když:

• monitoring funguje
• automatizace funguje
• zálohy jsou otestované
• dokumentace je aktuální
• architektura je odolná
• vývojáři mají self-service nástroje

databázový tým může mít méně krizových situací.

To neznamená méně práce.

Znamená to, že se podařilo odstranit zbytečnou práci.

---

Nejlepší DBA práce často probíhá před incidentem

Tradiční přístup se ptá:

„Jak rychle jsme problém opravili?“

Reliability přístup se ptá také:

„Proč vůbec musel někdo problém ručně opravovat?“

První otázka měří reakci.

Druhá otázka měří vyspělost engineeringu.

Obě jsou důležité.

Ale právě druhá otázka vede k dlouhodobému zlepšování.

---

Od DBA Operations k Database Platform Engineering

Vývoj může být jednoduchý:

Na začátku lidé databáze provozují.

Později vytvářejí systémy, které databáze provozují konzistentně.

To je zásadní posun směrem k modernímu Database Reliability Engineering.

---

Co automatizovat jako první?

Praktický začátek je jednoduchý.

Hledejte práci, která je:

častá.

předvídatelná.

dobře pochopená.

při správné validaci má nízké riziko.

Například:

• provisioning databází
• provisioning uživatelů
• health checks
• validace záloh
• standardní maintenance
• konfigurace monitoringu
• rutinní reporting
• konfigurace prostředí

Nezačínejte tím nejsložitějším procesem.

Začněte procesem, který se opakuje dost často na to, aby přinesl měřitelný výsledek.

---

Skutečný cíl

Cílem není udělat databázový tým neviditelným.

Cílem je vytvořit spolehlivou databázovou platformu.

Vyspělá databázová organizace by měla postupně přecházet od:

„Zeptejte se DBA.“

k:

„Použijte standardní platformu.“

A od:

„DBA ví, jak to opravit.“

k:

„Organizace ví, jak systém obnovit.“

A nakonec:

„Systém problém automaticky zabrání nebo ho sám zvládne.“

To je skutečný pokrok.

---

Závěr

Databázový tým, který je neustále zaneprázdněný, nemusí být úspěšný databázový tým.

Někdy je to varovný signál.

Může to znamenat:

• příliš mnoho manuální práce
• nedostatečnou automatizaci
• slabou dokumentaci
• nekonzistentní standardy
• špatný self-service
• technický dluh
• křehkou architekturu

Cílem by nemělo být udržovat DBAs neustále zaneprázdněné.

Cílem by mělo být vytvořit databázové prostředí dostatečně spolehlivé na to, aby se DBAs mohli soustředit na problémy, které skutečně vyžadují jejich zkušenosti.

Nejlepší databázový tým není tým, který vyřeší nejvíce opakujících se problémů.

Je to tým, který dokáže tyto problémy odstranit.

---

O autorovi

Tomas Solar
Principal Database Reliability Engineer

Více než 20 let zkušeností s Oracle, PostgreSQL, SQL Server, MySQL a MongoDB.

Specializace na databázovou spolehlivost, vysokou dostupnost, disaster recovery, performance engineering, automatizaci, migrace a databázovou architekturu.

Více než 15 let práce na dálku s týmy napříč EMEA.

Vyspělý databázový tým se neměří podle toho, jak je zaneprázdněný, ale podle toho, kolik zbytečné práce dokázal odstranit.

Komentáře