Česky na konci článku.

There is a dangerous culture in database operations.

A production problem appears.

Everyone calls the DBA.

The DBA connects to the server, analyzes the situation, finds the problem, executes a few commands and brings the service back.

Everyone is relieved.

The DBA becomes the hero.

And then, a few weeks later, the same thing happens again.

The same DBA is called.

The same pressure.

The same emergency.

The same solution.

This may look like excellent database administration.

It is not.

If the same person has to repeatedly save the system, the system has a reliability problem.

Heroic Operations Are Not Reliable Operations

A highly experienced DBA can sometimes compensate for weaknesses in architecture.

They know which log to check.

They remember an obscure parameter.

They know which process can be restarted.

They understand the application’s strange behavior.

They know which command should never be executed during an incident.

This expertise is extremely valuable.

But there is a problem.

What happens when that person is:

  • on vacation?
  • sick?
  • asleep?
  • working on another incident?
  • no longer with the company?

If the answer is:

“We don’t know.”

then the company has a serious operational dependency.

The Goal Is to Make Expertise Repeatable

A mature database organization does not try to eliminate expert knowledge.

It tries to turn expert knowledge into systems and processes that other people and machines can reliably use.

For example:

Instead of:

“Tomas knows how to recover this database.”

Create:

Documented recovery procedure

Then:

Instead of:

“Tomas performs the recovery.”

Create:

Automated recovery

Then:

Instead of:

“We hope recovery works.”

Create:

Regular recovery testing

The progression looks like this:

EXPERT KNOWLEDGE
↓
DOCUMENTATION
↓
STANDARD PROCEDURE
↓
AUTOMATION
↓
TESTING
↓
RELIABLE CAPABILITY

That is how organizations become less dependent on individual heroes.

A DBA Should Be Able to Take a Day Off

This sounds trivial.

It isn’t.

If a critical database cannot survive one senior DBA taking a week off, the architecture is not resilient enough.

The same principle applies to operations.

A good database environment should allow another qualified engineer to:

  • understand the architecture
  • identify the primary database
  • understand replication
  • check backups
  • perform standard recovery
  • follow escalation procedures
  • understand monitoring
  • safely execute documented operations

The system should not depend on one person’s memory.

The Bus Factor Is a Reliability Metric

Consider two teams.

Team A

Five DBAs.

But only one understands the production HA environment.

Bus factor: 1

Team B

Five DBAs.

Four can operate and recover the critical environment.

Bus factor: 4

The number of employees is the same.

The reliability is not.

This is why knowledge distribution should be treated as part of operational risk.

Documentation Should Answer “What Do I Do Next?”

Many database documents are written like architecture reports.

They explain:

  • server names
  • database versions
  • IP addresses
  • configuration parameters
  • storage layouts

Useful information.

But during an incident, the most important question is usually:

“What do I do next?”

A good operational document should answer that.

For example:

Primary database unavailable

1. Confirm the alert

Is the database actually unavailable?

2. Check the current primary

Is another node already serving the application?

3. Check replication

Is the standby current enough?

4. Check quorum

Can a safe failover decision be made?

5. Execute the approved recovery procedure

Do not improvise.

6. Validate the application

The database being online is not enough.

7. Record the incident

Capture what happened and what should change.

That is much more useful than a 50-page architecture document during an outage.

Runbooks Turn Stress Into Process

A runbook is not just documentation.

It is a way to reduce decision-making under pressure.

During a serious incident, cognitive load is high.

People make mistakes.

They forget steps.

They execute commands too quickly.

A good runbook provides structure.

For example:

ALERT
↓
CONFIRM
↓
ASSESS
↓
DECIDE
↓
RECOVER
↓
VALIDATE
↓
COMMUNICATE
↓
LEARN

The objective is not to remove human judgment.

It is to reserve human judgment for the decisions that actually require it.

Automation Should Follow Understanding

There is another common mistake.

A team discovers a repetitive operation and immediately automates it.

That can be dangerous.

If the process is poorly understood, automation simply makes the wrong process faster.

The better sequence is:

Understand → Document → Standardize → Automate → Test

For example:

If restarting a database is sometimes necessary, first understand:

  • why it needs restarting
  • what conditions require it
  • what can go wrong
  • what dependencies exist
  • how success is verified

Only then should the process be automated.

The Best Automation Includes Validation

One of the weakest forms of automation is:

Run command
↓
Success

Real operational automation should look more like:

Check preconditions
↓
Execute action
↓
Check database state
↓
Check replication
↓
Check application connectivity
↓
Check business transaction
↓
Report result

The system should not simply tell you:

“Command completed successfully.”

It should tell you:

“The service is actually healthy again.”

That is a much higher standard.

Incidents Should Make the System Better

Imagine an outage caused by replication failure.

A weak response is:

“We fixed replication.”

A stronger response asks:

Why did monitoring not detect the problem earlier?

Why did the replica fall behind?

Why was failover not triggered?

Why did the application not reconnect?

Why did the team need manual intervention?

Can the same failure happen again?

The incident is not finished when the database comes back.

It is finished when the organization has learned something from it.

The Right Metric Is Not “How Fast Did the DBA Fix It?”

Suppose a DBA restores a database in ten minutes.

That sounds excellent.

But what if the same problem happens every month?

Now compare that with a team that takes 30 minutes to resolve an incident once, then spends time eliminating the underlying cause.

The second team may look slower.

Over a year, it may be dramatically more reliable.

This is why reliability teams should measure more than MTTR.

Useful questions include:

  • How often does the problem happen?
  • Was it detected automatically?
  • Was recovery automated?
  • Did the runbook work?
  • Was customer impact reduced?
  • Did we eliminate the root cause?
  • Can the failure happen again?

Reliability Engineering Is About Removing Repeated Work

A DBA who performs the same recovery procedure ten times is not necessarily demonstrating productivity.

It may be demonstrating an automation opportunity.

Imagine:

Incident #1
↓
Manual recovery
↓
Document the process
↓
Incident #2
↓
Improve the procedure
↓
Automate
↓
Test
↓
Incident #3
↓
Automatic recovery

The objective is to make the third incident fundamentally different from the first.

That is engineering.

Don’t Automate the Hero — Replace the Heroic Moment

This is an important distinction.

The goal is not to replace DBAs.

The goal is to remove unnecessary emergency work from their jobs.

A senior DBA should spend more time on:

  • architecture
  • capacity planning
  • performance engineering
  • resilience
  • automation
  • disaster recovery
  • security
  • strategic improvements

and less time on:

  • restarting services manually
  • checking the same dashboards
  • copying the same commands
  • performing repetitive failovers
  • explaining the same incident every month

The value of an experienced DBA increases when their knowledge improves the system, not just the current incident.

What a Mature Database Team Looks Like

A mature team does not look like a group of people constantly fighting fires.

It looks surprisingly calm.

They know:

  • what is running
  • what is critical
  • what can fail
  • how failure is detected
  • how recovery works
  • who owns each decision
  • where the runbooks are
  • what is automated
  • what has been tested
  • what still represents risk

There will still be incidents.

But fewer of them become emergencies.

And fewer emergencies require heroics.

The Database Team Should Become Less Important During Incidents

This sounds strange.

But it is one of the strongest signs of maturity.

The more reliable the system becomes:

  • the more the platform detects problems automatically
  • the more recovery is automated
  • the more procedures are documented
  • the more knowledge is distributed
  • the more predictable incidents become

The DBA is still important.

But the DBA no longer has to be the person who manually saves everything.

Instead, they become the person who designed the system so that it can save itself safely.

Final Takeaway

A database team should not be measured by how many times its DBAs have rescued production.

It should be measured by how many situations no longer require rescue.

The real progression is:

Hero → Process → Automation → Reliability

The best DBA is not the person who knows the most emergency commands.

It is the person who turns that knowledge into a system that does not need emergency commands very often.

Because the ultimate goal of Database Reliability Engineering is not to create better heroes.

It is to create systems that need fewer heroes.

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.

The strongest DBA is not the one who saves the system every night. It is the one who makes sure the system doesn’t need saving.

Databázový tým by neměl být hrdina

V databázových operacích existuje nebezpečná kultura.

Objeví se problém v produkci.

Všichni volají DBA.

DBA se připojí na server, analyzuje situaci, najde problém, provede několik příkazů a službu obnoví.

Všichni si oddechnou.

DBA je hrdina.

A o několik týdnů později se stane úplně stejná věc.

Znovu volají stejného DBA.

Stejný tlak.

Stejná krizová situace.

Stejné řešení.

Může to vypadat jako skvělá práce databázového administrátora.

Není.

Pokud musí stejný člověk opakovaně zachraňovat systém, systém má problém se spolehlivostí.

Heroické operace nejsou spolehlivé operace

Velmi zkušený DBA dokáže někdy kompenzovat slabiny architektury.

Ví, který log zkontrolovat.

Pamatuje si neobvyklý parametr.

Ví, který proces lze restartovat.

Rozumí zvláštnímu chování aplikace.

Ví, který příkaz se během incidentu nikdy nesmí spustit.

Tyto zkušenosti jsou velmi cenné.

Ale je zde problém.

Co se stane, když je tento člověk:

  • na dovolené?
  • nemocný?
  • spí?
  • řeší jiný incident?
  • už ve firmě nepracuje?

Pokud je odpověď:

„Nevíme.“

pak má firma vážný provozní problém.

Cílem je udělat z expertizy opakovatelný proces

Vyspělá databázová organizace se nesnaží odstranit expertní znalosti.

Snaží se převést expertní znalosti do systémů a procesů, které dokážou spolehlivě používat další lidé i automatizace.

Například:

Místo:

„Tomas ví, jak tuto databázi obnovit.“

vytvoříme:

Dokumentovaný recovery postup.

Potom:

Místo:

„Tomas provádí recovery.“

vytvoříme:

Automatizovaný recovery proces.

A nakonec:

Místo:

„Doufáme, že recovery funguje.“

vytvoříme:

Pravidelné testování obnovy.

Celý vývoj tedy vypadá:

EXPERTNÍ ZNALOST
↓
DOKUMENTACE
↓
STANDARDNÍ POSTUP
↓
AUTOMATIZACE
↓
TESTOVÁNÍ
↓
SPOLEHLIVÁ SCHOPNOST

Takto se organizace stává méně závislou na jednotlivých hrdinech.

DBA by měl být schopný vzít si den volna

Zní to jako banalita.

Není.

Pokud kritická databáze nedokáže přežít týdenní nepřítomnost seniorního DBA, není architektura dostatečně odolná.

Stejný princip platí pro provoz.

Jiný kvalifikovaný inženýr by měl být schopen:

  • pochopit architekturu
  • identifikovat primární databázi
  • rozumět replikaci
  • zkontrolovat zálohy
  • provést standardní recovery
  • postupovat podle eskalačních pravidel
  • rozumět monitoringu
  • bezpečně provádět dokumentované operace

Systém by neměl záviset na paměti jednoho člověka.

Bus factor je metrika spolehlivosti

Představme si dva týmy.

Tým A

Pět DBA.

Ale pouze jeden rozumí produkčnímu HA prostředí.

Bus factor: 1

Tým B

Pět DBA.

Čtyři dokážou provozovat a obnovit kritické prostředí.

Bus factor: 4

Počet zaměstnanců je stejný.

Spolehlivost není.

Proto by distribuce znalostí měla být považována za součást provozního rizika.

Dokumentace musí odpovědět na otázku „Co mám udělat dál?“

Mnoho databázových dokumentů je napsáno jako architektonické reporty.

Popisují:

  • názvy serverů
  • verze databází
  • IP adresy
  • konfigurační parametry
  • storage layout

Užitečné informace.

Během incidentu je ale obvykle nejdůležitější otázka:

„Co mám udělat dál?“

Dobrá provozní dokumentace musí odpovědět právě na to.

Například:

Primární databáze není dostupná

1. Potvrďte alert

Je databáze skutečně nedostupná?

2. Zkontrolujte aktuální primary

Obsluhuje aplikaci už jiný node?

3. Zkontrolujte replikaci

Je standby dostatečně aktuální?

4. Zkontrolujte quorum

Lze bezpečně rozhodnout o failoveru?

5. Proveďte schválený recovery postup

Neimprovizujte.

6. Ověřte aplikaci

Nestačí, že databáze běží.

7. Zaznamenejte incident

Zapište, co se stalo a co je potřeba změnit.

To je během výpadku mnohem užitečnější než padesátistránkový architektonický dokument.

Runbook mění stres na proces

Runbook není jen dokumentace.

Je to způsob, jak snížit počet rozhodnutí, která musí člověk dělat pod tlakem.

Během vážného incidentu je kognitivní zátěž vysoká.

Lidé dělají chyby.

Zapomínají kroky.

Spouštějí příkazy příliš rychle.

Dobrý runbook poskytuje strukturu:

ALERT
↓
POTVRDIT
↓
VYHODNOTIT
↓
ROZHODNOUT
↓
OBNOVIT
↓
OVĚŘIT
↓
KOMUNIKOVAT
↓
POUČIT SE

Cílem není odstranit lidský úsudek.

Cílem je ponechat lidský úsudek pouze tam, kde je skutečně potřeba.

Automatizace musí následovat pochopení

Existuje další častá chyba.

Tým objeví opakující se operaci a okamžitě ji automatizuje.

To může být nebezpečné.

Pokud procesu dobře nerozumíme, automatizace pouze umožní provádět špatný proces rychleji.

Lepší postup je:

Pochopit → Dokumentovat → Standardizovat → Automatizovat → Testovat

Například:

Pokud je někdy nutné restartovat databázi, nejdříve zjistěte:

  • proč je restart nutný
  • za jakých podmínek se má provést
  • co se může pokazit
  • jaké existují závislosti
  • jak ověřit úspěšnost

Teprve potom má smysl proces automatizovat.

Dobrá automatizace zahrnuje i ověření výsledku

Jedna z nejslabších forem automatizace vypadá:

Spustit příkaz
↓
Úspěch

Skutečná provozní automatizace by měla vypadat spíše takto:

Kontrola podmínek
↓
Provedení akce
↓
Kontrola stavu databáze
↓
Kontrola replikace
↓
Kontrola připojení aplikace
↓
Kontrola business transakce
↓
Výsledek

Systém by neměl pouze říct:

„Příkaz byl úspěšně dokončen.“

Měl by říct:

„Služba je skutečně opět zdravá.“

To je mnohem vyšší standard.

Incidenty musí systém zlepšovat

Představme si incident způsobený selháním replikace.

Slabá reakce:

„Opravili jsme replikaci.“

Silnější přístup se ptá:

Proč monitoring problém nezachytil dříve?

Proč se replika začala opožďovat?

Proč se nespustil failover?

Proč se aplikace nepřipojila znovu?

Proč byl nutný manuální zásah?

Může se stejná chyba zopakovat?

Incident nekončí ve chvíli, kdy databáze znovu běží.

Končí až ve chvíli, kdy se organizace z incidentu něco naučila.

Správná metrika není „Jak rychle to DBA opravil?“

Představme si, že DBA obnoví databázi za deset minut.

Zní to skvěle.

Ale co když se stejný problém opakuje každý měsíc?

Nyní to porovnejme s týmem, kterému první incident trvá 30 minut, ale následně odstraní jeho skutečnou příčinu.

Druhý tým může vypadat pomaleji.

Za celý rok ale může být dramaticky spolehlivější.

Proto by reliability tým neměl měřit pouze MTTR.

Měl by se ptát také:

  • Jak často se problém opakuje?
  • Byl automaticky detekován?
  • Byla obnova automatizovaná?
  • Fungoval runbook?
  • Byl dopad na zákazníky menší?
  • Odstranili jsme root cause?
  • Může se problém zopakovat?

Reliability Engineering odstraňuje opakující se práci

DBA, který desetkrát provede stejný recovery postup, nemusí být nutně produktivní.

Možná pouze ukazuje příležitost k automatizaci.

Například:

Incident č. 1
↓
Manuální recovery
↓
Dokumentace procesu
↓
Incident č. 2
↓
Vylepšení postupu
↓
Automatizace
↓
Testování
↓
Incident č. 3
↓
Automatická obnova

Cílem je, aby třetí incident byl zásadně jiný než první.

To je engineering.

Neautomatizujte hrdinu — odstraňte potřebu hrdinského zásahu

To je důležitý rozdíl.

Cílem není nahradit DBA.

Cílem je odstranit z jeho práce zbytečné krizové operace.

Seniorní DBA by měl trávit více času na:

  • architektuře
  • capacity planningu
  • performance engineeringu
  • odolnosti
  • automatizaci
  • disaster recovery
  • bezpečnosti
  • strategických zlepšeních

a méně času na:

  • manuální restartování služeb
  • kontrolu stejných dashboardů
  • kopírování stejných příkazů
  • opakované manuální failovery
  • vysvětlování stejného incidentu každý měsíc

Hodnota zkušeného DBA roste ve chvíli, kdy jeho znalosti zlepšují celý systém, nejen aktuální incident.

Jak vypadá vyspělý databázový tým?

Vyspělý tým nevypadá jako skupina lidí, která neustále hasí požáry.

Naopak působí překvapivě klidně.

Ví:

  • co běží
  • co je kritické
  • co může selhat
  • jak se selhání detekuje
  • jak funguje recovery
  • kdo je vlastníkem jednotlivých rozhodnutí
  • kde jsou runbooky
  • co je automatizované
  • co bylo otestováno
  • co stále představuje riziko

Incidenty budou stále existovat.

Ale méně z nich se stane krizí.

A méně krizí bude vyžadovat hrdinské zásahy.

Databázový tým by měl být během incidentu méně důležitý

Zní to zvláštně.

Ale je to jeden z nejsilnějších znaků vyspělosti.

Čím spolehlivější je systém:

  • tím více problémů detekuje automaticky
  • tím více recovery je automatizováno
  • tím více postupů je zdokumentováno
  • tím více znalostí je distribuováno
  • tím předvídatelnější jsou incidenty

DBA je stále důležitý.

Ale už nemusí být člověkem, který ručně zachraňuje úplně všechno.

Místo toho je člověkem, který navrhl systém tak, aby se dokázal bezpečně zachránit sám.

Závěr

Databázový tým by neměl být hodnocen podle toho, kolikrát jeho DBA zachránili produkci.

Měl by být hodnocen podle toho, kolik situací už záchranu nepotřebuje.

Skutečný vývoj vypadá:

Hrdina → Proces → Automatizace → Spolehlivost

Nejlepší DBA není člověk, který zná nejvíce krizových příkazů.

Je to člověk, který dokáže tyto znalosti převést do systému, který krizové příkazy potřebuje jen velmi zřídka.

Protože skutečným cílem Database Reliability Engineering není vytvářet lepší hrdiny.

Je jím vytvářet systémy, které potřebují méně hrdinů.

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.

Nejsilnější DBA není ten, kdo každou noc zachraňuje systém. Je to ten, kdo zajistí, aby systém záchranu vůbec nepotřeboval



Komentáře